osm-3d and (Google Earth) geomodeling

Hi,
I will definitely provide all of my own models for free use if it can help make osm 3d happen (some are already to openbuildingmodels [203], [207], [209]).

I also plan to invite as many modelers as possible (I closely know the top ~80, and then there were 1000+ modelers whose work I know by sight). However there is the before mentioned chicken-egg problem: Now that so much time passed, I am not sure how many modelers I can reach and persuade. If we imagine Google would revive geomodeling, everyone would hear about it and modelers would not hesitate because of Google’s big brand and the familiar upload process. A comparable infrastructure does not yet exist for osm, so what could modelers do now (and see results?).
I’m thinking about an interim solution/activity, like adding 2d building foot prints to osm, generated from our 3d models.

About Collada: SketchUp say they have the industry’s most complete implementation (93+%) and considering that, the intercompatibility with other applications is really bad. There are even issues when re-importing into SketchUp (“projected textures”). And when importing into another application I have fear it does not support those advanced Collada features that SketchUp’s Collada makes use of.
Obj is (too?) simple, and it seems to support geometry groups (I don’t know about repeated geometry/components).

I did a collada importer to directX once and i will never go into this madness anymore i totally agree with Kendzi on this point :wink:
You can add to the list that .dae file are huge even for very simple geometries (that’s why we implemented a compressed format on F4Map)

Hi,

this is great news! I had a look at your warehouse site and this would be a huge start already!

I’d say this is enough encouragement to go and start a model site for OSM (and the like) for me/us.

However, there’s still the format problem and it’s not a good sign that 2 developers had issues with Collada and even you as a modeller had found issues. And I agree with Kendzi that metadata could also be simply put into a zip file. This way one could even distribute textures via a single file. Again, OBJ is simple, yes. But it lacks multitexturing and much of the lighting stuff. Aerillus, you used SketchUp for all your models, right? And that’s the main application other modellers use, too? For the 8.0 version that I managed to install via wine the only export format was kmz and dae. Do current version support more export formats out of the box in the free version? I’d guess this is an important point in decission making.

Before your objections, I would have chosen Collada. Now I’m not sure about the format any longer … more input and opinion welcome :slight_smile:

Aerilius:

You seem to be from Germany? Would you like to come to FOSSGIS conference in Berlin 19.03-22.03 to discuss the issue in person?

As far as I know, !i!, Tordanik and Peda will be there. I hope to be there as well.

Another issue is with modelling software.

Free version of Sketchup can’t be used for commercial work. Here is an excerpt from the license of the free version of Sketchup:

So I switched to Blender, though it definitely requires more time to learn than Sketchup.
Blender is more powerful tool than Sketchup. It’s rather a 3D platform than a software. It includes advanced modelling, rendering and animation parts. Everything can accessed via Python bindings.

At FOSSGIS-2014 I hope to talk how to georeference a 3D model with help of Blender and OpenStreetMap data.

Regarding formats.

Collada should be used only to exchange 3D models. It shouldn’t be used for production. There is some analogy with OSM file format. It’s normally used to excange data. Each OSM application uses optimized binary format for OSM data.

In my opinion pycollada library works quite reliably. It’s used in Blender to import/export COLLADA files.

I created a simple COLLADA->POV-Ray converter with the help of pycollada.

I’d suggest to have GUI for open 3D model repository similar to Sketchup 3D Warehouse.

Some time ago I wrote a simple application to explore a 3D model via prerendered sprites in the same way it’s done in Sketchup 3D Warehouse. Check a demo here.

I can contribute to a plugin for Blender that loads a model from and uploads it to the open 3D model repository.

SketchUp’s license aims to prevent professional architects to earn their living without paying the SketchUp developers to earn their living. Hobbyists can still use it for ever for free (that was probably a condition by Google). This is important to know, but I’m not sure how this could be a problem for open building models that are distributed under a free license. Even if distributed under public domain and someone else using it for commercial products (navigation software), I don’t think it would conflict with the license of the software.
I’d like if SketchUp itself was open source (or a comparable alternative existed), but we would probably better go the way of the least effort, use existing wide-spread tools/editors and concentrate on adding the missing infrastructure (repository and viewer).

