Check if and how we can include accessibility to green areas

[UJehle]

Quite challenging, because these are areas and not points. Maybe we can display the icon in the middle of the area and mark a green space as accessibile as soon as the isochrone overlaps with the area?

[EPajares]

@rafleo2008 is working on this. We are experimenting still with different solutions.

[EPajares]

Preliminaty results are that the entrances to the parks are derived and we use them to calculate accessibility. This could result in many entrances, so for the visualization on the client we have to think about a way to show them as areas instead of points. The same could be true for other amenities (e.g. outdoor gyms).

[UJehle]

Sounds good! Yeah, areas make more sense then points, especially when thinking about big green areas as Englischer Garten. Maybe just shading the area in green is sufficient?

[rafleo2008]

Up to now, I have been working on creating a new table called aois (areas of interest), with the same structure than pois. This table can store areas with their respective amenity classification and same structure than pois

In the specific case of parks/ green areas, I was doing some trials where I filtered the green areas in this way:

SELECT osm_id,'polygon' as origin_geometry, access,"addr:housenumber" as housenumber, 'park' AS amenity, tags -> 'origin' AS origin, tags -> 'organic' AS organic, denomination,brand,name, operator,public_transport,railway,religion,tags -> 'opening_hours' as opening_hours, ref,tags, way as geom, tags -> 'wheelchair' as wheelchair FROM planet_osm_polygon WHERE leisure = 'park' AND (ACCESS IS NULL OR ACCESS='public') AND ST_AREA(way::geography) >=300000;

Please note that this code filters zones with an area greater than 300.000 m2. In the case of Münich, that means 22 green areas, that can be shown in the picture.

Finally, I am also working on the creation of a new visualization function (like in pois) where we can filter areas with the same variable that pois. I used a function that calls the argument amenity, but it still does not work correctly. I should be missing something in between.

Therefore, I would like to ask you two things:

1. Do you think 300 000 m2 is enough to filter the big areas to be shown in GOAT?, should I increase/decrease this value filter?
2. Can you give me some extra guidelines about how to connect the POIS filter with this new layer?

Finally, I am also working on the definition of the SLD style to show it in the front end.

[EPajares]

Thanks Rafael! 1.This is a very difficult question as it could vary from place to place. @UJehle and me we will check it again.

2. We need some new Javascript functions. It might be the best if @majkshkurti is handling this. I will discuss it with him.

@rafleo2008 you could already create the SLD-styles in Geoserver. Maybe you find good existing styles that you could adjust. Let's stay in contact.

[rafleo2008]

OK, I will define the area as a variable in goat_config, as well as implement the code in POIS. This will appear in the next PR

[UJehle]

