[OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[pangoSE]

Hi Martin

I cooked up a suggestion for implementation of permids :) 

Den Sat, 22 Aug 2020 20:56:05 +0200
skrev Re: [OSM-talk] New API suggestion: Allowing contributors to
easily track their OSM-objects over time:

> On 2020-08-22 19:55, Martin Koppenhoefer wrote:
> > What kind of permanent ids do you want? For some more abstract
> > concept like a road with a specific name? A shop? A building? If
> > there’s a way tagged with building=supermarket, shop=supermarket,
> > name=Foo, and you add a permanent id to it. Then the supermarket
> > gets bought by someone else and changes to name=Pango? Or the
> > supermarket closes. Or it gets torn down and rebuilt by the same
> > operator. Or someone detaches the shop tags and adds them to a node
> > inside. What happens with the id?  
> 
> Your comment is spot on. We're discussing technical ideas for
> something that isn't even clear on a semantic level.
> 
> Somehow this whole discussion reminds me of this blog post [1], in
> particular the "Lack of Permanent IDs" section. A "Conceptual Object"
> as it is described in that blog post sounds like a great idea, yet it
> suffers from the same real world semantic issues that Martin already
> pointed out.

Could you give an example of the issues you are talking about? I'm
thinking we have a need to preserve the ids of anything with tags in
OSM (that is what you navigate via or to/from and whats interesting
for the outside world to link to (I have seen very few links ever to
nodes without tags, because they are often part of a way or
relation with tags or useless orphan nodes)). 

This is how it could work:

Say a shop: Mens Wear within a building is represented today as a node
in osm with a permid=Z123. Then someone deletes it erroneously when
the shop closes and we preserve Z123 and the last known position and
node tags (because it has a permid). 

Someone else comes along and
creates a new shop node: on the same spot or close nearby and now the
question arises, should the new node created be linked to the old Z123
or should we create a new permid=124?

We ask the mapper. If they get information about what was
deleted, they can judge whether the Z123 is still conceptually valid
and restore the old shopspace and rename it to the name of the new shop:

(this would preserve the history old->new also from the earlier
deleted node too essentially making it possible to restore nodes
with permids because they are valuable).
 
The permid then no longer represents a shop but the
location of a space where a shop could and now does exist. Someone
making a service cataloguing all shopspaces for hire in a city could
then link to this shopspace FWIW.

External tools like Wikidata might link to it because they want to list
all locations for a particular brand of stores. If the shop moves to
another shop area the permid of the shopspace remains the same,
wikidata will then have to purge the location and could do that either
by looking at the name tag present or if a qid is present. We could
create a special API or egress dump with an entry every time a name or
qid changes of one of our permids, that wikidata could ingest.

This is all just spun up out of the top of my head so it might not be
feasible, but I think it would work. Of course permids should be
handled in the background when users are creating a node and adding a
tag (I never get to select or edit a permid in wikidata but I can merge
two who represent the same physical concept in the same spot and the
earliest one (lowes id) lives on and the other higher id simply refers
to it).

I hope this made sense to you all, if not feel free to ask.

> 
> 
> [1] https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/

Thanks for the link. I read it before and forgot about it. Reading it
again I see 2 years have passed and not much has changed it seems
(besides we have a little more AI stuff going on in HOT and FB and
OSMF has opened for free membership of active mappers). Maybe he is
right that OSM has lived out its time and is unable to adapt, maybe
not. Lets create a high quality database, not just a mediocre
one with unknown quality and an outdated, stale infrastructure. :)