Adding rendering for boundary=protected_area [WIP]

[kocio-pl]

Resolves #603.

This code is currently quite simple (rendering protected_area the same as national parks and nature reserves), but it needs to be enhanced to render only those with protect_class=1-7,97 (as I understand the outcome of the discussion) and I don't know yet how to write such query, so help would be welcome.

Just a proof that it really works (nothing fancy or new about the rendering):
Before

After

[kocio-pl]

It looks like the following syntax:

WHERE (boundary = 'national_park' 
       OR leisure = 'nature_reserve' 
       OR (boundary = 'protected_area' AND tags->'protect_class' IN ('1','2','3','4','5','6','7','97')))

is working and is readable, so the question is if that meets our coding standards and if it can't be done in a better way?

[mboeringa]

@kocio-pl ,

Just a warning: especially with protect_class 5-7 and 97, you are likely to pick up a lot of either very small, sometimes culturally / historically significant areas, or vast tracts of agricultural land or water surfaces.

E.g., the European "Natura 2000" protected areas, cover huge and many areas in Europe, as said including vast tracts of agricultural land and inland water / sea surfaces that most people will not even be aware of being "nature protected". E.g. have a look at this webservice:

http://natura2000.eea.europa.eu/

As to historically significant areas: I have even seen individual houses having been grouped into a multipolygon relation because they were in some historically significant architectural style in a city neighborhood and classified e.g. as protect_class=5 "protected landscape". You definitely do not want to catch these... These can especially pop-up with classes 5-7, 97 and 98 (98 with World Heritage Convention / UNESCO world heritage).

You can exclude some of this heritage related stuff by adding a clause like:

(historic IS NULL OR historic IN ('no')) AND (heritage IS NULL OR heritage IN ('no'))

[kocio-pl]

Thanks! This is what we need here - the more precise rules, the better, because as we can see, protected areas can be very different.

[mboeringa]

I would definitely also advice you to make a test rendering, e.g. in a wide area around / covering Berlin (one of the places I saw boundary=protected_area being used in some unexpected ways).

[kocio-pl]

I've tried to evaluate the resulting query in a proposed location using Overpass Turbo. This query in wizard:

boundary=protected_area 
and protect_class~"[1-7]" 
and leisure!=* 
and heritage!=* 
and historic!=* 
in Berlin

gave me this:

http://overpass-turbo.eu/s/rHf

This is not accurate (I was for example not able to find out how to construct proper regex excluding 22 and including 97, but regex documentation was not too deep for me), but gives me impression, that even this set of rules would be too broad. Reducing regex to 1-6 was more reasonable:

http://overpass-turbo.eu/s/rHj

and replacing it with 97 gave no data on this area:

http://overpass-turbo.eu/s/rHk

Any comments or hints on this?

[mboeringa]

As to class 97 (or for that matter any other class), it could well be that it is simply not available / not used in that area, so I see no problem with the query not returning anything in Overpass Turbo

It of course also all depends on how people have tagged stuff. E.g., even though the Wiki lists Natura 2000 areas under class 97, I wouldn't be surprised to see some areas under other classes, or not tagged with protect_class at all, but maybe just leisure=nature_reserve.

You probably already tried, but if you drop all restrictions related to leisure, historic and heritage, you can clearly see some of the area / neighbourhoods I was talking about, that are tagged due to architectural heritage reasons. A lot of them especially in the South Western quarters of Berlin, near the Grünewald:

http://overpass-turbo.eu/s/rHl

Admittedly, my experience with Overpass Turbo and the query language, is also limited, so I can't really help you it with that syntax.

[kocio-pl]

In this ticket I try to be focused on creating working code, not explore the subject (we can discuss it more on #603). Please test the rules as much as possible (I have intentionally removed leisure=* to hide already rendered national parks and nature reserves) in different places. For example "1-6" query in Poland gives 6 POIs and 27 polygons, "7" - 1 polygon and "97" - 21 ways and 23 polygons, so the numbers are reasonable, but it would be good to check if they are what we really want.

We should deal only with nature-related areas now, because it's already quite complex problem.

[kocio-pl]

In Germany it would be probably too much of them (POIs/ways/polygons):

• 1-6: 20/95/777
• 7: 21/10/383
• 97: 0/2/42

[mboeringa]

We should deal only with nature-related areas now, because it's already quite complex problem.

Yes, there is an astounding number of regional, national and international arrangements even for nature-related areas, probably with lots of overlaps of areas as well.

[pnorman]

Given the number of protect_classes, boundary = 'protected_area' AND tags->'protect_class' IN ('1','2','3','4','5','6','7','97') is probably the best way to write it. A few points

• We only want to pick up things equivalent to nature reserves or national parks
• You will need to review the performance, in particular partial index usage.
• I'm iffy on rendering two sets of tags for national parks or nature reserves, because we already have tags for those. Can we exclude those protection classes so we're only rendering stuff we don't currently get? Rendering a different tag would encourage people to use it, causing problems for other data consumers.

[kocio-pl]

It looks to me like much more complex problem then when I have started this code. I'm not sure what level of protection would be safe, and which would cause just a clutter on a map. Maybe some areas need proper retagging to not promote parallel set of tags, as Paul have noticed, but that's far beyond my area of interest. Performance testing would be another hard thing to do.

Since I'm not ready to make a research to check how the SQL query should look like, I'm closing it now. If somebody is willing to take a research part, I would take care of the coding - in this case it's the easiest part anyway.