Hi mmd 😀 mmd <mmd....@gmail.com> 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 talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
