[Talk-us] An admin_level for CDPs?

Jeff Meyer jeff at gwhat.org
Tue Jan 1 23:52:30 GMT 2013


Zip code areas and voting districts seem to me to be be functionally
equivalent to CPDs in that they are arbitrary geographic distinctions
determined by agencies outside of local governments or administrations. Are
they given a boundary=administrative?

For most administrative boundaries, one side of the boundary (the interior)
is actually "administrated." (Administered?) The other side (the exterior)
is not. That doesn't seem to be the case with CPDs, zips, or voting
districts.

That said, that rule doesn't really help with college campuses, school
districts, school attendance areas, transit authority zones, UASI areas,
fire districts, post office delivery areas, etc.

Does administrative really mean governmental? Unfortunately, it's not clear
that that helps, either, as school districts can be municipalities.

Is there a master list / Rosetta Stone somewhere of these various entities
& recommended tagging?



On Tue, Jan 1, 2013 at 2:18 PM, stevea <steveaOSM at softworkers.com> wrote:

> On 12/31/12 5:12 PM, Minh Nguyen wrote:
>>
>>> I'd argue that not all governmental boundaries need to be tagged as
>>> boundary=administrative. In Ohio, we've started to retag CDP boundaries
>>> with boundary=census and place=locality but without admin_level. [1][2]
>>> They still show up in Nominatim as localities.
>>>
>> this is approximately what i was thinking should be done with CDPs.
>>
>
> This sounds workable to me, as well.  It is agreeable that CDPs not have
> an assigned admin_level, I was opening this for discussion to see if there
> might be wider consensus.  CDPs *are* created by the Bureau of the Census,
> but the *SAs are not, they are created by the Office of Management and
> Budget (OMB).
>
> It *does* beg the question of what *should* be tagged as
> boundary=administrative *and* have an admin_level tag.  For example, my
> local University of California campus has a polygon tagged
> boundary=administrative, border_type=university (and amenity=university +
> name=*).  Might/should it also be tagged admin_level=4?  Even though it
> partially overlaps (and largely is in) City Limits, it *is* an
> administrative unit of state government (neither city/local nor county)
> with its own police, fire and health-care infrastructure, its own planning
> and development functions and a recent lawsuit (since dismissed) between it
> and its "host" city, proving it and the city are different entities.
>
> The same question (admin_level=4) might also be asked about California
> State Park boundaries...but they are *already* tagged with admin_level=4,
> so at least there is precedent (thanks, Apo42) for state-level "units" with
> specific administrative boundaries to be tagged with admin_level.  I'd like
> that to become widespread among all 50 states, which also implies national
> parks get tagged with admin_level=2.  State/national parks and state
> universities really do have their own administrations, and this implies an
> admin_level tag.
>
>
>  In states that give civil townships some authority, they are much more
>>> important to the identity of an unincorporated area than CDPs. The TIGER
>>> boundary import excluded Ohio townships, so Vid the Kid and I have been
>>> painstakinglly filling them in.
>>>
>>>  i have started filling in Towns in upstate NY as well. i don't mind
>> identifying the Hamlets in some manner, but all they consist of typically
>> is a boundary drawn by the Census, and some green-and-white signs posted by
>> the NYS DOT in traditional locations by the road side. there's no
>> government there, whereas the towns maintain roads, provide the framework
>> for the volunteer fire districts, have a zoning & master plan functions,
>> inspect buildings & construction, and so forth.
>>
>> richard
>>
>
> What I found useful to do around here (where there are CDP polygons
> entered from TIGER, but they have no admin_level tag) is to add a point
> tagged hamlet=* or village=* or town=* (but not necessarily suburb=* as
> that implies city subordination, nor city=* as that implies incorporation)
> to the "approximate center point" of the CDP polygon, along with a name=*
> tag that matches the name of the CDP. This point might logically be a
> mathematical centroid, but I have found it more useful to place this point
> at a more culturally significant point in the "human center" of the
> community designated by the CDP.  Usually this is at or near a significant
> crossroads, where there might be a market, a church, a school, a small
> commercial district, or the like.
>
> What I am hearing:  there are many polygons in OSM with the tag
> boundary=administrative, but it makes sense for only some of them to have
> an admin_level tag.  (This seems odd, but gets solved in the case of CDPs
> having their boundary=administrative tag changed to boundary=census).  We
> agree on nation, state, county and city (2, 4, 6, 8), but there really are
> other polygons upon which we might appropriately add an admin_level tag,
> state parks being one of them. CDPs, no, but changing their tag from
> boundary=administrative to boundary=census seems a good idea.  And for
> other *SAs designated by the OMB (not the Bureau of the Census)?  What
> about those?
>
> Finally, while there seems to be no argument that New York City is 5, and
> LAFCos in California are 7, what about MPOs?  These are a odd blend of
> where a locality's transportation planning agency wants to qualify for
> federal money, so they create an MPO per federal Code which qualifies them
> for it.  This MPO becomes a de facto and de jure administrative boundary,
> for both local and federal reasons, effectively bypassing state-level
> government.  Do we want to assign MPOs an admin_level tag in OSM?  (I'm
> guessing no, but I feel the need to offer due diligence that at least this
> question was asked).
>
> SteveA
> California
>
>
> ______________________________**_________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-us<http://lists.openstreetmap.org/listinfo/talk-us>
>



-- 
Jeff Meyer
Global World History Atlas
www.gwhat.org
jeff at gwhat.org
206-676-2347
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20130101/8b889e89/attachment-0001.html>


More information about the Talk-us mailing list