Deprecate HERE provider

[nilsnolde]

I have no intention of ever working on the HERE provider and it's lacking behind since a while. I'd actually like to slash all commercial providers, but Google is too prevalent (and has fairly sane parameterization).

If anyone would like to keep it, speak up. Then it'll be your turn to maintain it properly:)

[1Maxnet1]

Hey there,
I am currently looking into your library for my student job, as we saw that you support HERE and OSRM/Valhalla (which are the routers we are interested in for our current project). Using your library would mean we do not have to duplicate the effort on getting a nice wrapper around those two to three routing APIs. Could you maybe extend a little on what "lacking" behind exactly means and how I/we could help to keep HERE as a provider supported? We had a working Code for the Routing HERE REST API for routing V8. I am currently looking into get it running, but have some issues with the credentials...

[nilsnolde]

I'm not sure what's missing, but yeah, v8 is the big thing I guess. HERE is just too much work to maintain and I don't think we'd want to have an update of that in this repository for the few folks using it (we're not) and still rather remove it either way. However, you could always maintain a fork with HERE as extra provider, it's not that bad IMO.

[1Maxnet1]

I'm not sure what's missing, but yeah, v8 is the big thing I guess. HERE is just too much work to maintain and I don't think we'd want to have an update of that in this repository for the few folks using it (we're not) and still rather remove it either way. However, you could always maintain a fork with HERE as extra provider, it's not that bad IMO.

Thanks for the answer. I understand that you do not wan to maintain something, you do not use (or not a lot of people use at all). I need to think about, whether creating a soft-fork is worth it for my use-case.

Did you consider using an external library (e.g. https://github.com/eifinger/here_routing) to support HERE as a provider without having much code in this repository? I do not want to convince you, but this was just an idea, how a fork could be avoided, but still keep the maintenance in a feasible manner for you.

[nilsnolde]

I appreciate your willingness to find an alternative solution, but I think I'll be quite stubborn on this;) I'm quite conservative with dependencies, also for stability reasons. In this case it might not change much in terms of maintenance hassle, I can't really count on upstream being diligent (don't want to judge based on commit history, that's a poor indicator, just a general comment for niche libraries).

Sorry for the stubbornness on my part. In the end my only allegiance is towards OSS routers, corps can invest their own resources for their closed-source stuff (case in point ;)).