Well, for someone who claims to not be a coder, you write pretty advanced code ;-)

In my case, the data I was writing about is actually not buildings (although I do use them as well), but processed forest polygons. Not that it really matters, the problems of validity checking are the same.

However, this is what still confuses me:

This page:

https://postgis.net/docs/using_postgis_dbmanagement.html#OGC_Validity

of the PostGIS online manual says:

“By definition, a POLYGON is always simple”

This text suggests it does not really make sense checking for simplicity for polygons? ;-()?

Yet, you (only) use ST_IsSimple? Or do you use both?

My code currently only checks validity using ST_IsValid in some steps, and the commands I wrote about before.

No, I haven’t yet attempted to track down the exact geometry causing the issue. It is also a kind of hard, because I know the original geometries are fine, they work well in a GIS. It is just after my processing, that a few features fail (which is unfortunately a big issue, as a GIS generally requires all geometries to be fully valid). Still working on getting it right…

Hi Tomas,

With “Simplification for 10m” you mean you use a 10 meters tolerance?

One other unrelated question, since you seem very experienced with PostGIS, have you ever had the situation where “ST_CollectionExtract(ST_MakeValid(way),3)” returned invalid polygon geometries?

I am kind of at loss at this moment with a problem I have: despite running the above command after a custom generalization process I developed, which even includes a test for a polygon area of 0 (so collapsed geometries are being dropped), and an “ST_Buffer(way,0)” step to potentially fix any other bad stuff, I still get an occasional bad geometry that causes an error in “A” ;-).

Have you ever experienced similar issues, and how do you guarantee valid geometries after some complex geometric processing?

And does your code run properly for both lat/long (4326) and Web Mercator (3857)?

Impressive, do you have any figures on the performance of this? How much time of processing for X million buildings?

Thanks for the additional info.

Admittedly, I haven’t had a look at the code repository yet, so aren’t yet aware of the exact process you used, but yes, I appreciate it is likely a lot more complex than just buffering.

Tomas,

Interesting, thanks for sharing that suggestion. I would never have thought you were using ST_Buffer for this. This option is also not clearly documented on the PostGIS website for ST_Buffer, but I guess it is also mild “hack”…

Nonetheless, the result is still impressive.

Adamnt1,

Tomas has to answer himself of course, but to clear up a misunderstanding: you do not “loose information” when generalizing: generalized data is for display at scales where that “information”, for all intents and purposes, is of no use at all, because it would get lost in a mist of tiny essentially invisible objects anyway.

We’re talking about especially the scale range of 1:10k - 1:50k for details like buildings and other stuff in city centers. At 1:50k, 2 cm on a map is 1 km, 1 mm on the map is already 50 m in reality. You can’t realistically display a visible patch of grass of 5 x 5 m at that scale, it would be 0,1 x 0,1 mm on the map…

And when you do want to see that level of detail, you zoom in on a web map, even if it has generalized data for smaller, zoomed out, scales.

All current vector tile implementations use heavy levels of generalization for smaller scales.

Hi Tomas,

Interesting work you did, and nice results! Especially the maintaining of square corners in the generalized building geometries must be tough to implement and get right.

For my own renderer, I took a far less sophisticated route, although I do think it is still a valid compromise between no generalization at all, or an advanced algorithm as you developed.

In my case, although this is somewhat simplified, I simply chose to generalize all buildings using a 9 m2 tolerance for the PostGIS ‘ST_SimplifyVW’ command (for ‘ST_SimplifyPreserveTopology’ it would be a tolerance of 3 m).

Additionally, to prevent collapsing already simple building structures with few vertices into something like undesirable triangles, I use a minimum 9 vertex threshold: if the geometry has less than that number of vertices, it won’t be generalized. This is to prevent e.g. ‘horseshoe’ shaped buildings to collapse in something unrecognizable.

Overall, this seems to give a nice ‘compromise’ result: it doesn’t distort buildings to much due to relatively low tolerance used (although square corners may be lost, but this is virtually indiscernible with this tolerance when viewed at appropriate scales), but still manages to cut away a lot of clutter in really detailed digitized complex buildings.

Again, definitely not as sophisticated as your approach, but I thought it nice to share for others struggling with similar issues.

Sempre avuto l’idea che Bill é un imperatore romano, e Microsoft il suo regno… ;-) Buona fortuna con le ricerche… e un saluto da Olanda.

Agree, nice reads, one good reason to not close down the diaries entirely as some have suggested in an overly bold response to the spam flow ;-) Thanks.

Zo kijkend naar de link die je mij had gestuurd, en de luchtfotobeelden openend in iD, snap ik wel een beetje waarom de paden niet zijn verbonden, ze eindigen bij een soort van grasveld. Er is wel eens meer discussie hier op OSM of je dan de paden moet verbinden.

Ik zou het hier overigens wel gewoon doen, omdat de paden al erg vaag zijn in dit gebied als je de luchtfoto’s bekijkt.

Verder lijkt mij, dat iemand die in de buurt woont, eens het gebied echt goed zou moeten verkennen. Er liggen waarschijnlijk nog meer paden, zo aan de oude 3DShape import en luchtfoto’s te zien. Aan de ligging van het een en ander mag nog wel flink wat gebeuren. Die 3DShape import laat altijd mijn handen jeuken, maar je kan op veel plekken wel bezig blijven dan…

Het zou helpen als je een directe link naar de objecten post, b.v. door simpelweg de link in de adresbalk van de browser, waarin de coördinaten zijn opgenomen van het zichtbare gebied, te kopiëren.

