OpenStreetMap tags in FlagEncoder vs custom model configuration?

[eheu.dev]

Hi, sorry in advance for the brief format of my question

What I’m ultimately trying to accomplish is using custom model configuration as an alternative to a custom FlagEncoder class.

As I want to change the speed of the bad surfaces, I’m configuring my custom model as such:

{
  "if": "surface == COBBLESTONE || surface == GRASS_PAVER || ...",
  "limit_to": 15
}

However, while the cobblestone surface is available in custom model configuration, it seems that grass_paver isn’t. Yet the grass_paver tag seems to be available in the bad surface mapping of the CarFlagEncoder.

How come there’s this discrepancy? And how would I go about making the grass_paver tag available for custom model configuration? Would you suggest another approach entirely?

EDIT: Actually, no surface tags work: encoded value 'surface' not available. I guess I need to add surface to graph.encoded_values.
EDIT: Point still stands, how come e.g. grass_paver isn’t available? It doesn’t seem to have been deprecated.

[leightonl]

Hi there @eheu.dev

Perhaps try to add “GRASS_PAVER” to the list in Surface.java Encoded Values.

Or would the highlighted “GRASS” be “GRASS_PAVER”? I would suggest first see if this is what you’re looking for:

“if”: “surface == GRASS” …

[eheu.dev]

Hi @leightonl

I’m sure that grass and grass_paver are distinct tags.

Thanks for pointing out the relevant source code - but I wonder if grass_paver being left out is an oversight or due some issue with it. If the former, I guess I might as well open a PR to include it.

I guess that in general, those enums should include all the values listed on the OpenStreetMap wiki page for each corresponding tag key, like the Surface page which includes grass_paver.

[karussell]

We won’t include all values for the surface tag but we could easily include a fallback from grass_paver to grass (see OSMSurfaceParser).

due some issue with it

Not an issue and also not decided, but the more values we support the more the end user has to support.

[eheu.dev]

the more values we support the more the end user has to support.

If e.g. the Surface enum were to include grass_paver, but the end user doesn’t use it in custom model configuration, what will be the default behaviour? Does Graphhopper maybe treat it like OTHER or perhaps MISSING? Also what does ‘support’ mean specifically in this context?

Thanks!

[karussell]

Does Graphhopper maybe treat it like OTHER

Yes, currently.

Also what does ‘support’ mean specifically in this context?

Sorry. This was a bit unclear. If the user needs a change for when “the surface is grass” then the user would need to support such special “sub”-tags too. So it would make more sense to set the value to grass for all grass_* “sub”-tags instead of creating a value for all unique OSM tags. And I guess in your case this would be sufficient too (?)

[eheu.dev]

Great, thanks for clarifying!

I have another few questions in the same vein:

1. If I want to handle the hgv tag from my custom model, am I correct that the steps to do so are:

• Implement a hgv enum
• Add it to DefaultEncodedValueFactory
• Implement a hgv TagParser
• Add it to DefaultTagParserFactory
• Add hgv to graph.encoded_values in config

2. I see the argument for leaving out some niche tag values like grass_paver.
   What’s the reasoning behind whether to include tags like hgv?

3. Are FlagEncoder classes on the way out like @otbutz suggests in this issue, or is that undecided?

[karussell]

Add it to DefaultEncodedValueFactory
Add it to DefaultTagParserFactory

There is no need to fork GraphHopper - you can add those encoded values in an application that just uses GraphHopper. You can implement the factory interface and set this in the GraphHopper class, so that it will replace the default factory.

What’s the reasoning behind whether to include tags like hgv?

This sounds useful and no reason to not include it

Are FlagEncoder classes on the way out like @otbutz suggests

Yes, FlagEncoder classes will be removed soon (^TM) but not clear when. There will be encoded value collection. See the PT module that is already usable without FlagEncoders and comes with such a collection: https://github.com/graphhopper/graphhopper/blob/master/reader-gtfs/src/main/java/com/graphhopper/gtfs/PtEncodedValues.java

[karussell]

And regarding grass_paver: we would certainly accept a PR where this tag is considered while parsing instead of putting it in OTHER (i.e. it would go into grass).