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

[Martin Koppenhoefer]

sent from a phone

> On 23. Aug 2020, at 13:40, pangoSE  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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [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. :)

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[pangoSE]

Hi Andy 

Andy Townsend  skrev: (22 augusti 2020 13:03:56 CEST)
> > 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.

Yeah. We should make it dead simple and easy to spin up a copy of our website 
and demo database for anyone to hack on on their pc or in the cloud. I'm going 
to contact the operations workgroup and start working on that because its 
crucial to making the much nedded improvements I'm interested in.

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

What a valuable writeup! Thats very cheap, interesting.
I just found http://fuga.cloud which is openstack based and also very cheap.

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

All right, sounds reasonable 

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[pangoSE]

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  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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[mmd]

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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[stevea]

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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Martin Koppenhoefer]

sent from a phone

> On 22. Aug 2020, at 19:44, pangoSE  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:

https://planet.openstreetmap.org/planet/full-history

Cheers Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[pangoSE]

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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Martin Koppenhoefer]

sent from a phone

> On 22. Aug 2020, at 19:44, pangoSE  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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[pangoSE]

Hi mmd 

mmd  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,  can be used to get more,  can be used to output
>up
>> to 300 entries, _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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Simon Poole]

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,  can be used to get more,  can be used to output
> up to 300 entries, _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
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[mmd]

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,  can be used to get more,  can be used to output up
> to 300 entries, _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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] 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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] 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 > 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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Andrew Harvey]

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  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,  can be used to get more,  can be used to output up to
> 300 entries, _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
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk