Request for Feedback on 3D Model Repository API + content guidelines

[Tordanik (Tobias Knerr)]

Thank you, your post touches exactly the kind of topics I was hoping to discuss.

@karlos

• We should add the “size” of the file in the file data api, so an app can decide not to show high res models.

Exposing more statistics about the model through the API is a good idea. We’ll have to see how easy it is to implement, but it would enable data consumers to automatically decide which models to include in their rendering.

@karlos

Guidelines, my spontaneous thoughts:

• The size should be im metric meters. But we should add the option to set a parameter “scale" factor while uploading.
• It would be nice, if the orientation is as in the real world. That’s rater not the case, so we need a parameter to set a direction offset while uploading.
• A glb fiel has a virtual zero point (3D) It should be at ground level and at that geographical position, the node in OSM is placed to. We could consider to support north/east offset parameters in meters.
  […]

I do agree with those conventions. However, I would personally go further and require models to follow the conventions, rather than permit non-standard scale/orientation/offset. (Or if we do offer such fields during upload, use that information to automatically fix the model before it is saved in the repository, e.g. by rotating it and scaling it to the correct size.)

To give people a better chance to get these conventions right, we should make things such as scale and direction visible during upload.

@karlos

For model instances, the tag may also contain the parameters. I.e.:
“3dmr”=“2;lat=-12.34;lon=45.67;dir=180;scale=1.0;north=0;east=0”

I’d rather not ask mappers to add this kind of data into a single tag value. As far as I can tell, all parameters besides 3DMR ID can be derived from established OSM tags such as direction=* to describe an object’s orientation. For scale, tags such as height=* can be used. (Although, as I said before, I would prefer if the model file is correctly scaled in the first place.) Are there any required parameters which we cannot get from the geometry and tags of the OSM element?

@karlos

I propose to have tags like “3dmr=" and “3dmr=yes” or “replaced”. This should work on a relation to of course.

This is a tricky topic. We do need to include the ID of the model that a feature gets replaced by. After all, a data consumer will most likely not use every model, and if they don’t use the model which replaces that particular OSM object, they will want to render the OSM object. Ideally, this would be rarely because the model should be for exactly one OSM element, but I can see that this is not a realistic expectation in all cases.

@karlos

I see 3dmr=31 using non Engish categories and tags. I would not support this.

I’m inclined to agree. In general, I do believe we will have to individually look at the existing models and clean them up in various ways.

@karlos

Some models are unique like the Eiffel Tower. The position parameters aren in 3dmr.

This if from the other thread, but I’d still like to ask you about it. My current thinking would be to use the same mechanism to place models no matter whether they are used only once or more than once. That is, the Eiffel Tower would have a 3dmr=* just like more commonplace objects, and that’s how you know where to place its model. What’s your reason for treating it differently?