So here’s what I found after comparing debug info provided by verygreen with the tiles data.
DEBUGgpsLat and DEBUGgpsLon are displayed with barely three digits after the decimal point. That’s not enough to determine the road, because it’s approximating position within like 100m range. Much more precise is geohash from DEBUGCurrentGeohash, but this also can be tricky (there is one example, where whole road is in the middle of the geohash bounds, but the relevant road is barely touching the corner).
The most interesting parameter is DEBUGtileNearestSpline. This simply shows ID of the spline. The problem is, that I decided to display this in HEX format in the viewer, while it is simply shown as decimal in the debug info. When searching for it on the map it looks consistent with the position defined by the geohash and it looks like the metadata is actually taken from this spline.
Below the spline ID entry is DEBUGtileSplineT parameter. This looks to be a value in range 0…1 showing the position of the car along the spline. This directly refers to the Begin/End ranges defining zones along the spline. Knowing the spline and this parameter it is possible to closely determine the position of the car on the map.
Trying to find which tile spline properties correlate to which debug parameters I found this:
F21 (Local road) correlates with DEBUGautoParkEnabled/autoParkEnabled.
F22 (aka "Not Divided") looks to match DEBUGautosteerRestricted/currentBranchIsAutosteerRestricted.
DEBUGpedalMisapplicationMitigationEnabled/pedalMisapplicationMitigationEnabled is active only in places where tile spline was not matched, but it happened on a parking lot, surrounded by splines with F23 (parking) active, so I’m assuming that F23 is actually related to pedalMisapplicationMitigation.
DEBUGradarBrakingEnabled/radarBrakingEnabled looks to be correlated with F25. Previously I incorrectly linked F18 with it. It is important to note, that F25 is active only in tiles from the "live" branch, so while searching for this property "live" branch must be used instead of "dev". In all tiles I checked from the "dev" branch F25 is always equal to 0, I don’t know why.
DEBUGcontrolledAccess, currentBranchIsControlledAccess, DEBUGonHighway and sideCollisionAssistEnabled are always the same and correlate with F24 (Highway) and F26 (Highway). F24 and F26 also always have the same value in all tiles I checked, so I have no way to differentiate them.
DEBUGramp/currentBranchIsRamp are of course active when Ramp Type in the tile viewer shows either On Ramp or Off Ramp.
DEBUGspeedLimit/speedLimit is consistent with Speed Limit in tiles (when converted to miles per hour), although debug info sometimes show non empty speed limit when it is missing in tiles, which proves that there is another source for speed limits.
DEBUGtileTrust correlates with F7. It is shown as a number in the debug info, but it only accepts values 1 or 0 (viewer shows F7 as Yes/No). I saw the name Trust in some photos of debug screens and associated it with F13 (that I named Trust in the viewer). Turns out It was a mistake, and F7 should be called Trust. F13 however does not match to anything in the debug info.
DEBUGtileBlacklistAvailable is active when the spline has non-empty F5 list (that I previously called Line Hints). When this flag is active, field DEBUGblacklistSource also shows Tile instead of None. At the end of the debug list there are fields like rejectLeftFreeSpace, rejestRightLane, etc. It would make perfect sense to me if those parameters were taken from Blacklist stored in F5 list, but all reject properties are always false in the debug info, even when the car position falls into an F5 zone, so it is still not clear.
DEBUGnextBranchDistanceInMeters and DEBUGnextBranchOffRampSide are most likely taken from the list in tiles that I named Next Ramps. Every entry of this list contains the distance from the end of the current spline to the beginning of the ramp spline, and a flag. Looks like the flag values are: 1:MPP, 2:Left, 3:Right. When named like that the first list entry corresponds to DEBUGnextBranchOffRampSide. I tried to calculate the distance to the branch from the current position by adding the remaining distance of the spline to the distance reported in the Next Ramps list [(1 – T) * SplineLength + DistanceToNextRamp] and it fits to the value from DEBUGnextBranchDistanceInMeters, not always perfectly, but close enough. MPP side description is used when the next spline is straight ahead, but I have no idea what it means.
I previously was under impression that F10 is a distance from the center of the spline to the left edge of the road, and F11 is a distance from the center of the spline to the right edge of the road (or the other way around, it’s hard to tell from google satellite photos). So the fact that the sum of those fields end up being the width of the road would make perfect sense. I compared the sum of F10 and F11 with DEBUGtileSplineWidth and it matches perfectly.
One thing to note is that Width does not have to be a width of the road. Its name suggests a width of the spline, so it could define for example an area of effect for the spline (a maximum allowed distance from the spline, to still be affected by the spline). There’s a lot of examples in the tiles where it is significantly larger than the width of the road.
acceptBottsDots seems like something that would be related to maps, but I didn’t found any correlation with tiles.
I don’t know what F18 means. It is changing in the splines for which the debug info were gathered, but does not match to anything in the info.
DEBUGgpsLat and DEBUGgpsLon are displayed with barely three digits after the decimal point. That’s not enough to determine the road, because it’s approximating position within like 100m range. Much more precise is geohash from DEBUGCurrentGeohash, but this also can be tricky (there is one example, where whole road is in the middle of the geohash bounds, but the relevant road is barely touching the corner).
The most interesting parameter is DEBUGtileNearestSpline. This simply shows ID of the spline. The problem is, that I decided to display this in HEX format in the viewer, while it is simply shown as decimal in the debug info. When searching for it on the map it looks consistent with the position defined by the geohash and it looks like the metadata is actually taken from this spline.
Below the spline ID entry is DEBUGtileSplineT parameter. This looks to be a value in range 0…1 showing the position of the car along the spline. This directly refers to the Begin/End ranges defining zones along the spline. Knowing the spline and this parameter it is possible to closely determine the position of the car on the map.
Trying to find which tile spline properties correlate to which debug parameters I found this:
F21 (Local road) correlates with DEBUGautoParkEnabled/autoParkEnabled.
F22 (aka "Not Divided") looks to match DEBUGautosteerRestricted/currentBranchIsAutosteerRestricted.
DEBUGpedalMisapplicationMitigationEnabled/pedalMisapplicationMitigationEnabled is active only in places where tile spline was not matched, but it happened on a parking lot, surrounded by splines with F23 (parking) active, so I’m assuming that F23 is actually related to pedalMisapplicationMitigation.
DEBUGradarBrakingEnabled/radarBrakingEnabled looks to be correlated with F25. Previously I incorrectly linked F18 with it. It is important to note, that F25 is active only in tiles from the "live" branch, so while searching for this property "live" branch must be used instead of "dev". In all tiles I checked from the "dev" branch F25 is always equal to 0, I don’t know why.
DEBUGcontrolledAccess, currentBranchIsControlledAccess, DEBUGonHighway and sideCollisionAssistEnabled are always the same and correlate with F24 (Highway) and F26 (Highway). F24 and F26 also always have the same value in all tiles I checked, so I have no way to differentiate them.
DEBUGramp/currentBranchIsRamp are of course active when Ramp Type in the tile viewer shows either On Ramp or Off Ramp.
DEBUGspeedLimit/speedLimit is consistent with Speed Limit in tiles (when converted to miles per hour), although debug info sometimes show non empty speed limit when it is missing in tiles, which proves that there is another source for speed limits.
DEBUGtileTrust correlates with F7. It is shown as a number in the debug info, but it only accepts values 1 or 0 (viewer shows F7 as Yes/No). I saw the name Trust in some photos of debug screens and associated it with F13 (that I named Trust in the viewer). Turns out It was a mistake, and F7 should be called Trust. F13 however does not match to anything in the debug info.
DEBUGtileBlacklistAvailable is active when the spline has non-empty F5 list (that I previously called Line Hints). When this flag is active, field DEBUGblacklistSource also shows Tile instead of None. At the end of the debug list there are fields like rejectLeftFreeSpace, rejestRightLane, etc. It would make perfect sense to me if those parameters were taken from Blacklist stored in F5 list, but all reject properties are always false in the debug info, even when the car position falls into an F5 zone, so it is still not clear.
DEBUGnextBranchDistanceInMeters and DEBUGnextBranchOffRampSide are most likely taken from the list in tiles that I named Next Ramps. Every entry of this list contains the distance from the end of the current spline to the beginning of the ramp spline, and a flag. Looks like the flag values are: 1:MPP, 2:Left, 3:Right. When named like that the first list entry corresponds to DEBUGnextBranchOffRampSide. I tried to calculate the distance to the branch from the current position by adding the remaining distance of the spline to the distance reported in the Next Ramps list [(1 – T) * SplineLength + DistanceToNextRamp] and it fits to the value from DEBUGnextBranchDistanceInMeters, not always perfectly, but close enough. MPP side description is used when the next spline is straight ahead, but I have no idea what it means.
I previously was under impression that F10 is a distance from the center of the spline to the left edge of the road, and F11 is a distance from the center of the spline to the right edge of the road (or the other way around, it’s hard to tell from google satellite photos). So the fact that the sum of those fields end up being the width of the road would make perfect sense. I compared the sum of F10 and F11 with DEBUGtileSplineWidth and it matches perfectly.
One thing to note is that Width does not have to be a width of the road. Its name suggests a width of the spline, so it could define for example an area of effect for the spline (a maximum allowed distance from the spline, to still be affected by the spline). There’s a lot of examples in the tiles where it is significantly larger than the width of the road.
acceptBottsDots seems like something that would be related to maps, but I didn’t found any correlation with tiles.
I don’t know what F18 means. It is changing in the splines for which the debug info were gathered, but does not match to anything in the info.
Last edited:
