[Imports] Charging Stations in Italy

Wed Jul 10 23:52:23 UTC 2013

Hi David,

I am OK with whatever you decide on the tagging. This is an emerging
feature in OSM. In a couple more years, when we have 100,000 charging
stations mapped the tagging will work itself out. I just don't think
an import should get ahead or deviate from what normal mapping
practice is in the db.

Martin raised yet another issue you might run into, which is somebody
putting your charging node into a relation. Lets list the stuff that
is going to happen to your code.

- ref:enel tag is deleted, node stays the same.
- node is just deleted.
- node is put into a relation.
- node is deleted, and all tags are merged into another  node (perhaps
a building node).
- node is deleted, and all tags are merged into a way (perhaps a
building way, or parking way).
- node is deleted, and all tags are merged into a relation (probably
won't happen, but it might)
- node is deleted, and some tags (not your ref) are merged into another node.
- node is deleted, and some tags (not your ref) are merged into another way.
- tags are added to your node.
- charging node is moved a 1 meter
- charging node is moved a 10 meters.
- charging node is moved a 1000 meters.
- charging node is moved a 10000 meters.
- tags you are maintaining are changed in conflict with your source
data (like your disused tag).
- existing ref:enel is copied to several new charging stations you are
not maintaining.

You should strive to preserve the existing OSM node/way ID when you
made your edits. Don't delete then add the entity or you will break
higher level relations and ways, and we will lose our history.

You can't 100% trust your ref:enel id, it will be copied, deleted, and
generally messed with. Don't think of it like a db primary key, it is
more like a hint. You will need to do bounding box searches to find
your change stations when the ref:enel gets messed up.

You will probably need to pay attention to who last touched the data.
The conflation logic is different if nobody touched the data except
for your bot, versus a new user_id. You can be very aggressive if
nobody has touched it, versus seeing a non-bot user id on the data.

The code should skip anything that looks weird, and get a human
involved. There are some scenarios that will need to get resolved by
sending an email to another mapper and discussing what they did.
Sometimes, you will just need to fix the map manually because it was
broken by accident.

It looks like you still developing your code. I suggest go finish your
code, and test all of these scenarios on the API dev server. After,
you can either point us at the code, or explain in your wiki what the
code does in each of these cases.

Jason

On Wed, Jul 10, 2013 at 9:17 AM, David Riccitelli <david at insideout.io> wrote:
> Hello,
>
>>
>> have a look at these:
>> http://wiki.openstreetmap.org/wiki/Key:disused
>> http://wiki.openstreetmap.org/wiki/Key:abandoned
>> http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts
>
>
> Sounds good to me, could we use the following? [1]
>
> proposed: (planned, with a high likelihood of being constructed)
> construction: (being constructed at this time)
> disused: (not current available for use, but could be reinstated easily)
>
>
> BR
> David
>
> [1]
> http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#.3Cstatus.3E:.3Ckey.3E_.3D_.3Cvalue.3E
>
>
>
>
> InsideOut10 ► Helix Cloud online video platform ► WordLift semantic web for
> WordPress ► RedLink - making sense of your data ► US Export compliance
> extension for WooCommerce (5 years celebrations: discounts up to 35%)
> ══════════════════════════════════════════════
> ► LinkedIn: it.linkedin.com/in/riccitelli
> ► Twitter: @ziodave
> ► GitHub: github.com/ziodave
> ---
> ► InsideOut10 s.r.l. (IT-11381771002)
> ---
> ► Layar Partner Network ► Interact Egypt - RealNetworks Partner
> ══════════════════════════════════════════════
>
>
> On Wed, Jul 10, 2013 at 4:10 PM, Martin Koppenhoefer
> <dieterdreist at gmail.com> wrote:
>>
>> 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:
>> http://wiki.openstreetmap.org/wiki/Key:disused
>> http://wiki.openstreetmap.org/wiki/Key:abandoned
>> http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts
>>
>> there is also a very recent draft for a proposal here
>>
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Tag:operational_status
>> 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.
>>
>> cheers,
>> Martin
>
>
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/imports
>