On Thu, Mar 21, 2019 at 10:31 AM Martijn van Exel <[email protected]> wrote: > The benefit is that it gives mappers a reason to examine places - not just > the disappeared feature itself but also the area around it - that would > otherwise go unexamined. Since we have so much unexamined space in the U.S., > any opportunity to spark mappers’ curiosity about some of that space, is a > welcome trigger.
I need no incentive like that, and no mapper that I've corresponded with does. I'm still in the middle of an area where TIGER mapping is absolutely atrocious, and I've cleaned only small corners. I've found that it's the best use of my very limited time to confine my edits to places that I've visited or intend to visit, which is why you'll see most of my mapping taking place in my own neighbourhood, in the vicinity of hiking trails, on the roads that I've travelled to get to the trails, and the imports that I curate with respect to the boundaries of public lands. I've edited and conflated a bunch of GNIS points. I have yet to see one marked as (historic) that was of the least bit of use. For the best of them, they designate a building that is still standing but has been repurposed. If I'm mapping buildings, I'll get around to that one in any case. If I'm not micromapping to the level of individual buildings, the information that "the private house here used to be a two-room schoolhouse," is simply a distraction. Even if I am mapping buildings, often the remodelling is so extensive that I can't spot any indicia that it was once a schoolhouse, and can't even state with confidence that the building wasn't demolished with a new building constructed on the site. For the limited sample of (historic) GNIS points that I've encountered, there is simply zero value to OSM (beyond possibly the spot elevation, which is also often of questionable quality.) I can't speak to OHM. I've never contributed to that project. I propose to let those who do contribute to it manage their own data imports, and judge the value of (historic) GNIS data only with respect to OSM, the project at hand. > It may feel like a time sink for some, but my hope is that others will feel > it’s an interesting exercise to improve the map. I understand in principle - but I don't see bad GNIS data as being any greater incentive than bad TIGER data - and the anti-import crowd hold the failure of the bad TIGER data to recruit mappers to fix it as a model for why imports in general have a negative impact on the community. Moreover, I've tried MapRoulette a few times, and every time, come away with a mix of, "I don't have enough local knowledge to do a good job here," and "I can make better progress cleaning other things up closer to home." Most of the things it gives me, I wind up clicking "too hard," while possibly tidying something else. > Stepping back a bit, the urge to fix previous automated edits with new > automated fixes is understandable, but it may lead to a more casual approach > to imports and automated edits, because we basically say with each fix that > ill-informed automated map edits can always be fixed with more automated > edits later. We’ve already gone down that path in the U.S. quite far, so we > should proceed with extra care - unless we as a community decide that that is > the nature of OSM in this country. It isn’t to me. Merciful heavens, no! Still, the fact remains that we have a bunch of botched imports from the early days of mapping in the US. No, 'botched' is too strong a term. They were done well according to the practice of the time. They significantly advanced the usefulness of the map when they happened. Still, in light of what we've learned since that time, they fall catastophically short of the data quality that we now expect of an import. Few, if any, of us argue in favour of importing at even close to that level of carelessness. Are you really arguing that making it as laborious as possible to repair _known_ bad data in these early imports is desirable, in order to discourage future reckless imports? That doesn't strike me as the way to make forward progress. For what it's worth I speak as someone who's, on a much smaller scale, taken on the repair of an early import that was of unacceptably loiw quality by today's standards. Check out https://www.openstreetmap.org/user/ke9tv-nysdec-lands/history for how much work *that* was. Without developing significant automation (a script that worked off PostGIS queries and connected to the JOSM API to set everything up for manual conflation), I'd not have been able to complete the task. I won't say that the results are perfect - nothing ever is - but it's a whale of a lot better than what was there before, and I use the result with confidence for guidance in the field. (And yes, the project was discussed on talk-us and imports, and wikified at https://wiki.openstreetmap.org/wiki/NYS_DEC_Lands - so I offer at least the semblance of due diligence.). So - don't tolerate ill-considered imports, but don't punish those who are trying to clean up old messes 'pour encourager les autres'! The discussion here is of the right level of diligence. A blanket 'no' is simply demanding to prolong the pain. I, too, would appreciate seeing some sample data, let's say, some reasonable radius around 42.8257, -73.8790. That's more to make sure that the technology is working right and not wetting on stuff that's already fixed, but of course, I'd check to verify my tentative conclusion that (historic) doesn't tag anything useful. _______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
