3D Development/Modelling
Contents |
How can we provide more detailed models to OSM?
Currently we can offer a wikipedia:level of detail grade 1 (LOD1) that extrudes 2D shapes to simple block models. LOD2 includes a detailed shape of the outer elements of a object, LOD3 is a perfect shape even with textures.
Objects are buildings but of course every other POI (monuments,....). This might cover procedural models, too (e.g. repeating/adapting a road segment or a tree to become a forest).
Feel free to expand the page. For personal comments let's use the talk page, please!
Internal Tagging
Most simple solution to tag and modell complex figures using OSM primitives as ways and special attributes that indicate
- starting from ground
- height
Some suggested but not widely used tags can indicate:
- type of building
- roof type
- colours
Pros:
- software tools already exist, mappers are familar with this process
Cons:
- might result in complex splitted up 2D shapes and a huge amount of tags per object
- problems with other renderers
- mappers might get annoyed
- no native approach on model in 3D
- no generalisation possible (a normal block in east Germany looks like this...)
- very limited details due to shape->extrude approach
- nothing keeps the parts of a model together
- tagging mostly for buildings won't affect to general POI models
- no direct storage of textures
- get heavy for OSM infrastructure
New API Revision
The OSM API is changing over time, we might introduce a new feature to API 0.7:
- The 3D features could be hidden from users in "2D mode"
Pros:
- Deeply integrated with OSM, no other dependant tool
- can start from scratch -> define tools, formats, APIs on the usecase
- can beneficiate of the OSM knowledge / infrastructure
Cons
- need lot of work, in server & client
- can be havy for OSM infrastructure?
- very confusing structures in the editors
External DB
This might be an external related project storing the models.
Pros:
- user can contribute without knowledge on OSM in general
- can start from scratch -> define tools, formats, APIs on the usecase
- can be used by others beside OSM
Cons
- a lot of work todo (sep. platform)
spatial Organisation
To deal with this mass of datas, we need to use a vector tile approach.
Data format
Storing/Exchanging 3D Models needs a format with the following requirements:
- able to store 3D geometry, textures, lights
This would be great, too:
- altering parameters (e.g. switch light on at nights) and model (e.g. random small houses for allotments)
- general coordinatesystem (indicating directions to next road, footway, coast,...)
- VRML:outdated
- WebGL: just in browser rendering
- X3D: W3C has a SIG working on a 3D earth [1]
- Collada:
- CityGML:
- http://code.kuederle.com/3dformats Good compare
Referencing
To link 3D models against OSM datas can be done in 2 directions:
OSM->3D model:
- (useful for one model per POI)
- Model can contain OSM ID of the object
- position
- shapes might get extra infos (center node)
- alignment
- base 3D vertices can contain OSM IDs of the objects nodes to align model
3D model->OSM:
- (useful for general models that apply on a lot of OSM objects)
- matching using different criterias
- tagging scheme (e.g. wind power generators)
- region (e.g. a German telephon box looks like)
- position
- calculation of centers on shapes might get different results
- alignment
- additional informations of directions might be nescessary (e.g. nearest road)
Modelling tools
existing OSM editors
- might add more dependencies
- has to be developed for every single editor
libs:
- https://launchpad.net/stereophoto
- http://www.ossim.org
- http://opencv.willowgarage.com
- http://pointclouds.org/
external
- Blender3D, Wings3D, PovRay+Morray
- Photogrammetry
Referencing
This seem to be the most important part, how can we design the workflow as pointed out above to link models against geopositions?
New Models
- Select objects in JOSM
- Export to COLLADA with 2D shapes and KML with geocontext
- Open Collada in you fav 3D Editor
- Upload both files to our webpage
