This is from a thread on [hidden email] 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.
One minor correction, one minor addition to my previous post on this topic.
Where I said "...none of these seems like it would be a boundary=admin_level..." this is more correctly stated
"none of these seems like they should be a boundary=administrative..."
Also, I have recently discovered (from the linked article on Honolulu County that it "is divided into 36 neighborhood boards," offices of which are "an advisory position for public policy and civil investment. Members are elected to two-year terms." If these have geographical data available to enter into OSM, I would support their entry into OSM tagged admin_level=9 or 10. While I am not local, these similar to "wards" (roughly, very local voting districts, but perhaps at, perhaps not quite at, the level of "neighborhood council," which in the USA we tag with admin_level=10. Yes, these are called "neighborhood boards" so perhaps 10 is correct, I can imagine either 10 or 9 being correct. More discussion among OSM Honolulu locals could achieve consensus.
This makes (say), ʻEwa Beach be in admin_level=2 for USA, admin_level=4 for Hawaii, admin_level=6 for Oahu, admin_level=7 for District 1, admin_level=8 for Honolulu, admin_level=10 (or 9) for 'Ewa Beach.
ZIP Codes (US Postal Service codes) are not administrative boundaries.
They are widely used for addressing, for routing and for deliveries by
private companies in addition to the USPS, but they are not used for
any official administrative purposes, at least not in the States where
I have lived.
> 6 Sep 2019, 22:10 by [hidden email]:
>> 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.
> Note that I was asking whatever it is
> actually administrative boundary
> (Postal codes are not forming
> administrative boundaries in Poland,
> not sure is it different in USA)
I agree; this sounds correct. I've lived in the USA for several decades (my entire life), though I do travel.
Country, state, county, city (in the USA) rather neatly map onto admin_level= 2, 4, 6 and 8 (respectively). There are wider-area exceptions (like township=7) and in some places things like villages, wards or neighborhoods with real elected councils (sometimes 7, sometimes 8, sometimes 9 and/or 10) and various other "we do things like THIS" in particular states, but ZIP codes, as described are for routing mail (and by some companies, other deliveries), not for political administration (admin_level).
> On Sep 6, 2019, at 11:59 PM, Joseph Eisenberg <[hidden email]> wrote:
> ZIP Codes (US Postal Service codes) are not administrative boundaries.
> They are widely used for addressing, for routing and for deliveries by
> private companies in addition to the USPS, but they are not used for
> any official administrative purposes, at least not in the States where
> I have lived.
> On 9/7/19, Mateusz Konieczny <[hidden email]> wrote:
>> 6 Sep 2019, 22:10 by [hidden email]:
>>> 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.
>> Note that I was asking whatever it is
>> actually administrative boundary
>> (Postal codes are not forming
>> administrative boundaries in Poland,
>> not sure is it different in USA)