Place area city/town #538
Closed
Place area city/town #538
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously we had one place layer for capitals and one for non-capitals when it came to towns and cities. This combines them, reducing the number of queries, making the SQL simpler, and making the layers more useful for other styles. Incidentially fixes gravitystorm#522
This is part of gravitystorm#103, but only fixes it for place=city/town The SQL is moderately complex and difficult to document in the .mml file so it's worth documenting here ```sql (SELECT way,place,name,capital,population FROM (SELECT way,place,name,NULL AS capital,way_area, -- The polygon table doesn't have the capital information with the default style CASE WHEN population~E'^\\d{1,9}$' THEN population::integer ELSE NULL END AS population -- We need to filter out population values that might cause exceptions. This is a fairly rigerous filtering as it will remove population=1,000 FROM planet_osm_polygon UNION ALL -- Join the two together SELECT way,place,name,capital,NULL AS way_area, -- Points don't have an area CASE WHEN population~E'^\\d{1,9}$' AND length(population)<10 THEN population::integer ELSE NULL END AS population -- as above FROM planet_osm_point) AS p WHERE place IN ('city','town') -- This condition is brought inside by the query optimizer ORDER BY CASE place WHEN 'city' THEN 0 ELSE 10 END, -- We don't actually need this at moment with the current MSS CASE capital WHEN 'yes' THEN 0 ELSE 10 END, -- Nor this way_area DESC NULLS LAST, -- Put physically larger first population DESC NULLS LAST -- For points (no area) put larger population first ) AS placenames_medium ``` The ordering merits further discussion We're currently not considering area or population for ordering, so anything is an improvement here. It's hard to say if area,population or population,area is better without trying one first.
Benchmarking shows \d+ and length with no NULL check is the fastest way to check if the population is safe to cast
|
Thank you for this PR.
I am not sure if I'd consider this a bug. On the one hand, it would be good to have one OSM object for every real-world object. On the other hand, points can indicate the center of the settlement, while the area can indicate the outline. Rendering the name in the middle of the area would often be ugly, in particular for 'unbalanced' settlements - like coastal settlements typically are, for example. |
Closed
|
Superceeded by #546 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #103
This will reveal two widespread problems in the data
I don't see revealing either as a blocker as it should lead to them getting fixed.