[OSM-talk] Building a free/open reviews community w/ OSM support

[joost schouppe]

Re: Erik

> Last but not least, do you have a sense how common this category of
change is for typical POIs?

I have no idea, but I would say fairly common. I analysed the evolution of
nature reserves in Belgium as a test case, and they do really evolve.
Starting their life as a node, then a way, then a relation. There is also
no real logic. For example, the way for nature reserve A can become the way
for nature reserve B upon remapping reserve A as a relation.


> Any external community-maintained database will typically at least
deal with merges or deletions. In those cases where my sync job
doesn't know what to do, my default would be to add the record to a
work log where the community can decide what to do. But of course I'd
like to keep those cases to a minimum.

Well yes, that would be a plan. However, as the example above illustrates,
not just the disappearance of an ID is a problem. The same OSM object might
have changed names to become something else. Say, I take the McDonalds
node, change it to Wendy's, move it next door, then create a way for the
McDonalds. Good luck with that :)

So the challenge isn't just finding the new way to refer to the same
object, but also deciding if the object has changed enough for you to
decide it no longer represents the same object.


Re: Marc

> It's better not to add external IDs to OSM. It would be OK if there is
> only 1 project in the world that would do this, but if every pet
> project will start doing this ...
>

I don't see the problem with having many tags. Considering that it would be
a bit of a special thing to do (if automated), case by case permission
would probably be necessary, thus avoiding multiplications of these tags.
It's also not much removed from the use of the ref=* tag.


> Also, in general, there is no way for contributors to verify the IDs
> added by third parties, which makes it hard to verify whether they are
> still valid.
>

Making verification easy could be a requirement for a project wanting to do
this.


> Furthermore there is no guarantee that someone might remove this tag.
> So you will need a fallback method anyway.
>

I don't think any of the three methods I described can work with just one
method. I think you'll probably need all three for decent results.

But I've got the feeling people here believe the "generalized description
link" should work. So maybe that's the best place to start.


-- 
Joost @
Openstreetmap <http://www.openstreetmap.org/user/joost%20schouppe/> |
Twitter <https://twitter.com/joostjakob> | LinkedIn
<https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup
<http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20160809/acbc040d/attachment.html>