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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

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

pangose
Hi

I would like to track all objects that I ever created or edited.
I suggest we implement a system to make this easy.

I suggest we create a new system that is updated every time a changeset is uploaded. The new system tracks userids and osmids and date of last change/edit.

When I create or edit an object an entry is made in this system (if a way is converted to relation the relation id is added and so forth). If another user converts my way to a relation the system edits the userobjects table of both users. This works around the problem of missing permanent ids. If a node, way or relation is deleted by anyone the row in my userobjects is deleted)

The system can then be queried lke this:

IMPLEMENTATION SUGGESTION:

GET Openstreetmap.org/api/userobjects/pangoSE
Outputs objects for user pangoSE with the oldest first (outputs 10 entries, &offset can be used to get more, &size can be used to output up to 300 entries, &modified_date=desc by default)

The osmids of the objects can then be used to query the suggested verification endpoint to easily find old userobjects that are stale and need reverification. The user can be used to generate maps and gpx exports of all osmids needing verification for the user to use during a mapping quest.

This data is privacy sensitive so the endpoint should require permissions from the user to make it easy to write a script or service that uses the data on behalf of the user.

WDYT?

Cheers
pangoSE
--
Skickat från min Android-enhet med k9.
_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

Andrew Harvey-3
I think you can set this up with OSM Hall Monitor https://github.com/ethan-nelson/osm_hall_monitor by tracking all the objects you touch and setting them up as subscriptions.

Personally I found it easier to just subscribe to my whole city in OSMCha.

Nothing is stopping such a system being built at the moment as a 3rd party service, just needs someone motivated enough to build and support it.

On Sat, 22 Aug 2020 at 19:11, pangoSE <[hidden email]> wrote:
Hi

I would like to track all objects that I ever created or edited.
I suggest we implement a system to make this easy.

I suggest we create a new system that is updated every time a changeset is uploaded. The new system tracks userids and osmids and date of last change/edit.

When I create or edit an object an entry is made in this system (if a way is converted to relation the relation id is added and so forth). If another user converts my way to a relation the system edits the userobjects table of both users. This works around the problem of missing permanent ids. If a node, way or relation is deleted by anyone the row in my userobjects is deleted)

The system can then be queried lke this:

IMPLEMENTATION SUGGESTION:

GET Openstreetmap.org/api/userobjects/pangoSE
Outputs objects for user pangoSE with the oldest first (outputs 10 entries, &offset can be used to get more, &size can be used to output up to 300 entries, &modified_date=desc by default)

The osmids of the objects can then be used to query the suggested verification endpoint to easily find old userobjects that are stale and need reverification. The user can be used to generate maps and gpx exports of all osmids needing verification for the user to use during a mapping quest.

This data is privacy sensitive so the endpoint should require permissions from the user to make it easy to write a script or service that uses the data on behalf of the user.

WDYT?

Cheers
pangoSE
--
Skickat från min Android-enhet med k9._______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

Andy Townsend


On 22/08/2020 10:32, Andrew Harvey wrote:

Nothing is stopping such a system being built at the moment as a 3rd party service, just needs someone motivated enough to build and support it.

Yes - exactly that.

Until such time as someone writes a "mailing list post to software translator"* it'll need someone to sit down and actually write some code.

 


On Sat, 22 Aug 2020 at 19:11, pangoSE <[hidden email]> wrote:

I would like to track all objects that I ever created or edited.
I suggest we implement a system to make this easy.

I suggest we create a new system that is updated every time a changeset is uploaded. The new system tracks userids and osmids and date of last change/edit.


The changeset feed and the OSM updates feed are both public.   There are things similar to what you want that you can borrow from, but I doubt that there's anything that does _exactly_ what you want right now, so you'll need to write it.

Best Regards,

Andy

