[Talk-us] Boundaries and verifiability (was Re: Retagging hamlets in the US)

Greg Troxel gdt at ir.bbn.com
Mon Apr 20 12:57:16 UTC 2015


Martijn van Exel <m at rtijn.org> writes:

> On Wed, Mar 25, 2015 at 3:00 AM, Minh Nguyen <minh at nguyen.cincinnati.oh.us>
> wrote:
>
>> If you're lucky, you can find an Ohio city limit's legal definition in
>> county commissioners' minutes when an annexation is proposed. The most
>> authoritative data representation is the county GIS database, which anyone
>> can easily access -- for a fee. After paying the county for that database,
>> you might well forget about OSM, because it's also the authoritative source
>> for road centerlines and names.
>
> That is actually not what I meant, but I could have been more precise. I
> guess this turns into a discussion of what 'authoritative' actually means.
> This is different things to different people. As OSM becomes better,
> increasingly folks will start looking at us for authoritativeness, which
> would make sense because everything is (supposed to be) verified on the
> ground.

"authoritative" is a complicated word.   One sense is the source that
legally defines something.   The other sense is what people usually mean
with maps, which is about whether the map production process is such
that a user can have a high degree of confidence 

> Because administrative boundaries have legal implications, the
> authoritative source will need to be someplace outside of OSM.

True, but I don't see the point.  The authoritative source for whether a
road exists is the fact in the real world, so that's outside OSM too.  A
map (database; that's not the point here) is a collection of useful
facts, and except for maps published by entities whose word defines the
world, no maps are authoritative in this sense.

It's certainly true that no court would decide if a house is in a
particular town by looking at OSM.  I'm not sure if you're suggesting
deleting all the boundary data, or just pointing out that most court
cases will not use OSM data, or something else.

> It may actually hurt OSM down the line if we include information that
> suggests authoritativeness we cannot provide.

I really don't follow your logic here.  OSM has all sorts of
information, and is the authoritative-as-defining source for essentially
none of it.  This is true of arguably every general-purpose map.  Even
the USGS map includes information where the Board of Geographic Names is
authoritative.

When I hear regular GIS people talk about authoritative data in the
context of OSM, the concern is that anyone can edit and there is no QA
process, so how can the data be trusted?  This is compared to NAVTEQ
(just to pick on), which presumably takes State DOT data and surveys/QAs
it (so how can the data be up to date?).  Whether the crowdsourcing
process or the standard process leads to better data is not a settled
question; there are valid arguments about the process both ways.  (I
find OSM data to be generally better in Massachusetts than e.g. the
proprietary data that comes with a Nuvi, but in some places it's worse.)

With respect to boundaries, careful curation of boundary information
(from the law, as Minh suggests, or actual stones in my state) by OSM
people leads to a good set of data, arguably as good as included in any
other general-purpose map.  So it's just the usual grand struggle to
improve and add data, and I don't see why there should be any special
concerns about authoritativeness.

>>>  All of this has little to do with neighborhoods, which are mostly (?)
>>> vernacular in naming and delineation, and even when there are official
>>> neighborhood designations, in my own experience they do not always match
>>> the vernacular names. I support point mapping of vernacular
>>> neighborhoods. If you really want to have shapes for vernacular
>>> neighborhoods, you can look at the now-ancient-but-still-cool flickr
>>> Alpha Shapes[2], last updated in 2011 but still available for
>>> download[3]. But please don't upload 'em to OSM :)
>>>
>>
>> As a political boundary (in the political map sense), an official
>> neighborhood designation can be distinct from the neighborhood with a
>> vernacular name, but that's an argument to map both rather than favoring
>> one over the other. They coexist and might share a name but aren't
>> necessarily the same thing. People should be able to get the concrete,
>> objective boundary of an official neighborhood from OSM and an amorphous,
>> subjective boundary of an informal neighborhood from Alpha Shapes.
>
> Sure, but vernacular and official neighborhood objects would then need to
> be represented differently so folks can tell them apart and know what they
> are dealing with.

That's basically admin_level=10 for an official neighborhood (I think
Boston and Newton have these), and some sort of place=locality for
things without legal boundaries.

This is related to the hamlet discussion.  One of the issues with OSM's
place name schema is the confusion between place names and boundaries.
Boundaries are actually pretty clear how they should be.  But the
place=town etc. talk about population, and you can't have population
without a boundary.  That probably made sense long ago when there were
villages with obvious boundaries (even if not defined legally; the last
house in the village was obvious) and then a few farms.  But now, at
least around me, there are town/etc. boundaries and within them
population is a clear concept.  Within these named towns there are
things that used to be "villages" (New England term, not OSM term).
They usually have a recognizable built-up center, but it's really hard
to talk about population.

I have been pondering this and avoiding jumping into the hamlet thread
-- but have more or less converged on the opinion that places that
aren't a unit of government and don't have a population should get
place=locality instead of place=hamlet.  Thus most of the GNIS
place=hamlet nodes could be converted.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20150420/87ef3ea9/attachment.sig>


More information about the Talk-us mailing list