Order placenames by population and substitute NE usage on low zoom level... #1461
Conversation
|
Can you provide before/after comparison? |
|
Regarding ordering by population - this might be a good idea but would need some examples. Regarding replacing the NE data with a high population cutoff - bad idea. I think this has been discussed before, importance rating of places does not work well based on population alone, you would need to take into account the surrounding, a huge city next to even bigger cities should not be rendered (think of the US east coast for example) while a medium size city with nothing comparable around for hundreds of kilometers should (think of Anchorage, Alaska or Murmansk, Russia). |
|
Here comes a comparision for z=3.
(But I don’t have a complete planet in the database. Only place=city here, with the country names missing.) In general, for z3 and z4, where “Natural Earth” is substituted, this means less city labels in Europe and North America and more city labels in Asia and Africa. The threshold can be tweaked… On the higher zoom levels it changes mostly which label will be supressed in case of collision. |
| WHEN (population ~ '^[0-9]+$') THEN CAST(population AS integer) | ||
| WHEN (place = 'city') THEN 100000 | ||
| ELSE 10000 | ||
| END AS population, |
There was a problem hiding this comment.
Maybe use INT_population here or something like that, otherwise it's very easy to get confused.
|
On low zoom levels I'd like to see countries/states and capitals, no matter how much people live there. Population is one of the most important hints for rendering when we have conflicting name labels (see #337). |
Maybe we can get closer to the desired behavior by raising text-min-distance and at the same time render places with lower populations earlier. So, we get more collisions, and these collisions can be solved e.g. based on the population=* tag. However, I think that Natural Earth does a quite bad job regarding your criteria. It displays a lot of labels in very small continent which is called “Europe”, and it displays less labels in a much bigger continent which is called “Africa”. So, I would say we don’t loose anything. In #337 you have proposed to use a score value:
Currently, we treat not only national capitals (“capital=yes”), but also regional capitals of a givel level (“capital=4”) in a special way. So, maybe we could do this: national capital → population × 3 What do you think about? Currently, we have also various layers — in this order: ↗ Natural Earth for z3-z4 If we would adopt the solution with the score: Could we even use only one layer (with different font sizes based on the score)? |
That is a result of the cutoffs we have set for rendering. It would be fairly trivial to display more cities, and in a sensible rendering order. |
Indeed - this is one of the reasons it should be replaced. My favorite example is: Miami: population 415000, shown But i would be against using this as an excuse to take the easy way and choose an alternative approach nearly as bad while better methods exist. If you can use Mapnik's collision detection to do the necessary proximity processing that would be fine with me - i am not sure if this is workable though. Because you probably want to show some labels even if they are close together (like New York and Washington DC) but do not want the same density of labels globally. On the other hand at z=3/4 rendering performance is not an issue so you could reasonably use even an expensive SQL query to do the necessary processing.
Whatever formula you use - it will require some tuning. This is best done with fast interactive feedback, i.e. not with the rendered map. The more important questions you would need to consider is how you treat populated places with no population tag. You could use the minimum number of a settlement of this class of course (i.e. city -> 100k) And yes, if you render the low zoom levels based on a score calculated directly from attributes you could use the same layer for all zoom levels. It might be somewhat inefficient w.r.t. rendering performance though. |
Yes. The current code of this PR uses 100 000 as default for place=city and 10 000 as default for place=town. The default is used when either there is no value or if the value is not valid (contains non-digit characters). [I suppose I should catch special cases of wrong tagging like population=123456789123456789123456789 in the regular expression. The current regular expression considers them as valid, but they are too big for the integer datatype, and this leads to an SQL error.] |
Have you something special in mind? |
What class are the two cities in NE? |
|
@sommerluk - you can do that in QGIS for example. @pnorman - SCALERANK is 1 for Miami and 2 for Havana. |
|
INSTALL.md would also need to be updated. |
|
Can you do a before/after out of the same database? |
You would need regional min numbers though, in China a place with 100k is likely not considered a city |
|
@math1985
And also get-shapefiles.sh |
I’ve tried it. I had raised text-min-distance. But it doesn’t work well. Imagine the following situation: Big city Medium city At low zoom levels, “Big city” will hide “Medium city” because it’s to close to “Big city”. However, “Small city” is displayed. At higher zoom levels, the distance between “Big city” and “Medium city” will be enough to display both, but the side effect is that “Small city” can’t be rendered anymore because it’s to close to the – now visible – “Medium city”. Result: “Small city” is e.g visible at z=4, not visible at z5–6, and visible again starting with z=7. I suppose that there will always be some of these inconsistent cases. But when I tested it, there were much more of these inconsistent cases when text-min-distance was raised. |
|
Maybe the value should be tweaked, so that we have more labels at z6 (and maybe also z5). Should there be a third font size for placenames-medium (current PR code: only 2 font sizes: high-score and low-score)? |
|
Current results look good to me, as far as I'm concerned this can be merged. |
|
Just wanted to mention that this change will likely increase the tendency to tag for the renderer with place classification and population numbers. This is already an issue right now (see for example the number of obvious bogus points in http://taginfo.openstreetmap.org/tags/place=city#map) A possible way to slightly counteract this would be to create an upper limit for population of place=town so pushing a small place significantly would require manipulating both population and place classification. |
|
2015-04-27 12:33 GMT+02:00 imagico notifications@github.com:
this should not be done (or had to be implemented in a more complex way), |
|
We could change the ORDER BY statement, so that first criterion is place=city/place=town, and the second criterion is the score that we have calculated. So place=city would have always a higher priority than place=town. Within each group, the elements would be orderd by score. Advandage: This approach would avoid to use a hard-coded threshold value and should be comprehensible for mappers (they get what they expect). (Minor) inconsistence: A city of 110 000 peoples without capital=* would have a higher priority than a town of 90 000 peoples with capital=*… |
|
This would avoid prioritizing a town with high population number over a city with lower one but the town would still have a high score and would be shown early if there are no competing cities. And i disagree with @dieterdreist - place classification is not an importance rating, the wiki bases it primarily on the function of the place for the people around it and this is very similar globally for places with a certain number of inhabitants. The population ranges of places with the various tags in different regions seem more a matter of local tagging habits than of actual differences in reality. So i think limiting the population of place=town to something like 200k in score calculation does seem appropriate. |
|
We should be rendering city before town, even if the city has a lower population. Capital might change that, but that's a cartographic decision which I've seen done both ways |
|
This PR now renders cities always earlier than towns. Exception: Towns that are capitals of a country may be treated like cities if their score is high enough. Within each group, the elements are ordered by score. |
|
I did a proper comparison for Europe, with full data loaded so there are the normal label collisions. I was mainly interested in how it stacked up against Natural Earth. I'll do some more for higher zooms where it's already using OSM data z3 z4 |
|
What is causing the difference in status of United Kingdom label on z3 and label for Poland on z4? It seems that this PR should affect only display of cities (and features colliding with city labels). |
sommerluk
force-pushed
the
lowzoomcities10
branch
2 times, most recently
from
ed12e1e
to
22b3ede
Compare
|
Sorry for the late response, my hard disk was broken and I could not test further things. About the issue with New York/Brookshaven: I have no idea why this happens. Maybe a data issue? I’ve tried to reproduce it with my cities-and-town-only database, and also with new-york-latest.osm.pbf (from last week) from Geofabrik. With both, I could not reproduce this issue. I’ve tuned now z6 to be more similar to the current situation on z6. |
|
Solves #1083 |
Maybe it is a data issue that is now fixed. |
|
@sommerluk The "fixes #xy" things must be in the commit message or in the first comment/description from you. Please add my issues, too :-) |
|
I've applied this patch to my local dataset (Ireland). It is an area where few towns have populations above 10000, so with this patch as it stands, many towns with no population data are superseding towns with population data, by virtue them being assigned a population of 10000 by the patch. So, major towns with population data are not appearing in favour of smaller towns which have no population data. Changing the population assigned to 1000 seems to resolve the issue, for Ireland at least. I have not noticed any problems with cities displayed in my dataset. Is there information available on average town population in OSM or proportion of towns with population included. |
|
@Teester Thanks for testing! Probably setting it low and encouraging to tag population for at least major towns is better than setting it high and expecting that every single small place=town will be tagged with population data. |
|
+1 |
|
@HolgerJeromin Thanks for the hint! |
|
The fallback score for towns without population key is now 1000. Thanks for testing! |
|
100 000 for cities is also too high - there is plenty of place=city with lower population - see http://overpass-turbo.eu/s/bqR |
|
Selecting a low fallback population number will probably not be much encouragement for tagging correct populations but likely significantly push tagging for the renderer with the place classes (if a town does not show up it is much more straight forward to tag it place=city instead of finding out the population number). The most encouraging approach for the mapper for correct tagging overall is quite surely interpreting the tags exactly as they are supposed to be used. The most important problem of the approach here is that is does not display smaller places even if they are far away from other places. Like: http://www.openstreetmap.org/node/244081999 The first two are correctly tagged as city, the latter is tagged for the renderer. They could all well show up at z5 although they do not. In the first case tagging the correct population will probably help, in the other two probably not. Apart from that i still think major cities should have priority over subnational admin entities. |
I’m not so sure about this. For towns, http://wiki.openstreetmap.org/wiki/Key:place says: “… often with a population of 10,000 people and good range of local facilities… In areas of low population, towns may have significantly lower populations.” This is a good reason to use a fallback score below 10 000. However, for cities, the very same wiki page says: “Should normally have a population of at least 100,000 people and be larger than nearby towns.” I know that the place value is not just population-dependent, but following the wiki a place=city with a population lower than 100 000 should be an exception. |
The 10%, median, and 90% population values for place=city are 30k, 131k, and 800k. For town they are 2.4k, 12k, and 45k. |
|
Thanks a lot for the PR @sommerluk! And sorry for the show review process. I think this is a significant improvement in terms of code, so I'm happy to merge it. We can always finetune later. By the way, it seems you are sorting by category both in the stylesheet (wit attachments) and in the SQL statement. Wouldn't sorting at only one place be sufficient? |
|
Thanks @math1985 for merging.
Good catch! PR at #1843 … |
|
Sorry, but #1083 still happens. Still happens at zoom level 9 http://c.tile.openstreetmap.org/9/258/191.png (the first city I talk about does not appear). Other levels fixed. |
|
This commit is not in the version used on tile.openstreetmap.org as it's not in a released version yet. |
Order placenames by population and substitute NE usage on low zoom levels.
Resolves #50
Resolves #255
Resolves #482
Resolves #1083
Resolves #1505
It tries to order cities and towns by population. This would improve the rendering regarding which label has to be supressed in case of collision.
It substitutes Natural Earth populated places labels on low zoom levels (3–4). It uses OSM data instead, making a choise based on population=*. It uses the same font color at 3–4 like on the higher zoom levels.
It tries to guarantie that once a label has been rendered at a specific zoom level, it is not supressed at higher zoom levels by other labels of start rendering only at higher zoom levels (as far as possible).
It tries to preserve more or less the current placenames density.