der-stefan / OpenTopoMap

A topographic map from OpenStreetMap and SRTM data
https://opentopomap.org
Other
471 stars 119 forks source link

Render names of further Regions #295

Open ppete2 opened 3 years ago

ppete2 commented 3 years ago

Right now just names of Regions with tags like _"region:type=mountainarea" and _"region:type=naturalarea" are rendered.

Please also render Regions with "place=region" tag only, for example https://www.openstreetmap.org/relation/11490442 and regions with other "region:type=*" tags, like https://www.openstreetmap.org/way/834744233

max-dn commented 3 years ago

We could collect some more region:types for "natural" areas....

A bare place=region should not be rendered, I think. For example in parts of spain a lot of administrative divisions are tagged as place=region: https://overpass-turbo.eu/s/17Eg

maxmichels commented 3 years ago

@ppete2 the tag place=region should not be used referring to https://wiki.openstreetmap.org/wiki/Tag:place=region so i would highly recommend not to render this tag.

ppete2 commented 3 years ago

Well that's just a theoretical guide of the Wiki, and this is also not accepted in each language. E.g. the German wiki https://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dregion doesn't write that this is a grandfathered tag.

In reality many important regions are tagged this way. E.g. the classification of the Alps: https://www.openstreetmap.org/relation/2113486 Or as mentioned in the first post Non-administrative regions, where "boundary=administrative" whould be the wrong tag.

So since this Regions are already being tagged this way, a renderer should deal with this tag. At least until they are replaced with another community-wide agreed tagging scheme.

maxmichels commented 3 years ago

Maybe the renderer should check if the relation has also the Tag boundary=administrative and then reject it

max-dn commented 3 years ago

In fact, this style does not care about place=region. It renders "region:type" IN ('natural_area','mountain_area') OR "natural" IN ('massif', 'mountain_range', 'valley','couloir','ridge','arete','gorge','gully','canyon')

We could expand this list but I would prefer some "positive" list (like "basin" in ppete2s example), not the absence of something like boundary=administrative, because place=region is used for a lot of things (cultural, natural, administrative..., eg https://www.openstreetmap.org/relation/3585544 ).

maxmichels commented 3 years ago

@ppete2 Do you have some identifiers for region:type that should be added?

The mentioned Alps-relation does not have any region:type identifier - just the members of the relation have the tag and most of them will be rendered as region:type=mountain_area. For Example the Member https://www.openstreetmap.org/relation/2128074 is rendered: https://opentopomap.org/#map=11/47.2071/10.0357

ppete2 commented 3 years ago

I forgot, that the Alps-regions (_"region:type=mountainarea") are already rendered in OTM.

And since some of you explained the rendering "region=place" without any further "region:type=*" might cause problems, cause many adminstrative or historic regions are tagged this way, I also would refuse from rendering it.

I think the best idea is, to tag non-adminstrative and non-historical regions with _"region:type=naturalarea" which is being rendered in OTM. E.g. for the posted exmples https://www.openstreetmap.org/relation/3585544 and https://www.openstreetmap.org/relation/11490442 which are regions whose names are (still) used nowadays.

Regarding https://taginfo.openstreetmap.org/keys/region:type#values this 2 values are by far the most used ones. Maybe treat addional values _"region:type=mountainrange" the same as _"region:type=mountainarea", and "region:type=basin" the same as _"region:type=naturalarea".

max-dn commented 3 years ago

I included mountain_range and basin as value for natural=* and region:type. We will see Machland ( https://www.openstreetmap.org/way/834744233 ) end of august...