> -----Original Message----- > From: David Groom [mailto:revi...@pacific-rim.net] > Subject: Re: [OSM-talk] ODbL-clean Coastlines > ----- Original Message ----- > From: "Russ Nelson" <nel...@crynwr.com> > Subject: Re: [OSM-talk] ODbL-clean Coastlines > > > > Paul Norman writes: > > > I have been running a nightly coastline generation on my server, > using > > > the > > > latest data from my jxapi server. Tonight I switched it over to > filter > > > out > > > data that WTFE reports as dirty. This is somewhat more aggressive > than > > > the > > > rebuild will be, but the results are worrisome. > > > > Nahhhh, not particularly. If you've looked at the PGS, you'll see that > > it is 99% crap. My problem with it is that 1) it's public domain, 2) > > imported by an anonymous user, 3) I fixed it in my region, leaving > > nothing remaining from the original import except the node and way > > existence, BUT (you knew there was a but) without the odbl=clean tag > > that I added, it would have been deleted. Or, at least, OSMI says it > > would have been deleted. > > > > Why are we deleting public domain data from OSM? If it says > > source=PGS, it should not be deleted no matter who did the import. > > If it was subsequently edited by a decliner, well, that's different. > > I guess there are at least two problems. > > Firstly the PGS import script had a "simplification factor" variable, > which > the person running the import could change. I know that prior to doing > my > imports I played "around with" a number of different values for this > variable to strike what I thought was an acceptable trade off between > number of nodes created, and the complexity of the resulting ways. > Therefore what was uploaded to OSM was not simply PGS data, but was PGS > data > as amended by my decision making process. I guess you would have to > know if > the user who did the imports in question made any similar changes. > > Secondly you could use the PGS import script in two ways. Either (i) > run > the script against the PGS data and let the script directly upload to > OSM ; > or (ii) use script to create an OSM file, which could then be edited in > JOSM, and then use JOSM to upload the data. If choosing method (ii) you > were then able to look at the data in JOSM and make corrections to it > before > uploading to OSM. Although when doing my imports I started using (i) I > later switched to method (ii) because that way what I uploaded to OSM > was > more error free. Had I now been a CT decliner I see no legal difference > between the resulting data in this instance and data which "If it was > subsequently edited by a decliner, well, that's different".
Yes - You'd need to know the process the importer used to see if they had any IP in what was uploaded. This has been done for some CORINE imports with changeset overrides (http://wiki.openstreetmap.org/wiki/Quick_History_Service) _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
