OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

Announcement

A fix has been applied to the login system for the forums - if you have trouble logging in please contact support@openstreetmap.org with both your forum username and your OpenStreetMap username so we can make sure your accounts are properly linked.

#26 2014-02-22 17:30:52

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,114
Website

Re: osm-3d and (Google Earth) geomodeling

Klamann, I generally agree with what you described, so I will only pick out one topic to discuss: Linking the model database with the OSM objects.

Klamann wrote:

No 3D model will be visible in the map until it's counterpart in the openstreetmap gets tagged with a reference to the object. This way, the 3D model and possible 3D structures generated from osm polygons will not be in conflict.
(...)
The tag can be used on a single polygon or on a relation that combines multiple elements, so all of them get replaced by one 3D model (e.g. a detailed 3d model of a castle with a park should replace all building parts, walls, trees, fountains, etc.)

One issue is that the same selection of models is not ideal for every application. Say, one application generates only static images and would profit from a nice 3D model of a fountain "frozen" in time, but another application has nice animated fountains and would rather not have the fountain be part of the 3D model. The same goes for flagpoles with waving flags, trees being affected by season and so on. Inserting a static model might actually decrease the visual quality if we do not handle this well.

Another challenge is when you try to go beyond displaying the scene and want to e.g. see a routing result displayed on your 3D map or have virtual cars driving around. That routing will happen on OSM data, so we need very precise matching between the two data sets to avoid cars diving into or hovering above a hand-modelled bridge, or a route going through solid walls instead of the gates 5 meters next to them. I do not think that a bounding volume alone can achieve this. Ultimately, I expect that we need some ability do create a 1:1 relationship between an OSM node and a point in the model.

That's not all there is to this - you described a few challenges yourself, such as general-purpose models like mailboxes, and there are likely many more that we will only realise over time. Due to all this, my personal preference would be to start out without the ability for users to create an explicit link between OSM and the model repository. Instead, I would leave it to the application developers to figure out a way of utilizing the 3D repository for their purposes, and explicitly select the models they want to use. Doing it this way allows experimenting with different approaches to the positioning problem in parallel. Once a solution is found, it can be used as the basis of a community-driven process.

Offline

#27 2014-02-22 20:23:16

Aerilius
Member
Registered: 2014-01-29
Posts: 10

Re: osm-3d and (Google Earth) geomodeling

We have already so many different branching off thoughts to which everyone  has something to say that it is hard to keep track of each subtopic. Maybe it would be good to start splitting up into new threads or in another discussion format?


As for the metadata saved in the database:
This is something that partly depends on the chosen file format. On the SketchUp/Google Earth side we had already a lot of experiences.

  • minlat, maxlat, minlon, maxlon: I would rather favor to reference one single point (lat, lon, elev.) in the real world to one single point in the model (this is straight-forward because every model has an origin at (0,0,0)). A single reference point is more reliable (and persistent when the model is enhanced) than a bounding box, also a boundingbox would need to be calculated first.

  • scale and rotation would better be saved separately, either as complete transformation matrix, or as (heading, tilt, roll) and (xscale, yscale, zscale).

  • as for the elevation: In Google Earth you could turn off the terrain and absolutely positioned models were flying in the air. Models should therefore be relatively positioned to the terrain (elevation - altitude). But this is not without issues: In early times the geo-positioning workflow had inconsistencies between SketchUp and GE, resulting in models that were suddenly either sunken below terrain or flying in the air.

Models would best be created to scale if the file format supports specific real-world units. However we need to take care of some file formats that use arbitrary units and unusual axis orientations. Only then the uploader must to specify a scale. When I tried to upload to openbuildingmodels.org, it ignored the scale of my model and I had to scale it by hand (which makes it very unprecise and distorts the aspect ratio).


As for collision detection in navigation systems (and other applications):

  • There are different modeling styles: A surface usually has zero thickness. Because of that, in solid modeling every volume would ideally be completely enclosed by faces. This is of course inefficient for smaller object. Google Earth modelers developed over time a modeling style that makes extensive use of single faces with png textures (eg. a rectangle with a texture of an arc). This was efficient to get a high degree of detail with a low polycount and low file size but it makes the model unusable if not rendered with textures. This could also cause a challenge for collision detection.

  • What belongs to a model? The Google Guides then came to the conclusion that models should only include a distinct, connected and permanent structure. Street lamps would have to be distinct models, as well as trees and plants. This allowed also more flexibility in the review process (eg. while a building perfectly met the quality criteria, bad plants models often degraded the model).

  • What belongs to terrain? Does a wall belong into the model or into the terrain, and what to do if the terrain data is too low detailed? Often we added "artificial terrain" to the model, but it looked inconsistent once the satellite image was updated and didn't blend anymore with the terrain. Google did a huge effort to update terrain even in customized small patches. What happens with terrain overhangs (rocks, caverns)? This was another reason for Google to move from elevation maps to 3d meshes.

  • bridges: I saw OSM has already efforts to make navigation systems work with bridges (that have sevaral levels: a car might cross and a ship passes through). We would need to take care that our solution works well with the rest of OSM.

