search

gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.51k stars 813 forks source link

Add rendering of place=locality polygon labels with starting zoom level and size based on way_area #4244

Closed atorger closed 3 years ago

atorger commented 3 years ago

Waters inside lakes and oceans which have names with undefined borders can be properly defined and named by making areas with "natural:strait" or "natural:bay". Text size and visibility is then appropriately scaled depending on the size of the area.

In Sweden, these type of areas of varying size and without defined borders exist plentiful over land, especially in rural areas. They were usually named hundreds of years ago, but the names are still in active use by the forestry industry, hunters and hikers and are prominent on official government issued maps.

These names often address slopes of mountains or hills, sometimes just one side, sometimes two sides or the whole hill. As there is no clear beginning or end of a hill or slope, there are no defined borders.

Following the OSM documentation the way to tag these areas would be to make a polygon and tag it place:locality, however these are not rendered by openstreetmap-carto. By making it a node it will be rendered but at a small text size, generally too small to make any sense, as these areas are generally span say 2 - 10 km.

In theory one could make a sub-polygon of the forest or the mountain and name that, but it will be very messy as the forest is generally speckled with ponds and wetland, it would be much better if locality areas names would render.

Below an example from an government-issued map. "Kaskeluoktliden" is one such name (translated "the Kaske-lake slope"), the names "Sörmyran", "Kåtamyran" etc are names of wetlands (which can be named and will be rendered as expected). As seen the Kaskelouktliden text is quite large as the area it covers is quite large, but no borders are shown in the map as there are no defined borders.

image

imagico commented 3 years ago

Changed the title to reflect what seems to be your suggestion here.

