Aloha, Brian. As you say, Hawaii is curious among the 50 states in that it lacks municipal governments. See https://wiki.osm.org/wiki/United_States_admin_level, its table-row for Hawaii and corresponding footnote 42, which agree with that sentiment. This wiki mightily attempts to be correct and even somewhat comprehensive to both describe and prescribe admin_level tagging for all 50 states, should specificity be required for any particular state, and given the size and complexity of the table, much specificity IS required! After a great deal of discussion and consensus, it is believed to be largely correct. However, it may still have minor errors or benefit from additional detail or granularity of correction.
That said, and respecting that you are local, your initial statement of "start the process of adding missing city/town boundaries...to Oahu" surprised me: as I understand it, there are no city/town boundaries besides the consolidated city-county (CCC) of Honolulu as Oahu's only incorporated area. According to the wiki, CCCs are properly tagged with TWO coterminous (geographically identical) relations, one for the county (tagged admin_level=6) and one for the city (tagged admin_level=8). I do see that osm.org/relation/3861844 appears to be a correct example of the former, however, I see no corresponding / coterminous relation for the CITY of Honolulu (which would be correct as essentially a duplicate of relation/3861844 but with admin_level tag of value 8 rather than 6) and the name field(s) as "City of" rather than "County of." There is an existing "place=city" polygon for Honolulu (relation/119231) which appears to be a CDP boundary and has slightly incorrect tagging: there should not be a place=city tag (the boundary=census tag is correct), and because boundary=census is used, not boundary=admin_level, the admin_level=8 tag from this relation should be deleted. This makes Honolulu (a CCC) have a county boundary, a MISSING (coterminous) city boundary, AND a CDP boundary. That's "almost OK:" the missing admin_level=8 relation should be created to make it a "real, OSM-tagged, CCC-as-we-tag-them-in-the-USA" CCC. Yes, as you say, there are (30 or so) CDPs (these are not "town boundaries" they are CDPs, a different entity) in addition to the single CCC of Honolulu (or will be soon, and the CDP for Honolulu appears to exist as 119231, but it needs some minor tag cleanup). That is apparently why you say Honolulu has "a level 8 boundary in OSM even though there is no defined city limits:" the city limit is missing (that "half" of the CCC isn't entered), but what IS entered is a CDP, which isn't the same thing. However, please be aware that rather well-established consensus (partly reflected in the wiki noted) has emerged that CDP boundaries be tagged with boundary=census, not boundary=admin_level, as well as omitting an admin_level tag with any value whatsoever. I (and I believe the greater OSM community) welcome the addition of both the CITY of Honolulu relation (simply duplicate the admin_level=6 relation, change admin_level to 8 and change County to City in text strings of name tags) AND the additional CDP relations for what you call the "30 or so localities" as boundary=census-tagged (no admin_level tag) polygons or relations. Those would be great additions to OSM! If you wrap your head around all that, I believe you'll know how to tag whatever peculiar much-more-local "exceptions that need to get dealt with manually." I'm not sure what those are, so I don't know how to tag them, and you likely do, but if you don't, I invite you to ask the list once again for our collective wisdom, and we'll do our best to help you get the tagging as OSM-consensus as it can be. Aloha! (I love saying that), SteveA California (one author of the United_States_admin_level page, but I am no political scientist, preferring to largely LISTEN) On Wed, 4 Sep 2019 11:29:30 -1000, "Brian M. Sperlongano" <zelonew...@gmail.com> wrote: > I am looking to start the process of adding missing city/town boundaries to > the island of Oahu in the US state of Hawaii. Currently on Oahu, only the > city of Honolulu has an administrative boundary in OSM. I am the developer > of an application that consumes administrative boundary data and it would > be useful to me to have boundaries for the other towns on the island in > OSM. I have recently fixed a handful of boundary issues in JOSM such as > duplicated nodes, unclosed loops, and missing boundary roles so I'm > generally familiar with how boundary relations and ways are constructed. > > I have local knowledge of the island, hence why I am focusing on Oahu and > not the other islands. > > The state of Hawaii does not have political divisions below the county > level and so there are no municipal-level entities (e.g. the mayor of > Honolulu is actually the county mayor). However, the statewide GIS > publishes census-designated place (CDP) boundaries for 30 or so localities > on the island, and they are public domain. For the most part, CDP > names/boundaries match the local usage for town-level/postal place names > and are analagous to towns even though there are no town-level governments, > however, there are a number of exceptions that need to get dealt with > manually. Honolulu has a level 8 boundary in OSM even though there is no > defined city limits. > > Place names in Hawaii derive from ahupuaŹ»a (historic chiefdoms) and are > observable on the ground today by signs marking the historic boundaries > (normally aligned to geographic ridge lines). > > There are a number of TIGER imported census boundaries that often, but not > always, line up with the local usage of place names. > > I think it makese sense to sort through through the existing census > boundaries, GIS CDP boundaries, and place name markers, and create level 8 > administrative boundaries that reflect local postal and customary place > name usage, adding existing place= marker nodes to the relations. This > would be done one at a time rather than a bulk import. This is a somewhat > larger project than the usual streets and trails editing that I normally do > so I'd appreciate community feedback on whether this approach makes sense. _______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports
