Avoid areas by type?

Developers
1

Hey, i am starting to play around with the graphhopper api (http://148.251.46.152:8989/maps/)
is there any way to avoid areas by type? So for example avoid landuse:residential?

thanks in advance!!

Cheers

2

I came up with this here, but it seems that this is a wrong idea… …at least i get the error: “Error response: cannot process input”

areas:
  stadt:
    features: 
      properties: {
        landuse: forest}

priority:
  area_stadt: {1}

So is there an other way?

3

This is not yet possible. But it is an interesting idea. Also it would be probably nice to avoid server-side predefined areas by name, so that not all requests have to include the lengthy GeoJSON for every request.

4

Ahhh :wink: then it makes sense why this would not work^^
Would it make any sense to create a github request? or what would be the way?

5

I used road names to block. I am actually a very novice learner and hope that it was right way to do. Anyway…I extended CarFlagEncoder and added 2 lines of code:

if (way.hasTag(“name”, “RoadName”)
return EncodingManager.Access.CAN_SKIP;

6

Yes, sure.

I used road names to block.

This is not the best way as it will be slower than with other approaches like marking the roads in a preprocessing step with a certain boolean value.

7

Hey, thanks for that super fast reply!
i tried to do that here… sorry in advance if that was the wrong section…

Cheers!

8

This is not the best way as it will be slower than with other approaches like marking the roads in a preprocessing step with a certain boolean value.

Would you mind to give me an example? I mean where to add that information?

9

The problem is that this is a relation and we currently have only special support for turn relations (see OSMTurnRelationParser). So there are two separate changes required:

  1. parsing areas and storing them somewhere and somehow and
  2. e.g. in a postprocessing step use this information to mark every edge with landusage=forest.

Regarding the 2nd step: usually this information is directly obtained from OSM way tags. See e.g. OSMGetOffBikeParser or OSMRoadClassParser. But you would feed this info from some existing polygons and create e.g. a new Landuse enum to be used as an EnumEncodedValue, see e.g. RoadClass. So a bit suboptimal as a first contribution. But once you have this as an EnumEncodedValue you can use it in a custom weighting.

A contribution where you could get started easier could be to create an OSMLaneParser that feeds into a new “Lane” EncodedValue (that extends UnsignedIntEncodedValue). A pull request in that direction already exists and needs to be rewritten for the new EncodedValue stuff and including some unit tests: https://github.com/graphhopper/graphhopper/pull/1269

10

Hi,
I’m also very interested in this topic. For my case I want to avoid tracks surrounded by landuse:forest.
I would like to work on this Issue #2072.
But I need a little help: I understand that i have to create a new Landuse Enum and use it as an EnumEncodedValue.

  • But where in the graphhpopper code would you feed the area information into the graph? Would that be in the setArtificialWayTags in the OSMReader class?
  • And where would you try to extract the area information from the OSM File? Would that also be in the OSMReader class?
11

Yes, this can work if the landuse information is stored in ways. Or is it stored in relations (too)?

And where would you try to extract the area information from the OSM File? Would that also be in the OSMReader class?

Yes, if it is stored in ways only then this is simpler. If it is in relations then this can get very tricky or might require even changes to OSMReader.

12

It looks like the majority of landuse=* tagging is done using ways, and only around 5% is done using relations: https://taginfo.openstreetmap.org/keys/landuse?filter=all#overview. But that does not mean it is easy to use this data in our OSMReader, because landuse is not just another additional tag on the ways of the road network (highway), but rather there are extra (closed loop) ways tagged as landuse which specify some area and what we/you probably want is figure out which highways are crossing these areas.

Like I suggested in the GitHub issue you mentioned, GraphHopper already provides a mechanism to set encoded values for all edges going through some area (custom areas). So the most basic approach might be extracting the landuse ways (closed Polygons) from OSM with any tool you like, store them as GeoJson on your disk and use these Polygons as custom areas. All you will have to do on the GraphHopper side is to create a landuse encoded value and a corresponding parser and you will be ready to use the landuse information in a custom model.

I’m not sure we really need this but we could also implement the first part in GraphHopper (parsing the landuse ways and feeding them as Polygons/custom areas to our tag parsers).

13

It looks like the majority of landuse=* tagging is done using ways, and only around 5% is done using relations: https://taginfo.openstreetmap.org/keys/landuse?filter=all#overview.

Only 5% of all OSM elements using the landuse tag are relations, but apparently these relations can have very many polygons as members and therefore cover a large amount of forestry areas for example.

I built a little prototype that covers ways tagged with landuse=* here