New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding rendering for boundary=protected_area [WIP] #2830

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@kocio-pl
Collaborator

kocio-pl commented Sep 13, 2017

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
i9rc68al
After
a8wbjmsy

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 13, 2017

Collaborator

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?

Collaborator

kocio-pl commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mboeringa

mboeringa Sep 13, 2017

@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'))

mboeringa commented Sep 13, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 13, 2017

Collaborator

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

Collaborator

kocio-pl commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mboeringa

mboeringa Sep 13, 2017

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).

mboeringa commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 13, 2017

Collaborator

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?

Collaborator

kocio-pl commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mboeringa

mboeringa Sep 13, 2017

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.

mboeringa commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 13, 2017

Collaborator

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.

Collaborator

kocio-pl commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 13, 2017

Collaborator

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
Collaborator

kocio-pl commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mboeringa

mboeringa Sep 13, 2017

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.

mboeringa commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 15, 2017

Collaborator

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.
Collaborator

pnorman commented Sep 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 22, 2017

Collaborator

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.

Collaborator

kocio-pl commented Sep 22, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment