[Imports] Charging Stations in Italy
david at insideout.io
Wed Jul 10 12:11:12 UTC 2013
I made an analysis of the existing data in OSM (using the data loaded from
There are 1.537 nodes, with 91 different fields, published by about 189
*car=* is never used.
*motorcar= *is used once.
*bicycle=* is used once.
*charging_station_type=bicycle* is used once.
I would just leave it off for
> since the community does not think that this information is import
> enough to maintain, regardless of what the wiki says.
Now I have a better picture: I agree, better leave it off.
Before you start doing any uploading, we really should take a
> look at any code you are using, and or discuss your manual workflow.
> It is only 200 points, so you could probably do it with JOSM and the
> conflation plugin. At the very least, talk about in detail what your
> conflation algorithm is.
It is currently about 230 nodes, which shall grow soon to 300. And every
now and then the nodes are set to maintenance and back to active. We'd like
to update the nodes more often than every couple of months using the import
- what happens if a mapper deletes a charging station
If the station is known to be active, a warning is raised and manual
intervention will be required.
> - what happens if a mapper moves a charging station node
The new location will not be overwritten by the import procedure.
> - what happens if a mapper, merges the node onto a building
The import procedure will use the charging_station node id for operations.
Will the charging_station node id change following a merge operation?
> - what happens if a mapper adds more tags to the imported nodes
Tags would be overwritten. Is this okey?
> - 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.
Thanks for your help,
InsideOut10 <http://bit.ly/e-insideout10> ► Helix Cloud online video
platform <http://bit.ly/e-helixcloud> ► WordLift semantic web for
► 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>
On Wed, Jul 10, 2013 at 1:24 PM, Martin Koppenhoefer <dieterdreist at gmail.com
> 2013/7/9 David Riccitelli <david at insideout.io>
>> I understand now the matter about car=yes.
>> Can you clarify the following:
>> 1. shall we then remove the *car=yes* tag? (at least until the matter
>> is clarified)
>> 2. what considerations shall we make for the value of the *access* tag?
>> Doesn't the *access* tag indicate who has access to the item?
> I think the intend was to point you to the standard vehicle classes in OSM
> (documented on the linked access-page) and to use motorcar=yes instead of
> car=yes, not to use literally access=*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Imports