I was wondering why? IMHO, if an encoder registers the GetOffBike encoded value, it should be also picked up in the instruction generation. Or is there an issue that if you register bike and car for example it will also pick up the GetOffBike for car?
For example if I create a new bicycle encoder but don’t want to reuse the BikeCommonFlagEncoder, I can’t use GetOffBike.
I think Country is a great example, where an Enum is too limiting.
The other examples I have are quite custom, where I want to add something that makes no sense in the general case.
I think GraphHopper’s Enums are very well crafted and thought through. I also agree that they are a very elegant way to solve this. In my own implementation I would prefer Enums over Strings every time. I think it makes no sense to store unknown strings, these should be defined beforehand.
My issue is that if I use GraphHopper as a library, I can easily create my own Enums with all the values I like and parse them. But then I can’t use them in some of the deeper levels of GraphHopper, like the instructions. And I also cannot change the existing Enums to something else so that I could abuse the existing Instructions code - that’s why I was thinking about a way to make the instruction generation extendable . I think the instructions are one piece of code where custom EncodedValues could be important.
So I think my issue could be resolved by adding a setter to GraphHopper like
setInstructionsFromEdges that I can use to pass down my custom instruction generation. My preferred way would be to pass some hooks to the instruction generation, so that it’s possible to slightly alter the creation of instructions, like when an instruction is created and the content of the instruction. This could be done by extending the InstructionsFromEdges class and to allow for example to overwrite the getTurn method and maybe a way to change the name and annotation of the instruction.
But I also understand that this is a bit of a special case . Probably most people wouldn’t want to touch the instruction generation .