capacity:charging just specifies the number of amenity=parking_space + parking_space=charging in the parking lot. It doesn’t allow you to specify any other detail about the charging station such as socket types, etc…
For a fully micromapped combined parking lot + charging station, I expect those to be tagged in addition to the charging station.
They ‘belong’ to both the parking lot and the charging station in a sense.
1 Like
site relation in adddition to a node
That is a bad idea, mapping something multiple times is not OK (and site relations are anyway pointless here, just map it as an area)
1 Like
Ah! OK - my mistake. “amenity=parking” aren’t generally nodes, and that combination is quite common. Just looking at nodes, there are still quite a few, but not as many.
Sorry if what I wrote implied that - I’m just try to get to somewhere where the data can sensibly be interpreted.
Just to make one comment on site relations - almost nothing can consume them. The honourable exceptions include OpenInfraMap, and I suspect that this PR for OSM Carto would also technically be able to (although I’ve no idea if it’s been implemented there).
If a site relation is the best solution to a problem then the fact that some renderers currently struggle with it should not be a reason to not use a site relation. As an example, this OSM feature wouldn’t really make sense as any other sort of relation.
Edited to add link to taginfo. One project, OpenCampingMap, is listed there.
site= is only used when there is no feature tag. power=plant has been used extensively on type=site ever since. site=parking is arguably an early artifact.
I agree, will clarify, the intention was either-or.
How would you map charge points which are dispersed (not adjacent to each other) with some distance along a street or across a parking lot without a relation?
If entire parking lot can be treated as big charging site with some additional parking - map as big charging site.
Otherwise map individual charger as separate charging stations
I think we’re at risk of conflating two different things. EV chargers come in different speeds. Those installed in car parking lots tend to be slow chargers → the primary function of being there is to park your car; the changer is a added benefit. In contrast, those installed in service areas on main roads tend to be fast → the primary reason to be there is to recharge quickly, but you happen to occupy a parking space and can grab a drink from the coffee shop while you wait.
1 Like
This is a fantastic post and description of the way the market is moving to cater for fast charging while on the road. It is precisely this arrangement that was not prevalent when the current tag was created and hence we now have a bit of a mess!
I am a bit lost on where this discussion has got too. The proposal on the wiki seems like a good one to me. Noting that it does require us to review what has already been mapped, but we have mapped literally nothing (less than 0.1%) of what will be present in just a few years as we continue to electrify transport.
I therefore say that we move forward with that proposal instead of continuing the status quo of adding more and more ambiguity into OSM.
OK. So suppose the proposal is accepted. I encounter a large car park with a few EV parking spaces, tagged as an area with amenity=parking capacity=200 capacity:charging=8 (a bit like this example). The individual chargers are not micromapped. I’m now supposed to add a single amenity=charging_station with capacity=8, plus optionally individual man_made=charge_points, and if I’m drawing individual amenity=parking_spaces, tag each of them with capacity=charging?
I can live with that, and I feel like the proposal would be better if it was documented that this is the plan. It means that all amenity=parking nodes/ways/relations with capacity:charging > 0 that don’t currently have an amenity=charging_station near them would need to have one added to them (how many are there? not sure).
As you pointed out yourself this is a somewhat dated view. The “fuel station” model of EV charger deployment, that is centralized larger numbers of fast chargers, makes sense along major highways/motorways and maybe specific travel hotspots, but doesn’t have any economic justification outside of that*. Naturally this will be regionally different, but for example here I don’t expect any major further expansion of larger sites because outside of the holiday season they are underutilized (actually I expect some to close down), even those of the market leader are rarely anywhere near full.
So we can expect the majority, from a count pov, of new public deployments (aka non-private or non-apartment specific parking spaces), to be in the “mid”-power range charging points for car owners that use street side parking (not saying that is a good idea btw). And as you point out the current tagging scheme works perfectly well for that, no ambiguity at all. .
I can give some irl numbers on charging costs etc if anybody is interested.
* it is different because most people don’t have their private petrol pump at home if that wasn’t clear.
2 Likes
Thank you for all comments. I am getting ready to bring the proposal forward to RFC and then to a vote. Just a couple of extra comments below.
I am not intending to make any changes regarding capacity:charging=* when used with amenity=parking. To me, this tag is just an indication that an amenity=charging_station could be mapped in the area. I could include a comment about that of course.
A couple of potential problems with using a site relation has been brought up. I am considering to exclude site relations from the proposal for now. I think most groups of charge points could be enclosed with an area, and hopefully most charge points will not be mapped individually. Any further comments before I exclude site relations?
1 Like
Just to be clear, I didn’t say that and I don’t agree with that. I think the current system fails for anything more than just a single charge point on its own. That includes groups of slow chargers.
Yep, exclude site relations for now. We can have a separate vote on that if we later decide it’s needed.
It won’t works for parking lot hosting several stations operated by different companies.
In this case, you should have as many polygons/relations as existing pools.
And there can be many of them out there.
@NKA, I don’t get why we need a supplementary man_made=charging_point when we can assume every charging point on parking spaces nodes/polygons.
We shouldn’t look at what is displayed in UX but to what the underlying data looks like.
Apps display “locations” and charging points because charging pools and charging points are the only features that must have a unique iD.
No term among pool, station and charge point shouldn’t be controversial. They are all well defined in standard ruling OCPP and OCPI.
in such case, what benefit would be given by site relation? Would it be even valid?
1 Like
Yes it will: mapping stations as nodes, possibly charging points as parking spaces polygons and pools as relations.
Pools relations will hold operator’s name and appropriate id.
What’s the solution then for mapping charging spots along a road, such as the one brought up earlier in the discussion? I don’t really see how you would reasonably map that without a site relation.
For this case I would just create one node with amenity=charging_station in the middle of the 5 charge points, with capacity=5 and the relevant socket tags.
But say that there is a kilometre long street with charging points in every third light post along the whole way. An amenity=charging_station in the middle starts to get further from what’s on the ground.