Nog beter is even voor “Kaartgegevens” te kiezen uit het “Kaartlagen” menu, het juiste object uit de brij van blauwe objectlijnen te selecteren die dan verschijnen (daarvoor moet je overigens wel inzoomen), en dan “Kaartgegevens” optie weer uit te vinken. Je hebt dan alleen nog het geselecteerde object in beeld, en de adresbalk van je browser geeft dan de directe link naar object en plaats.

Yes, sure, except for the curiosity of the Endless Runway project, which is less of a joke than it may seem, I know of no curved runways (yet)… ;-)

https://endlessrunway-project.eu/

Since you seem to go to great detail with this, a couple of remarks to take it to the next level:

• I noticed the lines and especially curves / bends are digitized quite coarsely. I recommend refining the 90 degree curves by adding and using at least 7 nodes for each curve. This will give a much nicer look when zoomed in on the map.
• Add surface=asphalt/concrete to both runways and taxiways (osm.wiki/Key:surface). This will allow distinct rendering for those renderers supporting it (I currently have a personal renderer that does this). This is of course a rough distinction compared to e.g. the list of surface types listed on Wikipedia (https://en.wikipedia.org/wiki/Runway), but these are the standard surface types currently in use in OSM.
• Add width=x to each runway and taxiway segment. It is highly preferably to use the standard minimal widths as defined by international standards for avation for different runway classifications, instead of approximately “measuring” it in an editor like iD. E.g. most used for runways are 15/18/23/30/36/45/52/60/65/80 meters widths, see for example here (https://www.legislation.gov.au/Details/F2010L02900). For taxiway, it seems usually something like 15/18/23.

Hi Ilya,

Thanks for making this available, I really enjoyed reading this, and seeing the perspective of “five white men” on this conference ;-) … Nice selection of topics to discuss.

As you assumed, the combo of auto-translation + your edit work was enough to make it understandable. Just a very minor suggestion: replace “report” with “presentation” in most places, and it will be even more readable, as I think in most cases, you meant presentation.

Marco

@Zverik,

I do slightly object to your usage of “we’ve got structural issues” and posing this as an indisputable given. A structural problem in my opinion would be if the current (database) infrastructure wasn’t scalable or totally unmaintained. Neither of these seems true. The PostgreSQL setup seems to handle the data volume fine, and the rendering processes still keep up (although sometimes with a little delay, occasionally due to some small technical hiccup). And there a dedicated people who invest there time to keep it all running, however small that group is (and thanks to all of them!)

The two “structural issues” that I actually see are of a totally different nature:

• People and developers are just unwilling to accept the reality that there are two ways to model our (geographic) world: 1) * The one chosen in OSM and using a point/line based approach, similar, but not entirely equivalent, to how classic CAD systems and e.g. the historic Arc/Info “coverage” format used to work, where lines and points can be shared between objects. This approach always requires some kind of “build” process to model and create area / polygon features. 2) * The “Simple Features” type approach, where each object is fully self contained, and polygon features are just another geometry type, but point and line segments inbetween two bordering features cannot be shared by them.

The problem is, that advocates for either approach, typically do not accept arguments in favor of the other. They do not realize that neither approach is perfect, and that both approaches have good and bad sides.

• The other structural problem is the disconnect between, and at the same time interwove-ness of our “user” and “developer” community, where people apparently arguing for the same thing, actually want something completely different: the “user” generally just wants to see some tagged object being rendered and often does not have any clue as to the (sometime) heavy technical consequences of his request, while the “developer” may have a purely technical reason to argue against or for the same thing.

I think this disconnect is also well illustrated by siberiano’s remark…

@siberiano:

No, that is not “generic people preferring other things”, that is developers(!) preferring those things. I haven’t heard of a single ordinary person ever asking for a “JS API”. Does your grandmother and -father of 70 ask for that when on holiday and needing a map?

@Zverik. Just a few minor technical remarks: shifted halo is just a consequence of the display engine of Adobe Reader. I export to high resolution 100% vector PDF, but Adobe Reader’s conversion to the actual display on screen and the anti-aliasing necessary for that, from which the screenshots of course were derived, is sometimes sub-optimal. I can assure you there are no shifted halos when viewing the same stuff on a high dpi device. This was just captured from a 125ppi screen though. Unlabelled roads is just a consequence of my personal cartographic choice for labeling thresh holds. More labels are shown on higher zoom.

I must be from another planet, because I just don’t get it: So people really prefer the right images over the left ones in your opinion?…

Instead of spelling “impending doom since 2011…”, I have worked quietly for the past 4 years developing my own personal style and renderer workflow, just on my own, no gazillion dollar company here… David against Goliath perhaps?, I leave it to you all to judge who wins ;-)

Full size image link: ArcGIS Renderer for OpenStreetMap - United Kingdom - Edinburgh

Full size image link: ArcGIS Renderer for OpenStreetMap - United Kingdom - Snowdonia

Full size image link: ArcGIS Renderer for OpenStreetMap - The_Netherlands - Kagerplassen

Full size image link: ArcGIS Renderer for OpenStreetMap - Austria - Hohe Tauern

Full size image link: ArcGIS Renderer for OpenStreetMap - Austria - Kitzbuhel

Well, with tourists recently drowning in the sea around Menorca trying to reach their fictitious sea located hotel (https://forum.openstreetmap.org/viewtopic.php?pid=688186#p688186), a power line connected to a road is probably our least worry, at least your Tesla gets a free boost ;-)

Yes, great job. This is indeed a common problem all over Europe, the inappropriate use of hospital tags.

I would also recommend to only use “amenity=hospital” for the entire hospital grounds, as per Wiki. Quite often, people tag “amenity=hospital” on individual buildings, which are more appropriately tagged “building=clinic” or “building=hospital”.

Lastly, I would also strongly recommend to always add “emergency=yes/no” depending on whether there is an emergency room and thus can deal with emergencies. This is an important distinction between hospitals or different locations of it.