Hi Rafael, we just had a look at the green areas in Munich. We think it makes also sense to include other green areas, not only parks, maybe you can use this query: select * from planet_osm_polygon where (leisure IN ('park','nature_reserve','garden')OR landuse IN ('village_green','grass') AND (access is NULL OR access not in ('private','customers', 'permissive','no'));

Then do the following:

1. merge all areas that border or overlap
2. filter in two categories:
   • all green areas of a size bigger than 20.000m²
   • all green areas of a size bigger than 300.000m²

[rafleo2008]

Just a few updates here:

1. The thresholds for parks (as in this case) has been stored in the variable container, therefore, each new area amenity type should be updated there (for example, historic areas).
2. I defined two new layers in the group of Point of interest, called Areas of interest and Areas of Interest (detailed), inside, there is a function that needs the variable %amenities%(like in POIS) for filtering.

Finally, I think the next step is to derive the POIS access to calculate the accessibility to parks, right? @EPajares

I'll create the PR soon with these adjustments.

[EPajares]

Great! I will check the PR. So you are having a new table called "aois" and we can create two layers from there? One Areas of Interest and the other one Areas of Interest (detailed)?

Yes the next step would be getting the entrances. From the calculation side I would treat it like POIs that have multiple entrances. But for the visualization I would shop the area and probably in addition the entrances at higher zoom levels.

[rafleo2008]

Done!, the PR and the description are here https://github.com/goat-community/goat/pull/760

[EPajares]

Great I have reviewed the changes! In principle everything looks good. There are some things we might have to discuss.

• What about forest areas? Do we want to include them.
• I think we should make the style more generic and also change the classification of "small zone" and "large zone" in something like small park and large park. Like this we can add more categories in the same table e.g. forests, rivers, lakes etc...
• How can we fuse further datasets? @UJehle any suggestions on data that could be useful here?

[UJehle]

@EPajares and me just discussed the further steps:

• [x] include also other recreation areas (landuse=forest and natural=water). For water we can maybe have two categories: "Bathing lake" (if sport=swimming) and "other Waters". --> task for @rafleo2008
• [x] check for other data sets --> task for @UJehle
• [x] define entrance points: As entrance points we should display all interesections of foot-/cyclepaths with the green area. These entrance points can then be used for the routing and the isochrone result box. --> task for @rafleo2008

• [ ] As a last step, when the backend functions are finished, the client needs to be adjusted. --> task for @majkshkurti

[rafleo2008]

The areas of interest, as well as the function to compute intersetctions, can be found in the last PR https://github.com/goat-community/goat/pull/810.

[UJehle]

Hi Rafael, I just checked the green areas in Hasenbergl which were missing. I would suggest to also include "natural=scrub" and "natural=heath". And I just fetched your changes, had a look at the parks and am wondering why this one is not included: https://www.openstreetmap.org/edit#map=16/48.1137/11.5457 (Park an der Plinganserstraße)

One more comment: sometimes, there are several green area right next to each other. I think it would make sense to combine them (at least for the compution of the area and the decision if the area_limit is reached). E.g. Feldmochinger See:

Otherwise, there are small areas inbetween missing (visualized in green):

[rafleo2008]

Many thanks Ulrike, I am working on this and send my updates once I get new advances

[UJehle]

Just as a record, I checked the ATKIS data on green areas and waters. They are quite similar to the OSM data, I would even say on average the OSM data are more accurate.

[UJehle]

The best alternative data sources I have found so far (unfortunately all of them are just lists and no spatial data):

• Parks: https://www.muenchen.de/sehenswuerdigkeiten/parks-und-gaerten.html (when you scroll down, there is a list)
• Parks: https://de.wikipedia.org/wiki/Liste_M%C3%BCnchner_Gr%C3%BCnfl%C3%A4chen (I know, wikipedia is not the best source, but here all parks from the link above are listed with the coordinates and size)
• Parks: https://www.muenchenwiki.de/wiki/Parks
• Forests: https://de.wikipedia.org/wiki/Liste_M%C3%BCnchner_Waldgebiete

--> could be useful to check the names of the green areas

[rafleo2008]

Thank you!, Even the list could help us to add the correct names to OSM 💯

[rafleo2008]

Hello @UJehle, I was checking the tag "natural=heath" and "scrubs", and I think those areas cannot be classified as parks or forests. Should we create a new category for them?.

Moreover, reading the descriptions, I think those areas do not permit recreation or leisure at all, in that case, they could be out of the scope of GOAT. What do you think?

I also was trying to find the park you said is not there: Is this the park you've mentioned? I was looking at it but I could not find it.

many thanks

[UJehle]

Hi @rafleo2008! Thanks for double checking the "heath" and "scrubs". You are right, those categories are neither fitting to "park" nor to "forest". They may be not the most attractive green areas, but still they can be used for recreation (maybe not for playing football/tennis but at least for going for a walk). Maybe we just make a new category and call it "Heath and Scrubs".

Where did you found that those areas do not permit recreation or leisure at all? I guess for some areas this will be true, but at least for the big areas in Munich, for example this "scrub" it's not the case: When I was there last summer, a lot of children were playing in the scrub and many persons going on a walk with their dog.

For the small "scrub" areas it may be true and most of them are rambling weeds. But those will luckily be filtered out by your algorithm.

Yes, exactly. This is the park that I meant. Was it already included? Maybe I have overseen it.

[rafleo2008]

Yes, you're right, I checked OSM tag and the pictures showed places fully covered with bushes like this one:https://upload.wikimedia.org/wikipedia/commons/8/8e/Starr_010831-0015_Morella_faya.jpg . According to the pictures, it does not look as places where you can't walk. But as you mentioned, it is different in MUC, so I'll create the category. 👍 https://wiki.openstreetmap.org/wiki/Tag:natural%3Dscrub

[rafleo2008]

Hello @UJehle, I have added the heath and scrub areas to the areas of interest, also, I applied the merging areas before filtering by size, still pending naming issues, but I think that's mostly linked with OSM mapping.

[UJehle]

@rafleo2008 awesome, thanks! I will check the PR later.

[UJehle]

Hi @rafleo2008 Thanks a lot for the PR. It looks pretty good. I just found a few issues that we may have to address:

1. for the entrance points: if the intersecting path is a bridge (tag "bridge"="yes"), we should not set an entrance point. Example: https://www.openstreetmap.org/#map=17/48.10477/11.64825 (Neuperlach, Ständlerstraße – Albert-Schweizer-Straße)

2. there are some aois, especially grass areas, with no (or just very few) entraces, here we somehow should generate entrances. Examples: https://www.openstreetmap.org/#map=18/48.08736/11.65243
   (Neuperlach, Arnold-Sommerfeld-Straße)
   https://www.openstreetmap.org/#map=17/48.04429/11.61301 (Taufkirchen) For forest areas it may be true that they are not accessibile if there is no path through it, e.g. this forest: https://www.openstreetmap.org/#map=16/48.0910/11.5922 (between Cincinnatistraße and Tegenseer Landstraße) If there are no paths through it you may only be able to walk around --> thus the area is not accessible.

We may have the same entrace problem when it comes to the accessibility of waters. I will create a new issue for that.

@majkshkurti as this feature is now nearly finished, could you please adjust the frontend and include the Areas of Interest (aois) as Thematic Data? (See my comment above from 1. October) As categories we need the following:

• small_park
• big_park
• small_forest
• big_forest
• small_heath_scrub
• big_heath_scrub
• waters
• swimming_lake

[EPajares]

I fixed some issues that occured with the new function generate_entries_from_polygon.sql.

• The way the function was written seemed to overcomplicate things. @rafleo2008 please check this adjusted implementation. I think the results are correct and performance is more or less the same.

• In case of overlapping line - line intersection the function returned POIs as Linestrings. This was messing up some downstream routines as we don't expect a pois to be a linestring. I fixed this by checking the intersection geometry.

[EPajares]

@UJehle and @majkshkurti let's discuss the following days the client implementation.

[EPajares]

Concerning the fact that many grass areas are not connected to the street network we probably should think about an alternative approach then creating arbitrary new points. I think the same issue we will have with the lakes. So maybe it makes more sense to find a way to do intersections by area for these amenities.

[UJehle]

@EPajares awesome, thanks! Yeah, let's discuss this in the following days. Yes, for the grass areas and lakes, I have opened a new issue: #871 .