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.