Too many placenames labels rendering for South Korea at z9

[clhenrick]

In South Korea when transitioning from z8 to z9 placename labels overwhelm the map style:

http://www.openstreetmap.org/#map=8/36.062/128.298

http://www.openstreetmap.org/#map=9/36.0646/128.2956

On first glance I think a simple fix would be to bump up text-margin on #placenames-medium::low-importance for South Korea to prevent so many from rendering.

[mboeringa]

I am not familiar with the Korean data, but another question that comes to my mind seeing this, is whether Korea actually has any meaningful distinction in place categories for its habited areas. Looking at the image at least suggests there is a lot of work to be done by the Korean community in this respect. If every hamlet is tagged as city or town, that certainly won't help...

[nebulon42]

To me this is clearly a data problem. A node I investigated was tagged place=town where no town nearby was to be seen. Maybe those are administrative entities? From an import?

[pnorman]

Much of the data is coming from http://www.openstreetmap.org/changeset/1409522

I also think this is a data issue, made worse by the name tag containing two names. I looked at a few place=town nodes and there were no buildings there. Even where there were structures, I would have expected them to be villages or hamlets. The rare one in a larger area looked to be within a larger city and therefor should be tagged as suburb or neighbourhood.

[kocio-pl]

Is there a place we could contact Korean community to let them know? I don't see the forum for this country.

[SomeoneElseOSM]

Maybe try some of the "gold" mappers (that are still mapping) from http://resultmaps.neis-one.org/oooc?zoom=7&lat=36.44631&lon=128.33933&layers=B00FTTFFFT and ask them?

(edit) Korea does look pretty moribund, actually. There are a few still-active "mapping editors" though.

[kocio-pl]

Message sent to user alimamo.

[pnorman]

I'd try talk-ko. It's not the most active, but they could reach out to locals better than other venues.

[clhenrick]

If possible I still think a temporary fix to make that part of the world more readable would be to apply a text-margin to town labels, say 25 or 50 pixels. Not sure this is possible without using a PostGIS query though. I don't think it would sacrifice any OSM contributions because more labels would be visible as you zoom in.

[alimamo]

It is mostly a data problem. Originally when Korea had very few mappers, things were pretty barren. Well before the administrative boundaries were added, "centroids" of all the different levels of administrative divisions were imported by a Korean mapper to help out. No, they probably should not have been added as "towns", especially the "-eup, -myeon, and -ri" divisions since the "centroids" rarely corresponds to any actual towns or villages. Part of the problem was language and translating the idea of those lower divisions.

In all honestly, those points that correspond to nothing (originally "centroids") could probably be removed or moved to a town/village that actually does represent the division. However, Korea still has only a few mappers and even fewer mappers that are on the ground and not doing "armchair mapping" which means people might not know which town to move the points to.

I suppose as administrative boundaries continue to be added to the lower levels, we won't need those points at all. But the Korean government is pretty stingy with (and paranoid about) their map data, so it will take some time. I will pass on the information here to other mappers with a suggestion of moving or removing "towns" that don't actually represent anything. I wouldn't suggest a wholesale deletion, though because I know some of the points are relevant.

Thank you.

[clhenrick]

@pnorman why close this, it's not resolved?

[kocio-pl]

I prefer not to make temporary fixes - unless you can prove it would really help here and it won't make a problem in a different part of the world.

[clhenrick]

I understand the guidelines for writing rule based styling is to assume all OSM data tagging follows the conventions as outlined in the wiki, and to not create rule based styling work arounds when the data is incorrectly tagged.

That being said I would argue that this issue covers such a large area (all of S Korea at z9), that the temporary fix would be so simple to implement ( setting text-margin to 25 - 50 for towns at z9), and that the data errors would still be noticeable so users could still be encouraged to fix them.

As to whether it would make a problem in areas for the rest of the world, I don't foresee that happening but it would make sense to test with some extracts of different countries.

[pnorman]

OSM data tagging follows the conventions as outlined in the wiki

Not following the wiki, but correct. These are ideally the same.

That being said I would argue that this issue covers such a large area (all of S Korea at z9), that the temporary fix would be so simple to implement ( setting text-margin to 25 - 50 for towns at z9), and that the data errors would still be noticeable so users could still be encouraged to fix them.

The issue is one with the data and impacts everyone using OSM, not just us. We want it fixed in the data. We might need to adjust display on z9, but to establish that we need to look at somewhere where the data is properly tagged.

[sommerluk]

If possible I still think a temporary fix to make that part of the world more readable would be to apply a text-margin to town labels, say 25 or 50 pixels.

This would not fix anything. It would of course decrease the number of labels, which is what our visitors might be used to at z9. But it would be unpredictable which labels are shown and which labels are hidden, instead of being based on the importance of the settlement. The remaining labels will continue to be wrong (no town exists there). In short: The map will continue to be as bad and as wrong as it is currently. The only difference would be that non-locals will not notice this anymore. I don’t think this would be an improvement.

[clhenrick]

@sommerluk yes, the proposed fix is strictly cartographic and intended to reduce the number of labels being rendered, not the to fix the underlying data.

Is the OSM Carto style is intended purely to give mappers feedback on their edits and show data that needs improvement? If so then leaving these labels as is doesn't solve a cartographic design problem with this area, the reason why I opened the issue.

[sommerluk]

Indeed, CARTOGRAPHY.md says:

OpenStreetMap data has to be manipulated for rendering, but since this style is intended for use by mappers to check their work, it should minimise any distortions.

But there are also cartographic issues. Currently, it is tecnically not possible to make region-specific rendering rules. So the rendering is the same all over the world. This leads to the following problems:

