Re: [Talk-us] An admin_level for CDPs?

2013-01-01 Thread Minh Nguyen
On 2013-01-01 4:29 PM, dies38...@mypacks.net 
wrote:

{{key|border_type}} is described as an alternative and sometimes complement to 
{{key|admin_level}} .  I have recently been drawing subdivision boundaries 
based on County GIS data and including {{tag|border_type|subdivision}} as part 
of a relation of type border; see for instance 
http://www.openstreetmap.org/browse/relation/2672911 . --ceyockey


I've also been using border_type as a way of distinguishing between 
cities and villages, which have the same admin_level in my state. 
However, I've been content with mapping suburban subdivisions as landuse 
areas rather than boundary relations. It's a lot easier for other 
mappers to work with.


The benefit of admin_level is that renderers know what to do with them 
right out of the box, whereas every country has different border_type 
values with different levels of significance.


--
Minh Nguyen 
Jabber: m...@1ec5.org; Blog: http://notes.1ec5.org/


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] An admin_level for CDPs?

2013-01-01 Thread Minh Nguyen

On 2013-01-01 2:18 PM, stevea 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).


Ah, my mistake. I'm not fundamentally opposed to putting in statistical 
areas; I just think it may be less confusing to use some other value of 
boundary=* (even with admin_level set), rather than overloading 
boundary=administrative for what evidently isn't a straightforward 
hierarchy of government entities. It's specialized information, less 
important than your typical city/county distinctions when completing the 
sentence "This business is located in..."



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.


I never really saw the need to tag state college campuses as 
boundary=administrative, just amenity=university, but some of the UCs do 
operate like cities unto themselves. The UC extension in Cincinnati ;-) 
has a neighborhood council that almost corresponds to the campus 
boundaries, so I mapped the neighborhood separately with admin_level=10.


However, I don't think it always makes sense to tag public property as 
boundary=administrative based solely on who owns the land.


In Ohio [1], a city can own property outside its limits: the City of 
Cincinnati recently sold a general aviation airport back to the suburb 
it's in, but it wouldn't've made sense to tag the airport as an exclave 
of Cincinnati. State law prohibits municipal exclaves, and it isn't as 
if any "Welcome to Cincinnati" signs were posted there. Also, a city or 
village can annex public property (such as a county park or public 
university) without the government agency's consent. [2] People describe 
public lands as being inside townships or municipalities, not as 
enclaves of them.



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.


I think you meant that national parks would get admin_level=4 and state 
parks admin_level=6. Otherwise, you'd make national parks into nations.


I've only mapped a couple of state parks, but here I'm also of the 
opinion that parks should get something other than 
boundary=administrative. Following examples in California, I've been 
overloading admin_level to indicate the admin_level of the operator (=2 
for national, =4 for state, =6 for county). But if you combine 
admin_level=4 with boundary=administrative for national parks and so on, 
then national parks would conceptually be peers with states and state 
parks peers with counties. They may be subordinate to the same 
authority, but they aren't peers.


So instead I've been misusing boundary=national_park, combining it with 
admin_level=4 for state parks. It stinks, but boundary=protected_area 
looks like a good way out of this mess. [3][4]



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 th

Re: [Talk-us] An admin_level for CDPs?

2013-01-01 Thread Paul Norman
> From: stevea [mailto:stevea...@softworkers.com]
> Sent: Monday, December 31, 2012 12:31 PM
> To: talk-us@openstreetmap.org
> Subject: [Talk-us] An admin_level for CDPs?
> 
> I have been pondering the use of the admin_level key in the USA, and
> have come to the realization that while  values 2, 4, 6 and 8 are
> correct for national, state, county and city boundaries (respectively),
> it is more complicated than that.

One minor point, although I realize your message doesn't actually raise this
issue directly.

People often assume that because admin_level=6 is used to tag counties in
most of the US an admin_level=6 area is the same as a county. Most of the
states have a very similar structure for administrative divisions so most
people don't encounter the other structures. In Alaska as well as other
parts of the world there are no counties. Other administrative divisions are
used, not because they're the equivalent of counties but because they're
what admin_level=6 means locally.

This is perhaps more relevant in the US to cities where there are more
definitions of what they are.


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] An admin_level for CDPs?

2013-01-01 Thread Richard Welty

On 1/1/13 6:52 PM, Jeff Meyer wrote:

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?

zip codes don't even properly belong in the discussion as there is no
such thing as an "official" zip code area. the post office sees them as
routes, not areas, and the Census zip code boundaries are a synthetic
approximation.

richard


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] An admin_level for CDPs?

2013-01-01 Thread Jeff Meyer
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  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 the

Re: [Talk-us] An admin_level for CDPs?

2013-01-01 Thread stevea

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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] An admin_level for CDPs?

2012-12-31 Thread Richard Welty

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.


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


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] An admin_level for CDPs?

2012-12-31 Thread Minh Nguyen

On 2012-12-31 12:30 PM, stevea wrote:

However, there are boundary polygons in OSM which are an odd duck in the
USA:  a notable one is Census Designated Places (CDPs), which came from
the TIGER import.  These are a bit like cities in that they are often a
similar size and population of a town or rather small city.  But they
are not strictly cities, in that they are derived from the federal
government (not "negotiated" with a state government like a city which
is or has incorporated) crafting them for statistical purposes.  CDPs
have no legal basis as incorporated cities do.  In fact, many of the
residents of these areas may not even be aware of the boundaries of
their own CDP.  However, CDPs are useful, as they often give name and
shape to a place or area which otherwise might not have one, and
frequently the CDP yields the only boundaries for doing so.

