2011/8/22 Anthony <o...@inbox.org>: > On Mon, Aug 22, 2011 at 8:44 AM, Stefan Keller <sfkel...@gmail.com> wrote: ... >> 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. > > I don't deny that at all. I'm just saying the right place to keep > those relationships is in the external db, and not in OSM. (I > explained why, but it seems you didn't understand my explanation.)
I think I got your explanation and still like to repeat that you can't say that so absolutely: There are use cases where this would make sense and would make things simpler. Like for some uses cases which are covered by the link type MERGE. Now - since we agree on the separate OMM db - these use cases should be still kept in mind. Use case 1 - Museums or administration boundaries: Since museums (nodes or ways, from the national association of museums) or administration boundaries (e.g. from national topographic institute) are probably undoubtedly part of OSM, this would - to me - justify an OSM import (of course accompanied with copyleft attribution tags). No OMM and no external links needed here. Use case 2 - Data from external like opengeodb in Germany/Switzerland. This is an example where an import should habe been avoided since there have been some interesting new atttributes. But there are also many unusable attributes and still one don't dares to delete them. OMM would have been of rescue here: In the OMM one yould have tagged these OSM objects as "SIMILAR_TO" or "EXTERNAL". Use case 3 - Special museum types and attributes special to OSM (from the national association of museums) which are of main (but non-exclusive) interest for specialists. That's the case where I would give a thought that it's equally easy to maintain external links in the separate database. Now its called MERGE. etc. Yours, Stefan _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