This is unlikely to happen. We view rendering of place=locality critically here because it is a very vague tag widely used just for placing labels and not to represent verifiable elements of the geography. Adding rendering of labels for polygon features with this tag as well, especially if the mapper can affect the nature of the label with the polygon geometry and there is no visual feedback on the geometry itself (see #3634 and https://www.openstreetmap.org/user/imagico/diary/43957) would further aggravate this problem. See also #3749.

By the way there are about 75k polygon features (or linear ways) with place=locality of which 63k have a boundary tag (which essentially means they are semantically incorrect in one way or the other). That leaves about 12k features, in Norway the vast majority seem to be combinations with historic=shieling, there are also some combinations with landuse=meadow and landuse=residential, natural=valley, natural=ridge, natural=beach etc. Most features with only a name tag in addition seem to be pure labeling features without a meaningful geometry - like https://www.openstreetmap.org/way/159929198.

Suggest to close this as the tag in the way it is suggested to be rendered lacks consistent use and rendering it would discourage more meaningful semantic tagging.

atorger commented 3 years ago

Ok, but how should these things be mapped then? Maybe some other tag which haven't such troubled history? I am not familiar with official Norweigian maps but I believe that they also have these type of areas. It's no surprise that it hasn't been consistently named so far as there has been no real way or guide how to map them.

I don't think it's a good idea to just not map them, as these names are in active use by anyone living in these areas or doing activities related to wildlife or forestry.

(I haven't got into mapping our high mountains yet, but I foresee similar problems there with valleys. I see there is a valley tag, but only as a way and not area and thus not possible to indicate its size which can vary a lot. It seems to me that labeling polygons would make it easier for the renderer to decide which names that should be visible on lower zoom levels, and thus making the map useful when zoomed out a bit, which it often is not today especially in rural and wildlife areas, names just disappear despite of lots of free space to render them.)

imagico commented 3 years ago

This is not really the right place to discuss tagging questions. In any case you should keep in mind that not everything that is displayed on maps outside of OSM can be mapped in OSM - we have the principle of verifiability which limits what can be mapped. What should guide you when considering how to map things as a mapper should always be primarily how you can efficiently record verifiable local knowledge, not how to add data for maximum usefulness for a certain type of data user. If a verifiably named feature has - as you describe it - undefined borders, it might still be verifiably mapped with a node as long as independent placements by people with local knowledge converge.

atorger commented 3 years ago

I always start with help.openstreetmap.org, I got the answer to use place=locality, and here we are.

I don't want to be a pain in the butt by filing impossible-to-fulfill-issues, but it seems like now when I for the first time after a few years of casual mapping starts go deeper and make quality mapping to rival our official general-purpose maps I immediately stumble into what to me seems like basic mapping issues. Basic things that seemingly just can't be done. If there's a better place to discuss these issues I'll go there, but I don't know where.

These names are verifiable in the way "that side of the hill is called Kaskeluoktliden" pointing in the general direction, or "that valley is called Syterskalet", but where these areas exactly starts and ends are just as poorly defined as straits or bays. Mapping these with a node (and indeed I do map very small bays with nodes) may be fine for casual mapping, but for high quality mapping it is inaccurate and gives no information for renderers how significant the area is.

I don't agree that this would be to cater a certain narrow type of data user, it's just basic mapping to be able to name things in the landscape. The reference map is a generic all-around map, and in this case I myself have local knowledge. The Swedish phone/address book web sites show these names in their generic maps. I don't see how this would be different from naming straits or bays. That it hasn't been done to a large extent before I'm not surprised, as the map in Sweden is largely empty outside the major cities, and even Norway which has much better quality so far is far behind the official maps outside major cities.

imagico commented 3 years ago

Opening issues like this is fine (as long as you look before if there is already an existing issue covering the matter). Suggesting to render a certain type of feature here is perfectly legitimate - and i think i explained why this is not being done.

What is however outside the scope of this issue tracker is the question if and how certain real world things can be represented in the OSM database. For that reason i deliberately refrained from commenting on your specific case example here. For discussing that you need to use other communication channels - see https://www.openstreetmap.org/help and https://wiki.openstreetmap.org/wiki/Contact_channels for some options.

jeisenbe commented 3 years ago

We previously discussed reducing the promience of rendering place=locality in PR #3749 and there are explanations there about the problems with this tag. There was also discussion of this on the Tagging mailing list: https://lists.openstreetmap.org/pipermail/tagging/2019-April/044648.html

Perhaps we need to consider removing the rendering for place=locality entirely, and instead add support for more specific tags like natural=valley and natural=peninsula - see https://github.com/gravitystorm/openstreetmap-carto/issues/788

(In the particular case above, it is not clear what “Kaskeluoktliden” represents from the description. Is it a plateau or flat spot which contains those wetlands? Is it a name for all the wetlands together? Is it a name for that ridge or slope of the mountain? All seem possible but each would need a different tag).

atorger commented 3 years ago

That sounds like a good idea as long as they can be made as areas... natural=slope would be perfect in this particular use case here, and I suppose would render the same as natural=valley and natural=peninsula.

I as not too experienced with OSM design is not sure what the policy of dealing with zoom levels is though. To me it seems natural that one should strive for having named areas rather than points most of the time even for these type of fuzzy areas, as that gives the renderer a good idea how large to make the text and at which zoom level it should appear.

imagico commented 3 years ago

Closing as we don't want to extend support for a questionable tag (and rather think of dropping support for it altogether).

Please move tagging discussion how to map certain real world features in OSM to a more appropriate venue.

jeisenbe commented 3 years ago

I agree with closing this issue.

Re: "one should strive for having named areas rather than points most of the time even for these type of fuzzy areas, as that gives the renderer a good idea how large to make the text and at which zoom level it should appear.”

We don’t want to encourage mappers to draw areas simply so there is a certain rendering results, especially if the actual area and boundaries are not verifiable. See “Don’t tag for the renderer”

For discussion of new tags, see https://www.openstreetmap.org/help and the Tagging mailing list and the Proposal process for new tags - though as always, decisions about what tags should be rendered by this style are based on consistent usage in the database and the importance of the information for a general map user, according to our design goals and guidelines).

atorger commented 3 years ago

Why do you allow it on straits and bays then? A size of the named area is vital information to be able to make a good map. It just don't make sense that a 500 meter wide hill should have the same text size as a named 10 km wide hill. Do you? It's not how we make maps here. I don't know for other countries, but Sweden's official maps are full of this, it's just basic cartography to us. It's beyond me how a mapping project don't have support for basic cartography features, it's like we believe this geo database shouldn't be used for making maps for humans to look at. Then there is this extremely slow and agonizing tag process which with increasing size of the community just become worse at getting any progress at all. OSM is getting more conservative than the catholic church. You need to be a ton more committed than I am to be able to survive such a tag approval process. It just won't happen.

It's also beyond me how a global project cannot recognize the need for a rich feature set to meet local variations in how things are named. Maybe the rest of the world only have named points except at sea, but here in Sweden there are actually plenty of areas on land, of varying sizes, with fuzzy borders, that have names. Why shouldn't these be in the database, which is supposed to be the basis to make render good readable maps that actually convey useful and accurate information? It makes no sense.

Making an area and tagging it with a name is not tagging for the renderer. If the area isn't representing the area that is named it's just wrong. I would argue that putting a point with a name is more tagging for the renderer because there you as a mapper make the actual choice where in the area the name is put. And putting a point inside an area without any indication of its size is missing vital information.

It actuallly is said there in the design goals that you should care about diversity, yet you need usefulness for the "general user" (globally I presume, which may not even understand our local conditions) before a feature is accepted. The design goals also has a point about "legability and clarity", yet we deny this feature which is key to be able to fulfill that goal.

OSM can be so incredibly frustrating at times...

atorger commented 3 years ago

Since all this is closed, I'll tell you a little story. This year I arranged a small gravel cycling race. I've always loved maps, so we made an app that the cyclists used on their phones that reported GPS position to a server so we in the audience could see where everyone was out on the course in realtime. The map was OSM, but as OSM had such little details in this area I made a custom layer with an government issue map (which is free for public use), so it only switched to OSM for the final zoom levels.

For the next year I thought that it would be cool to just use OSM, so I started adding in detail. Lots of detail. Over 700 wetlands, by hand from satellite photos, cross-checking with official maps and my local knowledge. Naming each that has names. Many mountain peaks, and ponds, and forest, and gravel roads of course, and hundreds of buildings in the various villages here and there.

But then I started to run into these problems, of basic naming patterns that simply can't be made in OSM. I couldn't name the hills and slopes. I couldn't make group names for those ponds and islands that had that. While bays could be named properly with areas, peninsula didn't work. I couldn't group mountain peaks into a group of peaks with a common name, as we have here (which naturally is the only name you see when you zoom out enough). And various odd quirks surfaced, like forest pattern drawn on top of streams and river lines, and often far from optimal label placement. To me these are serious flaws of what is needed as a basic feature set to make maps in this area.

To conclude it's today not technically possible to make OSM map to compete with our official maps, especially if you zoom out to get an overview. So for next years race there's no other alternative than to actually use the official government map instead as we did this year, despite all my mapping effort... I think that is sad, as none of the features needed are particularly technical (except for the label placement algorithm, but we could live with that for a while)

jeisenbe commented 3 years ago

@atorger, many the problems you are describing appear to be due to using this style, OpenStreetMap Carto, which is a general-use map, when you needed a map specially designed for cycling or mountain / gravel biking. We don’t even provide support for hillshading or contour lines.

There are other, specialized map styles based on OpenStreetMap data which do a much better job of showing the features in which you are interested (e.g. valleys, ridges, peaks, peninsulas, plateaus, etc) because they are focused on topography and outdoor activities, and because they do not have constraints about providing good, consistent feedback for mappers.

Examples:

If you have some experience with CSS and SQL and have lots of time, you could adapt one of these opensource styles to match your needs

Otherwise, if you have money, you could get a customized map style which would work better for your local conditions. Some pre-made options to check out:

And there is a whole list of professional cartographers and services which will combine OpenStreetMap data with government sources to design semi-custom or fully custom maps. A couple of the volunteer contributors on this style are on the following list: https://wiki.openstreetmap.org/wiki/Commercial_OSM_Software_and_Services

OpenStreetMap is a useful database, and this style represents some of the features in it. But there is much more that can be done with the data, especially if you are not limited to doing everything automatically and cheaply, like we have to do in this style.

atorger commented 3 years ago

No, I don't need a style specific for biking. The government map publically available is not a style for biking, it's just a general-purpose map for general orientation (you can see one rendering of it here: https://kso.etjanster.lantmateriet.se/). Why are there names in the landscape? So you can refer to the landscape by names and say where something or someone is. It's also a lot of local culture involved in all these names. Not being allowed to name them properly is just directly against the diversity design goal you have, just because we name areas here, or have group naming we're not supposed to have these names? I just can't understand why a database used as a source for generating maps shouldn't have solid support for naming. In my mapping contributions I have never done anything else than mapping things required for generating general-purpose maps.

I know about those alternative map sources, and I know about the controversy that if the default rendering becomes "too good" some think it will compete with the commercial providers whose money we need, so it's a bit sensitive. However this is not about that.

The way I see it, the default rendering must support and give feedback for all basic features necessary for making high quality general-purpose maps, so all those commercial providers actually get the data they need to render high quality maps. Without these features, it's not possible, not in Sweden at least. The community is now just too large to be decisive as a whole on these issues, and how in 2020 we still lack support for these basic cartography features is a clear sign of that.

None of these commercial providers can solve these basic cartography problems, as the data is not in the database, and the data is not in the database as the default style or any other widespread style support it, and there is no guideline on the wiki how to tag it. For feature naming for general-purpose maps the default style must take the lead, and it must be documented in the wiki.

About contour lines, indeed I do think that it would be a good idea that the default style would include contour lines, like opencyclemap or opentopomap does, with hill shading (at least when zoomed out a bit). That makes the map much more attractive, which is important as the default style is the face of the project, and competing maps like google maps etc have that. For the same reason I also think that the default style should be allowed to contain more expensive algorithms to get better looking results, concerning label placement in areas for example. That it's not possible today is a server infrastructure problem which needs to be solved first. I've heard that OSM servers 400,000 tile requests per second and has 2 sysadms. It's not sustainable. But that's a whole other issue, more commercial collaboration is probably required than the OSM project initially intended. Anyway, I think that it should be recognized as desirable to make good results with the default style though, instead of just saying "we want it ugly and less useful because it's fast".

It's also obvious that OSM-based maps are weak in rendering overview maps, and that's partly because lacking area-based naming. There's too little information in the database which labels are more prominent than others. These are basic issues that needs to be addressed, but it seems like the OSM community is not organized in a way to make it decisive enough to move forward.

The situation today is not the same as when the OSM project started. Quality standards of the competition has raised significantly, the OSM database is much larger, the community is much larger, the needs are more diverse. We can't go on pretending like nothing has changed.

imagico commented 3 years ago

Please stop the off-topic comments. I have said so above several times already, i will not do so again. Discussions of the general goals of this style as documented here would be subject for a separate issue. Discussion of the goals of OpenStreetMap overall are off-topic on this issue tracker in general - i already pointed you to venues to bring up such topics.

If there is anything on the specific matter of rendering place=locality polygon features as they are mapped practically in OSM at the moment they are welcome of course.

atorger commented 3 years ago

Sorry, I'll stop, there is obviously no way forward here anyway.

The problem is that you either do not understand or do not agree with that the issues I bring up is very much in line with the goal of this style, and failure to fulfill these issues is a failure to fulfill the goal of the style. It's that I try to explain over and over again in different ways (with some sidetracks, I confess), but nothing seems to bite.

You seem to divert issues of not fulfilling features required by basic cartography by pointing to the design goal document which as clear as one can be states that the capacity of basic general-purpose cartography should be fullfilled, and diversity should be respected. Or point to other styles that has the very same issues. Or claim that my suggestion promotes tagging for the renderer when it actually does the exact opposite.

It's confusing and brings a Kafkaesque quality to this issue tracker.

On the issue it's probably better to skip place=locality, and instead make this natural=hill, and make the already existing natural=peninsula render, and make area support for natural=valley. I can make a new issue for that, but I'm not sure if there is any point in that.

The overall point that we need to agree on to go further is that it is a good idea to have tags on areas that make names render as bay and strait but on land, and then one can continue to discuss what those tags should be. Place=locality is probably a bad idea due to its current history. I'm no expert in OSM and may not be able to suggest the best solution, but I am experienced with maps and I think I can describe the problem.

imagico commented 3 years ago

I know it can be kind of confusing for people used to general purpose communication channels to deal with strictly topic oriented and strictly structured venues like this. But diligent structuring helps us to stay focused and work productively.

And please don't take the fact that i did not comment on various things you said as either agreement or disagreement with your views or a lack of understanding. I can provide a differentiated opinion on many of them - but in the appropriate venue.

cepesko commented 3 years ago

@atorger: I understand your problem. Instead of just adding a node you would like to give and see more precise information on how far a locality extends. Using the node for a place=peak certainly does fit because it goes to the highest point whereas setting a node for a locality like a valley is always "wrong". A node is even more wrong than drawing an area without having a precise border because it suggests accuracy where in fact there is none. It could be set anywhere within a named area. A locality always stretches to some extent. The Wiki therefore rightly allows that you can draw an area to define a locality.

Here's my suggestion: Osmand, the very popular outdoor navigation, not only displays these localities at a certain zoom but also shows the polygon when tapping on the name, plus you see the description tag if set. That's very helpful when being outdoor and that's the reason why I started replacing my formerly added locality nodes of forest areas by polygons. And yes, Carto-style in the forests around my home has become less informative (hunting stands are more prominent than localities).