Openstreetmap-carto: natural=wood + wood:age=young objects should be displayed similar to natural=wood

[d1g]

ATM, there no fill: https://www.openstreetmap.org/way/56381553

According to definition, wood:age=* doesn't say they are absent or _lost_.

wood:age was suggested as additional tag to the numeric start_date=* and thus could be displayed using special style.

The best information about wood:age=* tags is here: https://github.com/igitov/forest-josm-tagging-presets/blob/master/forest-presets.xml

[pnorman]

natural=wood is rendered, and wood:age doesn't change that. In fact wood:age isn't even in the database.

If it's not rendered at a specific location it's not a style issue, but somewhere else in the toolchain, probably either caching or a multipolygon processing error, neither of which can be fixed by the style.

[mboeringa]

For the record: JOSM does not show validation errors on the way feature that is missing in rendering, nor on the multipolygon it is part of as inner.

[polarbearing]

My guess is, as the way cited above is an inner ring of this relation, and both are tagged natural=wood, that the inner ring is punched out of the MP and consequently not filled. I wonder if it is within the logic of a MP to punch out something with the same tagging, only to add a further qualifying tag.

[dieterdreist]

sent from a phone

Il giorno 21 ago 2016, alle ore 09:40, polarbearing [email protected] ha scritto:

My guess is, as the way cited above is an inner ring of this relation, and both are tagged natural=wood, that the inner ring is punched out of the MP and consequently not filled. I wonder if it is within the logic of a MP to punch out something with the same tagging, only to add a further qualifying tag.

it is kind of a bug of osm2pgsql, which had deliberately decided to drop tags from inner members if the outer has the "same" tags, IMHO that's too clever, osm2pgsql should rather not make this kind of adjustments hence encourage people to remove tags from the inner member where they do not apply to the polygon. This occurs also in other contexts (e.g. buildings with different attributes), a workaround is creating a new MP for just the inner object