They tend to come in relatively close groups due to the transmission infrastructure required and the civil works involved.
Perhaps in the future when all cars are electrical there will be charge points everywhere in some streets (perhaps conductive charging from the ground). At that point we may have to figure out how to tag highways.
how that helps for
?
And how it is superior over areas/multipolygons, one for each operator?
It depends if you have one station with 5 charge points or 5 stations with one charge point each.
Itâs not possible to conclude this way nor desirable.
Ids are mandatory for open data linakge and interoperability with existing electric mobility software. No ids, no usage.
A multipolygon grouping parking spaces covered by a given charging pool is a relation, ok for me.
Parking spaces covered by a pool arenât necessarily contiguous.
not really? Position and operator info will be enough in basically all cases.
When pools or stations are stacked over different parking lot levels, lat/lon location isnât suitable for matching. Only ids are.
Itâs kind of a problem to discuss about what can occur or not in reality while we intend to build a better model than existing ones.
then you can use level info (if such distinction between levels even matters)
Still, whatâs the harm in keeping site relations as an approved alternate way of mapping charging stations when a node or area wonât suffice?
Multipolygons enables some flexibility in mapping a dispersed group of charge points. Charging station multipolygon example. And unlike a site relation, it gets rendered. I do not have a strong opinion on site relations, though.
How would this be possible?
Level is not part of EVSE opendata or even data.
Is there any return on experience about this?
It should be low priority now.
It should be a point addressed later, when we will have a consensus of what should be achieved.
I would welcome that. If the proposal is accepted the wiki page for capacity:charging could then encourage people to add a charging_station and charge_points and vice versa. This would make clear that they are complementary, not competing tagging schemes.
Here is the RFC announcement for the proposal.
I think anyone holding this hope will inevitably be disappointed (as pointed out above). Thus such hope should not be the basis for the chosen way of tagging. Instead, any system we choose should allow a good way of mapping individual devices.
And why wouldnât we want to map individual chargers? They exist and are easily verified on-site or even from imagery.
It probably also means something that all the example images on Tag:amenity=charging_station - OpenStreetMap Wiki are of individual devicesâŚ
The proposal supports both tagging individual chargers and only tagging the location. It is entirely up to the user to decide and the proposal is not dependent on any preference and this regard. Personally, I would not tag 30 identical Tesla charge points on a location as it would create unnecessary duplicated information, but other users may think differently.
It probably also means something that all the example images on Tag:amenity=charging_station - OpenStreetMap Wiki are of individual devicesâŚ
There actually is a Tesla example at the end of the wiki table which is not an individual device (but the image is). And there clearly are several thousand non-individual locations mapped in OSM. But I agree that more examples of groups should be included on the wiki.
I will soon start the voting process for the proposal. Please let me know if there are any more comments.
From the tagging mail list:
@Mateusz_Konieczny :
I guess that in such cases it may be possible to tag it both as
charging station and
a charge point at the same time?Thatâd work - it makes it clear that this is a ânewâ
amenity=charging_station (e.g. a âgroup of chargersâ, even if there is
only one), not the previous âprobably a single charger but we donât
really knowâ.No man_made=charge_point | Tags | OpenStreetMap Taginfo
are yet mapped, so any with that tag must be the ânewâ schema.
@SomeoneElse: I am trying to conclude the charging station proposal and I am considering how to resolve this question. I would very much like to make the proposal as usable as possible. However, I am struggling to understand the use case here.
For my understanding, could you explain why it is important for consumers to know if an amenity=charging_station has a single charge point or multiple charge points? (beyond what can be interfered from capacity and socket tags)
I am thinking that we do not know this today either, and users may not always add an extra tag to clarify (for example double tagging with man_made=charge_point as suggested below). Is it not sufficient for map rendering and for apps to know that âthis is a location for charging carsâ? Additional information will be available through the other tags (capacity, sockets etc) + tags on individual charge points at the location if mapped.
If you were to know with certainty that an amenity=charging_station is either a single charge point or representing a group of charge points, how would you then use that information? And what would you do with the other âuncertainâ locations?
Let me rephrase that, in terms of petrol/diesel infrastructure - yes, I would like to be able to tell the difference between an âamenity=fuelâ and a âman_made=fuel_pumpâ. Currently I render the former and ignore the latter (see the pumps such as this one here).
Indeed - but we currently have one of two situations (continuing the petrol analogy):
amenity=fuelâ mapped, but not any âman_made=fuel_pumpâman_made=fuel_pumpâ mapped, with no surrounding âamenity=fuelâWe donât have a situation today where people have mapped both âamenity=fuelâ and âman_made=fuel_pumpâ on different objects at the same site, with the same tag. If we did, weâd have to change the tagging on one of them to know which was which.
You seem to be suggesting using âamenity=charging_stationâ for both the equivalent of âamenity=fuelâ and âman_made=fuel_pumpâ on different objects at the same site, which means that I wouldnât be able to tell which was which there.
Actually which generation and how many of each tesla super chargers are present at a location is quite relevant, and it could be that you have 10 V2s and 10 V3s (and soon V4s), which have different power output and other characteristics that you canât model with a single object.
Thank you for clarifying.
With the proposal, the idea would be that you render amenity=charging_station only and ignore man_made=charge_point, similar to your fuel example. man_made=charge_point should only be present if there also is a amenity=charging_station present.
If somebody maps a single man_made=charge_point anyway without an amenity=charging_station it will just be ignored in rendering. I would not rule out that some users would do that, for example for charging points which are not really intended for general public usage (even if the access=* tag should be used for that).
Sure, but then they are not identical âŚ
It is correct that you would not capture all details in such a case - you would get the maximum output only. Most Tesla Superchargers seem to be mapped in that simplified way (with only one node).