I would say navigation systems should follow basic OSM data (and ignore models), and models must be made to fit OSM data. In the modeling process, we would have to correct missing or unprecise OSM data.


Another issue (that Tordanik mentioned) is duplicate detection. How does an application developer know which models describe the same entity, so that he selects only one model from the database? What if a model describes a compound entity, where as other models describe only parts of that entity?
3D Warehouse has at least 100 Eiffel towers, and Google's reviewers had to take care only to accept one. Google used automatic checks as prefiltering, but all reviews were done by specially trained humans. The review pipeline was much more complex and sophsticated than this simplified graphic shows (I could tell more on FOSSGIS).

If we don't want hard-linking (OSM entity → model id, model → OSM entity id), we would at least some sort of soft-linking. For example somehow tagging models so that it is possible to determine which OSM entities they describe (the tags could automatically be suggested/added in the upload process).

Offline

#28 2014-03-06 22:54:34

Aerilius
Member
Registered: 2014-01-29
Posts: 10

Re: osm-3d and (Google Earth) geomodeling

Update:
Last week, Google 3D Warehouse was replaced by a new developed SketchUp 3D Warehouse. Some users are upset or confused by the new format, and also because social features have not been added yet (and the Google Earth related features won't be added back).
Since it also has no messaging system, I had to use the last chance to contact as many modelers as possible over the old messaging system to tell them about this project. Communication is otherwise more difficult now.

What is also noteworthy is that it comes with new Terms of Use. They are in principal not different than under Google but much clearer expressed. However there is one new section that caught my eye "Google Geolocated Models". I asked a responsible employee of 3D Warehouse and he told me that this section relates to models created by Google employees (so Google is the owner). These models are Google property and have special restriction (no use in other mapping services). This section does not relate to models created by arbitrary users no matter whether Google software were used.
Modelers are still the owners of their models and thus have the right to do what ever they want including uploading them personally to another repository. Third persons (not owner) who download models are however not allowed to add them to another repository.

Offline

#29 2014-03-16 16:54:03

yopaseopor
Member
Registered: 2013-08-07
Posts: 2

Re: osm-3d and (Google Earth) geomodeling

marek kleciak wrote:

Hello yopaseopor!

Welcome and thank you in advance! It would be great to have such 3D library from you!
We need low poly models, or 2 versions of models:
1. Low poly
2. Nice look.

I have some experience with this things, but unfortunately less time sad
If you wish, please contact me: http://wiki.openstreetmap.org/wiki/User:Marek_kleciak

Hi!

Regarding to my previous reply...

The models of the 3DWarehouse were not mine. I only join it in a gallery.And for the traffic signs models...

I have made a repository on Github (https://github.com/yopaseopor/traffic_signs) for the traffic_signs models for kendzi 3d JOSM plugin.I don't know such thing of programming and modelling but these models can be an idea of what a little model for a traffic sign should be.You can see it "in action" via JOSM Kendzi3D plugin in some locations like http://www.openstreetmap.org/#map=18/41.23285/1.66713

To make it works you have to add one preference line in advanced mode:

<list key='kendzi3d.models_library.resources_urls'>
    <entry value='plugin:/models/modelsLibraryInternalLayer.xml'/>
    <entry value='plugin:/models/modelsLibraryLayer.xml'/>
    <entry value='http://www.catmidia.cat/coses/2a_etapa/altres/trafficSignsLibraryInternalLayer.xml'/>
    <entry value='http://www.catmidia.cat/coses/2a_etapa/altres/ES_words_library.xml'/>
    <entry value='http://www.catmidia.cat/coses/2a_etapa/altres/ES_distances.xml'/>
    <entry value='http://www.catmidia.cat/coses/2a_etapa/altres/ES_milestones.xml'/>
    <entry value='http://www.catmidia.cat/coses/2a_etapa/altres/ES_numbers.xml'/>
    <entry value='http://www.catmidia.cat/coses/2a_etapa/altres/ES_references.xml'/>
    <entry value='http://www.catmidia.cat/coses/2a_etapa/altres/ES_signs_symbols.xml'/>
</list>

I hope they will be useful.
yopaseopor

Offline

#30 2014-03-16 18:03:36

marek kleciak
Member
Registered: 2010-10-11
Posts: 7,990

Re: osm-3d and (Google Earth) geomodeling

Hello yopaseopor!

Thanks a lot! Good and helpful job!
Could you render previev pictures for each 3d model?
It would be very helpful.

Best regards,
Marek

Offline

#31 2014-03-16 22:09:47

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,114
Website

Re: osm-3d and (Google Earth) geomodeling

To everyone who will visit the FOSSGIS in Berlin next week: I asked the organizers for space to run a "birds of a feather" meeting where all FOSSGIS visitors interested in a 3D Model Repository can meet. This will likely take place on Thursday, 17:45 (after the talks have ended for the day). As far as I know, the final information regarding when and where BOFs will take place will be available at the Welcome Desk of the conference.

I'm looking forward to seeing some of you at FOSSGIS. smile

Offline

Board footer

Powered by FluxBB