[Imports] Oahu, Hawaii CDP boundaries

[Brian M. Sperlongano]

Thanks Steve, this is good background.  I agree with most of this.

I can't buy into the proposed handling of the current Honolulu level 8
relation (119231).  Replacing this relation with one coterminous with the
current level 6 county relation would totally break the local understanding
of the difference between "Honolulu" and the political entity "City and
County of Honolulu".  Anyone that lives in Kailua, or Hale'iwa, or Kapolei
would tell you that they definitely live in a different place from
Honolulu, which a local understands to be the urban area on the southeast
coast stretching from the ocean to the Ko'olau crestline, and from Halawa
Stream to Makapu'u Point.  That's the boundary that a local would expect to
see when searching for Honolulu.  Other places on the island simply aren't
part of Honolulu despite being serviced by the C&C government.  Waianae or
Kaneohe or Mililani are NOT neighborhoods of Honolulu!

IMO, there needs to be *some* way to mark the real-world-use boundary of
Honolulu.  I do agree that an admin_level 8 isn't right because it's not an
administrative boundary.  Perhaps there is some other combination of tags
that can fulfill this purpose.  Defining "Honolulu" by the C&C boundaries
may be pedantically correct by the definition used on the mainland but it's
wrong on the ground.  A place marker alone is unsatisfying because there
are clear-cut boundaries that exist and are understood.  The county is not
a CCC in the way it's understood in other places because there's NO
municipalities in Hawaii.  Therefore, there should be NO level 8 boundaries
in Hawaii, period.  Coterminous boundaries make sense in other places
because they have both CCCs as well as standalone municipalities that are
sub regions of counties.  "C&C of Honolulu" is a naming convention rather
than a merger of levels of government that are otherwise separate in other
places in the state.  If they had chosen the name "Oahu County" instead and
changed nothing else, we'd all agree that this is a level 6 boundary only.


On Sat, Sep 7, 2019 at 1:56 PM stevea <steveaOSM at softworkers.com> wrote:

> Max says:
> > It may make sense to tag the boundaries as place=neighborhood or
> something
> > like that.
>
> Please, gentlemen and gentle readership of Imports List, let us tag
> correctly.  The place=neighbourhood tag (please note the "u" as this tag
> value uses British English) is used for places WITHIN a larger place (like
> a quarter or suburb which itself is within a city) or WITHIN a smaller
> place (like a town or a village).  It may very well be that partly because
> Honolulu-Oahu as a consolidated city-county (CCC) simply "contains and
> surrounds" anything within them that it might be tagged
> place=neighbourhood, so that would be a correct tag.  But if it exists, I
> would want any more-structured, finely-granulated hierarchy to be
> preserved.  For example, if it were proper to characterize a sub-area of
> Honolulu-Oahu as a town (maybe, maybe not), a neighborhood that is truly
> within that town should "aggregate with" the town.  But if it is a
> neighborhood which doesn't associate with a smaller (than city or county)
> entity (like a town or village), but rather Honolulu or Oahu itself, then
> THAT "hierarchical association" should be denoted properly in the tagging.
> This might cause, even force a choice to select place=suburb or
> place=quarter as opposed to place=neighbourhood.  Please see the relevant
> wiki, as this tagging can have subtleties that are difficult to describe,
> yet when they are understood, they can logically map quite well onto a
> particular urban conurbation with a characteristic "Aha!" moment as you
> realize this.  I expect Honolulu-Oahu, with about a million people, has
> some of this complexity, and I'd like to see it correctly captured as OSM
> better tags these.  That is why we have different tags of suburb, quarter
> and neighborhood.
>
> Max says:
> > It would depend on whether they have a firm enough meaning to locals or
> > whether they are statistical conveniences.
>
> Very much "Yes" to the first part, although if by "statistical" you mean
> CDPs (they ARE statistical), then please use boundary=census (if that's
> what the boundary is as you enter those data).  I agree it's PART how
> "firm" a sense of place is to locals, but it's PRIMARILY about selecting
> the most correct value of place=*.  Maybe it's suburb, maybe it's quarter,
> maybe it's neighborhood, but these have subtle differences.  Getting them
> right so they convey whatever sense of hierarchy there is in the real world
> is important.
>
> Max continues:
> > (obviously the places are meaningful to locals, I'm talking about the
> exact
> > boundaries)
>
> Again, should you have and enter exact CDP boundaries (a somewhat
> contradictory statement, as they are statistical, and can't really ever be
> "exact" as they are always slightly changing) it's OK to enter them tagged
> boundary=census, but never with an admin_level tag.  I'll say it one more
> time, a very good place to start (and maybe best in the long-term, almost
> certainly best in the short-term) is a NODE tagged place=*.  This should be
> either centered in the spheroid it roughly defines, or placed at or very
> near a "center" which, for example, might be the commercial area of a
> village (however small it may be).
>
> While Brian says:
> > Being an extinct volcano, the boundaries are usually defined by rather
> > dramatic topographical features.  But yet there are some CDPs (Kaneohe
> > Station) that are as you say statistical conveniences used locally.
> That's
> > why I'm leaning towards using the postal service's boundaries as level 8
> > admin boundaries and CDPs as neighborhoods where they match reality on
> the
> > ground.
>
> Please don't use postal service boundaries in OSM unless they are
> explicitly tagged boundary=postal_code.  This is done in Germany in Belgium
> but not the USA (or if it is, it shouldn't be, in my strong opinion).  In
> this instance (in the USA) I believe it is better to use a node with a
> place=* tag and its proper value.
>
> > For eample, if you look at the leeward (west) coast of Oahu, the
> entirecoast north of Ko'olina uses "WAIANAE, HI" for its postal address, and
> > there are multiple CDPs (e.g. Nanakuli, Ma'ili, Makaha) that are
> > essentially neighborhoods, but with boundaries well defined
> topographically
> > by parallel rivers and ridges running from the mountains down to the
> > coast.  But then there are oddballs like you have a "Makaha" CDP and a
> > "Makaha Valley" CDP just up-valley that in real usage, is one
> neighborhood
> > just called "Makaha"
>
> OSM in the USA doesn't really map postal addresses, as noted above,
> although I agree that sometimes the name of a post office can offer a sense
> of place-name to an area.  In that case, please use a node with a place=*
> tag and its proper value.  CDPs must be tagged boundary=census, not
> boundary=administrative and should not have an admin_level tag with any
> value whatsoever.  It is OK to enter these, but in my opinion, it would be
> better to supersede these (you COULD enter both, but that's slightly
> confusing to many) with nodes with place=* tags and proper values.  If the
> proper value for the areas you are talking about here really meet OSM's
> definition of place=neighbourhood, then please use that tag.  Be respectful
> of what higher-in-the-hierarchy entity (town, city, county...) they
> subordinate to as you do so, please.  And if they don't subordinate like
> this, then place=neighbourhood isn't really the correct tag.  Maybe
> place=village or place=hamlet is a better tag on that node.
>
> Brian continues:
> > Oh, and the whole shebang is contained within Honolulu County which has a
> > county mayor and is administered by the government entity "City and
> County
> > of Honolulu".
> >
> > Hence I am thinking, for example:
> > Honolulu County = admin boundary level 6
> > Waianae (all of zip code 96792) = admin boundary 8
> > Makaha+Makaha Valley CDPs = place=neighborhood boundary, perhaps with or
> > without a level 10 admin boundary.
>
> Yes, to Honolulu County and admin_level=6; this already exists in OSM as
> the aforementioned relation/3861844 (properly, in my opinion, with a node
> tagged admin_centre and a node tagged label).  But, its coterminous
> Honolulu relation does need to be entered (as Honolulu is a CCC), and the
> existing Honolulu (messy, incorrect, old) polygon (tagged boundary=census)
> needs to be removed, or at a minimum must have its admin_level=8 tagged
> removed, as this does not belong on a boundary=census polygon.  This is
> also a weird multipolygon as it only contains one member, if it must
> persist in OSM, de-multipolygonize it by making it a properly tagged
> polygon, please.
>
> No, to Waianea as admin_level=8, as that clashes with Honolulu, which
> should be entered as a coterminous relation to 3861844, but tagged
> admin_level=8 and "City of Honolulu" (distinct from County of Oahu) in its
> name=* tag(s).  Waianea can be entered (in order of preference) either as a
> node tagged place=[town, village, hamlet, isolated_dwelling], a node or
> (multi)polygon tagged place=[suburb, quarter, neighborhood], though please
> have it clear in your mind — or even a note=* tag — what it subordinates
> to, or as a boundary=census (multi)polygon containing NO admin_level tag.
> ONLY if there is a formal political structure, like an elected neighborhood
> council, should boundary=administrative be used on something like Waianea
> (with a corresponding tag of admin_level=10, or 9, if there are two of
> these, one at a higher level of the hierarchy).
>
> It seems complicated.  Yet I know and feel the effectiveness at having
> tagged with these conventions for years, largely because I have read and
> understood ALL of our place=* wikis.  (There are quite a few of them).
> Please absorb this knowledge and let it guide your tagging in Oahu.  Our
> beautiful map will be better for it, more comprehensively conveying to all
> who follow its guidelines, how particular Hawaiian places are named,
> properly.
>
> SteveA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20190915/907ad09d/attachment.html>