It might go without saying for most OSM contributors, however, it is time to say out loud: data which make their way into OSM must be
1) Of a geographic value such that they positively further the goals and hew to the tenets of the project, 2) Current or recent, not of a vintage that even as entered do not fully reflect on-the-ground reality right now, 3) Especially if imported, of a scope which, even if large, become structures which conform (<2000 nodes) rather than overwhelm, 4) Free from extraneous key-value pairs which have no reason to be in OSM, 5) Able to last well into the future, or at least until a next update of a newer, better dataset, and 6) A contribution to the depth, richness or correctness of our shared map data, not primarily for the amusement of the contributor. Unfortunately, I am of the opinion that much data from FMMP imports largely fail all of these. Paul Norman's brief contribution to this thread may not have teased out the logic of his actions that allowed him to partially remedy the situation, and I don't wish to put words in his mouth, but it seems clear he first reached similar conclusions. I say this that we might understand it is OK for us to conclude there truly are bad data in OSM and we can and should do something about them (delete them, improve them if they have partial value...). Of course, proper vetting BEFORE an import is precisely what largely prevents this in the first place. This happens to be a case where we already have such bad (well, perhaps "marginally useful") data in our map. I think it important that we reiterate that mature, seasoned OSM editor/contributors can and should redact (or improve) these data when they are identified to be marginally useful or just plain bad. While doing so, good, clear communication, especially with the original data editor/importer/author, is paramount. Thank you, SteveA California On Aug 15, 2017, at 7:21 AM, Tod Fitch <t...@fitchdesign.com> wrote: > Definitely a pain. It took me a long time to alter (I hope improve) the land > cover around the Morgan trailhead and San Mateo peak. Trails, etc. were easy > to do from my Garmin tracks and satellite imagery but working with the > existing land use/cover was so frustrating I nearly decided not to touch it. On Aug 15, 2017, at 6:37 AM, Steve Friedl <st...@unixwiz.net> wrote: >> The challenge with the Scrub from Hell is that it’s mostly one huge area >> (role=outer in 8 segments) and 40 or something role=inner that provide >> “cutouts” for things other than natural=scrub; this could be a lake or it >> could be a city or whatever. This is the largest single object I’ve ever had >> to work with in OSM. >> I guess I’ll start looking for natural boundaries to split the big area into >> smaller ones which will make them more manageable (and separate). >> >> Some have suggested just removing the scrub entirely, but this is going to >> make the Santa Ana mountains look lousy; it’s almost entirely scrub, and >> that’s where I hike. _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
