search

nilsnolde / routingpy

🌎 Python library to access all public routing, isochrones and matrix APIs in a consistent manner.
https://routingpy.readthedocs.io/en/latest/?badge=latest
Apache License 2.0
272 stars 28 forks source link

Deprecate HERE provider #119

Open nilsnolde opened 1 year ago

nilsnolde commented 1 year ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 ;)).