[OSM-talk] Tool for tag tracking

Tobias Zwick osm at westnordost.de
Fri Jan 12 13:24:18 UTC 2018


Wow, Roland, this is awesome!

So, this seems to make any deliberations of introducing a
survey_date:something tag or similar obsolete, because in the future,
one will be able to search with overpass through the history on a
per-tag basis.

This will make it possible for QA and hm... data-actuality-maintenance
tools (made up this term, this category of tools doesn't exist yet I
guess) to find data that haven't been changed for a long time and should
be re-checked some time.
I am thinking of finding automatically certain data points (tags) that
haven't changed in the database for X months and should be re-surveyed.
Will that be possible also (checking for "last change on tag older
than...")?

This feature makes it possible to greatly improve the maintainability of
data in openstreetmap.
For example the smoothness of streets and cycleways in particular is
something that should be revisited every few years, same as the street
surface especially in developing countries. Also, the presence of
cycleways on streets might be something that should be re-checked every
decade or so at least. Etc etc

Great work!

Cheers
Tobias

On 12/01/2018 06:31, Roland Olbricht wrote:
> Hi,
> 
> for the sake of completeness, I would like to give a preview what is in
> the development for Overpass API:
> 
> Similar to this one
> 
>> https://help.openstreetmap.org/questions/54268/search-for-objects-created-after-a-certain-date-with-overpass
>>
> 
> you could nowadays search with https://overpass-turbo.eu/s/uF0
> for all highways that have changed since the beginning of the year in
> and around Antwerp:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> out geom;
> 
> I suggest the "out geom" mode over recursing to the nodes. Overpass
> Turbo can handle both, but the "out geom" means that there is exactly
> one item per object in question. No unchanged nodes get involved.
> 
> The above result is bloated by objects like
> https://www.openstreetmap.org/way/469659128/history
> It has no change to its highway value but just lost the unrelated tag
> "horse=no".
> 
> Here comes a feature in the staging area for the next version into play.
> We do not ask for all changes but just for changes that affect the tag
> "highway": https://overpass-turbo.eu/s/uF2
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:t[highway]);
> out geom;
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> The line "compare(delta:t[highway]);" reads as: keep only objects that
> have changed in the value "t[highway]". The last line is a directive to
> execute the query on the development server.
> 
> We could even drill down further and retrieve only objects that have
> been created or deleted: https://overpass-turbo.eu/s/uF4
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0);
> out geom;
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> This is admittedly hacky and the final implementation might have a more
> straightforward term. The condition for "compare" always evaluates to
> the empty string for non-existing objects. And for existing objects to
> "0" as we just have specified, hence it can tell apart existing from
> non-existing objects.
> 
> Can we separate the deleted from the created objects? Yes,
> https://overpass-turbo.eu/s/uF7 delivers only created objects:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0)
> (
>   way._(newer:"2018-01-01T00:00:01Z");
>   out geom;
> );
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> And https://overpass-turbo.eu/s/uFa delivers only deleted objects:
> 
> [diff:"2018-01-01T00:00:00Z"];
> way[highway]({{bbox}});
> compare(delta:0)
> (
>   ( ._; - way._(newer:"2018-01-01T00:00:01Z"); );
>   out geom;
> );
> {{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}
> 
> Please note that these are not yet in a published release because there
> may come up a reason to change the syntax. If that happens, I will write
> a mail here again. For example, it might be more concise to do these
> tasks with a three argument "changed" condition. But I have not
> evaluated yet whether this leads to a logically sound syntax.
> 
> Best regards,
> Roland
> 
> 
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk




More information about the talk mailing list