add access restrictions to /locate response

[nilsnolde]

While debugging some issue I was missing the access restrictions in the /locate response. I added most, except the time-specific restrictions, there it's a "value": null in the response. Adding time domains would add a bit more code. I'd leave it out for now and add it in a separate PR if we want that too.

[nilsnolde]

Looks like this in the response:

		"edges": [
			{
				"access_restrictions": [
					{
						"truck": true,
						"pedestrian": false,
						"wheelchair": false,
						"taxi": false,
						"HOV": false,
						"emergency": false,
						"value": 3.50,
						"motorcycle": false,
						"car": false,
						"moped": false,
						"bus": false,
						"edge_index": 28162,
						"type": "max_weight"
					}
				],
...

It's quite verbose, but I find it pretty useful to debug truck restrictions.

[kevinkreiser]

i would wait on this. it would be better to either just do this now or let this out of the pr to avoid any api breakage questioning

[nilsnolde]

this is more work than anticipated.. basically we'd have to reverse the parsing process of OSM tags and output smth similar to it to make it (intuitively) usable

    // Mo-Fr 06:00-11:00,17:00-19:00; Sa 03:30-19:00
    // Apr-Sep: Mo-Fr 09:00-13:00,14:00-18:00; Apr-Sep: Sa 10:00-13:00
    // Mo,We,Th,Fr 12:00-18:00; Sa-Su 12:00-17:00
    // Feb#16-Oct#15 09:00-18:30; Oct#16-Nov#15: 09:00-17:30; Nov#16-Feb#15: 09:00-16:30

as you can imagine that'd be ugly code. and a lot of it. making it saner in the code would make it much less usable or very big as response.

but I'd honestly still like to know if there's a time-based restriction, even the value is not provided. if anyone would ever tackle this, it'll need to be a (nested) map for the value for sure. so IMHO providing an empty map right now would still be fine for the future. we could also leave out the value property, then those time-based ones would show up but not have that field at all (but all other restrictions would). I'd prefer the empty map, but not too strongly.

EDIT: well, I argued against myself there, ideally it'd be a string as in OSM, not a map, but that would reverse this function:

valhalla/src/mjolnir/timeparsing.cc

Line 148 in d533886

std::vector<uint64_t> get_time_range(const std::string& str) {

. Urgh.. Then just leave out the value field in the response?

wdyt @kevinkreiser ?

[gknisely]

who wrote this....oh wait nm ;-)

[nilsnolde]

haha this time shit is just so disgusting to work with..

[gknisely]

yes it was not fun at all

[kevinkreiser]

could be the tiniest bit more fancy and actually look at the type bit and serialize accordingly

[kevinkreiser]

actually dont we have to turn this into a date_time object when we check it in dynamic cost? can we do the same thing that that does, turn begin and end into date times for the YMD case and just show the human strings for that.

for the day of the week case i guess we'd just want the day name for start and end and the time? surely there are clues in costing on how its interpreted but also we could just print out each field and call it done

[kevinkreiser]

a compromise would be to have a map with just the raw value in it:

{
  "time_domain": 23049872312
}

and then down the road we can add "begin" and "end" date time strings when we have the time (pun intended)

[gknisely]

Also, we should grab from ComplexRestriction because we do toss malformed input from the user. We may not toss everything as parts could be correct. We do also toss unsupported types like PH for public holidays.

[nilsnolde]

10 mins is vastly exaggerated for any sort of half-usable output, but yeah prob not more than 2-3 hours with some fanciness added. I'm also fine with the compromise of returning the raw value. we can keep it forever as well, even when we add the actual map. let's do that then for now. the next weeks should be pretty calm, maybe I find the motivation to flesh it out a bit more.