Integration with OpenStreetMap

I’m a long time contributor of OpenStreetMap, and thought there is an obvious opportunity for OSM and OCM to work together.

Needless to say, I’m not the first! There is a page on their wiki with some discussion - https://wiki.openstreetmap.org/wiki/OpenChargeMap - mostly about the legal technicalities (licensing of data, etc). The discussion is a couple of years old though - so I’m wondering if there has been any more activity or follow-up on this. And also though I would create this thread on the OCM side for a bit more awareness!

If nothing else, OCM users may want to be aware of the structure of the data used by OSM for charging stations - https://wiki.openstreetmap.org/wiki/Tag:amenity=charging_station. I’m thinking, maybe a field for OCM reference (e.g. OCM-98064) may be useful in tying the two databases together?

4 Likes

We do support (sort of) metadata fields where we can apply metadata such as foreign keys to POIs. OCM-ID’s can certainly be used in OSM if you like, and OCM-98064 would be fine.

Our data licensing is a bit too pragmatic for OSM (we use a mixture of imported and crowdsourced data, at the POI level) , the OSM data license is at the data set level. I have looked at their data a couple of times with a view to importing it etc but the quality is extremely varied and the metadata tagging is quite random, so there is nothing we can really import. You can add layers to the OCM App in Advanced mode (settings) if you can craft your own POI json, which you can then use as a overlay to see where we may have data missing that OSM has. I wrote something ages ago to export OSM charging POIs and covert to a POI list for the app but it’s lost in the depths of my disk.

OSM do a great job overall but basically we are not the real blocker for OSM to have OCM data, they can use it if they want but I think the initial reactions/discussions were so high-and-mighty about how trash we were that I think the motivation really need to come from them if they want the data. We can even consider a re-license (non-imported stuff) if required and asked to do so by an official OSM representative but several people have raised the topic of OSM before and not really picked up the ball. I’m sure you could do it but I think it’s more political than technical (OCM would still consider itself the primary source which is probably not the way OSM would like to run it).

On the plus side, OSM have at least 1000 times as many data contributors as we do and they will eventually all be driving electric cars, so maybe there’s hope in the long term. If an official from OSM said we want to take over Open Charge Map and make it part of the OSM dataset we’d probably go for it, as running OCM just cost us/me time and money :slight_smile:

2 Likes

Hello, I’m another OSM contributor who arrived here with the same question.
OSM doesn’t accept mass imports because quite often they’re wrong - I just saw in OCM a charger at a wrong location 40m away.
It has been reported that https://www.kiwhipass.fr/carte.html has stations completely off, and I see stations being off on OCM.
So if an import is made on OCM, it should be confirmed by a driver that the station indeed in the correct location, correct connectors and in working conditions, and so OCM will send data to OSM and it will be always updated.

2 Likes

@beatnick my own survey of ev charging POIs in OSM showed their information was both incorrect (location) and extremely inconsistent (metadata for equipment, network).

OSM is a great resource but it has no specific advantage for data accuracy over OCM, other than it has more editors, but does it have more editors who are also EV drivers? I don’t know.

Anyway, the root of the discussion is probably the question of whether OCM should exist at all if OSM exists, that’s one for the OSM community to answer by becoming the definitive reference for EV charging data, which would then make OCM no longer required. This is fine if it can be done, but it won’t be me doing it.

If OSM are not going to import OCM data then there is no other alternative approach in order for OSM to be relevant to EV drivers that I can see?

I was only talking about the regions I’ve mapped the chargers myself (Greece, Croatia, North Macedonia) by visiting them, and making a POI with my phone just above the station, to have the best possible accuracy. For example, I see a charger in the street 38.04039° N, 23.80377° E when the correct location is in the parking out of the building https://osm.org/node/7655167097
Of course both OSM and OCM have errors to be corrected.

I think the role of OCM would be to keep a database of imported, unverified charging stations, the driver will verify the station has correct data, and then OCM will update OSM.
I’m not sure if this can be implemented as a separated app, which it is already, or as a plugin of OsmAnd~.

I have created a group for brainstorming about charging stations on Telegram and we’re already a few people there : https://t.me/openchargemap

1 Like

Awesome, I hope the community can take that forward. It’s not something I have time for myself but I think there are plenty of other people who could help organise it. You could extend/enhance the existing OCM app or build something else, but what we don’t need are any more databases to be maintained.

