Talk:3D development/Modelling

External model Reposity

Thumbs Up from me. I would really like to share my models I used to donate to Google.

I would prefer the 'external database' approach, as these models have nothing to do with the map data, neither technically nor logically. OSM is not a 3D representations of the world. It doesn't even include terrain height so far.

I would furthermore propose the collada file format for the 3D models, as it is an open, xml based format. It's machine- and human readable and would even allow osm specific extensions. (It would also allow easy sharing of models already created for google, as the sketchup-tool supports it.)

All we would need in the osm database is an anchor point. Mapping the local coordinate system of the model to the global system of the map would fall in the reign of the renderer.

Looking forward to this Chaos99 09:36, 10 February 2011 (UTC)

Well Collada seems to me a bit over the top cause it seem to be more than just exchanging 3D datas, it's more a exchange complete modeller sessions between tools, right? wikipedia:X3D is also XML based, the sucessor of VRML and therefore widely support, i guess? --!i! 09:42, 10 February 2011 (UTC)

Basic info on the number of floors, height, start_date, even facade material do IMO have a place here, as I could well envision a map showing regional differences in heights or the prevalent wall covering. Also, where the middle levels of a building affect highway features, routing being a major use case, modeling them in osm directly offer a possibility for more detail to a traveller. Beyond that, i concur that the extra nodes and ways do seem better stored in some other format altogether. Alv 10:10, 10 February 2011 (UTC)

I agree with the idea of using an external database for detailed 3D models of buildings (and other features that are hard to describe using just a few tags, such as sculptures). Of course, some data should be part of OSM itself, too. This makes sense where evaluating that data would be useful for other purposes than just realistically rendering the building and where the data amount and structure are suited for being used within usual OSM editors. For buildings this could include:

• a few tags such as levels, height, colors/materials
• outline ways, possibly multiple outlines where they vary significantly across building parts/levels
• rough data for roof shapes

Information beyond this (such as sub-level details, ornamentation, individual textures, roof details beyond basic shape/ridge orientation...) is clearly more suited an for external database. --Tordanik 10:45, 10 February 2011 (UTC)

I am also in favor of an external db, which would still require some new features in OSM (to assure linking works). I would want to be able in OSM to have building parts though (currently many people draw building parts and marks them as whole buildings). I agree that the numbers of floors (above ground, below ground), heights (building, roof bottom, roof top), roof shape are attributes we could have in OSM. Also additional information like position of entraces and exits, inclined surfaces made to walk on, areas on the roof or outside (terraces, yards), bridges are compatible IMHO. On the other hand, material, colors, high detail (this is relative, I intend stuff <50 cm ), detailed building volumes, roof additions, textures are more suitable to an external database.

For the format I also suggest an open format. X3D seems to be a valid approach, but AFAIK currently there is no free software available that works in implementing at least the basic features (the format is full of features and allows also subsets to implement).-- Dieterdreist 18:08, 10 February 2011 (UTC)