In other words, CDPs (and others, see below) really are administrative
divisions in the USA, we just don't often think of them that way, and so
we don't (often) classify them into a hierarchy.  I do believe it is
proper and useful to do so, but of course we should strive to get to as
correct as a consensus/result as we can.


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.


As you mentioned, CDPs' boundaries have no legal status. There is a 
reason most residents aren't aware of their CDPs' boundaries: the CDPs 
themselves are a statistical convenience rather than a fact on the 
ground. Yes, they were drawn up by an administrative agency, but nothing 
is administered differently inside them. Unless a data consumer cares 
about census delineations in particular, place=hamlet POIs are more 
appropriate for population centers without formal boundaries anyways.


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 edited
http://wiki.openstreetmap.org/wiki/United_States_admin_level to reflect
the reality of this more complicated picture in the USA, some states
which don't cleanly follow the 2/4/6/8 model, and at least some of these
"more federal" entities.  (There are also LAFCos in California, as well
as COGs in many states, which are state-defined, in addition to MPOs,
which straddle a local/federal level, and PSAs, CSAs, MSAs, and µSAs,
defined by the executive branch of the federal government).


PSA, CSA, MSA, and µSA boundaries have more bearing on reality than 
CDPs, but again they don't correspond to any government agencies, so 
boundary=census would still seem to fit these divisions better.


At any given place in the U.S., you're likely to be subject to a variety 
of government agencies with crisscrossing jurisdictions. Some of these 
boundaries matter more than others. For example, in Ohio, it makes a 
whole lot of sense to map townships, even if they sometimes cross city 
limits. But if I mapped every water board, school district, fire 
department, and sewer district in my area, the result would be an 
illegible map. If we considered congressional and state legislative 
districts to be "administrative" as well, it'd be even worse.


COGs and MPOs, on the other hand, often map very cleanly to county 
lines, as do state DOT districts, state patrol districts, and so on. 
Perhaps these boundaries matter a lot more in some states than others, 
but they still seem like highly specialized data that's more appropriate 
for a mashup than the OSM database.



As a starting point, we can keep this discussion simple and decide
whether a CDP might rightly be assigned an admin_level of 5, as it is
both a federal and quasi-local entity which correctly "lands in the
middle" (below state but above county), or whether it might actually be
lower than a city (but implying subordinate to? -- doesn't seem
correct...) with an admin_level of 9.


Just because they can cross county lines doesn't necessarily mean they 
should sit above counties. Some states allow cities and villages to 
cross county lines, but they're still admin_level=8.



SteveA
California


[1] http://wiki.openstreetmap.org/wiki/Ohio#CDPs
[2] http://taginfo.openstreetmap.org/tags/boundary=census

--
Minh Nguyen 
Jabber: m...@1ec5.org; Blog: http://notes.1ec5.org/


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-us] An admin_level for CDPs?

2012-12-31 Thread Richard Welty
funny you should bring this up, i've been pondering CDPs a bit lately 
and have come to very different conclusions from yours.


On 12/31/12 3:30 PM, stevea wrote:
I have been pondering the use of the admin_level key in the USA, and 
have come to the realization that while  values 2, 4, 6 and 8 are 
correct for national, state, county and city boundaries 
(respectively), it is more complicated than that. It is likely time to 
end the pretending this oversimplification is sufficient.  It is not.


A useful tool is http://www.itoworld.com/map/2#fullscreen which shows 
admin_level boundaries from 2 to 11 (11 for Germany and Netherlands 
only) in different colors.  Yes, it is true in the USA that for those 
boundaries which are tagged correctly (all 50 states, many or even 
most counties, some cities) we do see good boundaries and colors.


However, there are boundary polygons in OSM which are an odd duck in 
the USA:  a notable one is Census Designated Places (CDPs), which came 
from the TIGER import.  These are a bit like cities in that they are 
often a similar size and population of a town or rather small city.  
But they are not strictly cities, in that they are derived from the 
federal government (not "negotiated" with a state government like a 
city which is or has incorporated) crafting them for statistical 
purposes.  CDPs have no legal basis as incorporated cities do.  In 
fact, many of the residents of these areas may not even be aware of 
the boundaries of their own CDP.  However, CDPs are useful, as they 
often give name and shape to a place or area which otherwise might not 
have one, and frequently the CDP yields the only boundaries for doing so.


In other words, CDPs (and others, see below) really are administrative 
divisions in the USA, we just don't often think of them that way, and 
so we don't (often) classify them into a hierarchy.  I do believe it 
is proper and useful to do so, but of course we should strive to get 
to as correct as a consensus/result as we can.


the only "real" function of CDPs, so far as i know, is to provide a 
boundary to scope counting heads by the Census bureau. i'm hesitant to 
grant full
admin boundary status to them. in particular, they don't always nest 
well within the NYS Town boundaries, and in general the town containing
the CDP supplies the government for the CDP. CDPs are mostly around 
hamlets here.


the import of CDPs around here used level 8, so i've used level 7 for 
the NYS town boundaries i've brought in (manual import, one town 
boundary at a time.)


in the Capital District of NY, the


As a starting point, we can keep this discussion simple and decide 
whether a CDP might rightly be assigned an admin_level of 5, as it is 
both a federal and quasi-local entity which correctly "lands in the 
middle" (below state but above county), or whether it might actually 
be lower than a city (but implying subordinate to? -- doesn't seem 
correct...) with an admin_level of 9.
if they were to remain an admin_boundary (a case which i don't think 
you've adequately made) 5 is way, way too high given what the CDPs look 
like around here.


richard


___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us