[Imports] Charging Stations in Italy

Martin Koppenhoefer dieterdreist at gmail.com
Wed Jul 10 13:10:54 UTC 2013

2013/7/10 David Riccitelli <david at insideout.io>:
>> >> - what happens if a station is deleted from the source data
>> > Stations deleted from the source data, or marked as inactive (e.g.
>> > maintenance), will be removed from OSM.
>> not sure if stations marked as inactive should be completely removed,
>> maybe better set them in OSM to maintenance as well (in a way they
>> won't get interpreted as charging stations by simple software, e.g.
>> with a prefix on the amenity-key).
> Yes, my aim is to avoid people reach the station and eventually find out
> it's not active. If we define the right tagging, we could actually publish
> also the planned charging stations. Can you make an example on how the
> amenity key should look like?

have a look at these:

there is also a very recent draft for a proposal here
but IMHO should be switched to the newer disused/abandoned scheme in
order to avoid confusion for users of less advanced programs.

> About the merge operations, I need to understand better: do we envision a
> map where charging stations could become buildings?

some mappers believe it is a good idea to mix up the building and
contained POIs into one object in order to reduce geometric redundancy
(e.g. amenity=post_office, building=yes), but they really should do it
differently (e.g. use a relation of type multipolygon for
amenity=post_office). Despite for many tags it might be unambiguously
clear to which object they refer (e.g. a charging station won't have a
tag building:levels), it will create problems in the long run. It also
is not always clear, e.g. in the post office example it might be
sometimes disputable whether a separation is a good idea, while in the
case of a shop that occupies only part of the building it might be
more obvious.


More information about the Imports mailing list