* People were making jokes about how it was impossible to do this 40 years ago.  I remember people humorously suggesting "add-ons" to program generator "The Last One" (https://en.wikipedia.org/wiki/The_Last_One_%28software%29 ) saying that "this, really, is the last program you will ever need".  I laughed at the time, but then spent quite a few years in the 80s and 90s writing code generators :)




_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

Andy Townsend
 > How/where was the notes addition proposed and implemented?

If I remember correctly, it was done as a "Google Summer of Code"
project - effectively a sponsorship deal.  However, that project
requires a clone of the OSM website, which is a much harder job than
merely doing something with OSM data as it is updated.

 >  I intended to write it myself it others find it useful.

Great!

 > I would prefer that it is an official api so I don't have to cover
the hosting costs.

Well if you start writing it locally and start initially with a small
extract of OSM data your hosting costs will be zero.  Even if you
absolutely need to go for a hosted server it needn't cost more than a
Northern European cup of coffee a month to start with (see e.g.
https://blog.jochentopf.com/2019-03-07-the-new-osmdata-service.html )

 >  Is there anywhere to post an issue to implement this and later pull
requests?

I'd suggest creating such a place in a shared code repository such as
github (which is where lots of OSM-related stuff already is).  Don't
worry that it isn't "official" - very little in OSM is.  If it becomes
valuable it can easily be built on or incorporated into osm.org
centrally later.

Best Regards,
Andy


On 22/08/2020 11:22, Egil wrote:
(snip)


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
mmd
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

mmd
In reply to this post by pangose
On 2020-08-22 11:08, pangoSE wrote:
> The system can then be queried lke this:
>
> IMPLEMENTATION SUGGESTION:
>
> GET Openstreetmap.org/api/userobjects/pangoSE
> Outputs objects for user pangoSE with the oldest first (outputs 10
> entries, &offset can be used to get more, &size can be used to output up
> to 300 entries, &modified_date=desc by default)

I don't think this is in any way feasible for the main API (and it
wouldn't fit its main purpose as editing API due to the analytical
nature of this request).

OTOH, I know that some people monitor dozens of boundary relations for
any changes via a single Overpass API queries. If you run your own
Overpass instance, and feed it with a list of object ids, you already
have your solution, and we can stop the discussion right here.

Transitions from "I used to be a node, and now live on as way" are more
complex to deal with. At least you would find out that the node ceases
to exist at one point.

By the way, quite a number of people have come up with your suggestion
before, and those projects always projects fail due to the sheer size of
OSM data. OWL (that was one project that was mentioned as GSoC project
in another thread) never took off exactly for that reason.

--



_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

SimonPoole
In reply to this post by pangose

As, independent of any other concerns, a matter of good form, I would want to point out that there is no such thing as ownership of OSM-objects, and discussing a concept of "their OSM-objects" is starting the discussion on the wrong foot.

Am 22.08.2020 um 11:08 schrieb pangoSE:
Hi

I would like to track all objects that I ever created or edited.
I suggest we implement a system to make this easy.

I suggest we create a new system that is updated every time a changeset is uploaded. The new system tracks userids and osmids and date of last change/edit.

When I create or edit an object an entry is made in this system (if a way is converted to relation the relation id is added and so forth). If another user converts my way to a relation the system edits the userobjects table of both users. This works around the problem of missing permanent ids. If a node, way or relation is deleted by anyone the row in my userobjects is deleted)

The system can then be queried lke this:

IMPLEMENTATION SUGGESTION:

GET Openstreetmap.org/api/userobjects/pangoSE
Outputs objects for user pangoSE with the oldest first (outputs 10 entries, &offset can be used to get more, &size can be used to output up to 300 entries, &modified_date=desc by default)

The osmids of the objects can then be used to query the suggested verification endpoint to easily find old userobjects that are stale and need reverification. The user can be used to generate maps and gpx exports of all osmids needing verification for the user to use during a mapping quest.

This data is privacy sensitive so the endpoint should require permissions from the user to make it easy to write a script or service that uses the data on behalf of the user.

WDYT?

Cheers
pangoSE
--
Skickat från min Android-enhet med k9.
_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

pangose
In reply to this post by mmd
Hi mmd 😀

mmd <[hidden email]> skrev: (22 augusti 2020 13:41:00 CEST)

>On 2020-08-22 11:08, pangoSE wrote:
>> The system can then be queried lke this:
>>
>> IMPLEMENTATION SUGGESTION:
>>
>> GET Openstreetmap.org/api/userobjects/pangoSE
>> Outputs objects for user pangoSE with the oldest first (outputs 10
>> entries, &offset can be used to get more, &size can be used to output
>up
>> to 300 entries, &modified_date=desc by default)
>
>I don't think this is in any way feasible for the main API (and it
>wouldn't fit its main purpose as editing API due to the analytical
>nature of this request).

But the notes API is not strictly speaking related to editing either is it? It could also have been created as a thirdparty feature because it has no connections to osm objects anyway.

You could say the same about gpx points and tracks as well.

