3D tagging on general objects

This should be a discussion based on my experiences in micromapping here in Rostock. It’s a second part of my post on Simple 3D buildings, but more focused on 3D tagging in general.

To make it short, it’s already now really impressive, on how much reality you can cover with OSM I strongly belief, this would make a difference of “feeling home” in all 3D stuff that is generate with OSM.

But there are still a few questions I ask myself while tagging:
Need we a general agreement (or just a list as here), of which street furnitures etc. all tools should support (and visualise the same way).
Do we need an general “Simple 3D features” minimal schema, that every application understands and that allows general customisations to every kind of objects? e.g. colour, material, width, height, …

Beside aspects that have currently no stable tags, there are existing object classes, that could need some more work:
Ways: Stitching roads, ways and pedestrian areas is quit hard. Any way we can collect the knowledge and/or adding some more deeph?
Steps: Currently we lack of a DEM, so steps seem to be the only things with a native 3rd dimension. Any ideas here?

To present street furnitures we need list of important poi. For all items in list we need:

  • tag filter
  • 3d model
  • default height
    But it could be some problems with creating low-poly 3d models…

I do not think there is an urgent need of standardization - or did you notice incompatible differences in how the tools interpret street furniture tagging?

Are we talking about POI models that are hand-made and imported into the program, or models that are generated in program logic from parameters?

For imported models, a scale factor (probably height=) relative to the default height, a rotation (probably direction=) and a texture based on material/colour are all that’s needed or even possible.

Generated models can represent more details and may be a bit more complex, however: A bench may use width/seats and height independently, as well as backrest=yes/no, and of course direction, material, colour. A lamp may use everything listed in the proposal. And so on.

In simplest scenario we can use many object as static 3d models with only two parameters like height and direction. Of course generated models are more power-full but each of them we need to be implement individually. And this is time consuming.

Static models looks nice and can be made and maintain by peoples who can’t code.

Some example:

All configuration can be stored in xml like this [1]

[1] - https://github.com/kendzi/kendzi3d/blob/master/kendzi.josm.plugin3d/models/pointModelLayer.xml

I think you are right that static models should be an option. I will probably aim for a setup where the user can pick any built-in model from the code or model file through the config file.