User talk:Tordanik/Proposed features/3D model repository links
Height, width and length
- 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
- 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)
- 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
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
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)
- 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)