On Sat 2017-05-13 11:06:25, michael spreng wrote: > On 12/05/17 18:08, Ilya Zverev wrote: > > Hi everyone, > > > > First, I was amazed at the response. Thanks for constructive feedback, > > which I answer below, and no thanks for toxic responses, including asking > > for money (what money? We — as in maps.me — get none out of this) and > > imposing impossible restrictions (manually investigate context for each of > > thousands of points?). No import is perfect, and I cannot make this one too > > good for you. But it is pretty okay to me. > > > > * "The general view seems to be against IDs like this": what has happened > > with the principle "any tags you like"? Did we saturate the key space and > > not accepting new keys anymore? Can I read that "general view" documented > > anywhere? The "ref:navads_shell" key is the only one that is not verifiable > > on the ground, and is clearly added so the further updates do not have to > > rely on matching. > > > This is the desire not to be the database of a closed circle. This id is > only meaningful to that company. The rule this falls under would be the > "on the ground" rule probably. Anyway, I feel like some public ids are > ok, like the post codes, but private ones are a clear no like this > navads_shell. And using it for updating might not work as expected. For > example a copy of the fuel station for the competitor close by. The one > editing doesn't know what this id is, so it remains on the copied fuel > station. It's better to do the matching again.
We want to update data from the import in the future, so this kind of id is ok. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
