Proposal talk:3D model repository links

Height, width and length

About the tags height width and length: -karlos- (talk) 19:24, 30 June 2017 (UTC)

• Are this tags to be meaned before and not after applaying direction=*?
• The default unit is Meter and they are NOT scale faktors? The models proportions will change!
• Should we also have scale tree factors?
• Please at last one tag scale=* for all 3 dimentions and proporional size change

-karlos- (talk) 19:24, 30 June 2017 (UTC)

Hi, thank you for your interest in the model repository. I've split the question in two parts, hope you don't mind!

• The width/height/length tags have the same semantics as they do normally (they need to, as using the linked model is optional for applications). So e.g. the width of a bench is relative to the bench's direction, it's not fixed to the global coordinate axes.
• These are existing tags with a default unit of meters, so yes. And they are indeed not scale factors. If you're trying to use a model of a two-seater bench to represent a four-seater bench, then that will inevitably lead to distortions. I feel that this would be an error by the mapper who linked the wrong model, though.
• I'm trying to avoid tags that only make sense in the context of the repository as much as possible, which is why I prefer values that have a meaning in the real world ("height" and so on instead of "scale"). But as I said, a model should only be linked if it matches the real-world object. If applying the model's real measurements would lead to noticable distortions, then the model should probably not be linked in the first place.

But this is just a draft, so I'm happy to discuss this if you disagree! --Tordanik 11:02, 1 July 2017 (UTC)

Ah, I didn't think of benches but uniq famous Buildings. And they should be stored, already proper aligned and don’t need this tags, may be except direction. -karlos- (talk) 17:30, 1 July 2017 (UTC)

I agree that unique objects, such as famous buildings, should already be properly aligned, scaled, and ideally also properly rotated in the model. These tags are indeed intended for generic objects. --Tordanik 21:10, 1 July 2017 (UTC)

This is something you may ask for but you can't expect it. Especially complex objects might be modelled in some axis aligned way and afterwards never rotated to correct direction. If then placement information should be present in model repository, I'm fine with that. It would solve the point and also help other databases handling it. --OSMBuildings 2017-10-27T01:07:00Z

Referring ID

I consider referring just the model ID is not a good idea. I'd recommend either globally unique id's (GUID) or something prefixed with a platform identifier. I.e. key=3dmr:42 Otherwise we would exclude any other platform. --OSMBuildings 2017-10-27T01:13:00Z

My idea was, to use readable meaningfull strings to identify diffent repository servers and also models like: model3d=3dmr:london_eye or omb:bench_wood3 -karlos- (talk) 19:27, 28 February 2018 (UTC)

Model replacing more than one building

Many times, a model replaces more than one building (i.E. the Atomium). The model tags may be placed to a well positions node. How to tag the replaced buildings without seein many models? -karlos- (talk) 19:24, 30 June 2017 (UTC)

Replacing multiple elements that are not in a hierarchy (i.e. not building parts of a building, members of a site relation, etc.) is hopefully a comparatively rare case. I'm not sure why the Atomium would be mapped as multiple buildings rather than a single building with parts, for example. But in the cases where that doesn't work, we probably need to use a relation. --Tordanik 11:02, 1 July 2017 (UTC)

The Atomium is an unusual example, but still to be solved. There is a relation 1243821, but only for the metal part, not visible on the 2D map. The visible ground buildings (442046313 388842414 442046315 442102754) should be hidden to. A simple way would be tagging “3dmr” “replaced” or just “yes”. A reference to the model would be better. Then we would have multible references but only one model must be placed. We could use a prefix “replaced:<model-id>" -karlos- (talk) 18:36, 30 December 2017 (UTC)

Many unique objects replace multi elements: Berlin Alex, Dubai Arabok tornya Atomium EifelTower. So I added a value 'yes' for near by replaced elements. -karlos- (talk) 19:27, 28 February 2018 (UTC)

I don't think "yes" works because data consumers should have the option of using only some, rather than all, linked models. The value "yes" does not tell you which model the given element is affected by. --Tordanik 22:42, 8 March 2018 (UTC)

Do we agree to need a solution. I am open vor any better solution. The same ID with a prefix? -karlos- (talk) 15:40, 9 March 2018 (UTC)

Same ID + prefix would be an improvement compared to 'yes'. However, I still wonder whether the existing solutions aren't already sufficient, so I'd like to discuss that first. For example, there's the documented possibility of adding all the replaced elements to a relation tagged with 3dmr=*. In my opinion, that's an acceptable solution as long as it's rare. So I guess the question is if the set of elements is usually specific to the model repository. I would imagine that OSM could use a relation (or other element) representing "the Eiffel tower" or "the Atomium" anyway? --Tordanik 23:38, 13 March 2018 (UTC)

Even building:part(s) are often not members of a relation. So the description of the tag “3d_model” should explicitly demand a relation in this case. -karlos- (talk) 17:30, 1 July 2017 (UTC)

You don't need a relation to find out which building:part(s) belong to a building, and therefore to avoid rendering them. Like with normal 3D buildings, want to avoid relations unless they are needed. --Tordanik 21:08, 1 July 2017 (UTC)

Yes. Also my renderer is just to stupid coded to do it :-) -karlos- (talk) 19:27, 28 February 2018 (UTC)

Addend links ot 3d render examples. We may do more tests. -karlos- (talk) 19:27, 28 February 2018 (UTC)