gravitystorm / openstreetmap-carto

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

Render polygonal breakwaters as polygons #4537

Open pszhuchkov opened 2 years ago

pszhuchkov commented 2 years ago

Some 'closed' breakwaters which don't have area=yes render as line. Can we render these features as polygons? Are there any reasons not to do it?

https://github.com/gravitystorm/openstreetmap-carto/blob/1178dfba278f1eee0ce018f72bcc88b5596d2929/openstreetmap-carto.lua#L46

https://www.openstreetmap.org/#map=18/43.47519/39.89111

image
imagico commented 2 years ago

This has been discussed in the past (#1362, #2693, #2987) - my understanding of the current default is that based on the dominance of mapping man_made=breakwater with linear ways and according to https://github.com/gravitystorm/openstreetmap-carto/issues/3611#issuecomment-460483238 the iD defaults the decision has been made to maintain in #4032 the default originally chosen in #1504/#2533.

By the way - for your example the correct tagging would probably be man_made=groyne and not man_made=breakwater (which however has the same defaults).

pszhuchkov commented 2 years ago

Thanks. It's just an example. There are lots of the same cases.

I've noticed that piers had been excluded from exceptions (https://github.com/gravitystorm/openstreetmap-carto/issues/3611#issuecomment-460483238)

Screenshot 2022-04-23 at 22 40 04

https://github.com/gravitystorm/openstreetmap-carto/blob/1178dfba278f1eee0ce018f72bcc88b5596d2929/openstreetmap-carto.lua#L46

Why did it happen?

jeisenbe commented 2 years ago

As mentioned in #2693, #2987, "all objects that can represent both linear and area features now require explicit area=yes to treat them as areas. In the old situation, closing a linear feature could (unexpectedly) change the semantics.”

All tags that can both be areas and lines are always treated as lines now, unless they have an explicit area tag or are mapped as a multipolygon (which always represents an are). The tag man_made=pier is used mostly on linear ways but also sometimes on areas, so you have to make it explicit.

Note that the wiki page for man_made=pier says "For wider piers create a closed area and add man_made=pier and area=yes."

pszhuchkov commented 2 years ago

Thanks. I see.

I missed this useful comment:

The setting change is because there was a conflict with linear ways of man_made=breakwater, in the sense of ambiguity: is a closed way always an area? No, it could be a circular way (think dikes), that needs to be treated as line object instead of area.

I thought about this reason too. Maybe you have any examples of this cases?

But I'm asking about man_made=pier because I see that 'closed' piers are mapped as polygons anyway.

Look: https://www.openstreetmap.org/way/26640574#map=19/43.42156/39.91720

Is it expected behaviour?

imagico commented 2 years ago

For clarity: What we currently do in OSM-Carto is: Interpret closed ways with man_made=* as polygons unless they are tagged with area=no or it is one of the values: breakwater, cutline, embankment, groyne, pipeline.

That means man_made=pier currently defaults to interpretation as polygons. We can discuss changing the default for breakwater/groyne the next time we do a database reload. But in this purely technical aspect of data interpretation it makes sense to look at what other tools and data users choose as default to support a consistent data model as far as possible. This especially applies in cases like this where the vast majority of data is linear ways.

pszhuchkov commented 2 years ago

@imagico ok, that's clear. Thank you.

I'm just processing OSM data and going to convert all closed ways for piers and breakwaters to polygons (without area=yes). And I wondered when I saw different behaviour for these type of features in OSM-Carto.