This is from a thread on impo...@openstreetmap.org of the same title (Vol. 123, 
Issue 6).
The thread is not attached here, but it involves Brian asking after tagging CDP 
boundaries in Oahu County and its coterminous incorporated 
consolidated-city-county of Honolulu.

Brian, I agree with Mateusz that you help OSM by specifying better granularity 
of place tagging on Oahu, but with some minor clarifications.  In the USA, we 
tag CDP polygons with boundary=census, no admin_level tag with any value 
whatsoever.  We do not tag postal boundaries (or if we do, we shouldn't), as 
while the USPS is sort of ("barely?") governmental, the imprimatur of locality 
that it may lend an area, its ZIP code, isn't a boundary at all, it is more 
like a routing algorithm for mail, so I disagree with your "reasonable 
approach" conclusion in your option 2.  Yes, it is true that the name of a post 
office may offer a sense of place (name) to an area.  In my strong opinion, 
those MIGHT be tagged with a node, if no other better place/locality name data 
are available.  I slightly disagree with Mateusz that we "reflect local postal" 
boundaries, as we don't do that in the USA with ZIP codes:  they are routing 
algorithms, not actual areas definable by a (multi)polygon.  I do agree with 
him that "it makes sense" to sort through and both better understand and better 
tag such "smaller than an island/county" areas.  In the USA, and in a state 
with no municipal government (an oddity of Hawaii, but a truth nonetheless) 
this is best done with nodes tagged place=* primarily and secondarily CDP 
boundaries (as they are more statistical than on-the-ground factual and by 
definition change constantly).  DISTANTLY secondarily.

CDP boundaries should be actual (you say state GIS authorities provide these 
federal data), tagged boundary=census (and no admin_level tag).  But I assert 
that much better are nodes tagged with place=*, with appropriate values (town, 
village, hamlet, isolated_dwelling).  In the USA, these are added to OSM nodes 
like this largely based on population.  For example, in the 
https://wiki.osm.org/wiki/United_States_admin_level#Unincorporated_areas 
section of the wiki I referred to earlier, we say "place=village on rural 
unincorporated communities with a population between 200 and 9,999 (consensus 
is emerging that a 'village' has at least a small commercial landuse area: a 
market, fuel station/convenience store, a bank, post office, etc.)."  For 
populations between 10,000 and 50,000 tag the node place=town, for between 
three households and 199 tag the node place=hamlet, etc.  (Our wikis can be 
helpful).

So, to sum that up, tag with place=* nodes where you can (or have population 
data, or even better, know personally from local, on-the-ground experience).  
If you have nothing else, CDP data tagged as boundary=census polygons are OK, 
but in some sense, these data are not much more than "better than nothing."  If 
a post office name is used on a node for an area with a place=* tag having an 
appropriately-population-derived value, that's OK, too, but don't use ZIP code 
"boundaries," such data don't belong in OSM.

Concomitantly, "CDP boundary data are available for Hawaii" is similar for what 
is going on with the same for Alaska:  simply because the federal Department of 
Commerce's Census Bureau aggregates population data into statistical areas 
(CDPs) doesn't absolutely mean that these data are the best representation of 
"place and size" to enter into OSM.  (In Alaska, they are convenient to 
delineate smaller areas of the Unorganized Borough — a huge area bigger than 
even Texas — and these areas are created in mutual cooperation with the state 
of Alaska, adding to legitimacy for OSM entry).  Slightly differently with 
Hawaii, though the similarity of "the federal government wishes there to be 
smaller, sub-county sized areas to delineate," asthe state of Hawaii does do 
this (see 
https://en.wikipedia.org/wiki/Honolulu_County%2C_Hawaii#County_districts to see 
a small map of Honolulu's nine "county districts," which I support being mapped 
in OSM as admin_level=7 boundaries).  Hawaiians on the ground, you included, 
very likely also identify many more place names, though none of these seems 
like it would be a boundary=admin_level, much better a node tagged place=*.  
I'd like to see the best data representation of those enter OSM.  The state of 
Hawaii absolutely, unequivocally delineates "what is and where the boundaries 
are" of the County of Oahu AND it absolutely, unequivocally delineates (and has 
since 1908) that Honolulu is a consolidated-city-county (CCC) with Oahu.  So 
OSM's (in the USA) convention of tagging both the admin_level=6 Oahu boundary 
(as we do, relation link included before) and a new coterminous boundary tagged 
both admin_level=8 and name=City of Honolulu is correct:  this is a CCC as we 
specify in our admin_level wiki.  (Honolulu IS an incorporated city — 
admin_level=8 — and OSM really should tag counties, cities and CCCs as what 
they are, especially as Honolulu's population reaches 1 million).

All that said, I support the addition of the coterminous (with Oahu) Honolulu 
city boundary, removal of the much smaller (and older and incorrect) 
admin_level=8 polygon mentioned before, PERHAPS addition of the "county 
districts" (though it would be good to discuss their admin_level=7 tag a bit 
more), MAYBE the CDP data (as boundary=census polygons without any admin_level 
tag) if there exist nothing better, and absolutely certainly say YES to adding 
more nodes tagged place=* with values of town, village, hamlet or 
isolated_dwelling in the County of Oahu (and anywhere the state of Hawaii, for 
that matter).  That's my best "resonance of OSM consensus of how to do this in 
the USA" and while Hawaii is certainly a UNIQUE part of the USA, it is, most 
agree, that (at least today, and that's how we map).

I invite further discussion, either on- or off-list.

Aloha, SteveA
California


_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Reply via email to