Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for better (but attached to costs) sources #306

Open
greentux opened this issue Nov 13, 2023 · 3 comments
Open

Add support for better (but attached to costs) sources #306

greentux opened this issue Nov 13, 2023 · 3 comments
Labels
question Further information is requested

Comments

@greentux
Copy link

The 2 available sourcen goingelectric / open chargemap are free but with a lot of problems (user maintained). In the future this will become more and more inaccurate. So perhaps an option for an charged source would be helpful.

@johan12345
Copy link
Collaborator

johan12345 commented Nov 14, 2023

Hmm, I understand what you mean, but:

a) what data source would actually be better?
Official data from the charging station operators can be obtained through the roaming networks, for Europe this would most likely be Hubject. Hubject's pricing seems to be prohibitively expensive though (especially the 4-figure setup fees), even if this were a paid feature in the app. The data quality is also not perfect, e.g. often the listed charging power is inaccurate, or a whole charging site can be listed sometimes as a group and sometimes as a separate entry for each single charger.

The Google Places API also provides EV charger locations now, but from what I saw in the Google Maps app, data quality is not very good (some duplicates, often inaccurate operator information, many chargers without realtime status). Pricing here is per request, so there's no fixed upfront or monthly payment. But still, with a large amount of users, this would not be insignificant.

And then we have other companies that also build charging apps themselves, like Cirrantic (operators of the Moovility app, data is probably mostly from Hubject and partially directly from operators) or PlugShare (community-maintained data, just like GoingElectric and OCM). I don't know about their pricing.

b) what benefit would it bring to EVMap?
Data from the roaming networks usually just gives you very basic information like location, operator, available plugs and power, EVSEIDs and possibly realtime status. All this information is already available in any of the charging providers' apps. So what benefit would it have to show exactly the same data in EVMap, especially if the users would need to pay a monthly subscription for something that they get for free in other apps?

I think one of the main benefits of EVMap is exactly the more detailed information (like photos, descriptions, fault reports, compatibility with different charging cards) that can only be contributed by users and is rarely available in the charging providers' apps. If we want to keep this, we would either have to aggregate free and commercial data sources together (which is not trivial to do well 1) or build a new community-maintained data source ourselves (which could be subject to the same problems as the existing ones, maybe even more due to the smaller user base).

c) What does it mean for the open source project?
The more paid APIs we use, the harder it becomes for people to contribute to the development of the app2. There are already not a lot of external contributions (mostly translations) - but if a paid API were the primary source for charging stations, it would become pretty much impossible for others to contribute to the app.

Also, shouldn't we as an open source project rather try to promote contributions to community-maintained and open3 data sources? As the number of EV drivers is growing, if we can convince enough of them to contribute, the data should not become more and more inaccurate.

Footnotes

  1. Especially with the considerations needed to make sure the GoingElectric API's terms of service are respected - as far as I understand it, the aggregation would need to be done locally in the app in real time, and not as a one-time job on a backend server. Also, data coming from different sources need to be clearly marked.

  2. We do already use some paid APIs (Chargeprice, fronyx), but both are not impacting the most basic functionality of the app, and at least Chargeprice provides a public staging API that can be used for testing.

  3. Unfortunately only OCM and OSM (which is currently being integrated in Implement OpenStreetMap data source #290) are truly open data - GoingElectric's data is not released under an open license, and as mentioned, their API has pretty restrictive terms of use.

@johan12345 johan12345 added the question Further information is requested label Nov 14, 2023
@greentux
Copy link
Author

For me its the only charger mapping app an AAOS (maps is not on that level). But from time to time I recheck charger status on Moovility because of that charging station configuration hassle (distance between chargers not in sync with GE). i know its all community driven data, right.
But I am looking for a Moovility or mobilit+ AAOS app with additional data from GE :)

@johan12345
Copy link
Collaborator

johan12345 commented Nov 16, 2023

Isn't mobility+ available on AAOS? They do have an Android Auto version at least...

Aggregating data from Moovility (or any other source mentioned above) and GE would run into the same problems as our current matching for the realtime status, because it would need to be done in basically the same way (mostly based on closest distance) as the GE API doesn't provide any data we can match unambiguously (such as the EVSEID). Of course the matching algorithm can still be improved (see #243), and it might be easier if we can process the data globally instead of one charger at a time (which, as I said, may not be allowed according to GE ToS), but it will probably never be perfect...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants