[Imports] Charging Stations in Italy

David Riccitelli david at insideout.io
Thu Jul 11 08:23:36 UTC 2013


Hello,

Thanks for all of your contributions, I'll try to summarize where we are
now, and actions to take.

*Summary*

The import procedure under test currently follows this workflow:

 1. load the data from the original source to a local DB

 2. for each Charging Station in the local DB
     a) if the Charging Station does not yet have a node id, create the
node in OSM and save the node id/version,
     b) if the Charging Station has a node id, check the version of the
node in OSM,
         i. if the version in OSM is higher than the local version (meaning
that a mapper updated the node), update only the tags (not the coordinates),
         ii. otherwise update the node and save the version,
     c) if the Charging Station is no more present in the original source,
and has a node id, delete the node from OSM.

**we don't use the ref:enel tag as primary key, we provide this information
just like any other**

In addition, we do reverse geocoding and, if we find that the address/city
at the provided coordinates do not match the data in the original source,
we raise a warning to the owner of data for a manual check.

*Actions to take*
*
*
>From our discussions so far, I believe these should be the actions, before
proceeding with the import:

 1. finalize the *tags definition*, so far:
     a) add the *name=* tag with the official name ("Enel - stazione di
ricarica")
     b) remove the *car=* tag
     c) keep the *ref:enel=* tag
     d) maybe add the *ref:enel:serial_number= *with the station serial
number (this should be visible on the station hardware and might be helpful
to identify the object in real life)
     e) use *proposed: disuse: construction: *according to the station state

 2. *change the import behavior* defined above (points 2.b.i and 2.b.c):
**since we save in our local DB the node id and version of last update** if
we find that in OSM the node has been deleted or that the version is higher
than the known version, *we don't perform any kind of update or operation*,
instead we raise a request for manual verification to the owner of data.
Therefore subsequent updates/deletes of nodes by mappers won't be therefore
affected by the import procedure.

 3. *management of existing data*: we're making a census of existing
charging stations data in OSM [1]. There are 73 stations currently on the
Italian territory (not all of them are related to Enel). We need to
reconcile our data with what is currently available on OSM.


The above changes would conform with the principles of safeguarding the
edits made by mappers and avoid duplicating data.

Thanks!

David

[1] Charging Stations in OSM,
https://docs.google.com/a/insideout.io/spreadsheet/ccc?key=0AgxvdfBRek4bdHRaR3M1bzBoWDh0azBuTVpkYTRnZGc#gid=0



David


► Helix Cloud online video platform <http://bit.ly/e-helixcloud> ► WordLift
semantic web for WordPress <http://bit.ly/e-wordlift>
► RedLink - making sense of your data <http://bit.ly/e-redlink> ► US Export
compliance extension for WooCommerce <http://bit.ly/1864GLD>
    *(5 years celebrations: discounts up to 35%)*
══════════════════════════════════════════════
 ► LinkedIn: it.linkedin.com/in/riccitelli <http://bit.ly/e-riccitelli>
► Twitter: @ziodave <http://bit.ly/e-ziodave-twitter>

► GitHub: github.com/ziodave <http://bit.ly/e-github>
---
► InsideOut10 <http://bit.ly/e-insideout10> s.r.l. (IT-11381771002)
---
► Layar Partner Network <http://bit.ly/e-layar> ► Interact Egypt -
RealNetworks Partner <http://bit.ly/e-interactegypt>
<http://www.interactegypt.me>
══════════════════════════════════════════════


On Thu, Jul 11, 2013 at 2:52 AM, Jason Remillard
<remillard.jason at gmail.com>wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20130711/268aa622/attachment-0001.html>


More information about the Imports mailing list