Skip to content
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

Merged

Conversation

matthijsmelissen
Copy link
Collaborator

  • 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.

* 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.
@matthijsmelissen
Copy link
Collaborator Author

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.

@matkoniecz
Copy link
Contributor

This requires that country and state multipolygons are not broken, otherwise the labels won't render.

I am unsure is it a bad thing.

@HolgerJeromin
Copy link
Contributor

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.
I like the visibility of a broken polygon.

@matthijsmelissen
Copy link
Collaborator Author

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.

@matthijsmelissen
Copy link
Collaborator Author

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.

@HolgerJeromin
Copy link
Contributor

@dieterdreist
Copy link

2014-11-20 15:58 GMT+01:00 math1985 [email protected]:

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.

I believe this is a misconception, the arguments usually are that a node
has some unique information (the perceived "centre" or a central spot of
the place) but this shouldn't be confused with a "label". The latter is up
to the rendering software to decide, the former is data content. For cities
there is a point in having both, areas and nodes, and yes, for countries
nodes should not be needed when there is a polygon.

I welcome the step to use polygons rather then points for rendering country
names and other lower entity admin names.

@matthijsmelissen
Copy link
Collaborator Author

Lesotho has http://www.openstreetmap.org/relation/2093234

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.).

@HolgerJeromin
Copy link
Contributor

Berea has http://www.openstreetmap.org/relation/1252926 but this is admin level 5...
http://wiki.openstreetmap.org/wiki/Lesotho#Borders_and_Boundaries leaves this open.
By looking at http://wiki.openstreetmap.org/wiki/Admin_level Lesotho should have districts on 4.
http://www.openstreetmap.org/changeset/24031629 changed this.

BTW Croatia has no 4, but 5 with "borders of statistical regions" so this is probably ok.

@matthijsmelissen
Copy link
Collaborator Author

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.

@dieterdreist
Copy link

2014-11-20 17:47 GMT+01:00 math1985 [email protected]:

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
http://wiki.openstreetmap.org/wiki/Lesotho#Borders_and_Boundaries, 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 we shouldn't require tagging to change in order to make a rendering
change work (unless there are good arguments that tagging was flawed and
the rendering change has showed this, e.g. by looking at NUTS codes what
works mainly in the EU*). Are we sure that US states should be
admin_level=4? If I compare them to a German Bundesland or an Italian
Regione (both also level 4) I'd expect them to be a lower number (i.e. 3)
because they are more autonomous than a German Land is.

My suggestion for rendering purposes is to make groups:
admin_level=2
admin_level=3 or 4
admin_level=5 or 6


@Rovastar
Copy link
Contributor

"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."
+1 exactly my point of view.

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.
One of the potential problems of "each countries has its own rules" is that there can be a lack of international consensus/standard and they can be out of synch with the rest of the world. Hopefully this will highlight more these cases,

@1ec5
Copy link

1ec5 commented Nov 24, 2014

Regarding the U.S., see this discussion (threaded) on the talk-us mailing list.

@matthijsmelissen
Copy link
Collaborator Author

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.

@matthijsmelissen
Copy link
Collaborator Author

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.

@gravitystorm gravitystorm self-assigned this Dec 10, 2014
@gravitystorm gravitystorm merged commit b522c67 into gravitystorm:master Dec 10, 2014
@gravitystorm
Copy link
Owner

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. name of switzerland) and differences in refs between states and admin_level 4 (e.g. ref in Finland). But that's no reason not to move forwards.

@matthijsmelissen
Copy link
Collaborator Author

Thanks, I will send an e-mail to tagging to give advance warning of this change.

@imagico
Copy link
Collaborator

imagico commented Dec 14, 2014

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
(note labels for Russia and USA)

http://www.openstreetmap.org/#map=4/64.36/-169.76
http://www.openstreetmap.org/#map=4/75.48/39.51
(the Russian text in both says 'Russian Federation')

http://www.openstreetmap.org/#map=5/64.886/-163.894
http://www.openstreetmap.org/#map=5/78.673/79.387
http://www.openstreetmap.org/#map=7/-55.242/-68.901
http://www.openstreetmap.org/#map=7/29.898/-17.562
http://www.openstreetmap.org/#map=6/79.652/30.839
http://www.openstreetmap.org/#map=6/76.710/86.649
http://www.openstreetmap.org/#map=6/75.877/143.932
http://www.openstreetmap.org/#map=6/21.248/-159.664
http://www.openstreetmap.org/#map=8/-8.999/141.435

Most of these violate at least one of the following basic rules of label placement:

  • never label a smaller separate part of an entity unless the main part of the entity is also labeled
  • only label a smaller separate part of an entity if this part in itself (usually an island or an archipelago) is also labeled.
  • when labeling smaller separate parts the higher admin_level, i.e. the more specific label, should take precedence.

Another problem is some labels are inexplicably missing, like:

http://www.openstreetmap.org/#map=4/73.05/-63.50
(no label on Greenland and Nunavut)
http://www.openstreetmap.org/#map=6/-27.489/132.638
(only NSW and Victoria are labeled)

@matkoniecz
Copy link
Contributor

http://www.openstreetmap.org/#map=3/68.40/-30.50
(note labels for Russia and USA)

It seems that Denver blocks USA label (already reported as #1157, PR waits for merging).

@matkoniecz
Copy link
Contributor

@imagico
And - please report new bugs as issues, not by commenting in closed pull requests. It makes certain that report will not be missed.

@matthijsmelissen
Copy link
Collaborator Author

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.

@dieterdreist
Copy link

2014-12-09 0:52 GMT+01:00 math1985 [email protected]:

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 using admin_level=4 for state names is fine.

don't know what you are looking at on this page, many/most countries don't
have "states", so have you been looking at level-4 admin entities and
concluded that they are all on the same admin level? Without having
actually counted I got the impression that most entities on level 4 are
called "provinces" or "regions". Anyway, I agree that rendering area names
rather than node names is a good decision.

@matthijsmelissen
Copy link
Collaborator Author

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.

@dieterdreist
Copy link

2014-12-16 16:44 GMT+01:00 math1985 [email protected]:

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.

You'll have those often only on the tagging-for-the-renderer nodes, the
admin boundaries typically won't have them anyway. How could we get along
with this for so much time? Thanks to all for this current progression!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants