Different geometry decisions (point/line/polygon) on database re-import

[sommerluk]

Currently there is no database re-import planned. And apparently also no urgent need to do so. Anyway it might be useful to have a list of geometry decisions (point/line/polygon) that we might maybe change if in the future we would make a database re-import.

• barrier=toll_booth as line geometry (reference #3249 and #3244)

[jeisenbe]

I also noticed that waterway=tidal_channel should be added to the list of waterway linestrings

[jeisenbe]

Any thoughts on importing attraction=, club= and emergency= as polygons when mapped as closed ways?

For attraction= there are a number which are mapped as lines, so we could import just these as polygons: attraction=animal, =amusement_ride, =carousel, =big_wheel, and attraction=yes

Club= is always an area or node, though we probably won't render it. Should it still get imported properly as a polygon?

The emergency= features are all nodes and areas. There is a long list of rather rare tags, so perhaps the whole key should be imported as a polygon, even if these will not be rendered?

[jeisenbe]

It appears we can make a goal of finishing this discussion for the next release in a month.

Who has a server with sufficient RAM to import the whole planet.osm.pbf with the new schema_changes, to confirm that performance is acceptable? @pnorman?

[pnorman]

Who has a server with sufficient RAM to import the whole planet.osm.pbf with the new schema_changes, to confirm that performance is acceptable? @pnorman?

What specifically are we looking to performance test? I don't see anything that needs it

[jeisenbe]

Perhaps I misunderstood your comment above:

"we're going to need to test any changes, and part of testing is full planet imports"

https://github.com/gravitystorm/openstreetmap-carto/issues/3611#issuecomment-479744738

(And also https://github.com/gravitystorm/openstreetmap-carto/issues/3611#issuecomment-479748496)

My understanding was that we ought to test the full planet import prior to merging schema_changes to master?

[jeisenbe]

Declined:

• [ ] attraction=animal, =amusement_ride, =carousel, =big_wheel, =maze as polygons. Unfortunately there is a "long tail" of features which could be imported as polygons, such as swing_carousel, drop_tower, winery, formal_garden, kiddie_ride, etc, but also these are intermingled with linear features like pirate_ship, dark_ride, boat_ride, river_rafting etc, so importing the whole key as polygon features would be imprecise.

Since we do not have a current plan to render these features, they will have to wait till another year.

[jeisenbe]

It would need to go inside the loops searching through the objects tags:

https://github.com/gravitystorm/openstreetmap-carto/blob/295d65d7623c6a323d83bb254cefadeeb8e4c10c/openstreetmap-carto.lua#L395-L397

Right now for tags that match and don't have a polygon override it's an area, a v ~= 'no' check would need to be added.

I tried changing the line to:

            if k == ptag and not (linestring_values[k] and linestring_values[k][v] and v ~= 'no') then
                return 1

Using v4.24.0 as the basis for rendering, this still renders the hedge fill for barrier=hedge + landuse=no closed ways, but renders nothing at all for barrier=hedge + building=no, whether or not area=yes is used. Perhaps I have the syntax wrong?

Ideally, we would like to ignore <polygon_key>="no", but still import the feature properly if there is another polygon key or an area=yes on the feature.

(In practice, I think only "building=no" is very common)

[Adamant36]

No winery huh? Bummer.

[jeisenbe]

Do you mean attraction=winery? This is a rather rare, and undocumented, tag.

But I've submitted a PR to import craft= as a polygon, and craft=winery is common: https://taginfo.openstreetmap.org/tags/craft=winery

[Adamant36]

Yeah, I got it confused with craft though. My bad. It makes way more sense as a craft key.

[jeisenbe]

One more thing: should barrier=hedge closed ways be imported as polygons?

Discussion on the tagging list shows that some mappers are unhappy with #3844 which removed the area rendering for barrier=hedge, and there is not yet an alternative way of mapping hedges as areas (apparently some mappers disgree with use of natural=scrub for these areas, though landuse=forest is sometimes used for tall hedges).

In a comment, @imagico suggested the possibility of rendering barrier=hedge areas as landcover, with lower priority than other landuse, so that issue #971 would not reappear on features like leisure=playground + barrier=hedge.

See: https://github.com/imagico/osm-carto-alternative-colors/tree/hedge_polygons_as_landcover

However, currently this would only render barrier=hedge areas which are tagged with area=yes or mapped as multipolygons or tagged with another key which is interpreted as a polygon. It would be more consistent to import barrier=hedge areas as polygons if we are considering rendering them again.

(We could also consider this for barrier=wall and city wall areas, but these are less common and were never supported by this style).

[pnorman]

One more thing: should barrier=hedge closed ways be imported as polygons?

I'm against this. The first reason is that none of the other barrier values default to being a polygon. The second is that this adds another situation where you can't tell if something is an area or not based on tags. The third is it's against what all data consumers and editing software expects. The fourt is it doesn't reflect current usage. I sampled 32 closed ways without area tags on them, and 6% were probably intended to be areas, 84% were clearly lines, and the remainder I couldn't tell by looking at surrounding OSM data and imagery.

[imagico]

In conclusion i concur with @pnorman (as indicated before - me making a branch implementing that does not mean i am in favor of it, i just want to demonstrate that this would be the way we should implement it if we decide to do so) but i disagree with reason four - you cannot just look at the features without an area tag. In terms of closed ways with a barrier=hedge tag the ones meant to be 2d representations outnumber the 1d representations probably somewhere between 3:1 and 4:1. That most of these currently have an area=yes tag is largely due to us having incentivized that in the past.

But i agree on the other points and especially think we should be very careful in special casing new key/value combinations, especially if we render them both as 1d and 2d features. This makes life more complicated for all data users and mappers and the whole idea of dual use of tags for both 1d and 2d representations is bad practice we should avoid to support when not unavoidable due to extensive legacy use.