On Mon, 20 Jul 2020 at 12:33, David Wales <[email protected]> wrote:
> Is there any reason against using a custom tag as a linking key? > > e.g. some_import_object_id=123456 > > Then when you need to update the data, you can match the key in OSM with > the key in the source data. It can be a deterrent to mappers, they may see these external ids and think oh I don't understand that, maybe it's special and I shouldn't touch it, maybe it is owner by someone else and they update it directly. Similar to what Mateusz said, if the community can't verify it, how do we know it's right? What should we do if things change on the ground? How do we know if the ID still applies to the new tag? In my opinion a better solution for a private linkage is for the 3rd party database to point directly to the OSM node/way/relation ID. The external database should monitor for changes to those IDs and then review after each change if the linkage is correct or needs changing. Though still the private ID method has been used for imports of the past, and I'm not saying it can't be used, but there are disadvantages and valid concerns. On Mon, 20 Jul 2020 at 14:08, Greg Dutkowski <[email protected]> wrote: > Hi, > I was thinking of using the ref tag to store the council ID for the > object, and then the council could use the OSMID in their database. > What I was looking for was tools or approaches for keeping the two in > sync. The foreign keys in each system are part of that. > The conflation tools Andew Harvey pointed to may be a way to go. > OSM is so big and diverse it is hard to get your head around all of the > possibilities, so contacts with people who are making conflation work would > be ideal. > I haven't tried those tools before, but my outsider view is that they are too low level and not mature. I would love to see something similar to Maproulette or Tasking Manager from an ease of use and non-technical setup point of view but for maintaining linkages with external datasets. I wrote recently about a conflation I did to compare government traffic lights data https://www.openstreetmap.org/user/aharvey/diary/393663 and I avoided any coding in that process.
_______________________________________________ Talk-au mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-au
