Thanks for fixing this. Most areas seem to be ok
There are minor bugs that might result from different defaults (roof angels, …) but they are minimal.
IMHO a nice last step could be to derive simple colors from the xyz:material tag. So brick is somewhat like orange/red, glass is blue, metal is grey, … . Maybe also using default colours as flat roof is grey and angled one somewhat red.
And if you have still time/fun you might add a default for building=garages (here in Germany 1 level buildings with flat roof with multiple doors for the cars)
Sorry, one more question:
I added yellow colour to all building (not part!) elements of the Schwerin castle, but it still appears in white. Isn’t the colour of parts derived from the building, or did it still need time to update the changes? (I edited yesterday afternoon)
I’m using ST_Intersects to determines if a part is in a building, but this leads to some parts having many building and i’m only keeping the last one (as returned by postgis), and this could make the part inherits unwanted attributes.
however using ST_Contains breaks some building too when the parts points are not snapped correctly to the building…
The issue Cactusbone was talking about is here but it’s not visibile anymore, i fixed it on osm side by tagging roof:shape=flat
As a picture is better than a complicated explanation look here : .
The building:parts from the white building between the blue and red one sometimes inherit from the blue/red roof:shape=skillion attribute because they got common nodes.
I’ve added st_touches (thanks for that i didn’t know it existed) and 95% area check (great thinking here thanks again!), and i have not yet found another part to building error.
it can take up to 24 hours before buildings refreshes
It has “building:parts”:“vertical” and our old behavior was to consider it as the outline of the relation. I will remove this as we now handle building and parts intersection properly on server side.
In fact we got a fallback table with color when it’s indicated with ‘words’ (i.e: black, red, yellow…) but if it’s a #ffffff hex color we don’t change it.
We’re not planning to add 3d terrain (even if we got a working solution for that) because it strongly complexifies building placement and camera movements and we don’t want to add performance bottleneck. Adding bridges is linked to having a 3d terrain, without that it’s not very usefull.
If you already have a working solution, wouldn’t it be nice to make it optional for stronger machines? From my point of view, this would be extremely cool!
1. Artifacts
See [1] and on O2W. I know such issues, it appeared times before when I missed some nodes that are shared by various building parts but usually this would affect O2W, too.
2. S3D interpretation This green building looks very different on f4. I guess there are still some problems with defaults or interpretation of S3DB. IMHO this should be a higher priority (incl. all supported types of roofs etc.) if you want to make your map looking right.
3. Mixing weather data
I’m not a lawyer and don’t know how our copyleft affects your final product and all data included. But I recommend to use www.openweathermap.org with the same ODbL to avoid any conflicts with your commercial weather map provider.
4. Scrup as performance killer
Yes, the little plants look very nice, but they just kill my desktop and you see how they need still generated line by line. IMHO this slowdown is to radical.
Currently your map update seems to be paused. When will there be any updates?
Our tiles are created using TileMill and Mapnick we mostly use flat colors and textures for grass, sand… (using the polygon-pattern-file style)
We don’t want to release performance killer features too early to keep an overall satisfying result for most users.
This sometimes occurs when several nodes or ways sharing the same position are not merged in osm.
This comes from our interpretation of building:levels + roof:levels, i’m currently working on a fix for this issue.
In your example the building got conflicting attributes i think it should be simplified (for example i don’t understand how roof:shape=flat combined with roof:levels=1 could work).
I’m not either a lawyer, i’ll ask the team opinion on this.
Scrubs are currently a first version, we’re always working on optimization and performance improvement, for now scrubs and forests are performance killer when applied on large areas.
The synchronization server was paused for a week during the annual F4 team holiday, it should be back to normal in a few days.