Real time 3D map using WebGL

I’m sorry but there seems to be a misunderstanding:

  1. What I ask F4M for is to provide max. compatibility to the current S3DB schema and existing tools.
  2. The Talk page itself is collecting experiences from mappers to do further extensions to S3DB or a more complex one, as I pointed out before. But as this is still WIP, it would make no sense to add such kind of features (as they aren’t well discussed in the community).

P.S. Once more, here is the link to your support page, that somebody already replyed:
https://getsatisfaction.com/f4map/topics/compilance_to_the_s3db_schema
My 1st post concering this topic was just a few days ago in the same thread: http://forum.openstreetmap.org/viewtopic.php?pid=364451#p364451

I am the F4 team 3D developper that replied on the getsatisfaction, talking about that here or on our getsatisfaction won’t change anything i’m still the same guy in front of my keyboard :smiley: (but talking here will involve more contributors)

What are we missing from S3DB except half-hipped roof ?

Btw i already filled the 3D tagging page with our supported tags.

Ah ok, I wasn’t aware that it’s the same person. I would suggest to splitup a seperated thead if you want to discuss this topic here, as I’m sure that the other devs don’t want to spend their time to scan all 5 pages for hints about incompatibilities :wink: I’m ok with your getsatisfaction also, as this topic is dedicated to F4M.

What I remember is that there were also problems with roof:shape=gambrel and esp. that you seem to use different defaults for various aspects (angles, …). And as I said, your building:part calculation seems still to cause some problems.
For a detailed report please start a seperated thread (and wiki page?) and make a call for participation to the community so we can check the demo areas between your and the other renderers.

Thats very kind of you, but this page was just for peaparing the 2. 3D Workshop in which result we created the S3DB out of this experiences.
So currently we don’t maintain a seperated 3D tagging catalogue.
What maybe would be very nice, if we can start a more general ‘micromapping’ catalogue (trees, city furnitures, …) to see what is also already supported. But I think this will get a really big list and I’m not sure if we can get any value of it (was what means ‘supported’ in each case?..).

Hi!
http://map.f4-group.com/#lat=59.9516088&lon=30.3079719&zoom=17&camera.theta=80&camera.phi=69.041

What does cause the problem?

I’m already working on this issue, it’s the “remove parts from outline” algorithm from Cactusbone that sometimes keep some edges as if they were not snapped.

I will try to detect and fix it on client-side.

If i got enough time today i’ll fill the demo areas links to F4 Map.

Could you switch off volume rendering of building outlines (building=yes), which have tag building:parts (building:parts= ) and don’t have tag building:part= (except building:part=no)? It can help to switch off volume rendering manually in cases, where tag building:parts had been already written by editor.

We did remove the volume for building:parts=yes but as it broke some stuff that were mapped for OSM2World we removed this test a few time ago.

del

But considering building=yes with tag building:parts= as a building, which has volume dividing to parts (building:part= ) is correct. If building doesn’t have volume dividing to parts, using of building:parts= is incorrect. Switching off the volume rendering of building, which has volume dividing to parts (building:part= ) is correct, isn’t it?

In other words, not every building with volume dividing to parts (building:part= ) has tag building:parts (building:parts=), but every building with building:parts= tag has volume dividing to parts (building:part= ) and we should switch off volume rendering of such building outlines.


This relation has building:part=roof, but your renderer shows its walls.

I think, it is a mistake.


As I see, man_made=chimney is rendered now, only of there is also tag building=yes, but there are ~11 000 man_made=chimney on nodes, and less then 2 000 on lines and areas. Less than 10% of man_made=chimney have combination with building=yes. What do you think about rendering all man_made=chimney even without building=yes? If we have man_made=chimney at node we can use some standard diameter for chimney, if we have man_made=chimney without height, we can use some standard height.

Buildings with building:parts=true aren’t extruded anymore.
building:part=roof are now handled like building=roof.
Check our changelog for more news :wink:

For now we can’t handle man_made=chimney without building=true as our building request is based on polygons so we can retrieve them the same way but we’ll think about that in further updates.

… by the way: your wiki seems to be flooded with spam,

see http://wiki.map.f4-group.com/wiki/Special:RecentChanges

I am sure there is a way to reduce new bot-driven users

Yeah, I know, I’m working on it, reCAPTCHA does not seem enough to stop the bots…

This is now fixed on server side.

This is now handled properly with a 1m radius building.

Please use for barrier=fence also area=yes tag for rendering of volumetric bodies.
Also highway=footway with area=yes for rendering of ways as surfaces…

Best regards,
Marek

Can you please be more precise, i’m not sure to understand what you mean.

This is already handled but we sometimes got ordering issues on overlapping areas (i.e: footway as area within a surface=grass or leisure=park).

It´s easy to understand.
Look here: http://map.f4-group.com/#ui.discoveryOpen=false&lat=53.0287356&lon=18.6555022&zoom=19&camera.theta=46.768&camera.phi=-12.318

Hedge can also be an area and not a kind of wall :wink:

You have to remove grass or leisure surfaces from such areas.
I know, it´s not so easy…

Hedges makes sens, you said “barrier=fence” on last post that’s what confused me :smiley:

I’m working on graphic details optimization/improvement i’ll try to push this request in my refactoring (i could also handle barrier=wall + area=yes).

PS: this could lead to unexpected results on some polygons i.e: a pedestrian area surrounded with walls will get highway=footway + area=yes + barrier=wall/hedge and i would fill the whole place with a wall/hedge. Not sure if it exists in OSM for now but it would be hard to handle.

Sorry, my mistake. Of course- hedge…
Wall with area is a good idea. I have already described in OSM-4D Definition.
Unexpected results: Its easy: Yu may cot the wall in 2 segments and this problem is fixed…
Do You already support several natural=tree geometries?

Yes we’ve got 3 models for trees: deciduous, conifer and palm.
I try to deduce it from tags “tree”, “type”, “wood” or “species” using some voodoo regular expressions or using latitude to semi-randomize type.
From pole to equator we’ll add only conifer then deciduous+conifer mix then palm+deciduous mix.

In such cases the barrier should be tagged as a separate way (might use the same nodes), so a strange rendering for this would be fine (so people notice this error).