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

Stefan Keller sfkeller at gmail.com
Mon Aug 22 13:44:54 BST 2011


Hi Anthony, hi all

2011/8/21 Anthony <osm at inbox.org>:
> 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 <osm at inbox.org>:
> On Sun, Aug 21, 2011 at 12:41 PM, Anthony <osm at inbox.org> wrote:
>> On Sun, Aug 21, 2011 at 9:23 AM, Stefan Keller <sfkeller at gmail.com> wrote:
>>> 2011/8/21 Frederik Ramm <frederik at remote.org>:
>>>> 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.
>



More information about the dev mailing list