In OSM we should only draw the floor plan of a building, the ID of the way can be linked to the external model or perhabs there is coming a new approach for linking with external data (not only 3D data, why not many of the relations for routes or other information, OSM describes what it IS on the ground floor and the external data describes for what it is USED FOR and what it WAS before - only an idea). The current practise is not that good, not precise enough (look at the Eiffel tower example or at nearly every old church... disgusting!), OSM in its present status is designed for 2D usage so we should remain on this. The other two dimensions (3D and time) should be external or we have to redesign OSM or at least the editors. The design for 3D should empower the user for micromapping, one of the most fascinating things of OSM (don't know how to do this). The format should use a web standard, why not X3D. Perhabs we should contact the new project OpenDem http://www.opendem.info/? They are contributing open 3D data, usable with OSM data --DINENISO 22:47, 10 February 2011 (UTC)

What does floorplan include for you? Number of levels/height, building/level usage, ..? I agree with Frederik and yes TMC, OpenSeaMap,... mass of tags can be annoying. But on the other hand I see that different tools can benefit by tagging it directly to OSM (as pointed out above) --!i! 17:20, 12 February 2011 (UTC)

For me a floor plan includes the most simple model of a building. Perhabs we only need a complex model for some special buildings, but as I said above I think some people will use this special model to draw their whole city with many details. The more we discuss the details the more I think we should keep the data but have to hide it for the "normal" user via special API features. --DINENISO 18:30, 12 February 2011 (UTC)

Other possibility: All the data remain in the DB but with our standard editors we only download the 2D data via the API and need special editors for the 3D data (same with the time (historic) dimension, where we normally load the data of the present infrastructure, not all from the previous centuries). With this solution it is only an API feature. What do you mean, which of the three solutions (external, internal or mixed by LOD) should be realised? --DINENISO 17:18, 12 February 2011 (UTC)

What historic data you are talking about? Full planet dump? --!i! 17:26, 12 February 2011 (UTC)

With historic data I mean e.g. the shape of buildings which no longer exist (there was a discussion on the ML in the past). When I draw all the previous buildings in an old city (what about Rome or Jerusalem?) I will have a chaos similar to the chaos I have with complex buildings --DINENISO

Unfortunatly there is no good scheme for historic tagging (see Comparison of life cycle concepts). Personlly I use disused=yes to mark buildings that were left in past.

But a complete API rewrite would take a lot of time and needs coordination with a lot of other tagging aspects (yes for example historic tagging) to make sure that it comes up with a general sollution. To me this sounds for to much work to get the first results withum medium amount of time. There is also the con, that it is limited to OSM Mappers again and it isn't supported by tools of other communities (3D, CAD,...) that might want to contribute/use the 3D datas --!i! 11:17, 19 February 2011 (UTC)

So concerning the data format COLLADA seems to be a better choice for our usecase cause we aren't focused on web presentation only [1] --!i! 18:33, 19 February 2011 (UTC)

There is a nice document pointing out the differences/teamwork between X3D and Collada [2] --!i! 19:12, 12 February 2011 (UTC)

Oh and here a doc on the geospatial X3D extension [3] --!i! 10:50, 13 February 2011 (UTC)

Concernig the concretelow resolution tagging, let's split them up at 3D_Development/Modelling. --!i! 21:42, 11 February 2011 (UTC)

I asked the CGI staff at my university concerning this formats. They recommend that we should decide if we just want to add single objects, it's geometry and textures (than X3D or .OBJ,....) or if we would add a comlete scenegraph. This includes multiple objects and beside their geometry/texturing things like lightning and may be interaction (COLLADA, VRML). They suggested to keep it as simple as possible for the start. So what to do? --!i! 10:54, 23 February 2011 (UTC)

I think OSM should remain a data base, and in my interpretation of data geometry is enough. When we can add textures - OK, but light/shadows etc. should be made by an external tool (postprocessing) an not in the data base of the geographical data. Another point is the history and the used editor. This information is stored in Collada - what about X3D in this case? --DINENISO 12:58, 24 February 2011 (UTC)

AFAIK it consist applying a complete modifier stack on the original geometry, thats what comes next to a 'history'. But I guess you spot on managing different versions (even replaces) of models? That is what is our task with an own management DB for the 3D models --!i! 14:18, 24 February 2011 (UTC)

I created a topic at the offical COllada/Khronos group forum, lets see what the experts say [4] --!i! 14:18, 24 February 2011 (UTC)

further impressions

Huh, I am happy to see that a deeper discussion on 3D extensions has been kicked off. My two cents:

1. The OSM data format is not very suitable for modelling in 3D. However, also 2D map renderers my benefit from additional attributes. Look at Google Maps and zoom in to Berlin for instance. It just looks nice although it's not very accurate. From above it would be also nice to see some roof lines and micro details, to some degree at least and maybe depending on the zoom level. What we include in OSM must work in Mapnik and Osmarender as well. If we include too much, the 2D view gets cluttered. Or we have to introduce new tags for micro details, which would inherit attributes from building.

Yes as pointed at the discussion above it seems to become a mix between osm tags to get a nicer LOD1 modell and linked external models --!i! 17:42, 11 February 2011 (UTC)

I think some people will expand the LOD1 model using building parts and multi level building. This will result in a very confusing mix of many closed ways (areas) in the DB - not that user friedly... I don't know the perfect solution (I know there won't be one), but what Frederic posted on the ML (TMC data) last week is a very serious aspect: the more complex the data is, the less people contribute. I repeat my statement from above: OSM should only store the floor plan, not more. --DINENISO 16:32, 12 February 2011 (UTC)

In my opinion, mapping building parts should be possible within OSM, because they are necessary for a lot more purposes than just 3D rendering. Other uses include outlines for indoor maps and adding tags to distinct, externally visible building parts (e.g. where building parts have their own name). While we should avoid excessive complexitiy, it doesn't help if even relatively simple situations require external tools. After all, overlapping areas aren't nearly as confusing as having to learn using Blender. ;) --Tordanik 17:54, 12 February 2011 (UTC)