I think it’s a weak point of Sketchup. Someone creates a model with a free version of Sketchup and publishes it in the repository with a free license. Then someone uses the model for commercial work. In my opinion this contradict to the license of the free version of Sketchup.

As it was mentioned already a much more powerful and open source alternative to Sketchup is Blender.

I also agree that it’s a good idea to distinguish between source file formats (ie. .blend, .skp, etc.) and the target file format that would be used in the repository, and to be displayed in osm. (Another question would be, is it worth to keep a copy of the source file in the repo, for easier editing?)

I could contribute a GUI for uploading from SketchUp. I have a couple of plugins for SketchUp, and currently I’m working on a plugin using OpenLayers and OverPass/Nominatim APIs.

I’ve been thinking to come to FOSSGIS, though I’m very new to this (and geomodeling or GIS is for me rather interest than my profession). Even better when I know some people who go there!

The turntable (or swivel view) is great! I’m not able to tell anything specific about the future of 3dwh, but technology doesn’t stop there. That’s why I mentioned webgl somewhere above. WebGL is quite universal and cross-platform (without need for Java or any plugins), so once there exists an OSM WebGL viewer, it could be easily included in a future open buildings repository.

Yes, we’ll be there - and it would be cool to meet you at FOSSGIS. Almost all members of the OSM community are hobbyists, including many of the speakers at the conference.

Regarding the different preferences for modelling software expressed here, it would be good if we could pick a format that works well for both Sketchup and Blender users. Blender, due to being open source and working natively on Linux, is a natural fit for an open community, but it is also hard to use. With Blender being our “JOSM”, it would be great to have Sketchup as our “Potlatch” - a simple editor usable by everyone. The license issue sounds unpleasant, but I wouldn’t form a conclusion without looking at it more closely.

Hi!

I’m presenting me.

I’m yopaseopor, a catalan guy (yes, this part of Spain called Barcelona in which political things are being speed up about independence)
I am a user of OSM, a little formerly contributor of 3Dwarehouse (in other projects find the EuroMediCat galleries http://sketchup.google.com/3dwarehouse/search?q=euromedicat&styp=c&scoring=t&btnG=Buscar&reps=1 ) and now a OSM contributor for my zone (basically “Catalonian countries”).
But one of my other hobbies is traffic signs.If your GPS says you maxspeed of the way, imagine if it says all the traffic signs of the road, street (if you watch stop,give_way,and traffic_lights why not the other about 300,a very concrete state of the way can be used to assist semiautomatic driving?).
My goal is to spread the use and make bigger Roadsigns JOSM pluging here in Catalonia and Spain with a preset for the plugin, a style to JOSM, a preset for tag intensively one way and also add the traffic signs…and a little port to make the traffic signs will be available to Kendzi 3D plugin (it was the only existent solution that shows me a little concrete model visible and available for all OSM via JOSM).
Instead I don’t know such thing about programming and 3D design, I want to next generation of 3D models will make able to include in OSM things as little as a concrete traffic sign in a concrete node in a concrete place with a concrete orientation, lamps, trees, etc. And also I want to make disposable to all the community and be able to upload all my work I have done for Kendzi3D so I hope contribute to this OSM Warehouse will be easier as editing the maps in OSM.

Thank you
yopaseopor.blogspot.com
PD: sorry for my bad english :stuck_out_tongue:

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 :frowning:
If you wish, please contact me: http://wiki.openstreetmap.org/wiki/User:Marek_kleciak

Hi there, I’d like to join the discussion because I think it would be awesome to have high-quality 3D models in the openstreetmap, but I’m not convinced that s3db and comparable attempts that try to introduce 3D capabilities in the existing osm database are the right tools for complex buildings/structures (for most of the buildings out there, s3db is already fine in it’s current form, but it will never work for the really interesting ones ;)).

