Admin_level for Michigan, Wisconsin, Minnesota, and North Dakota

Communities United States
1

I propose that we re-tag the town and township boundaries in four states (MI, WI, MN, and ND) from admin_level=7 to admin_level=8.

As far as I can tell, in these four states, towns, cities, and townships, all form a single space-filling layer that fit together like a jigsaw puzzle. Therefore they should occupy the same admin_level value:

image
image624×672 152 KB

This image is from Wisconsin; towns are in red and cities are in yellow.

We had a similar discussion in Maine, where we agreed to re-tag all of Maine’s town and township boundaries with the same admin_level=8:

This is substantively the same situation: a continuous, space-filling layer without boundary overlaps, where some boundaries are incorporated and some are unincorporated places.

Additionally, we can tell the two cases apart already with the border_type tag. For example, border_type=township, border_type=town, and border_type=city. Of note, not all townships are mapped in MN and ND. However, the ones mapped so far appear to be of the space-filling variety.

4 Likes
2

According to the Census Bureau, North Dakota and Wisconsin never allow townships and incorporated places to overlap, and Michigan and Minnesota equate townships to incorporated places, so there shouldn’t be any overlap there either. However, Minnesota and North Dakota don’t completely subdivide all their counties into townships, so the Census Bureau comes up with “unorganized territories” as placeholders.

1 Like
3

Thanks for clarifying! Still, since they are still non-overlapping, the townships and cities in those states should still be admin_level=8.

1 Like
4

The Census Bureau states that for South Dakota too, however with the way townships work here places in incorporated areas are still denoted as part of a township. It looks like North Dakota is similar: Map | Cass County, ND

For example, Barnes Township, Cass County is almost completely comprised of cities (Map) but it still technically exists over the whole original extent.

Essentially, I’m fine with WI/MN going from 7 to 8 but I think ND should be left at 7.

It looks like in Michigan villages are included within the township as well: List of municipalities in Michigan - Wikipedia

1 Like
5

I see what you mean. The BAS map for Barnes Township shows Fargo and West Fargo reducing the township to a tiny sliver, but that contradicts how locally produced maps depict the township. The Census Bureau sometimes overindexes on governmental authority, since demographic information is reported in service of governments. Maybe they’re only counting the unincorporated areas subject to the township’s zoning ordinance. For boundary mapping purposes, the nominal jurisdiction would matter more, so I agree that North Dakota’s townships should remain at level 7 (and similarly for South Dakota if the situation is similar).

Ah, you’re right, I misread the Census Bureau explanation. It’s just referring to charter townships, but there’s nothing stopping a charter township (which is like an incorporated place) from also containing a village (which is an incorporated place). Level 7 it is.

3 Likes
6

That isn’t how townships are currently mapped in ND:

image
image648×462 39 KB

So it sounds like maybe these need to be re-mapped if they’re supposed to be overlapping?

7

Yes, they need to have the city limits removed from the relations. Not too much of a pull.

2 Likes
8

Thanks for this discussion, since there doesn’t seem to be any disagreement on MI, WI, and MN, I’ve updated the United States Admin Level article on the wiki consistent with these changes.

9

I have updated MI on United States/Boundaries - OpenStreetMap Wiki as well, haven’t checked for other states. Doesn’t it make sense to have only one table in the wiki? I get the point, that they are slightly difference in the level of detail, though it’s kind of odd if we end up with different definitions.

10

This started out as a simple, digestible guide for mappers that didn’t go into edge cases like the main article and tried to stick to boundaries that are actually mapped in OSM, whereas the main article went into lots of interesting detail that wasn’t always relevant to OSM. But since then, both articles have converged so that the distinction isn’t so clear anymore. These days, I don’t feel comfortable pointing less experienced mappers to either article when they need a how-to guide. But they can still be useful as a source of truth about our tagging policy.

11

I have done my share to contribute to both wiki (US_Boundaries and US_admin_level), agreeing that Minh started Boundaries as “another tome in the library” (of OSM knowledge) and I have tweaked both it and US_admin_level — as have others — as “one tome in the library.” There has been (and even still is) a good amount of backchannel / private message and one-on-one discussion (like between people in a single state or states in a region, like New England, where admin_level distinctions have particular subtle aspects which it took some time and effort to discuss and hammer out). What we have is a long consensus (since 2010-12 or so in the USA, and ongoing since) though it is a solid consensus. Consensus can often be improved, especially if it is “only” a rough scaffolding or an early version.

As for “less experienced mappers” looking for a how-to guide: reading both tomes, while being knowledgeable about this history, can be both helpful, edifying and overwhelming as well as perhaps stupefying or at least confusing with plenty of errata and maybe even detritus. Both tomes (wiki) have a place in this complex space and “less experienced mappers” are welcome, though, I will say personally, a great deal of wide, sometimes highly esoteric knowledge (knowable, to be sure, but obscure, nonetheless) is either required or almost required. At least twice over the decade-plus as a contributor and “listener” in this realm, I’ve put out a serious call for an academic-level political scientist who is OSM-savvy, culturally American and maybe has passed a bar exam. What we do with admin_level in the USA isn’t easy, but we have drawn a “certain sized box” around things (for now).

