[Imports] Charging Stations in Italy

David Riccitelli david at insideout.io
Wed Jul 10 13:17:59 UTC 2013


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 <http://bit.ly/e-insideout10> ► 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20130710/6824f935/attachment.html>


More information about the Imports mailing list