So here’s my idea how to add 3D objects to the openstreetmap:

  • There will be a separate database that stores all metadata about a 3D scene that is required to display it on the map. Required fields are:
    [list=*]

  • id (String): chosen by the contributor, but must be unique

  • minlat, maxlat, minlon, maxlon (decimal): defines location and extent of the whole scene

  • minheight, maxheight (decimal): lowest and highest point of the scene, relative to the ground level at (minlat, minlon)

  • model: the actual 3d model, as blob or reference to some other datastructure

  • integer-id, timestamp, changeset, user (whatever is required to properly support vcs)

[/*] [*]I will not join the discussion about the best 3d model format, because that's not my expertise, but it'd be nice to have all data (except for textures) in a non-binary and uncompressed format to support diffs and therefore efficient version control (at least for the database, for the contributors it would be great to support as many formats as possible, which can be converted without losses in the internally used format).[/*] [*]We need a platform where users can upload and tag 3D models. A framework like [https://sketchfab.com/](https://sketchfab.com/) would be awesome! Some more details on required capabilities:
  • The uploader will provide a unique name for the object (like files in mediawiki)

  • Uploaded files and metadata are under version control and can be edited by all registered users

  • There should be a user-friendly live-preview-kind-of-way to position the object on the map and set the correct scale. center, scale and ground offset may then be converted to the not-so-userfirendly but more precise database fields minlat, maxlat, minlon, maxlon, minheight, maxheight.

  • All metadata that goes beyond the required fields (e.g. description, license, ratings, etc.) will be stored in the (separate) database of this platform. The 3d model storage database should be kept free from all of this to make it as fast as possible.

[/*] [*]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.
  • We’d need a new tag, e.g. “model=*” where * is the unique name of the 3d model in the database

  • 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.)

  • Further Advantages: Because all metadata is stored in the database, no additional tags are required to position the object. If someone creates a new 3d model, the old one doesn’t have to be overwritten or deleted. The osm database is kept free of 3D-data, existing polygons don’t need to be altered.

[/*] [/list]

So, what do we gain here? We have a separate database for 3D models, which I think is a good thing, because we wouldn’t have to change the OSM database model and the planet files wouldn’t get polluted with 3D meshes and gigabytes of high-res textures (thereby dramatically increasing acceptance in the osm community). Still, the 3d models would be closely linked to the OSM database through the tag describing which elements are to be replaced by which 3d model in maps that support the display of 3d models.

For the geomodelling-community and all other interested contributors we’d provide a nice and easy to use platform, where models can be shared and integrated into the openstreetmap without too much effort.

For developers of 3d maps, there’d be a simple database schema available where the 3d models can be retrieved from. For 2D purists and all other applications where 3D models are irrelevant (e.g. routing algorithms), the overhead caused by 3d-related nodes and tags would be negligible.

OK, that’s it, what do you think about it? :smiley:


Related stuff I’m curently thinking about:

  • Decoupling the location data from the actual 3D objects for better reuse. Ideas:
    [list=*]

  • Express all of the location data in OSM tags (bad idea, locations shall never be stored in tags)

  • create a new polygon with only 3 tags: the 3d model reference, minheight and maxheight; the corners of the polygon define the extent of the model. Create a relation with a special type and roles, containing this polygon and the osm elements to replace (works, but quite complex)

  • allow multiple locations for one 3D object (locations go in a separate table of the database) and give each location a new name that may be referenced in the model tag, e.g. “model=tower:north”, “model=tower:south” (would require a changes of an object’s metadata rather than changes in the map, maybe not the right place?)

  • → right now I’m in favor of the second approach (polygon with relation), though I would leave the location data attached to the 3d object (as default location and definition of size) and we’d need a JOSM plugin to get a polygon of correct size and preset with the correct model reference and height values.

[/*] [*]3D models linked to tags: People should be able to create general-purpose models that can be used in 3D maps. They would require slightly different metadata (length, width, height instead of min/max lat/lon/height) and maybe some additional testing / approval by experienced users, but then we could get a variety of high-quality models of highly reusable objects like trees, mailboxes or objects that can be randomly placed on playgrounds, graveyards, construction sites etc.[/*] [/list]

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.

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.

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).

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.

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

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

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. :slight_smile: