Proposed manual import of Gridserve EV charge point data (UK)

Communities United Kingdom
, ,
1

Hi UK community, Hi all,

I am proposing a manual (i.e. case by case) import of Gridserve EV charge point data in UK. The import will be done manually - i.e. checking each item and adding the relevant data to any existing node/way in JOSM. Data has been sourced from the API created by Gridserve to meet the legal requirement for Open Data under the UK Public Charge Point Regulations 2023. The data is compatible with OpenStreetMap as it is released under the Public Charge Point Regulations 2023 in a manner which is ā€œin line with the Open Government Licenceā€. Furthermore, as part of transforming the data to OpenStreetMap tags I have been in contact with the data team at Gridserve and as such they are aware that I will be adding this in to OSM and are in support of this.

Only the locations will be added (i.e. amenity=charging_station) and not each individual charging stall (man_made=charge_point). Data transformation is via a python script which has also been checked by Gridserve.

Further details is at EV charge points in the United Kingdom - OpenStreetMap Wiki

Please comment here or on the wiki page.

5 Likes
2

Good stuff. Great that organisations want to make their data available to everyone.

Have Gridserve shown interest in maintaining the OSM data themselves once it is imported?

And will they be ā€˜dogfoodingā€™, i.e. contributing to, then using OSM as a data source/database for apps?

1 Like
3

From chatting to them it is clear that they want their data to be accurate and maintained across all major mapping platforms. They spoke about how they provide a change file through to others. Not yet sure how best to do this for OSM but training them on how to do it is one option to consider.

Iā€™m not sure that they will use the data from OSM. Not when they have their own data processes that include live availability data updated to the minute.

2 Likes
4

I donā€™t think this is actually an import, this is literally manual editing. Anyway, it looks good, thank you for talking to them and doing the work.

Have you considered brand:phone=+44 800 240 4242 instead? Since they are all the same.

1 Like
5

Conflation with existing data is always required if thereā€™s a chance some of it already exists.

The end effect is going to be a copy of an external database being placed into OSM.

1 Like
6

I think that generally looks good.

Iā€™d probably prefer not to use website=* when itā€™s not site specific, and go for brand:website=* or operator:website=* instead. (Similarly, I wonder if operator:phone might be better for the support number.)

@RobJN perhaps you might be able to convince them of the benefits of having a link that takes users straight to the details of each individual site. (They have the site details popping up on the map at https://electrichighway.gridserve.com/ when you click on the icon on the map, itā€™s just the URL doesnā€™t change to something thatā€™s book-markable.)

2 Likes
7

Thanks. It has been fun working on this one and is something that I think will make a great addition to OSM.

As for your suggestion to ask them to create individual pages for each site: They used to have a URL for each site (some of these are in OSM) but they have removed all except a few for their larger forecourt sites (meaning the links in OSM are now 404). I do not see it as likely that each will have their own dedicated URL even if we ask. My reasoning is below.

For context: The UK has circa 8000 petrol stations. I just checked one major brand and they donā€™t have separate URLs for each site. The current number of charge point locations in the UK is over 38,000 (according to ZapMap stats page).

I will have a further think about the website tag choices, but from a quick look, my current proposal does not seem to be out of line with how the wiki page is written (e.g. it suggests website=https://bahn.de as a valid example) or how the tag is being used according to TagInfo.

P.S. I guess they could make unique URLs via a query parameter or one of the # endings (excuse me not knowing the proper name) but there is no guarantee that it will continue to work as websites get developed / map JS libraries replaced etc.

1 Like
8

I really donā€™t understand any company that doesnā€™t have a bookmarkable/lilnkable URL for each of their outlets. They can presumably show the store info on a web page, so why not allow people to link directly to it? In the case of the charging stations, the use-case is obvious. If people find the site in OSM or an OSM-powered app, a direct web link would allow potential customers to go directly to their specific site page giving availability and pricing info. Instead, theyā€™re forcing potential users to have to search again on their site.

Re petrol stations, Iā€™ve just checked the four biggest UK brands, and Shell, BP, Esso and Texaco all have individual URLs for each site.

Iā€™d argue that website=* should be for a site specific site, not a generic brand one. Thatā€™s the pattern thatā€™s mostly followed elsewhere. Otherwise, why does brand:website exist?

1 Like
9

Iā€™ve put some more thought in to this and decided that I will proceed as is. My reasoning is below:

  • Using website= and phone= will ensure the maximum number of end users get access to the details (not all applications use the other tags).
  • EV charging stations are not like Petrol stations: they are not staffed on site and people will know that the phone number is not to a specific site only.
  • The brand:website tag was introduced recently with no proper discussion and vote. While it states that website= should not be used for non-site specific URLs this has not been properly discussed, contradicts with examples on the website= tag page and contradicts with real use as shown on TagInfo (real use is inconsistent).
  • If I was to not use website= then it is unclear if I should be using brand:website= or operator:website=. This would lead me to wanting to use both at the same time which just feels like clutter. Same for phone.

I hope that this is something that you can understand even if it does not align with your own tagging preferences. If consensus develops on the wiki then it is something that could be easily changed at a later date. Having a proper vote on the brand:website tag would be a good starting point.

10

I agree with this viewpoint; website is only useful if it gives some information that is relevant ā€œusingā€ the POI, although this could be fairly generic information. Thereā€™s no point linking to a marketing website ā€œWe are Xā€; a user would be disappointed.

brand is the stronger concept - the lettering that mappers see on the charge point.

I think tagging should be judged primarily on its usefulness. Thanks to Rob Wā€™s tools, brand:wikidata is being widely used in the UK to match objects to external data sources, and I often use brand:website for cases where only a ā€œgeneric websiteā€ is available.

11

Iā€™m not disagreeing that brand:website is useful. Where I disagree (and would vote against) is the suggestion that the website tag should be left blank if there is no URL that links directly to a specific shop/site. I would prefer to always populate the website tag with the best URL you have (site specific or not) before going on to add the brand:website tag if the mapper wants to.