• I had a look at some other places around the world, and the change that you propose would indeed break the map. In many contries, you have regions with high settlement density and other regions with low settlement density. The map should reflect the reality, and you expect a higher label density on the map where more settlements are, and a lower label density where less settlements are. Increasing the minimal distance between labels would break this behaviour in the rest of the world.
• While working on the new order of placenames, I had played around with higher distances between the labels, but this increases a lot the inconsistency between zoom levels (features that show up on lower zoom levels will disappear suprisingly on higher zoom levels, see https://github.com/gravitystorm/openstreetmap-carto/pull/1461#issuecomment-87274760 for details).

Overall, increase the label distance would make the rendering much worser outside of Korea.

I’m sorry, but there is no trivial solution.

[clhenrick]

Okay, thanks for the detailed explanation.

-Chris clhenrick.io

On Wed, Aug 10, 2016 at 3:57 PM, Lukas Sommer notifications@github.com wrote:

Indeed, CARTOGRAPHY.md says:

OpenStreetMap data has to be manipulated for rendering, but since this style is intended for use by mappers to check their work, it should minimise any distortions.

But there are also cartographic issues. Currently, it is tecnically not possible to make region-specific rendering rules. So the rendering is the same all over the world. This leads to the following problems:

• I had a look at some other places around the world, and the change that you propose would indeed break the map. In many contries, you have regions with high settlement density and other regions with low settlement density. The map should reflect the reality, and you expect a higher label density on the map where more settlements are, and a lower label density where less settlements are. Increasing the minimal distance between labels would break this behaviour in the rest of the world.
• While working on the new order of placenames, I had played around with higher distances between the labels, but this increases a lot the inconsistency between zoom levels (features that show up on lower zoom levels will disappear suprisingly on higher zoom levels, see #1461 (comment) https://github.com/gravitystorm/openstreetmap-carto/pull/1461#issuecomment-87274760 for details).

Overall, increase the label distance would make the rendering much worser outside of Korea.

I’m sorry, but there is no trivial solution.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/2275#issuecomment-239029973, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ31AiJ3Xk5a7lkZXpKjPcuF4UnxXWfks5qeldTgaJpZM4JfmgY .

[kschoi4github]

Dear all,

As one of the Korean mapping users, I feel indebted to all who expressed the concerns about the populated labels at z9 of Korean placenames.

Regarding this issue, I happened to notice it by chance. And, reviewing the comments, I could feel some of you had experienced frustrations coming from inactive contributions by the Korean community. Here, I'd like to express my intention to add my effort for the contribution from now on.

Though this issue #2275 looks closed apparently, let me add my comment if allowed. As for me, it is only this year that I turned my interest toward open data as well as OpenStreetMap. It is true that the labels at z9 of Korean placenames are too populated. However, from my perspective, I have regarded it was designed on purpose for the sake of label justification.

As you know, OSM can be used not only for an online map service but also for a data source of valued map products. For use of online map service, I agree the placenames labels are really ugly. But, in terms of overall mapping quality at https://www.openstreetmap.org, I don't hand out good marks to it. Owing to this, I myself have regarded the placements labels were just the part of the unsatisfactory areas of OSM. Soon, comparing the labels with the neighboring countries like China and Japan, I realized what you pointed.

So... how can we fix this kind of problem if it happens again? What are your recommendations for the Korean community to react? Why doesn't an OSM mapping style template restrict this kind of deviation? Does local edits (by Koreans) take precedence over any other overseas contributors?

As a following effort to promote OSM mapping activities in Korea, I'm going to show a presentation at a national geospatial expo event in early September. I hope your coming recommendations or comments become the ingredients for the presentation.

Any feedback will be greatly appreciated.

[kocio-pl]

@kschoi4github Thank you for your input.

I don't feel it was frustration about the inactivity of your community, we just didn't know how could we effectively contact you - but it worked, so I'm quite happy with it, we can now go on with solution.

Closing this ticket does mean only that we think the solution is outside the scope of this style, it tells nothing about the problem itself being "not real" or "not important". We just think that in this case rendering only follows the data and this is the proper place to fix it.

What are your recommendations for the Korean community to react?

@alimamo knows the problem and has the general idea how you should deal with it, so I guess you could talk with each other - maybe using talk-ko list to make other people in community aware of the issue, so they could join this task.

Why doesn't an OSM mapping style template restrict this kind of deviation?

It is simply not the role of the style to correct data problems in general. The more clean and quirk-free the style is, the better, since it's already very big and complicated.

Does local edits (by Koreans) take precedence over any other overseas contributors?

I don't think so, all edits are the same from a technical point of view, anybody can edit any part of the world, but of course it is a good practice to respect local conventions and try to reach some agreement. Why do you ask about it?

As a following effort to promote OSM mapping activities in Korea, I'm going to show a presentation at a national geospatial expo event in early September.

Great idea! Here in Poland the community is quite big and healthy and I think it's the most important asset for producing a lot of high quality OSM data, even if local authorities are not so open. If you want to learn more, I'm happy to share my knowledge and you can talk with us in English on our forum. I also think that talk list is a good place to start gathering experience from other local OSM communities.

[kschoi4github]

@kocio-pl Thanks a lot for the note.

Does local edits (by Koreans) take precedence over any other overseas contributors?

I assumed the issue was supposed to be handled by the own efforts of Korean contributors which was not required from the technical standpoint (as you stated). My assumption prompted me to ask it...

Now. I'm more convinced to make the most of the OSM forum & talk list. Many thanks,

[dieterdreist]

sent from a phone

Il giorno 11 ago 2016, alle ore 11:14, Kyu-sung Choi notifications@github.com ha scritto:

So... how can we fix this kind of problem if it happens again? What are your recommendations for the Korean community to react?

nowadays imports have to follow the import guidelines, which include public announcement and discussion prior to importing anything, so it should not happen again or would be reverted very quickly.

As a following effort to promote OSM mapping activities in Korea, I'm going to show a presentation at a national geospatial expo event in early September. I hope your coming recommendations or comments become the ingredients for the presentation.

Any feedback will be greatly appreciated.

you should try to ask this on the talk-mailing list, because here is the issues section of the osm-carto rendering style.

[kocio-pl]

@kschoi4github

Now. I'm more convinced to make the most of the OSM forum & talk list.

Do you like to have forum created for your country? I have noticed there no such thing yet and it could help build your local community.

Is there any other help you may need to fix this data problem?