Re: [OSM-dev] Measuring the current state of play wrt new contributor terms
Hi Jim, nice idea. The code could also be reused for the revert scripts in case some Teleatlas data has to be removed aagain. Jim Brown wrote: * Where geometries have changed: o If the object has a prior version, take the prior version of the geometry and then apply subsequent geometry edits past theirs o If the object does not have a prior version, then it is probably lost to the db along with its tags. I'm not sure about this. At least on the node level it should be changed. If a node is moved then this is a combination of two actions: First delete old coordinates second insert new coordinates. So there is nothing left from the previous coordinate that needs to be removed. Even the information that there is an object is implicitly inserted again by the new editor. From the algorithmic POV: reset the geometry to 0,0 (or some other magic number). Then apply subseqent geometries. In case at the end the geometry is still 0,0 remove the node (with its tags) o If the object has a newer geometry use the newest geometry available o If the object has no newer geometry but a prior version, take the prior version o If the object does not have other geometry information, then it is probably lost to the db along with its tags. Stephan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Measuring the current state of play wrt new contributor terms
Am 09.08.2010 23:27, schrieb Jim Brown: and a feed of the userids of those who have accepted the new terms and conditions (also updated over time) Wehre do you plan to get this from? I thought about developing a web-app that connects to the OSM Page using OAuth and allows users that have not yet voted to give their opinion. This Voting would be totally meaningless for the LWG but could be interesting for such an analysis. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Measuring the current state of play wrt new contributor terms
The plan is to make it an opt-in on the account page shortly per the rollout plan. And then make it a simple extract updated on a regular basis for this type of analysis. j -Original Message- From: Peter Körner [mailto:osm-li...@mazdermind.de] Sent: 10 August 2010 07:01 To: Jim Brown Cc: dev@openstreetmap.org Subject: Re: [OSM-dev] Measuring the current state of play wrt new contributor terms Am 09.08.2010 23:27, schrieb Jim Brown: and a feed of the userids of those who have accepted the new terms and conditions (also updated over time) Wehre do you plan to get this from? I thought about developing a web-app that connects to the OSM Page using OAuth and allows users that have not yet voted to give their opinion. This Voting would be totally meaningless for the LWG but could be interesting for such an analysis. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Measuring the current state of play wrt new contributor terms
Hi, On 9 August 2010 23:27, Jim Brown j...@cloudmade.com wrote: and for each row/object type show: # objects in db as of last update # tags in db as of last update # objects totally clean (all editors in the history have accepted) # objects initial editor accepted # objects clean so far (no editors have refused) # objects initial editor refused (entire object may be lost) # objects with partial data loss (one or more editors have refused, but not the first one) # tags totally clean (all editors in the history have accepted) # tags initial editor accepted # tags clean so far (no editors have refused) # tags initial editor refused (entire tag series may be lost) # tags with partial data loss (one or more editors have refused, but not the first one) It may be more readable if instead of making separate categories for accepted and not refused you'd have two values for every category: the min and max. Min would assume that all undecided will accept and max would assume that all as yet undecided will refuse (or do nothing), the two numbers should be slowly getting closer Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
