Proposal
As the world of EV charging has moved from pilot projects to growing international standards the need to grow and mature Open Charge Map has also developed. We're now at a point where we need to plan our next round of big changes to be able to accurately and efficiently capture, maintain and distribute the important details about the worlds EV charging infrastructure.
We've seen equipment and vehicles become more sophisticated and charging networks grow, merge or become obsolete. Charging stations have gone from being basic power delivery machines to multi-headed, networked, smart units often servicing multiple bays.
With that in mind, OCM needs to look at the information we currently capture and maintain and look forward to how we think it should be organised and managed in the future.
For a given location we currently (Mid-2015) store the following information:
* Address Details (Location Title, Address, Latitude & Longitude, Access Comments)
* A single associated Network Operator ID
* Number of Bays/Stations
* A single associated Data Provider (usually Open Charge Map but info may be imported from an external source)
* A Data Provider Reference (if imported)
Equipment Details:
This proposal and discussion broadly covers the need for a new (non-breaking change) design to capture equipment details in a way which more accurately reflects the real world and will allow for greater data accuracy.The aim of this is to then be able to show clearer information about available equipment at locations.
Suggested Changes
Network Operator - Standard Equipment
Versioned preset equipment configurations which users can select from a list after selecting the Country & network operator. This enables easier addition of locations where equipment is generally of the same specification. In addition the resulting UI could allow for further customisation on a per-location basis.
Related Operators
Establish relationships between network operators so that if an RFID card from one operator will work with another (and perhaps vice-versa) then that can be centrally documented and all associated charging stations will reflect that automatically.
Charging Stations vs ConnectionInfo
Currently a location may have one or more ConnectionInfo entries which details a connector type, power level etc. The proposal is to allow these to be grouped into a physical station (of which there may be several at the site), which in turn can service one or more parking bays.
A station may allow a single or multiple connections to be in use at any one time.
A station may have a distinct geographic location and access instructions at the common site (shared with other stations) .
Each station will be associated with a Network Operator (who controls access and may in turn do equipment maintenance or may outsource maintenance to one or more parties). How would we represent situations where the network operator is a corporation but the branding for the network is local (local government initiative etc.)?
The number of bays present at a given station needs to be clear, as does the number of available stations and their ability to share connections with multiple cars simultaneously
.
The OCM-ID of a location will point to one or more stations at a single common site (Point Of Interest [POI]), multiple network operators and equipment types may be present at the site.
The POI may be a composite of imported data which has since been edited.In this case multiple data providers are responsible and each provider and their associated license details needs to be identified.
OCM can currently hold external metadata about a site (this includes data attribution, POI types) - we would like to develop this more so that sites can be tagged with metadata such as the Hotel, Secure Access, Restaurant, Toilets etc.
As a related project, our current default API JSON output consists of monolithic objects for Data Provider, Country, Connection Type etc. Instead these should consists purely of reference ID's which related to our Core Reference Data (DataProviders, ConnectionTypes etc). This will greatly reduce the default API results payload size.
This proposal will be updated as we arrive at decisions.