For OCM we have 3 types of data:

  • Imported data from 3rd party sources (transformed to our data model but otherwise unmodified). This remains copyright the original license
  • Imported and then edited. The edited versions are marked as licensed by OCM because creative work has been applied by the OCM editor/contributor. Data may be similar or completely different to the original (referenced in the parent id).
  • Crowd sourced data, manually input by users (this is about 50% or higher of the data). This should not be copied from another original source and we take the users agreement that it’s their own work.

Whether you can use any of the data for OSM is of course up for debate by OSM. At the very least you could use it to trace possible locations and suggested configurations but you should also mark up the version in OSM with an OCM ID to cross reference because if either point moves you would then lose the only join you have.

For the OSM data to be useful/consumable in other apps it needs strict specification of metadata for:

  • equipment types (tethered and non-tethered connectors)
  • power KW of the supply equipment is essential information.
  • network operator(s)
  • ideally you would have some way for users to feedback usage experience information e.g. “I turned up and the hotel owner said it would be $25 to charge for half an hour (etc).” If you maintain the OCM ID this could be fed to OCM instead of OSM if OSM doesn’t have something to capture this. Quality of charging experience is a massive issue for EV owners.
1 Like

Hi everyone, very sorry for starting this discussion and not having returned to contribute further :frowning:
I’ve just joined the telegram group linked by @beatnick above.

Thinking after reading Christopher’s questions and thoughts about OCM and OSM long term…

I think one of the important things is to find equivalent OSM tags for every field and value that OCM stores in it’s own database. That will make it easy to transition between one and the other - whenever or even if that happens - in the future.

I see a possible future where OSM is the data repository for the charging stations and OCM is the interface for adding and viewing data, perhaps in a format or with a method that is more convenient to EV drivers.

1 Like

Hi all,

I’ve made a suggestion here - https://wiki.openstreetmap.org/wiki/Talk:OpenChargeMap#Stagnant_discussion_-_how_to_move_forward.3F

I used the OSM wiki since it is the most public/accessible discussion point.

Thoughts - especially @Christopher ? I’ve quoted you a couple of times there and want to make sure I’m not mis-representing what you’ve said.

@chuq that seems to mostly align with how I see it, we definitely wouldn’t stop growing the OCM dataset until OSM were 100% committed at the OSM foundation board level, and prepared to drive any relevant migration themselves. If on the other hand the OSM community and board just see it as yet another data set then it wouldn’t be in the best interests of our data consumers.

As an side, there is still a possibility of us re-licensing user contributed data to CC-BY, as yet there hasn’t been much demand asides from a couple of commercial organizations who wanted us to get rid of the share-alike clause. I believe this license change would allow for migration of our data into OSM(?).

The bigger issue may be the amount of re-tooling of software required for us if we want to still offer data editing/data population tools and an API - we have an existing userbase of API consumers and data editors and after considering it some more I don’t think can just point them to the OSM API and OSM editor and expect that to be an easy transition for them.

As another aside, I noted that the OSM foundation is financially the same size as my own small company (Webprofusion which is the host for Open Charge Map), this doesn’t inspire much confidence as I’d assumed OSM were better funded than that. They do have the advantage of having many community editors, but currently I can’t tell how many of those are interested in EV charging.

Re: the ref:ocm discussion, it’s relevant in OSM because OCM will continue to have user checkins and photo metadata for locations, which is not necessarily metadata OSM will capture(?). We can also use it to cross reference data and potentially highlight differences. It’s not 100% required as we could attempt to deduplicate on the combination of approximate position and network operator - I think the main objection from OSM seems to be they don’t want to acknowledge other data sets within their own data. The alternative could be that OCM instead holds metadata for the OSM identifier as we would potentially also like to hold cross-reference id’s for other datasets (like PlugShare etc). We already have some metadata capture for things like geocoding sources etc.

After reading the whole discussion, i would like to know what is the recommendation recently.
Because of the licensing and the stucked discussion on both sides recently, i see both charging databases independent growing(nothing bad, just notice).
It seems like @Christopher would have no issue instead of running a own database to see merged everything in one single free (as in freedom) database. I also like this idea. I also think that probably the OSM database would be the way to go in the future. But having openchargemap.org as a community and the map as a custom rendering project specified for EV-chargers should not be lost.

My idea would be to add the functionality to the OCM to display the OSM charging stations. This should have no licencing issues. But when having both data on one map, it would be easy to compare the data. Then it can be checked if the OSM and the OCM differs. If it differ, then a human can go to the charging station and check what is the correct data and fix the wrong one (either OSM, OCM or even both). At the moment it is not possible to compare the data that easy.

