<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Frederik Ramm:<br>> Keeping a link to the source signals to the mapper "don't touch this, it's official data" or "your edits can be overwritten by a future import".<br><br></div><div>Andy Mabbett:<br>> That may be your interpretation; it is most certainly not mine. Do you have any evidence that anyone other than you interprets links in this bizarre manner?<span class="gmail-im"><br></span><br></div><div dir="ltr"><div dir="ltr">Mateusz Konieczny:<br>> *raises hand*<br><br>Martin Koppenhoefer:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I can confirm that for my mapping, having external ids is making editing significantly more complex, and often I don’t know how to deal with these when I do operations like merging or splitting or even just correcting a brand or operator tag.<br></blockquote><div><br></div><div>Rest assured that if you are actually editing anything that I've imported, you can feel free to edit the object without fear of being overwritten or breaking things. Any foreign keys that I provide serve one of the two purposes that I outlined: (1) as a bookmark so that I can find an object that I imported - to make sure that a reimport is NOT overwriting another mapper's work! - or (2) as a link to useful external data (some of which, even in our time, is on paper, so paper file numbers that you can give to a reference librarian come in handy). <br><br></div><div>In the first case, you won't get overwritten, or even make more work for me. I'd be rather cross if you deleted the foreign key without making any other changes, because that means that I'll be conflating the object manually the next time I update. If you have some other reason for touching the object, I know that I'm going to have to do manual work on the next update to avoid damaging your work, so don't worry about the foreign keys, that's my responsibility. If you have no other reason to edit the object, please just leave the foreign keys alone, and I'll be happy.<br><br></div><div>In the second case, I'm simply presuming that anyone who, say, edits the boundary of a historic site will preserve its 'heritage=2 heritage:operator=nrhp nrhp:nhl=yes ref:nrhp=72000840'. If that gets broken, that's no better nor worse than breaking website=* or phone=*. Most mappers don't break those, and it doesn't keep mappers from editing objects that have contact information attached.<br><br></div><div>I also use a source=* tag on imports, simply as a courtesy to the data source. While it may be lawful to import the data, as a scholar I would surely feel that it would be plagiarism were I to fail to credit the source.<br></div><div><br></div><div>I'm willing to cope with virtually any edit, short of outright vandalism [1], from another mapper, but I appreciate the courtesy of having my foreign keys not deleted arbitrarily. Every such tag that I added was documented in the import plan, and discussed on the mailing lists. If I didn't use them, I wouldn't have added them!<br><br></div><div>I do concede that there appears to be a fairly large amount of detritus [2] out there, mostly from old imports that certainly wouldn't be acceptable by today's standards. I'd surely be willing to entertain a case that keys like 'gnis:county_name' or 'tiger:cfcc' add no value whatever, but only occupy space on people's SSD's. Nevertheless, that particular question is above my pay grade. I don't mess with tags that I don't understand. That means, for instance, that if I find a node with gnis:*=* tags, and promote it to an area, I retain the tagging.<br><br>If Frederik and the other board members, DWG members, server admins, want to take on the task of sweeping up some of the debris, or at least identifying which keys are thought to be useless, I'll cheer them on. Still, I hope that they'll give people for whom foreign keys actually assist with a workflow a chance to respond. </div><div><br><br></div><div>[1] I have had the experience of spending hours correcting data, only to have it overwritten by someone else's undiscussed and undocumented import. I very much appreciate the assistance of the DWG in setting it right again. The guy who helped me even spotted another case that I needed to fix manually. It got fixed, along with a note=* item containing a link to an OSM diary item that describes a complicated issue affecting an administrative boundary between a park and a military reservation.<br><br>[2] I'll plead guilty to a few rubbish tags - and 
probably at some point ought to remove 'facility', 'NYCDEP:changed_fraction' and 
'NYCDEP:prev_osm_id' in a mechanical edit. They don't participate in my 
workflow, and leaked into OSM through a program bug. I'm simply deferring that particular task until the next time I'm updating that particular import I usually do it in the springtime, when outdoor recreationists are starting to look at getting out again. That synchronizes fairly well with upstream, too, since the state releases the updates in April.<br><br></div></div></div></div></div></div></div></div></div>