Golf cart costing

[ianthetechie]

Issue

Adds golf cart costing (see #4475; let's discuss if this closes it or not).

Quick hits:

• This has seen production use for 6+ months (not this exact code, as I just merged master this week, but substantially the same)
• This exact code (incl. the speculative Meili fix) have been tested to generate on a relevant extract covering GA and FL + produce good routes in the golf communities there
• Currently highly specific to golf carts; I could see us expanding to other forms of LSVs / NEVs in the future, as I mentioned in the original issue, but I'm not sure I have enough of an opinion on what that should be yet (the golf cart rules were developed with both municipal reps and people intimately familiar with the rules + using them for daily transportation)
• Initial PR still has some rough edges before merging (see discussions + checklist). Also my IDE has some opinions and I don't know how widely those are shared 😂 (ex: markdown table formatting)
• Includes a few unrelated cleanup bits that either were flagged by clang-tidy or caused issues on my ARM mac. (Note: I do get one failure when running make -j8 check locally, but it appears to be somewhat spurious related to floating point comparison; we'll see what the official CI run says.)

Tasklist

• Add tests
• Add #fixes with the issue number that this PR addresses
• Update the docs with any new request parameters or changes to behavior described
• Update the changelog
• Update the taginfo

Requirements / Relations

N/A?

[ianthetechie]

Combine this into the access tests to reduce the number of executables that need to be built.

[ianthetechie]

Move this up to the top of the block; doesn't break anything.

[ianthetechie]

Add BETA to docs and do a quick second pass on prose.

[ianthetechie]

Quick update on the status of this... I'm working to ensure the first version doesn't require too much of an overhaul later ;) To that end, I've been having conversations with others involved in the LSV space over the last month, and learned quite a few things about which assumptions are golf-cart specific and/or should be tunables vs being generally applicable, including things like "primary roads are actually routable in downtown LA because speed limits are so low."

I'm continuing work on this in the background and will likely have a more polished generic LSV profile ready in a few weeks (I have completed most of the refactor to generalize terminology locally).

[kevinkreiser]

@ianthetechie no worries i very much appreciate the diligence in using this last bit in the access mask and making it as worth it as possible 😄

[ianthetechie]

Yeah, here's a quick info dump on that just so it's recorded in one piece (there will also be comments in the code to note areas for further improvement, specialization, etc.).

First, there is no tagging scheme, either de facto or in use, which covers LSVs as a more general class, nor do I think there is likely to be one anytime soon. LSVs/quadricycles (EU equivalent) mostly behave like cars with somewhat different preferences and a federal/national or state law restricting roads they can legally use based on the posted speed limit.

Thus, the access bit will have to go to golf carts, which do have a widely used tagging scheme and are often subject to specific restrictions that are only modeled this way.

Fortunately, there are no scenarios I'm currently aware of preventing LSVs/NEVs which are not easily captured in some other attribute like max allowed (tagged) speed. So we'll get a general LSV profile that's tunable for both vehicle type and max allowed speed, and we can evolve it as we uncover more use cases. Most of my work recently has been around making sure that the first version allows for such expansion.

[nilsnolde]

So we'll get a general LSV profile that's tunable for both vehicle type and max allowed speed

this is sadly not fully true.. "max" allowed speed is not something we capture today for edges. we have a "tagged" speed, but that's not necessarily the OSM maxspeed value: if the same edge has a maxspeed:practical (or default or whatever that was), then we prefer that over the plain maxspeed when we set an edge's speed value. the reason is that maxspeed is rarely useful for costing. problem is we can't distinguish those, it'll always just be "tagged". it's not trivial to support that, but certainly possibly with some bit juggling.

we do have speed_limit on EdgeInfos, but again, we don't want to use that for costing.

[ianthetechie]

we have a "tagged" speed, but that's not necessarily the OSM maxspeed value: if the same edge has a maxspeed:practical (or default or whatever that was), then we prefer that over the plain maxspeed when we set an edge's speed value.

Ahh, interesting. That's actually good to know... I guess we'll just need to document that's an edge case for now unless another solution presents itself.

Of course there are options if you're willing to run a custom graph / pre-processed OSM data file specific for LSV routing, but that is indeed inconvenient that my assertion isn't fully true out of the box.

we do have speed_limit on EdgeInfos, but again, we don't want to use that for costing.

I understand that this is bad (slow), but out of curiosity just how "bad" is it? We aren't running hundreds of req/sec yet, but at moderate load we actually had (maybe still have? I forget 😂) deployed an older version of this PR that accessed the EdgeInfo::speed_limit and it was acceptable for our use cases.

Would you be opposed to accessing this when a max legal speed limit is specified and clearly documenting the tradeoffs that you're opting into by doing this? It seems useful to me to unlock that use case unless I'm missing something (quite probably). I'm guessing adding speed_limit to DirectedEdge isn't an option? Looks like that's already packed...

[nilsnolde]

you can have a look at this: #2910 (comment). I didn't really in a few years, can't remember well what the suggestion was exactly, but I remember thinking it would work before that particular project I was working on went away.