Yes, regarding equipment grouping at sites, it’s a difficult problem. If we provide the information grouped by site it’s easier for consumers to then optionally break the information apart, if we present it as separate data then it would be up to consumers to (optionally) merge site markers.
The EquipmentSummary is not explicitly present in the current data model, it is a new proposal for how to present the existing (legacy) information we currently have without forcing data to be split into per-EVSE level information. If we can alternatively come up with a model that combines both the summary information we do have, with per-EVSE grouping, then we can merge the models into one. The more I think about the more I think we could just have a flag on the SupplyEquipment model to indicate that the data has not yet been split into per-EVSE information, then the editor UI would allow the user to perform that split and migrate it. This would remove the need to have EquipmentSummary.(which is redundant information if you have SupplyEquipment).
The primary objective of the data model change is to be able to accept data from network operators which identifies their equipment at the port level in a well structured way (which the existing model doesn’t really do).
We would intend to import and export OCPI data (and other formats): https://github.com/ocpi/ocpi so we also need to close the gaps between that and the model we have. We could just entirely adopt OCPI but I don’t know how we would migrate our existing data to that model.
Yes. conceptually, although we do none of that currently. Our current data is static (it does not have live status updates) and the handful of [custom] imports we have built in the past are slowly being phased out.
There is a wobbly line between having crowdsourced data (which you can easily have an open data license on) and having imported data (where each data source has a license, which is hopefully an non-restrictive open data license variant). Typically connector level data (i.e. connector unique network id etc) is only available from the network itself, not via crowdsourcing.
Our current data model lacks the explicit grouping (by EVSE) of individually addressable equipment connectors, but it’s only really a minor model change to add that grouping. The larger problem is maintaining compatibility so that apps/services using our data notice no difference and even if we change our model we can still provide useful data transformed into the old model.
The other problem (for me) is that I don’t have time to work on any of this and I’m definitely not the best person to speak with individual networks [if we even should].
Long term I’d like us to provide a clear, singular method for networks to push data to us (and possibly stream status updates), the act of which licenses the data under a single open data license. No individual network agreements, no special treatment. Some more thought around whether network submitted data should be editable by users is required. This has actually been the idea since the start, it just has never happened mostly because it relies on me to make it happen.
Well, if you’ve got time on your hands! OCM has been a hobby of mine for 10 years but if we could find a way to fund it’s development (and promotion) that would be great for progress.
As mentioned on the other map icon thread, OCMs primary objective is to be the open data source for charging locations. In an ideal world, apps like PlugShare (the defacto standard for check-ins etc) etc would use our data instead of maintaining their own, and corrections would be fed directly to our database or funneled back to the networks to update their source data. Apps and services will come and go, I’d rather their data didn’t.
What we currently have is a slightly clumsy mash-up of that idea and the world has moved on in the intervening years, so we have an opportunity to reset, confirm if our project goals are the same (I think they are/should be) and prepare for the next 10 years.
For my own part I simultaneously want to be able to work on it more but regularly can barely face working on it (see also: Retirement of Data Imports etc).
If you’re keen to work on certain areas please do play around with stuff, let me know if you need something (I’ll update the old database clone here ocm-docs/Database/Clone at master · openchargemap/ocm-docs · GitHub) and if you have an idea for stuff to work on please raise it before spending too much time on something so we can be sure it’s the right direction.
I’ve you’re a keen people person/communicator (I’m not) then feel free to reach out to parties that could perhaps be involved. For instance perhaps Tritium in Aus has contacts and could connect us to willing data contributors, or perhaps Chargefox would provide an example feed. Fastned were going to give us an OCPI feed but it fell through when it came to the open data agreement (this also happened with Google and Apple Maps circa 2015!).
In line with the theme of “next 10 years”, I think we need to move to .NET 6 - by that I mean get rid of all the deprecated code. That’s all that needs to be done right now in that space. It means that when we get .NET 6.1 or 7 or whatever, it will simply just continue working (or mean less work to continue working). This of course will also mean that I can get a little more used to your coding style, plus you can see what I do.
Sure thing, everything should be .net 6 now but it is indeed a legacy code base in some parts (it was built API first, just before REST apis were a thing and before JSON was the most popular default for data feeds).
We currently host everything in Windows in an Azure VM (paradoxically, our SQL Server database is running on Linux) because we have $10k of azure open source credits until June, but before that we had one windows VM on AWS and multiple linux VMS acting as read only API mirrors).
Fastned wanted a special data agreement signed, I wanted them to just give us the data under an Open Data license, we didn’t agree on us relicensing the data as open data (which is kind of the point), so it stalled.
Google got as far as reviewing with lawyers but they didn’t like our Creative Commons Share-Alike license, which I was prepared to change for just CC with Attribution but then they just got cold feet. Apple maps I think just lost their way in terms of management reshuffles as the initial reception for Apple maps wasn’t great when it launched.
Other organisations which may be using OCM data (they have contact us to say is it ok if we use this data/api) include:
Yeah, I do find that people can’t really get past PlugShare in conversations but see how you go. Most people not being developers can’t really see the point of Open Charge Map.
Oh really? I know they had their own data of sorts, but you’ll see we have other threads on OSM here. Lots of people have asked us to “do something” to make OCM part of OSM but I never really got past the idea of trying to jam high fidelity data into (slightly more ramshackle) a low fidelity metadata format.
Well that and they don’t really care as long as they don’t have to look in multiple places. PlugShare have recently started adding ads to the web UI which is symptomatic of seeking a revenue stream, and in turn will likely play out into either a subscription or finding cost savings. They have changed hands 3 times in the past 10 years so eventually they will have commercial pressure, using us for data would be a potential cost saving for them and would centralise edits/imports for the community. I put a similar idea to Chargeway a while back but that fell down due to mutual lack of interest.
That leads me back to the data model, governance, SLAs, quality etc. I doubt in our current state that our data (or service) is attractive to them. I think there is a solution but it’s quite a significant task:
Attracting high quality data from networks and implementing it in a standard way with least friction for us or them.
Enabling more data quality workflows (edits, reviews, feedback)
Formal governance (not really my bag, needs keen and committed communicators).
Providing a robust service. This may have to involve networks contributing a subscription fee relative to their network size (they get advertising of their network after all). Maybe large apps/services and other consumers should be on a subscription as well. I’m reticent to introduce these, then I remember the ~$20K spent so far hosting OCM
