Modify

Opened 10 years ago

Closed 9 years ago

#6232 closed enhancement (wontfix)

Add a possibility to search for primitives compatible to new CT

Reported by: anonymous Owned by: framm
Priority: normal Milestone:
Component: Plugin licensechange Version: latest
Keywords: search odbl ct Cc: framm

Description (last modified by joshdoe)

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.

Attachments (0)

Change History (15)

comment:1 Changed 10 years ago by bastiK

Cc: framm added

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.

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by 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.

comment:4 in reply to:  1 ; Changed 10 years ago by 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 ...

comment:5 in reply to:  4 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by kellerma

Regarding "full history":

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

Thank you.

comment:8 Changed 10 years ago by 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.

comment:9 Changed 10 years ago by 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?

comment:10 in reply to:  9 ; Changed 10 years ago by 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?

comment:11 in reply to:  10 Changed 9 years ago by joshdoe

Description: modified (diff)

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.

comment:12 Changed 9 years ago by anonymous

Priority: majornormal

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?

comment:13 in reply to:  12 Changed 9 years ago by 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.

comment:14 Changed 9 years ago by joshdoe

Component: CorePlugin licensechange
Owner: changed from team to framm

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

comment:15 Changed 9 years ago by Don-vip

Resolution: wontfix
Status: newclosed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain framm.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.