Hi Anthony, hi all 2011/8/21 Anthony <[email protected]>: > These are the kinds of things that people are going to maintain in > OSM. Whereas external_link:HCPA=376284734 is not.
Given there is an organisation like the museum (in the proposal) then there *is* a community which would take care of whatever is needed to keep the relationships between the OSM and the external db up-to-date. but you probably thougt of other use cases where there in fact was no one interested to maintain imported stuff. So, for this discussion it is important to separate the different use cases if needed. So I agree with you: The disadvantages and requirements outweigh the current concept of maintaining OMM as a separate (meta-)database. Still keep in mind how users are kept aware that this is a OSM object is an object which is referred to. This would help avoiding duplicates, for example when a county makes a donation and then the central organisation (say: the topographic institute) does the same some months/years later. Yours, Stefan 2011/8/21 Anthony <[email protected]>: > On Sun, Aug 21, 2011 at 12:41 PM, Anthony <[email protected]> wrote: >> On Sun, Aug 21, 2011 at 9:23 AM, Stefan Keller <[email protected]> wrote: >>> 2011/8/21 Frederik Ramm <[email protected]>: >>>> Hi, >>>> >>>> Stefan Keller wrote: >>>>> >>>>> What about storing the object ID (and the link properties) directly in >>>>> the OSM object? >>>> >>>> Wasn't the idea of *not* polluting the OSM database with external reference >>>> data at the very core of Jaak's proposal? >>> >>> "Polluting" sounds to me a little undifferentiated. Maintaining such a >>> tag would support simplicity - and that's (another) core design >>> principle. >> >> Requiring OSM mappers to maintain links to external databases doesn't >> seem like a good idea. It's hard enough keeping OSM up to date with >> what's actually in existence on the ground. Adding a requirement to >> keep up to date with a potentially limitless number of external >> databases would make things too difficult. >> >> If you want to use OSM for this, I don't think anyone's going to stop >> you. But the vast majority of people aren't going to help you, >> either. What's almost surely going to happen is that the information >> is going to rot. It's not going to be kept up to date. When people >> delete and recreate elements to handle some sort of problem they're >> not going to copy the links (and/or they'll copy them incorrectly in >> some way you didn't expect them to). Ways will get split and merged >> and split and merged over again, and the links are going to wind up >> pointing to things that you never intended them to point to. >> >> Take a look at TIGER TLIDs if you want a preview. > > And so that I'm not being totally negative... > > If you want to put something in OSM to use to match to an external > database, try to choose something that exists in reality. If you're > matching two roads with slightly different names in each database, put > in an alternative_name=* tag on the OSM road (or fix the road name in > your local copy of the external database). If you're matching two > McDonalds locations, change the name of each from name=McDonalds to > name=McDonalds #542 (or whatever). Add addresses into OSM, and/or add > addresses into your local copy of the external database. > > These are the kinds of things that people are going to maintain in > OSM. Whereas external_link:HCPA=376284734 is not. > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