This is clearly visible in the model: https://wiki.openstreetmap.org/wiki/File:OSM_DB_Schema_2016-12-13.svg

>
>OTOH, I know that some people monitor dozens of boundary relations for
>any changes via a single Overpass API queries. If you run your own
>Overpass instance, and feed it with a list of object ids, you already
>have your solution, and we can stop the discussion right here.

What I want as an individual is not relevant here IMO and setting up highly technical software is not going to help the average editor.

I'm interested in discussing the data model and why this is a core OSM feature we should work together towards supporting.

>
>Transitions from "I used to be a node, and now live on as way" are more
>complex to deal with. At least you would find out that the node ceases
>to exist at one point.

Yeah I'm guessing this will have to be handled somehow. Maybe we should first add permanent ids (new table) and reference that.

>
>By the way, quite a number of people have come up with your suggestion
>before, and those projects always projects fail due to the sheer size
>of
>OSM data.

Interesting that I'm not the first. I did not hear about any others until today. I guess its ahard problem then. I'll take that as a challenge 😉
I see the table sizes here:
https://wiki.openstreetmap.org/wiki/Database/TableInfoDump

Permanent ids would add some GBs in a new table to represent each one of the many nodeids. What is the current rowcount on the current_nodes table?

>OWL (that was one project that was mentioned as GSoC project
>in another thread) never took off exactly for that reason.

Thanks for the pointer. I found https://wiki.openstreetmap.org/wiki/OWL unfortunately it is not stated there why the initiative failed. If someone could clarify that I would be happy to learn more. It does seem quite different from my suggested implementation.

I suggest we add a new tables in the main database instead like we did with notes (2 new tables). What exactly they should contain depend on the way forward we choose.

The information we need to store on every changeset is:
Link between userid and a new permid that is permanent or link between userid and node/way/relation ids

A permanent id is really something that could benefit us in many ways. It could make it possible to reliably link to an object over time which is important in integrations.

So one new table for permanent ids that is updated every time:
* a node is created or deleted
* a way is created from scratch or deleted
* a relation is created from scratch or deleted
* a way is converted to a relation and then deleted (retains the ways permanent id)
* a node is converted to a way
*...

I'm not sure about all the possible transformations, are they already documented somewhere?

Cheers
PangoSE

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

pangose
In reply to this post by SimonPoole
Hi Simon

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

> As, independent of any other concerns, a matter of good form, I would
> want to point out that there is no such thing as ownership of
> OSM-objects, and discussing a concept of "their OSM-objects" is
> starting the discussion on the wrong foot.

I intentionally
avoided the word "own". What I mean is that our users touch a number of
objects by either creating, changing or removing them. Is that correct?

Every time this happens I would like OSM to log that in such a way that
it is possible to track the object (even if the osmid changes). This of
course comes at a cost with every changeset, but I think its worth it
because it makes it possible for users to "follow" an object.

https://wiki.openstreetmap.org/wiki/Database lists our current data
model for anyone interested.

/pangoSE


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

dieterdreist
In reply to this post by pangose


sent from a phone

> On 22. Aug 2020, at 19:44, pangoSE <[hidden email]> wrote:
>
> Maybe we should first add permanent ids (new table) and reference that.


we do have permanent ids for nodes, ways and relations. ;-)
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?

You can have this with relations, but it (associated street, street) did not find a lot of support from the contributors and most mappers have decided for themselves that it does not work for them.

Cheers Martin
_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

dieterdreist
In reply to this post by pangose


sent from a phone

On 22. Aug 2020, at 19:44, pangoSE <[hidden email]> wrote:

So one new table for permanent ids that is updated every time:
* a node is created or deleted
* a way is created from scratch or deleted
* a relation is created from scratch or deleted
* a way is converted to a relation and then deleted (retains the ways permanent id)
* a node is converted to a way
*...


this is all already recorded, you can download it here:


Cheers Martin 

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

