The Osm2pgsql importer for OSM data to Postgres results in two tables for ways, one called planet_osm_roads and a second one called planet_osm_lines
The Osm2pgsql documentation states that the planet_osm_roads is a subset of planet_osm_lines and is useful to display roads a zoomed out levels to reduce the postgres server workload on lookups on the much larger planet_osm_lines
There are two approaches to styling the roads using these two tables:
The first option requires accessing planet_osm_roads THEN planet_osm_linesThe second option requires accessing both tables all the time
My Question is:
Which is the most effective approach assuming that no data can be removed from the tables because of the minutely diff updates and considering the following two objectives:
أكثر...
The Osm2pgsql documentation states that the planet_osm_roads is a subset of planet_osm_lines and is useful to display roads a zoomed out levels to reduce the postgres server workload on lookups on the much larger planet_osm_lines
There are two approaches to styling the roads using these two tables:
- Use planet_osm_roads until a certain zoom level and have the SLD stop styling at that sale, say a minimum of 250K then start styling from a maximum scale 250K down using planet_osm_lines
- Use planet_osm_roads for styling Motorway, Trunk, Primary and Secondary Roads down to the minimum scale and use planet_osm_lines to style all the other roads except for Motorway, Trunk, Primary and Secondary starting from a maxscale of 250K
The first option requires accessing planet_osm_roads THEN planet_osm_linesThe second option requires accessing both tables all the time
My Question is:
Which is the most effective approach assuming that no data can be removed from the tables because of the minutely diff updates and considering the following two objectives:
- Efficiency in interpreting SLD in Geoserver
- Efficiency in table geometry lookups on the postgres server
أكثر...