It has been an exercise (a tiring and trying one, at times) to “complete” this. What we have are (at least!) a “couple good tomes in the library,” the open dialog (like here) among its contributors both ongoing and harmoniously and a solid scaffolding upon which a good future ahead hangs and can continue to be built.

Throwing one’s shoulder into it, picking up a hammer here and there: well, that’s always welcome. I like to see that when / as it happens. Keep up the great work, OSM.

12

I agree that laypeople can easily come away with this impression. I think this is because either article effectively covers three topics: one attempting to describe the real-world state of affairs, competing with Wikipedia; a second laying out general principles for when to use certain tags; and a third applying these principles. The two articles differ in the degree to which they seek to shape the database versus describing it, but regardless they cover a lot of ground that a mapper doesn’t necessarily need to know. Not every mapper needs an explanation grounded in political science in order to know how to translate an administrative area into tags.

In other words, I don’t know that this is true anymore:

There are numerous exceptions to the information below, some of them quite significant, but this article ignores them in order to focus on how to tag new features as they come up. For a more detailed explanation of governmental structures described in this article, see United States admin level and Wikipedia’s series on U.S. Political divisions.

13

Yes, I have found this an oddity since the article’s creation, as it almost makes a future of extending the article impossible or improbable. Are there contradictions it makes about itself? Perhaps. Perhaps, still.

While my goal is always to improve, sometimes I find I or we back myself or ourselves into a corner. This is uncomfortable and not always easy to exit. If there are improvements to be made to either article, or their scope or intentions, let’s please discuss and potentially improve them. Though, fair warning, sometimes effort expended exceeds value received. This may be such a case, though I don’t wish to be pessimistic.

The suggestion to see Wikipedia on U.S. Political divisions is good and can remain, as I see things. Beyond that, it gets somewhat exhausting for me…perhaps I have exhausted my usefulness in this realm and it has become time for me to hand the baton to the next runner.

14

The thinking at the time was: sometimes less is more. Eliding obscure details can help readers comprehend the bigger picture. I don’t think the article takes this approach anymore. Either it should go back to its roots, or the inaccurate language should be removed in favor of a third article that gives a more general overview.

2 Likes
15

By all means, feel free to remove any inaccurate language. A third article that fills a specific empty niche right now is as welcome as pretty spring flowers after rain.

16

My point at least was more about the duplicated table and not so much about the words around it.

1 Like
17

While we have broadened the scope of this topic from “admin_level for four Midwestern/Plains states” to a more purposeful future of how we endeavor to update our documentation, the latter does naturally follow from the former, especially as Henning updates / synchronizes the table(s).

The tables aren’t exactly “duplicated,” although they can be or seem redundant for certain purposes. The admin_level table does not explicitly specify border_type data (for 47 states where this is less critical compared to how OSM tags to be relevant), whereas the Boundaries table does do this more explicitly for states where these data are found and more relevant (especially Maine, New Hampshire and Vermont). Given the different font that these tags are expressed in at the top of the table, this (more precise syntax) is at least somewhat visually clear, though perhaps its intentions could be made more explicit in the text of the Boundaries wiki.

Moreover, Minh recalls here that his initial creation of Boundaries was as a more “simple, digestible guide” that avoids edge cases and “streamlines towards simplicity” (an admirable goal, to be sure). But as our knowledge of specificity in more and more states has deepened, and each table gets updated with this knowledge (thank you, Henning, for your updates / synchronizing of the Boundaries table!) Minh says that this complexity drifts away from simplicity (and it does, especially as the two tables converge towards staying roughly or exactly sync’d with each other, including the fact that the Boundaries table has additional border_type data).

Regarding a “how-to guide,” I’m not sure how best to proceed, and if our Boundaries wiki getting updated over the years has spoiled that somehow, I apologize for any part I might have played in that (unintentionally, as I only wished to update, not radically change the original intention) and listen as to how that may be remedied. Indeed, it may be a best approach is for a third wiki, as I’m not sure how Minh might intend for the Boundaries wiki to best “return to its roots.”

Wiki can and do straddle not-always-clear purposes of whether they “seek to shape the database” (prescriptive) versus “describing it” (descriptive), and we do characterize these two wiki as being skewed towards different ends of this spectrum (admin_level as more prescriptive, Boundaries as less prescriptive, more descriptive). If there are additional purposes for which wiki should be written (for example, as a how-to guide for less-experienced mappers), it does seem to me this should be a goal “started anew” and crafted specifically for that purpose.

1 Like