stevea
In reply to this post by pangose
One of the best suggestions I and others have made to pangoSE regarding this proposal is a very strong use case or solid, easily-grasped geographically-based examples of a problem (exclusively or largely unsolvable in OSM today, with today's data and tools) that would make for a solvable problem getting solved.  There is a great deal of effort involved from presenting "a solution" to the larger OSM community (first, so we understand it, second so we might reach consensus about it, third so we might implement it with a particular method) when no underlying problem is apparent.  This is what is meant by "a solution in search of a problem."  What is it that pangoSE is so anxious to fix that significant entanglement with a new naming system (linked semantic wrappers) is required?

Perhaps there ARE problems that cannot be solved without such radical changes to our naming machinery.  I'm simply saying I have yet to read / hear one that has been sufficiently articulated for me to consider this proposal further.

If problems are identified and articulated, that's a good and necessary next step.  But then so would be the greater buy-in of a well-presented proposal that engendered sufficient discussion and perhaps eventual wide consensus to proceed with the detailed and accepted proposal.  We are a long, long way from any of this.  Let's start with what might be broken or difficult or impossible to solve with what we have now and go from there.

I'm not saying OSM couldn't benefit by such a scheme (I keep calling it "Web 3.0-flavored" and maybe I'm right, maybe not; pangoSE chiming in about whether his proposal and elements of Web 3.0 overlap or not is very much appreciated).  I am saying, let's have it presented to the community in a way that is usual, potentially successful, "problem first, solution second," bite-sized in a way that makes comprehension widely accessible and solves "something" (rather than as it appears now:  a hive of snarls that looks like deliberate obfuscation by high priests of special knowledge).  Clearly-stated concepts of what this might solve must come first.  Presenting a technical solution without articulated problems it might solve is backwards.

OSM now has an existing "history of object edits."  If you "do it right," it is technically possible to leverage this into what you are proposing ("tracking objects" to "follow" them?) with absolutely no change to OSM's present database model.  Maybe this is a good idea, maybe not.  But pangoSE has not even identified any costs that wold be associated with changing OSM's database model, he simply sent us a link to it (which we can find ourselves, but thanks for the effort).

pangoSE:  please stop ignoring me in these threads.  I'm extending effort to listen, your lack of reply seems disingenuous.

SteveA
_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
mmd
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

mmd
In reply to this post by dieterdreist
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.


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


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

pangose
In reply to this post by dieterdreist
Hi Martin :)

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

> sent from a phone
>
> > On 22. Aug 2020, at 19:44, pangoSE <[hidden email]> wrote:
> >
> > Maybe we should first add permanent ids (new table) and reference
> > that.  
>
>
> we do have permanent ids for nodes, ways and relations. ;-)

Okay I think I understand what you are saying. You are saying that if
I create a node, edit it in another changeset it still has the same
id, right? (same goes for the other 2) The problem is that the rest of
the world talks about physical objects like houses, hospitals and
toilets and not nodes, ways or relations and things relying on OSM break
when mappers enrich the map and e.g. embed nodes in a way and move the
tags to the way.

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

Our datamodel and tools currently does not support keeping a higher
order view of an object and letting the user modify it using our
internal representations at will. Instead we treat objects as like the
don't belong together or relate at all unless they are part of a
relation.

From what I understand an uploaded way converted in JOSM to a relation
get a new osm_relation_id, (asuming I first upload a
node with changeset A, change it to a way by adding another node to it
in changeset B and finally convert it to a relation in JOSM in changeset
C). But I might be wrong about this.

>
> You can have this with relations, but it (associated street, street)
> did not find a lot of support from the contributors and most mappers
> have decided for themselves that it does not work for them.

Yeah, that was perhaps not the best way to implement a model (the name
implies that it only relates to streets btw.) that handles human
features well over time.

Cheers
pangoSE

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

pangose
In reply to this post by Andy Townsend
Hi Andy 😀
_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

pangose
In reply to this post by mmd
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. :)

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: New API suggestion: Allowing contributors to easily track their OSM-objects over time

dieterdreist


sent from a phone

> On 23. Aug 2020, at 13:40, pangoSE <[hidden email]> wrote:
>
> 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.


it really depends what you believe the permID represents, i.e. your usecase. Someone might be interested in the builtup space of the shop, another one on the business operated by this operator and yet another one in businesses selling men‘s wear or selling clothing of selling products in general.
According to this interest, the permanent ID would either have to be kept, or marked as „closed“ or „sold“ and a new one created, etc. Neither the API nor the mapper who maps the update can know what action they should perform wrt the permanent ID because it is only clear within the context of those who use the ID, not within the map data itself.

There is a concept for permanent IDs with overpass API, are you aware of it?

I believe this is nothing that the main API must provide, it can be a third party offering.

Generally, all the OpenStreetMap history is recorded and available, so you can already track those events which are interesting to you.

Cheers Martin
_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk