Avoid areas by type?

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

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?

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.

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?

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;

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.

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


Cheers!

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?

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

Powered by Discourse