<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 2:55 PM Christoph Hormann <<a href="mailto:osm@imagico.de" target="_blank">osm@imagico.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For this purpose it is completely unnecessary to bother the OSM <br>
community with external IDs. If you want to check if the data has been <br>
unchanged since you added it then do exactly that - check if there are <br>
any newer versions of the objects that have originally been added in <br>
the import.<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't really understand why this discussion is coming up again and <br>
again with imports here. To me this very much looks like a 'lazy <br>
programmer' attitude - having an ID available probably seems the most <br>
conventient way to identify the object. But think about this for a <br>
moment - you want to bother the OSM community with the burden of <br>
dealing with these IDs forever just to make it a tiny bit easier for a <br>
programmer to possibly in the future write code to identify what <br>
features from the import have not been changed since they were added.<br></blockquote><div><br></div><div></div><div>The programming to which I refer is not some speculation about what I<br></div><div>might do 'possibly in the future,' it is the process that I'm using<br>right now in the present. I've done multiple updates to imported data <br>using exactly the technique that I describe.<br><br></div><div>You're right that I'm lazy - to the extent that I'm not willing to repeat all of<br></div><div>the work of the initial import - which took me several months, off and on,<br></div><div>every time that New York posts an update to the data set. I simply am<br></div><div>not going to be able to keep up with the workload unless I have tools to<br></div><div>recognize what has changed and speed the process of updating only<br></div><div>what has changed. In a way, that's an assertion that all programmers<br></div><div>are lazy, since any process that can be programmed can hypothetically<br></div><div>be done without automation! <br><br></div><div>Still, leading off by calling me a lazy programmer doesn't predispose<br></div><div>me to treating the rest of your arguments with the respect that they<br></div><div>no doubt deserve.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note i completely get that many programmers are unfamiliar with the OSM <br>
concepts of changesets, object versions etc. and for them it would <br>
indeed be more convenient not to have to deal with that and instead <br>
retrofit OSM to what they are used to. But that is not something OSM <br>
should accept. <br></blockquote><div><br></div>Very well, in addition to being lazy, I'm also ignorant. Presumably<br></div><div>you with your superior wisdom and industry can enlighten me. <br>Can you detail what your ideal process is for this use case:<br><br></div><div class="gmail_quote"><div>I have an object in an external shapefile, that has a stable external ID.<br></div><div>I have likely imported that object before. I may well have altered it from<br>the shapefile in order to merge changes with another mapper's view<br>of the world, to simplify ways, to correct topology, or otherwise to make<br>the object conformant with OSM practices.<br></div><div><br>I wish to (a) locate the OSM object that corresponds with the object<br></div><div>in the shapefile, and (b) determine whether it has changed since I saw<br></div><div>it before. Ideally I want to do both without having to maintain a persistent<br></div><div>external store other than the shapefile itself and the OSM database,<br></div><div>because I want someone else to be able to run my script if I am not <br>available, and don't want to have to get into the business of distributing<br>a third artifact that would give the external ID<->OSM ID mapping.<br></div><br><div>(b) is handled well with change sets, and in fact that's what I use.<br></div><div>I check whether the most recent change set is mine. (And in fact,<br></div><div>part of my workflow, in the event that the object has changed, involves<br></div><div>doing a three-way differential comparison between the version<br></div><div>that I last imported, the latest version, and the version in the<br></div><div>external data set.)<br><br></div><div>But how do I do (a), and not have to get into doing data distribution of<br></div><div>yet a third artifact? I can't do an exact match on geometry - I likely<br></div><div>tweaked it (simplifying ways, correcting topology, ...). I can't do<br></div><div>a simple match on name - that too, may have been misspelt,<br></div><div>miscapitalized, contained abbreviations, .... What is left that I can<br></div><div>match on, if I don't record some sort of stable key?<br><br></div><div>Recall that this is not a hypothetical argument. I have an existing<br></div><div>workflow that functions for me. You are insisting that I need to change<br></div><div>it to remove what amounts to a single tag on each imported object,<br></div><div>because that is too much computational and intellectual overhead<br></div><div>for the rest of OSM to deal with. I consider that the burden of proof<br></div><div>is on you to demonstrate a workable alternative.<br><br></div><div>If that alternative requires me to maintain a separate, external<br></div><div>database, also under version control, that I must distribute to<br></div><div>and synchronize with everyone who helps me with an update,<br></div><div>then, pray tell, why should I bother contributing the data to OSM<br></div><div>at all rather than just keeping it to myself and my friends?<br></div><div><br></div><div>Simply telling me that I'm ignorant and lazy doesn't address my use<br></div><div>case. <br></div></div></div>