do not display borders between national parks on lower zoom levels

[matkoniecz]

In some regions there are multiple joining national parks. Western USA is the most impressive, with many protected areas covering significant area with byzantine shapes and topology.

For example in this area where national park borders seems to be drawn by Elbridge Gerry everything is anyway inside a protected area.

As result both on high and low zoom levels is quite bad.

This is not limited to the USA. For example - http://www.openstreetmap.org/#map=7/48.247/24.587 is area where Slovenia, Ukraine and Poland have five joining protected areas.

Note that many joining national parks are curently badly mapped as not joined, so there are some rendering artefacts caused by poor tagging. This effect is welcome rather than a problem but it makes testing harder.

http://www.openstreetmap.org/#map=17/52.57878/14.63135

On higher zoom levels it makes sense to display borders also between joining protected areas, it is open question what should be choosen as threshold (currently in proof of concept all joining borders are eliminated).

I developed it as part of a more complex change, but it stands well also on its own.

I submit it as a issue, not PR as I have only a proof of concept. SQL query is partially a massive HACK/TODO and there are some suspicious rendering articacts (I submitting it anyway, as after days of battling with pg_hba.conf, qgis etc it finally works)).

My code used to generate before/after below is at matkoniecz@3f05be3 (updated code is at https://github.com/gravitystorm/openstreetmap-carto/compare/master...matkoniecz:dissolve_national_parks_proof_of_concept?expand=1)

I will now look for way to correctly compute way_pixels (in case that it is obvious for somebody - comments/hints are welcomed).

In regions like UK with sensible structure of protected areas it should have no noticeable change.

There are some negatives effects - obviously it hides some data about structure of protected areas and is a performance hit.

before/after

here tagging mistakes ale clearly visible:

https://cloud.githubusercontent.com/assets/899988/16359316/b3aaaec8-3b2f-11e6-8b25-3ca418feeb44.png

[matkoniecz]

part of #2194

[matkoniecz]

One important thing that is missing: currently with any displayable nr all, also small nr are displayed. This is obviously unwanted.

At the same time filtering in subquery would have a different poor result - large area made of many small joining protected areas would not be displayed.

[matkoniecz]

Now I see that

AND building IS NULL
AND way_area > 0.01_!pixel_width!::real_!pixel_height!::real

is missing in the new query, adding it back should partially solve problem of displaying too small PR.

[dieterdreist]

sent from a phone

Il giorno 25 giu 2016, alle ore 23:51, Mateusz Konieczny notifications@github.com ha scritto:

For example in this area where national park borders seems to be drawn by Elbridge Gerry everything is anyway inside a protected area.

As result both on high and low zoom levels is quite bad.

I don't think the result is necessarily bad, it depends which information you want to get from the map. If actual borders are like this I think it's good to show these rather than make a cleaner looking less accurate picture by hiding the complex reality

[pnorman]

I like the results, but performance is potentially a big issue, and one that you won't see unless you have a full planet DB. Are there any potential clever Mapnik tricks that would avoid the need to do this in SQL?

I'll sit down and have a good think about ways to do this.

[matkoniecz]

it depends which information you want to get from the map

Yes, for map about national park structure it would be unwanted. But currently such borders are dominating everything else - rivers, roads. In many regions it crosses point where adding more data means that one gets less information.

one that you won't see unless you have a full planet DB

I may be mistaken but this query should be about equally (in)efficient in full planet and simplified osm2pgsql database dump? It querries and processes only (boundary = 'national_park' OR leisure = 'nature_reserve') polygons and all such ways are present in that database.

Pulling polygons from planet_osm_polygon that match protected area tags will take slightly longer in database with additional polygons - but that part is done now anyway.

I considered putting WHERE (boundary = 'national_park' OR leisure = 'nature_reserve') query into third-level subquery (to filter by tags before checking ST_Intersects(way, !bbox!)) but I assumed that quivalent optimization would be anyway performed by databse itself.

And on simplified osm2pgsql database dump database zoom 7 worked. Performance penalty was not large enough to notice without checking rendering time logs.

And AND ST_Intersects(way, !bbox!) really works, as it is able to generate something in simplified dump - version without that works solely for small regional extracts.

Are there any potential clever Mapnik tricks that would avoid the need to do this in SQL?

I thought about doing similar trick to borders (#1107) draw big polygon, slightly larger than NR, then erase polygon of NR size. It should leave border around nature reserves, without borders between them.

I never investigated it further (maybe I am missing something that makes it impossible) as it would falsely make protected areas larger on map than in the reality.

[dieterdreist]

sent from a phone

Il giorno 26 giu 2016, alle ore 11:48, Mateusz Konieczny notifications@github.com ha scritto:

Yes, for map about national park structure it would be unwanted. But currently such borders are dominating everything else - rivers, roads.

I thought this was intentional, we show them very early as one of the few things in low medium zoom levels. Btw, there is some inconsistency, e.g. here: http://www.openstreetmap.org/#map=8/44.941/12.313
as you zoom in, the national park label disappears until quite high zoom levels

[matkoniecz]

here: http://www.openstreetmap.org/#map=8/44.941/12.313 as you zoom in, the national park label disappears until quite high zoom levels

It is because labels for towns appear later than the national park label but with higher priority. I am unsure is it worth changing.

[dieterdreist]

sent from a phone

Il giorno 26 giu 2016, alle ore 14:07, Mateusz Konieczny notifications@github.com ha scritto:

It is because labels for towns appear later than the national park label but with higher priority. I am unsure is it worth changing.

yes, this is the perceived inconsistency: first you see national park labels where towns are not displayed yet, and when these minor towns are displayed at higher zoom levels they have a higher priority than the np labels.

[matkoniecz]

I thought this was intentional, we show them very early as one of the few things in low medium zoom levels.

I agree that showing large protected areas makes sense. I see no point in displaying detailed legal structure of protected areas too early.

[matkoniecz]

I thought about how size of nature reserves after joining them may be calculated

• currently the same value is set to all of them what is clearly horrible
• sum way_area of merged areas - areas covered by multiple protected areas will be counted multiple times, I have no idea how to make such query (see http://gis.stackexchange.com/questions/199978/postgis-st-union-polygons-keep-sum-of-attribute)
• use bounding box of area as equivalent of way_area (distorting for everything except squares, will affect especially long, narrow areas)
• use st_area and rescale it by Math.cos(latitude * Math::PI / 180) to get projected size

[pnorman]

use st_area and rescale it by Math.cos(latitude * Math::PI / 180) to get projected size

ST_Area is in projected units.

sum way_area of merged areas - areas covered by multiple protected areas will be counted multiple times, I have no idea how to make such query (see http://gis.stackexchange.com/questions/199978/postgis-st-union-polygons-keep-sum-of-attribute)

The problem is the ST_Dump.

ST_ClusterIntersecting has a bad API for this and is 2.2 or later only. ST_ClusterDBSCAN has a better API and I could easily write a query that does this, but that is 2.3-dev only.

[matkoniecz]

ST_Area is in projected units.

Thanks for the info!

The problem is the ST_Dump.

What about such query? It is ugly, but it works.

        (SELECT
            way,
            NULL AS name,
            'national_park' AS boundary,
            ST_Area(way)/NULLIF(!pixel_width!::real*!pixel_height!::real,0) AS way_pixels
          FROM (
            SELECT
              (ST_Dump( ST_Union( way ) )).geom AS way
            FROM (
              SELECT
                way,
                boundary
              FROM planet_osm_polygon
              WHERE (boundary = 'national_park' OR leisure = 'nature_reserve')
                  AND ST_Intersects(way, !bbox!)
                  AND building IS NULL
                  AND way_area > 0.01*!pixel_width!::real*!pixel_height!::real
            ) AS unmerged_polygons
          ) AS merged_polygons
        ) AS national_park_boundaries

[pnorman]

Don't return a name or boundary column at all.

To see if ST_Intersects(way, !bbox!) is faster than way && !bbox! requires testing. The former takes longer to evaluate, but returns fewer results which will make the ST_Union faster. It's just a question of which is more significant.

Do we want to handle almost-connected national parks where a railway or road cuts a small line in them?

e.g.

[imagico]

I think it looks promising but am somewhat irritated because in the past one of the goals in further development of this style was reducing/limiting complexity and this change will likely add significant complexity to the code.

[kocio-pl]

What is our current view on the subject? With proposed rendering for boundary=protected_area (#603) I plan to implement soon, there will be more of such borders. On the other hand:

1. This is work by @matkoniecz and I don't know if you are still willing to make it.
2. The concern about complexity hasn't been addressed yet (it's valid problem, but we may decide to do it anyway).