[Talk-us] [Talk-us-newyork] [Imports-us] LAST CALL - Retagging of place nodes in NewYork State

[Kevin Kenny]

On Wed, Sep 7, 2022 at 8:54 AM D. Joe <osm+joe at etrumeus.com> wrote:

> On Tue, Sep 06, 2022 at 02:22:43PM -0700, Minh Nguyen wrote:
> > Vào lúc 09:49 2022-09-06, D. Joe đã viết:
> > >
> > >First, to be clear, I do not support changing the New York State place=
> tags as proposed.
> >
> > Can you elaborate on your concerns or link to where you've previously
> > brought them up, for the benefit of those who are only aware of the
> proposal
> > due to this last call?
>
> I began to address them in an earlier email.
>
> The core of my concern is
>
> > I'm deeply uneasy at the thought of a proposed scheme for tagging places
> in New York based on arbitrary population threshholds, while in the process
> overloading and obscuring how those terms are used every day in the state,
> eg, city, town, village, hamlet.


That's a fundamental misunderstanding.

I'm not proposing a scheme for tagging moving forward.  I'm proposing the
first step toward cleaning up a mess. Right now, what we have is entirely
without rhyme nor reason. We have nearly uninhabited townships in which the
tiny hamlet that bears the town's name gets `place=town` because it's a
township. (RIght down to Red House, pop. 27, if memory serves).  We have
small cities of 50-60 thousand inhabitants classed as `place=hamlet`
because they're governed by their respective townships. And we don't have
even that consistently because mappers have tried to fix it on a spotty
basis. The place nodes tell us nothing useful about the places.

> Or maybe the population information could be carried by a different tag?
>
> because I wasn't conversant with the popululation= tag to that point.
>
> It seems that this scheme brings no further information to bear than what
> that tag already presents, merely stretching that information further into
> a crude binning.
>
> What's more, it does so at the expense of, at the best, perpetrating the
> confusion borne of having multiple administrative areas with the same name
> that are either adjacent, or overlap. At worst, it creates further
> confusion of its own by adding yet another thing that would carry something
> idiosyncratically OSM's alone.


Please note that we are dealing with only _nodes_ in this proposal.

The multiple administrative areas that have the same name are all there as
boundary relations.  Their names all are tagged with
`border_type={city,borough,town,village,hamlet}.  They are named more
formally, "City of Elmira", "Town of Elmira" so that the line between city
and township will render correctly.  They have wikipedia and wikidata
links; moreover, the city, village and town halls are nearly mapped (I
think there are about 1500 out of 1600 done), and have `operator:wikidata`
links that match the corresponding boundary. (They are not `admin_centre`
by the OSM definition and so do not participate in the boundary relations.)

There's no loss of organizational information here.  Where the Village of
Schoharie lies within the Town of Schoharie within Schoharie County, the
relations all reflect the fact. The populations of all three regions are
shown. All three have separate GNIS, FIPS and SWIS
codes, separate Wikipedia and Wikidata links, and so on.  The seats of
government of all three are identified.  None of this will change.  The
only thing that's affected is the label nodes: the objects that make dots
on a small-scale map.

In all cases where a 'place' node represents multiple administrative
regions (Village and Town of XXX is the usual combination), the place node
does NOT have the FIPS code, SWIS code, WIkidata and Wikipedia links, and
population of either region - it simply carries name, GNIS ID, elevation
and place=*.  The population and administrative information are on the
relation that it labels.

It's taken me countless hours over the better part of a year to bring the
relations to this point. When I started, about a quarter of the townships
weren't there at all, and there were wildly inconsistent boundaries all
over the place, the result of four or five not-entirely-successful imports
from GNIS and TIGER, neither is well regarded as a source of clean and
authoritative information.


> Population alone cannot be the arbiter of what constitutes any given type
> of place, otherwise we might perpetrate absurdities like calling Montana a
> city: Thin as the population is, if we encompass all within its boundaries
> we get a bustling "metropolis" of a million people.


Note that the changes proposed do not affect any administrative region
larger than a township. I'm not going to call a county a city!

The five boroughs of New York City are already accounted for and will not
change. The sprawling rural townships that do not contain villages or
hamlets all have low enough populations that they would come in as villages
or hamlets in any case - and this is fitting, since they really don't
contain anything that would class as a 'regionally significant population
center'. Their residents will mostly travel outside the township to shop
for anything but routine groceries, see a doctor, visit a bank, and so on.

You're right that stratifying based on population cuts with a dull knife,
but it's a start.   In an ideal world, we'd conduct a study of all 1600
municipalities in New York, evaluating them for the presence of services
such as shopping opportunities, banks, airports, colleges and universities,
railroad stations, hospitals, libraries, and so on. We'd then
systematically de-rate places that are within the 'sphere of influence' of
nearby larger communities, and so on.  But I'm not going to get anything
like that done in a reasonable length of time. All I'm proposing is that
(a) the relations have accurate information about boundaries, populations
and links to external data sets. (Done, for the most part) and (b) that the
labels are at least not wildly off the mark in terms of importance.

This is a stopgap measure, no more and no less.

-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20220907/6e7e59fb/attachment.htm>