Add a possibility to search for primitives compatible to new CT

[anonymous]

Add a possibility to search for primitives compatible to new Contributor Terms or ODBL.

It should be possible to differ between accepted, disagreed and no response.

[bastiK]

This is not so easy as you have to analyse, when a way was split or combined and maybe also way nodes and their history. There is no official policy by OSMF yet, but as long as we only display facts (and do not suggest actions) it should be fine.

[anonymous]

I'm in the process of setting up a fast history API that will allow JOSM to quickly find out which users have touched an object.

[vsandre]

+1

Why not? The data is available for josm and together with the new mapcss support you could create a nice mapstyle. If josm will support the announced fast history API, the displaying could even go further.

[bilbo]

Replying to bastiK:

This is not so easy....

There is already author box which knows about users agreeing or disagreeing to new CT. So if you simplify the problem so that "compatible=last touched by user agreeing to new CT", then the solution could be quite simple. Doing full analysis to come with some "reliable" value maybe close to impossible without very complex history inspection, due to people splitting ways (thus erasing history), or reverting (person A adds tag, person B found that tag to be bad and deletes it - so if A disagrees with new CT and B and other authors that touchd the way agreed, the way should still be CT-compatible, as all contributions of A were removed), etc ...

So I think this could be solved by merely search for all elements with author set to a CT-compatible user ...

[bastiK]

Replying to bilbo:

Replying to bastiK:

This is not so easy....

There is already author box which knows about users agreeing or disagreeing to new CT. So if you simplify the problem so that "compatible=last touched by user agreeing to new CT", then the solution could be quite simple. Doing full analysis to come with some "reliable" value maybe close to impossible without very complex history inspection, due to people splitting ways (thus erasing history), or reverting (person A adds tag, person B found that tag to be bad and deletes it - so if A disagrees with new CT and B and other authors that touchd the way agreed, the way should still be CT-compatible, as all contributions of A were removed), etc ...

So I think this could be solved by merely search for all elements with author set to a CT-compatible user ...

Then we have to do full history analysis or rely on a third party service, that we can query. What is the value in showing objects that have a CT-Ok-user as last editor? Often you have the situation that someone surveys a way and another user only does minor changes to it and stuff like that.

It may be possible to have good heuristics even if you use api calls only, to fetch history. E.g. when a way is split, one of the end nodes usually remains in the old way. So one should inspect the history of the adjacent ways to see if one is a candidate for split.

[bilbo]

Even when considering only last user the result can be valuable - object marked as ct-compatible according to last user may or may be not compatible, but object marked as ct-incompatible is almost surely ct-incompatible no matter of its history.

[kellerma]

Regarding "full history":

Frederik has developed Quick History Service, see ​http://wtfe.gryph.de/

Thank you.

[framm]

I am currently doing a JOSM plugin that will colour things according to their relicensing status; much like the old validator plugin. This will be based on the Quick History Service. I'm sure it will only be a beginning; in the long term we will want to have something that neatly integrates individual history requests and the QHS.

[simon04]

When adding this to the search dialog, this would require fetching data from QHS while performing the search. Therefore better integrating that to the relicensing plugin?

[bastiK]

Replying to simon04:

When adding this to the search dialog, this would require fetching data from QHS while performing the search. Therefore better integrating that to the relicensing plugin?

Yes, so basically we need a way to extend the search engine by plugins?

[joshdoe]

Replying to bastiK:

Replying to simon04:

When adding this to the search dialog, this would require fetching data from QHS while performing the search. Therefore better integrating that to the relicensing plugin?

Yes, so basically we need a way to extend the search engine by plugins?

This is something that is being done in #7178, so once the design is finalized and committed someone can extend the licensechange plugin to provide these kind of search operators.

[anonymous]

Problem is that the plugin does not necessarily have license change data for *all* objects - only for those selected when the user hit the "check license" button. - Maybe the LC plugin should be a bit bolder and insert itself into the download process, so that when the LC plugin is loaded, whenever you download something from the OSM server it will automatically query QHS?

[joshdoe]

Replying to anonymous:

Problem is that the plugin does not necessarily have license change data for *all* objects - only for those selected when the user hit the "check license" button. - Maybe the LC plugin should be a bit bolder and insert itself into the download process, so that when the LC plugin is loaded, whenever you download something from the OSM server it will automatically query QHS?

I think being more intrusive in that matter could have some benefits. However as part of the search operation being executed it could download the license change data; perhaps a slow method (especially for repeated results), but it would at least work.

[joshdoe]

Note that the dependency #7178 has been accepted in core, so this functionality can now be implemented.

What keywords should be used? licenseproblem for any problems and/or separate ones for each category of license problems?

What about getting the license data? Query the server for all objects for every search? Only query the server if license information is missing for some of the objects? Or maybe make the operators UnaryMatch and thus only query a subset of objects in the DataSet? Or as suggested by anonymous insert the plugin into the download process (likely requiring changes to core)?