[Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

Kevin Kenny kevin.b.kenny at gmail.com
Thu Mar 21 17:18:17 UTC 2019


On Thu, Mar 21, 2019 at 10:31 AM Martijn van Exel <m at rtijn.org> 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.



More information about the Talk-us mailing list