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

Jaak Laineste jaak.laineste at gmail.com
Mon Aug 22 15:25:44 BST 2011


Hi all,

2011/8/21 Anthony <osm at inbox.org>:
> 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.

Yes, this is the hardest part. It must be easy to maintain, so
community can do it. Not just external thing, or some weird number tag
to objects. My proposals, you know probably better how realistic they
are:

1. integrate it to the OSM editors. As plugin first, later built-in
feature to JSOM, P2 etc. In essence MetaLinks are special kind of
Relations (external relation), with quite similar issues of accidental
breaking of them etc. It would mean that editing actions and Validator
will always check whether modified object has MetaLinks attached - if
you delete or split object with them, then user will be warned and
will get few easy to understand options to solve it. To make seeing
linked data easy you will have in data download window one more tag
(in addition to data and GPS tracks): linked data. If clicked, you'll
see linked data just as OSM data.

Editing example: if you split linked way, then will link can be
attached to one of derivates or to both of them (as one-to-many link).
If you add a POI then it will check whether similar name in nearby
already exists, if yes then suggests to MetaLink them. Simpler cases
could be transparent, so links are automatically updated. There are
many interesting cases to handle, but I believe that after analyzing
them and prototyping the key complexity would not really be in number
of required lines of code.

2. Have MetaMap server also as part of OSM, as a special dataset. Like
there are GPS tracks now: different API, database and also license
terms (I hope I did not open Pandora's box with this question - but it
needs to be defined too). Also the main OSM map view would have
different styles like "pure OSM" and "extended OSM" with linked data
from other sources. Technically I could use some own servers, but
being closer to OSM infra would be much better in principle.

Important question for me is what the key people developing key
editors and managers of servers think about this. JOSM, Potlatch and
P2 cover over 92% of "market" now, so we can focus on these, 100% of
editor coverage is actually not needed (other users just need to fix
their damage of MetaLinks). We would start with plugins and test
prototypes with them, but in 6-12 months it should become more
integrated.

> 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.

I totally agree. I see no practical point in doing it totally
separately, even if it would be technically possible. Fortunately I
don't have enough qualified resources to implement all it by my own
anyway.

-- 
Jaak



More information about the dev mailing list