Rendering style problems.

art commented

2026-08-18 21:40:24 +00:00

Owner

While the deliverable of this project has always been the importer/schema/database and the rendering and style are just for debugging and ocular inspection when the style is bad it could hide actual problems in the data. Also, it's nice to have something nice to look at.

With the buildings import I can no longer ignore the problems caused by a bad style:

Road/rail hierarchy

We need to have a global level hierarchy shared by roads, railroad, metro, tram, canals, aqueducts (do we even have aqueducts? we should), etc.

The hierarchy should be simple:

underpass - there is something above me
NULL/normal - there can be an overpass over me or an underpass under me, NULL/no attribute set is probably a good idea to reduce the MVT size because this will dominate and even the clever enum compression that MVT does still takes more than 0 bytes per attribute.
overpass - there is something below me and there's definitely nothing above me.

If there is a tunnel attribute map it to an underpass. Same way, bridges should probably be overpasses. Although there are bridges that are underpasses too, the area between Gullmarsplan and Skanstull in Stockholm should be an interesting test case for this.

Underpasses should render as tunnels - dashed casing and maybe faded color. Is the right order to render - normal casing, normal, underpass casing, overpass casing, underpass, overpass? Since the underpasses are tunnels (ish) and render faded (transparent?), they should be visible over normal streets, I'm thinking metro lines, you want to see a metro line despite there being buildings above it.

railroad, tram, should render over streets.

If the metro doesn't have any data about this we can probably safely assume it's all tunnel.

Maybe I'm wasting my time overthinking this and there's an industry standard for how to make this look good.

Streets are too fat.

The buildings import actually gave me a good data point that my earlier request to make streets fatter was actually too much. The buildings are more or less the size they are on the ground. Which means that if there is a street between two buildings its rendered size should scale at the same rate as the distance between the buildings. It's nowhere near that right now and it looks terrible when zooming (would it be possible to specify road/street size in meters and let the renderer deal with it?). A vague thought is that streets should render roughly as big as they are on the ground until z12 or maybe even z11.

We can also use buildings to estimate how thick streets should be and how well our classification works. A street shouldn't render fatter than the distance between the buildings it's between. If it does we might have a problem with how we're classifying things.

buildings shouldn't overwrite everything

Buildings should be drawn relatively early. even underpass metro lines should be drawn above them. And probably normal underpasses too. Currently buildings even cover up city names and that's just wrong.

While the deliverable of this project has always been the importer/schema/database and the rendering and style are just for debugging and ocular inspection when the style is bad it could hide actual problems in the data. Also, it's nice to have something nice to look at. With the buildings import I can no longer ignore the problems caused by a bad style: ## Road/rail hierarchy We need to have a global level hierarchy shared by roads, railroad, metro, tram, canals, aqueducts (do we even have aqueducts? we should), etc. The hierarchy should be simple: * underpass - there is something above me * NULL/normal - there can be an overpass over me or an underpass under me, NULL/no attribute set is probably a good idea to reduce the MVT size because this will dominate and even the clever enum compression that MVT does still takes more than 0 bytes per attribute. * overpass - there is something below me and there's definitely nothing above me. If there is a tunnel attribute map it to an underpass. Same way, bridges should probably be overpasses. Although there are bridges that are underpasses too, the area between Gullmarsplan and Skanstull in Stockholm should be an interesting test case for this. Underpasses should render as tunnels - dashed casing and maybe faded color. Is the right order to render - normal casing, normal, underpass casing, overpass casing, underpass, overpass? Since the underpasses are tunnels (ish) and render faded (transparent?), they should be visible over normal streets, I'm thinking metro lines, you want to see a metro line despite there being buildings above it. railroad, tram, should render over streets. If the metro doesn't have any data about this we can probably safely assume it's all tunnel. Maybe I'm wasting my time overthinking this and there's an industry standard for how to make this look good. ## Streets are too fat. The buildings import actually gave me a good data point that my earlier request to make streets fatter was actually too much. The buildings are more or less the size they are on the ground. Which means that if there is a street between two buildings its rendered size should scale at the same rate as the distance between the buildings. It's nowhere near that right now and it looks terrible when zooming (would it be possible to specify road/street size in meters and let the renderer deal with it?). A vague thought is that streets should render roughly as big as they are on the ground until z12 or maybe even z11. We can also use buildings to estimate how thick streets should be and how well our classification works. A street shouldn't render fatter than the distance between the buildings it's between. If it does we might have a problem with how we're classifying things. ## buildings shouldn't overwrite everything Buildings should be drawn relatively early. even underpass metro lines should be drawn above them. And probably normal underpasses too. Currently buildings even cover up city names and that's just wrong.