registerEncoder understanding issue

Open Source Routing Engine
1

Hi all,

thanks first of all for this great project! I’m currently trying to adapt it to my needs and encountered a problem. I don’t really understand what the encoders are doing and as I’d like to add additional information (like the value of the maxspeed tag) this is a problem.
From what I understand
EncodingManager.registerEncoder( AbstractFlagEncoder encoder )
is using the same long variable to add the WayBits and the RelationBits. Now I was debugging through the Test-case “OSMReaderTest.java” and when the encoder for “FOOT” ist added (line 103 of OSMReaderTest.java), I can see in “registerEncoder” that the nextWayBit = 18 while nextRelBit = 3. The Bitmasks are set accordingly. Is that correct. Aren’t we now using the same bits for the Way information of the car encoder and the relation information of the foot encoder?

So for the bitmasks of the two encoders “car” and “foot” I observe the following:

wayBitMask_car = 0000 0000 0000 0000 0000 0000 1111 1111
wayBitMask_foot = 0000 0000 0000 0011 1111 1111 0000 0000
relBitMask_foot = 0000 0000 0000 0000 0000 0000 0000 0111

Which would mean, while the wayBits for foot and car are exclusive, the relBits of foot interfere with the waybits for the car.
Is this a bug or am I missing something? Maybe both encoders get an own long flag variable? But if so, why are the wayBits for foot then shifted such, that they don’t hit the wayBits for the car encoder?

Thanks
Stefan

2

Hi Stefan,

yes, this is a bit tricky and hopefully we can make this easier in the next months.

Currently relation information is, as you’ve found out, a different long value and has its own HashMap in OSMReader. Afterwards this value is mixed in in the way bitmask at e.g. this point for foot.

The none-shifting behaviour that you see is the result of that ‘car’ does not overwrite the defineRelationBits like the FootFlagEncoder does. So it should not be a bug and the shifting is necessary if you have multiple encoders like when you have bike and foot which would both require retrieving information from OSM relations.

Still, if you encounter strange stuff, bugs or would like to improve the (internal) documentation - feel free to ask or submit a PR

3

Hi karussel,

grat, thanks for the information! It’s now a bit more clear. The relation bits will be handled in a separate hashmap but in the end, it will be placed in the long VirtualEdgeIteratorState::flags via the priorityWayEncoder bits reserved in defineWayBits.

I enountered that when reserving additional 5bits for the speed limit, the flag size will be violated for many of the JUnit tests (where 3 or more encoders are created). If I wanted to save such additional information - as speed limit - for the edges, is it meaningful to intruduce an additional flag variable in VirtualEdgeIteratorState, or do you have a proposal for a better approach?

Thanks a lot,
Stefan