Absolutely but the question is how? Currently overlapping isn't a big issue for 2D rendering, but might clutter on 3D (min derivation on height levels, edges,clipping...). So should it be ok to simply draw the garage along the side of a house or does it have to share nodes or to be grouped by a relation? (both I would like to avoid) --!i! 18:37, 12 February 2011 (UTC)

2. Usually 3D models are not defined in lat/lon coordinates but in cartesian coordinates with a local origin. 3D shapes are usually defined as polyhedra / indexed face sets, not as collection of closed ways. The OSM editors do not support a third dimension/value for each node (or do they?). And they will not support texturing in the near future. But at some point people (at least I ;) will want to see some landmarks as nice and colorful models (or perspectively rendered in 2D).

Definitly, but as written on the page, we have a lot of options to embedd the local coordinate system to the global OSM CS. --!i! 17:42, 11 February 2011 (UTC)

3. Where to store 3D data? I do not know. building:model suggests an arbitrary URL which leads to a very distributed and potentially unstable network. We thought about a model repository for OSM-3D with an upload form but never finished. Can a central repository be set up on a OSM server? A kind of directory and file structure on a web server could do the job.

Yes an external repositiy would be fine. To make a cut, I would recommend a project different to OSM (something like open3dworld.org or similar). So would be less confusing and support the general indepandence of the repositiy (as said I like my general matching pattern approach).

4. As to the format: Sketchup is the easiest to use tool in my opinion and it is popular. It outputs KMZ files, which is basically an archive containing a) a COLLADA model and b) a KML file with a reference point in lat/lon. The elevation can be set to be "sticking on the ground", i.e. it is not included. This is fine because OSM does not contain a digital elevation model and models can adapt to available terrain data sets. KMZ would be a proper format for this purpose and wouldnt it be nice to abuse Sketchup for other purposes as intended by Goggle? There is also a free CityGML plugin for Sketchup as alternative, somebody wants to check this out? For X3D you would either need to use the Geo-Component (GeoLocation, not supported by any editor) or combine it with KML reference file, or include an anchor point in OSM.

Ah realy? Yes Sketchup is quite easy to use. But unfortunatly it's only a windows program and I would recommend to allow other free 3D apps to contribute. I guess 3D artists might be a very skilled to help us on the project. So we should care about manually merging a Collada to a manually entered position on the portal. --!i! 17:42, 11 February 2011 (UTC)

I am strongly against Sketchup and KMZ. We should decide independant from existant products and sould not rely on a single Windows application (better: Blender?). Perhabs we can develop a KMZ2X3D-converter for alle the existing Google models ;-) --DINENISO 16:32, 12 February 2011 (UTC)

Aschilli showed that KMZ is independent from the editor (even currently only Sketchup supports it). Don't forget that usability is king, so we had to develop something on our own that can bet Google Sketchup. And to me this seem to be a lot of work :/

As said, we can provide a KMZ builder. So you upload your Collada by any editor you want and align it to OSM map after the upload --!i! 17:24, 12 February 2011 (UTC)

I think KML is not the point here. It's an international standard maintained by OGC and supported by many programs. But AFAIK a common procedure in Sketchup is to download a subset of Google data (terrain and imagery) and start working on that, i.e. Google imagery can be used for tracing buildings and for georeferencing. I guess that would be violating OSM license und must be disallowed. I don't know what Google terms of use say. Perhaps !i! can make a table of potential editors, if not already started ;-) --Aschilli 12:58, 13 February 2011 (UTC)

To correct some of the above statements: SketchUp is not a Windows-only tool, at least a Mac Version is available and supported. But yes, there is no Linux edition. But I think the tool is not the point. It's about the format. As long as we use a free data format anyone can choose a tool to his liking. Blender is available on most platforms and supports at least the collada format. I don't know from memory about X3D. The KMZ container adds so little to the equation I think it can be ignored. It's collada within and not much more than a coordinate reference in the kml. The rest is 'zip all files', which is hardly a 'format' at all. Chaos99 19:21, 14 February 2011 (UTC)

Yes you are right. It will be a bonus if we support Google Sketchup (but also provoke some problems) but in the end let the users decide. Yes Blender seem to support X3D, too [5]. So the choice seem to bee X3D or Collada? What about supporting both or splitting up the formats for the toolchain (import, storage, export)? --!i! 21:56, 14 February 2011 (UTC)

5. Free sources of DEM data are SRTM/CGIAR, ASTER (though I don't recommend it), and in a couple of years TerraSAR-X (2016). --Aschilli 16:13, 11 February 2011 (UTC)

A collegues of you started recently OpenDEM that might become nice results :) --!i! 17:42, 11 February 2011 (UTC)