Real time 3D map using WebGL

Doesn’t work even though I explicitly specified roof:height

@shrddr
roof:height would only have fixed dome :confused:
we’ll look into it.

I have found some problems with 3D objects in Warsaw on F4, but it doesn’t seem to me to be a data issue (at least Kendzi3D shows them properly):

  1. http://www.openstreetmap.org/relation/3217013http://demo.f4map.com/#lat=52.2424786&lon=21.0122054&zoom=19
  2. http://www.openstreetmap.org/way/34614532http://demo.f4map.com/#lat=52.2491393&lon=21.0033659&zoom=20&camera.theta=73.984&camera.phi=94.252

@kocio
Metropolitan : be careful, relation#75539 is also marked as building
way 238660071 is marked as building with a height = 0.1. I think this is to avoid volume rendering. for f4map you can use building:part=no for that. height on the building should always be the real height of the building
That being said, I don’t know what’s causing the bug, we’ll look into it too

For the library, there are no parts starting from the ground. It seems like you’re trying to use the outline for rendering this time. You must use a part for that too, and set the correct height on the outline (which is not rendered at all since it’s fully covered by parts)

Thanks! I will pass the message to the people dealing with those 3D objects.


I have also more general 3D-related problem. I try to render fountains on osm-carto, but it seems that current definition (amenity=foutain) does not cover such things as nozzles and other objects being a part of fountain (for example lights and the artworks). For example in this fountain:

http://www.openstreetmap.org/way/79738429

the name shows that “fountain” is this whole structure, but it’s tagged just as a water and individual nozzles are tagged as amenity=fountain. My current tagging idea goes like this:

https://github.com/gravitystorm/openstreetmap-carto/pull/1804#issuecomment-137197243

but maybe looking from 3D perspective you have more ideas to try?

@shrddr ok we fixed it. thanks again for the report ! :slight_smile:

Something changed some time ago and now most buildings in Moscow, Red square (and Kremlin) are gone
http://demo.f4map.com/#lat=55.7521494&lon=37.6247769&zoom=17&camera.theta=43.236
http://www.openstreetmap.org/#map=18/55.75264/37.62351
They are tagged as relation type=multipolygon+building=yes + type=multipolygon + building:part=yes

It seems there’s a problem with elevations activated. try without them :slight_smile:

EDIT : fixed with elevations! thanks for the feedback :slight_smile:

@Cactusbone

Apologies for hijacking this thread, but I’ve been trying to get in touch with f4map.com since we’d like to know what the licensing options are to integrate the map into a custom, commercial application for GPS tracking - to no avail. Is there anything you can do to get me in touch with the right people?

You can email me: johan (dot) dams (at) wrdsystems.co.uk

Dear F4 team,
I go crazy because of differences of the interpretation of 3D tagging between you and Kendzi3D which is the only one existing tool which shows in real time what happens during 3D attributation of tags.

An good example could be this: http://demo.f4map.com/#lat=27.7151026&lon=85.2904818&zoom=21&camera.theta=72.215&camera.phi=-14.61

https://www.openstreetmap.org/way/201223707

I would suggest a meeting to clarify the differences.
I have also suggestions regarding bottom parts of building:part elements.
I started to describe this here:

http://wiki.openstreetmap.org/wiki/Roof_position

Difference is impressive indeed… We’ll try to find what’s wrong.

building:roof handling seems different, when we see building:roof, only the roof part is rendered, not the building below it. this enables to have a floating roof, which seems to be what you want here :slight_smile:

Central part : It looks like we’re inheriting roof:shape from the building to the parts.
Either make the bottom dome a building:part, or specify roof:shape for every part.

I don’t know what properties kendzi inherit from building.

Interesting roof proposal :slight_smile: I like how it enables to make arches, but it’s not straightforward to think of the roof as beneath the building. and you need another part to have a normal roof above.

We can simply use the wording:
bottom:shape=* , bottom:height=* etc. In this way we could have unambiguous description of elements. It is easy to implement.

Btw.: you have a bug in the interpretation of skeleton algorithm and calculating heights of ridge and edge lines based on the highest ridge line which has the height of height=*

The point is: only the ridge line, and it is only one line in 3D building, geths this value of height. BAsed on that:

  1. Calculate angle of 2 neighbour surfaces
  2. Based on calculated angle from 1 calculate heights for next ridge lines as a vertical penetration of 2d element ridge line with the calculated surfaces.

Let´s meet. I was supervisor of the master thesis: “implementation of OSM S3DB 2.0 approach” We have done really nice things. Now we need it in OSM as well.

We’re using http://postgis.net/docs/manual-dev/ST_StraightSkeleton.html for skeleton (Postgis 2.1) based on SFCGAL

Yes, ther is the bug.

Edit: see this: http://wiki.openstreetmap.org/wiki/File:BadSkeletonAlgorithmImplementation.jpg

Above is the 1:1 implementation.

I’m not sure when we’ll have time to look into this :frowning:

It is not rocket science. Lets talk: I can explain you how to implement it. One afternoon should be enough for writing this code.

If you’re talking about changing the skeleton code, it’s not gonna be easy, it’s in CGAL which is used by SFCGAL which is used by PostGIS which is loaded by PostgreSQL. so even if it’s not rocket science, i have no clue what the code looks like :slight_smile:

I do understand what you want but it’s really not simple the way we’re using skeleton :slight_smile:

Just to give idea of straight skeleton algorithm complexity:

https://github.com/reinterpretcat/StraightSkeletonNet

This is my C# port from kendzi’s Java implementation.

Yes, I know. Kendzi is my good friend.
But now one question to you, eis_kalt.
Kendzi had an accident and has arm in the sling, with other words he is not able to implement new things.
We have an discussion in polish and german forum about modeling of bottom parts of buildings. The last approach is here as variant 2: http://wiki.openstreetmap.org/wiki/Roof_position

Do you think, you could enhance existing PlugIn with this functionality if Kendzi agree of course?

Unfortunately, I just don’t have time: all my spare time I’m spending on my project (see utymap repository for details).

Also, straight skeleton porting process was relatively easy because the logic is encapsulated in single package and I didn’t have to go into details of existing plugin implementation. For roofs, I’m afraid it is not so simple.