-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change rendering country/state labels #1134
Change rendering country/state labels #1134
Conversation
* Country and state labels are now rendered from the admin borders in the polygons table rather than from the place nodes in the points table. * The maximum zoom level requirement for country/state labels is replaced by a maximum area size requirement. * A minimum area size requirement for country/state labels is added. Advantages: * Avoid cluttering of too many labels of small areas, in particular on z4 and z5. * Easier to detect broken country and state multipolygons. Disadvantage: * This requires that country and state multipolygons are not broken, otherwise the labels won't render.
I only tested this on a database containing a single country. It would be good if someone could test this on a database containing more data. |
I am unsure is it a bad thing. |
The placement of the label is calculated by mapnik and not the mapper placing a "label" like node. Not sure this is an disadvantage, but a change. |
For cities, I have argued that a label node is better than a calculated placement, but for countries and states, I think calculating the label placement works fine. |
It should also be noted that this drops labels for countries for which we have state labels, but no state borders in the database. As far as I could see, the only country this applies to is Lesotho. |
Lesotho has http://www.openstreetmap.org/relation/2093234 |
2014-11-20 15:58 GMT+01:00 math1985 [email protected]:
I believe this is a misconception, the arguments usually are that a node I welcome the step to use polygons rather then points for rendering country |
That's the country relation, which is fine. There are just no relations for the states (apparently Lesotho calls these districts), while they do have labels (Leribe, Berea, Maseru etc.). |
Berea has http://www.openstreetmap.org/relation/1252926 but this is admin level 5... BTW Croatia has no 4, but 5 with "borders of statistical regions" so this is probably ok. |
Egypt also looks like a problem from the documentation, as place=state refers to governate and governates should be tagged as admin_level=3, but in practice they are tagged as admin_level=4 so that's fine. What is a problem is Japan, where place=state refers to admin_level=3 (state border), while admin_level=4 refers to prefecture borders. The same holds for Senegal. So Croatia, Lesotho, Japan and Senegal seem to be the only problem cases. From this page, it seems Croatia, Lesotho, and Senegal can easily move their highest subdivision borders to admin_level=4 if they want the names to be rendered. I think in fact that would be an overall improvement. In Japan, that's not really possible, so the proposed change would lead to rendering prefecture names rather than state names - I'm not sure whether that's an improvement or not. |
2014-11-20 17:47 GMT+01:00 math1985 [email protected]:
I think we shouldn't require tagging to change in order to make a rendering My suggestion for rendering purposes is to make groups: |
"For cities, I have argues that a label node is better than a calculated placement, but for countries and states, I think calculating the label placement works fine." It may be that some cases here we need to look at the countries/states that don't follow our logic. This is not a bad thing as it will get a better international standard for OSM for these things. |
Regarding the U.S., see this discussion (threaded) on the talk-us mailing list. |
Does anybody have the ability to test this? Or is there a way to download all admin_level 2 and 4 borders? It seems to be too large for the Overpass API, which timeouts. |
It seems according to http://wiki.openstreetmap.org/wiki/Admin_level that there is a quite strong agreement to have admin_level=4 for state borders. Therefore I think assuming admin_level=4 for state names is fine. Assigned to @gravitystorm for review. Please note that I have only tested this for a limited number of countries. |
Merged. I bet this'll cause some ire while a few tags are changed and boundaries fixed. I've tested it on 3 countries and there's some differences between tags on place=country nodes and admin_level 2 (e.g. |
Thanks, I will send an e-mail to tagging to give advance warning of this change. |
This change has a number of serious issues which are apparently not due to tagging inconsistencies, here a few examples: http://www.openstreetmap.org/#map=3/68.40/-30.50 http://www.openstreetmap.org/#map=4/64.36/-169.76 http://www.openstreetmap.org/#map=5/64.886/-163.894 Most of these violate at least one of the following basic rules of label placement:
Another problem is some labels are inexplicably missing, like: http://www.openstreetmap.org/#map=4/73.05/-63.50 |
It seems that Denver blocks USA label (already reported as #1157, PR waits for merging). |
@imagico |
I think the labelling for Canada, Norway, Sweden and Finland on z3 are also not ideal. We can consider reverting this change if we can't find a solution. |
2014-12-09 0:52 GMT+01:00 math1985 [email protected]:
don't know what you are looking at on this page, many/most countries don't |
When I say state border, I mean the type of entities that are tagged as place=state (which we used to render as labels). I realize many of them are normally referred to as provinces or regions. |
2014-12-16 16:44 GMT+01:00 math1985 [email protected]:
You'll have those often only on the tagging-for-the-renderer nodes, the |
table rather than from the place nodes in the points table.
maximum area size requirement.
Advantages:
Disadvantage:
the labels won't render.