Return datasource names along with datasource annotation

[danpat]

Issue

We currently expose the datasources annotation, which returns the index of the datasource as supplied with the --segment-speed-file parameter to osrm-contract or osrm-customize.

This PR exposes the string version of that - the actual filename (minus file extension) that was passed to --segment-speed-file. This is useful for getting a human readable version of the annotation, rather than needing to jump through hoops to figure out which index matches to which file supplied.

The new format adds a metadata sub-structure, and the datasource_names list resides therein:

annotations: {
    datasources: [ 0, 1, 2, 3 ],
    metadata: {
        datasource_names: [ 'lua profile', 'traffic1', 'traffic2', traffic3' ]
    }
}

Tasklist

• CHANGELOG.md entry (How to write a changelog entry)
• add tests (see testing documentation
• review
• adjust for comments
• cherry pick to release branch

[TheMarex]

Thanks for taking a stab at this! But we should re-consider adding a new annotation type for this. It might be easier to just add a new property to the RouteLeg object something like datasource_name that lists the names of the data sources if you pass annotations=datasources. That would get around the old "many strings in vector" problem and be more consistent with the current API. Basically we only need to add the dictionary for our dictionary encoded data sources.

[danpat]

Ah, good idea. How about just putting it inside the annotations object, like so?

  routes: [ {
     annotations: { datasources: [0,2,1,1,1,2,1],
                    datasource_names: ["lua profile","traffic1","traffic2"]
  }
  }]

[TheMarex]

Ah, good idea. How about just putting it inside the annotations object, like so?

Yeah that could work, the only concern is that people could be confused about the fact that it behaves differently then other entries in annotations.

[danpat]

@TheMarex I know, I wish we'd thought ahead and could put this under datasources: { names: [...], ids: [...] } or something.

I'll put it under annotations, at least that way it's somewhat tied to the annotations= query parameter. I'll make sure the docs are up-to-date. Although most annotations work on a per-segment or per-coordinate basis, there's no contract that says they have to.

An alternative, maybe to try to future-proof this a bit, might be to add a metadata thing inside annotations, like:

{
  annotations: {
    metadata: { datasource_names: [...] },
    datasources: [....],
    speeds: [...]
  },
  ...
}

This would give us a spot to put future metadata like this so we could say "the metadata property contains data used by other annotations" or something, and would be the only exception to the per-segment/per-node pattern.

[danpat]

@TheMarex I moved everything under a new metadata sub-structure. Want to take another look?

[TheMarex]

@danpat one of the unit tests is failing:

/home/travis/build/Project-OSRM/osrm-backend/unit_tests/library/route.cpp(456): error in "test_manual_setting_of_annotations_property": check annotations.size() == 5 failed [6 != 5]

[TheMarex]

Looks good! 👍