[OSM-dev] Proposal for OpenMetaMap - proper OSM import solution

Stefan Keller sfkeller at gmail.com
Mon Aug 22 20:48:56 BST 2011

2011/8/22 Anthony <osm at inbox.org>:
> On Mon, Aug 22, 2011 at 8:44 AM, Stefan Keller <sfkeller at 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.


Yours, Stefan

More information about the dev mailing list