Creating a map that shows OCM data and OSM data would be easy enough, if you have an API for the OSM stuff. OSM (last time I looked) has a very limited data model for EV charging information and I really don’t think it’s good enough as a replacement (OCM also has much room for improvement).

Just to add support here, that integration should really happen sooner than later.
As it stands now more and more of the locations which I add into OCM are already identified as charging points within OSM - and appear to be precisely recorded in terms of the grid coordinates. It makes me feel like I’m duplicating effort.

I’m not proposing to implement this in OCM, however if someone wants to try (perhaps creating a map with both sets of data) that would be a start so we can compare stuff.

For us, the OSM data needs to have at a minimum:

  • Position
  • Network Operator (from a standard list)
  • Connection type (from a standard list) and max kWh power.
  • Access/use restrictions (from a standard list)

Good to see this thread revived, I’m guilty of popping in every so often and saying “someone should do something!” but then not doing anything myself.

I think simply (I say “simply”, again being hypocritical, far outside my skillset) making a map that looks like OCM but sources data from OSM would be a good proof of concept.

The other thing needed may be to check and update the tags used:

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station

While these are free text, most have a specific set of values that are recognised.

Operator

OSM has three similar fields:

  • brand=* - The brand name of the station.
  • operator=* - The name of the operator of the station.
  • network=* - The name of the Network, with that the operator cooperates.

Probably worth having a discussion as to how these are used.

Connection type

Most people don’t use the “current” or “voltage” fields, and just lists the number and output of each socket type.

Access/use restrictions

It’s not specifically listed on the charging station page, but OSM has a tag “access” which is used for multiple object types (roads, paths, businesses, car parks, etc). There might be a bit of work to translate the OCM access types into this format. Examples are here:
https://wiki.openstreetmap.org/wiki/Key:access#List_of_possible_values

There are some other items that are on the “charging station” page (my first link), such as costs etc. and any number of non-charging-specific additional info can be added for random things like “opening_date”, for example.

Don’t forget OSM is community operated, so if we (as EV charging “experts”) deem there to be a requirement for a new key or value, we can suggest it.

2 Likes

Thanks! Yes just to clarify, I’m unlikely to do any work on this myself, which usually would mean it won’t get done at all.

Any JavaScript developer (of which there are millions in the world) should be able to use both the OCM API and and OSM API (?) to produce a map that can show results from either data source :slight_smile:

3 Likes

There would be maybe in near future a implementation in the smartphone app EVMap https://f-droid.org/en/packages/net.vonforst.evmap/
Until now there are already two API for charging stations implemented. One is OCM. It seems like the third one would be OSM: Support OpenStreetMap as data source · Issue #97 · johan12345/EVMap · GitHub

I’m not familar with that app, but it looks like a good move. While OpenStreetMap does have a map on it’s website, it’s primarily a data source and is intended for use by third parties. So the more websites/apps using OSM the better :slight_smile:

A bit more on the brand/operator:

OpenStreetMap integrates with another project called the Name Suggestion Index (NSI).

This is basically a database of organisations, businesses, brands, etc. which links a brand that appears on OpenStreetMap to their Wikidata entry (Wikidata is basically a massive database, partner site to Wikipedia)

The Wikidata entry then contains further information about the brand, including links to their social media pages.

This sounds over the top, but the benefits are:

  • NSI acts as a repository of charging network operators. See Name Suggestion Index “charging station” list - so every location of a particular network has the same brand/operator tag.

  • The links to social media pages mean that OSM can display the logo of the brand. Of course the logo is copyrighted but OSM never hosts the logo file, it just displays what the brand uses for its social media pages.

For example I just went to my nearest supercharger, which happened to have very minimal tags:

image

Upon editing it recognised it was part of a network and suggested additional tags:

image

I ticked “upgrade the tags” and it added them all:

image

This might look overwhelming but the idea is that when a new site is added the editor selects nothing except for the brand and all the rest are automatic. This just shows what happens in the background.

I can now also add site specific values such as number of stalls, speed, etc.

For anyone who wants to see if their local charge networks are included, you can look directly at the NSI link above or if you are an OpenStreetMap editor, just add a new point and start typing in the field. As well as the normal “generic” types you’ll see brands in your region pop up. e.g.

image

image

Results vary based on what country you are in.

TL;DR: This might all look very complicated to some, but the idea is to show what is happening in the background, so that contributors don’t need to stress about a bunch of text based key=value strings.

3 Likes