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?

3 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.

1 Like

@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.

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.