The location_index field is relevant whenever custom matrices are used. It plays a similar role as the location field when the routing engine is used. So, all the objects have both of these fields to be used depending on the situation. However, I see that in the output, only the location field is present (in the unassigned key, and the step object).
The user-defined matrices and the location_index type of fields were introduced in v1.2.0. Do we have any reasons for omitting the location_index type of field from the output, or is it because this field was not required then, so was not added?
I feel that it would be better to also add the location_index index field in the unassigned key, and the step object in the output. Firstly, it would look more consistent - both the location and location_index fields could be present in the output, depending on whether the custom matrices or the routing engine is used. Secondly, getting the location index of the task in the output might be useful to the users who are using custom matrices. Obviously, the end-users can get the location index of the task manually, but I think it would be easy to do it in the vroom itself without adding any extra complexity.
If this looks okay, I would be happy to submit a PR. :-)
The
location_indexfield is relevant whenever custom matrices are used. It plays a similar role as thelocationfield when the routing engine is used. So, all the objects have both of these fields to be used depending on the situation. However, I see that in the output, only thelocationfield is present (in theunassignedkey, and thestepobject).The user-defined matrices and the
location_indextype of fields were introduced in v1.2.0. Do we have any reasons for omitting thelocation_indextype of field from the output, or is it because this field was not required then, so was not added?I feel that it would be better to also add the
location_indexindex field in theunassignedkey, and thestepobject in the output. Firstly, it would look more consistent - both thelocationandlocation_indexfields could be present in the output, depending on whether the custom matrices or the routing engine is used. Secondly, getting the location index of the task in the output might be useful to the users who are using custom matrices. Obviously, the end-users can get the location index of the task manually, but I think it would be easy to do it in the vroom itself without adding any extra complexity.If this looks okay, I would be happy to submit a PR. :-)