The biggest problem with ids is that it may degenerate into cases where single objects has a giant list of various ids.
2014-09-18 9:17 GMT+02:00 Peter Wendorff <wendo...@uni-paderborn.de>: > Am 18.09.2014 um 08:35 schrieb Alex Rollin: > > On Thu, Sep 18, 2014 at 12:18 PM, Mateusz Konieczny < > matkoni...@gmail.com> > > wrote: > > > >> That is really poor idea. IMHO remembering location and object type > should > >> be enough to identify it. > >> > > > > OK, I'm game: let us say it is a node with an amenity and name tag > > attached. Let us also say that the positioning is absolutely accurate, > for > > the sake of the cases. Let us say my goal is to maintain the node, in > the > > same place, and to add international names and more information over > time. > > These are heritage objects, for the most part, not commercial locations. > > > > So, I post it to OSM, and then it is changed. > > > > Change case 1. Someone moves the node, changes the name, changes and the > > amenity tags (new, different amenity value) > > Change case 2. Someone deletes the node, and then someone else adds it > > again in a slightly (100m) different position > > > > How do I know/get-notified it was changed? > Counter-question: Why should your personal id help there? Some examples: > > Change case 3: Someone removes your ID (whyever), as a result your id is > missing and you have to fall back to handle it as if there was no id at > all. > Change case 4: Someone moves your object without touching the id - what > do you do in that case? is it still the same object or something else? > Spotting that could be done by observing the object by id (and react on > edits on it) > Change case 5: Someone edits the tags of your object. Let's say you have > a heritage that is a building and inside this building there's a museum. > Let both be tagged on a single node where you set the ID to. Someone > else adds the building outline and re-uses the node as one node of the > outline. Should your ID be moved as well? > Change case 5a: Same as 5, but as in the building there's more than just > the museum, the node has to be split to two (or more) objects. There's a > polygon for the building outline, and three nodes inside - one for the > museum, one for the gift shop and one for the public toilets. Where > should the ID go to? The Building? The Museum? The shop? Building and > museum? It's very hard to decide that without exactly knowing how your > ID is built. > > In contrast look at the overpass-permanent-id [1] as another way how to > achieve such ids. > This is more a qualitative approach: You define what to link to by it's > properties. > If you want to link to the museum with a given name in a roughly known > area, you can do that. If you want to link to a building with a given > address, that's possible, and if you want to link to a gift shop even > that's no problem. > Of course this may break as well, but you don't have much more work to > spot these errors, and mappers who want to edit the objects you linked > to have much less work and confusion. > > regards > Peter > > [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID > > Specifically, how would you setup a system to receive notification that > the > > object was changed? > > Have you done it? Do you have some scripts to share? (Can I please NOT > > have to add a relation?) > > We are talking about many thousands of nodes, btw. > > > > Oh, btw, should we be busy stripping out all the USGS GNIS tags? Of > course > > not, so, I am new to this, and I spend a lot of time on OSM, but I really > > don't know where to start with scripting tracking for thousands of nodes > > that might get a new unique ID every other week. > > > > Where do I start? > > > > > > > >> 2014-09-18 1:43 GMT+02:00 Alex Rollin <alex.rol...@gmail.com>: > >> > >>> Hello, > >>> > >>> We are surveying for local points of interest. > >>> > >>> We need to store an ID for these objects to keep track of them. I think > >>> this is called a "personal key"? > >>> > >>> Something like indonesiaheritage:ID=231892312 > >>> > >>> Is that the acceptable format for such a thing? > >>> > >>> We will then publish a page on the wiki about the data, and connect > that > >>> page to the WikiProject. > >>> > >>> I am deducing from what I see for the USGS_GNIS survey import: > >>> > >>> https://wiki.openstreetmap.org/wiki/USGS_GNIS > >>> > >>> gnis:feature_id (allows feebdack on the data set, corresponds to > original > >>> data) > >>> > >>> Is there anything else we can do to improve our plan? > >>> > >>> Relevant links: > >>> > >>> WikiProject Indonesia: > >>> http://wiki.openstreetmap.org/wiki/WikiProject_Indonesia > >>> > >>> Here is my user page on the wiki. > >>> > >>> https://wiki.openstreetmap.org/wiki/User:Alexrollin > >>> > >>> -- > >>> Alex > >>> > >>> _______________________________________________ > >>> Tagging mailing list > >>> Tagging@openstreetmap.org > >>> https://lists.openstreetmap.org/listinfo/tagging > >>> > >>> > >> > >> _______________________________________________ > >> Tagging mailing list > >> Tagging@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/tagging > >> > >> > > > > > > > > _______________________________________________ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
