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 <da...@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 > <dieterdre...@gmail.com> wrote: >> >> 2013/7/10 David Riccitelli <da...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/imports > _______________________________________________ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports