<div dir="ltr"><div><div>I've been working on place=town, place=village, and place=hamlet classifications in Vermont and thinking about how CDPs may be helpful to this effort. The town of Milton has a <a href="https://www.openstreetmap.org/node/622776905">place node</a>, a <a href="https://www.openstreetmap.org/relation/199120">boundary=census</a> (CDP), and a <a href="https://www.openstreetmap.org/relation/8897021">boundary=administrative</a>. The administrative boundary represents the area that the Town of Milton government has authority over. The place node represents the built up area that is considered a town. Here I use "town" in the small t sense of a built up area rather than the large T sense of an official government. The CDP area represents the same thing as the place node, but as an area instead of a node. While I don't see a huge problem with mapping a place=town|village|hamlet as an area (likely based on a CDP area), I believe the standard layer won't display a label. Other than that, having both a node tagged place=town and an area tagged boundary=census seems like duplication to me. They even both link to the same wikidata item Q1789757. For a map renderer to effectively use the CDP area, they'd need to de-duplicate so they don't get two Milton labels. This could probably be done, but I'm not sure if any data consumers are prepared to actually do this.<br><br></div><div>Side note: does anyone know of an interactive map of 2020 census data that shows CDPs with their population? I've found a map that show population by census tracts and a map that shows CDPs, but not the populations of the CDPs.<br><a href="https://www.census.gov/programs-surveys/geography/data/interactive-maps.html">https://www.census.gov/programs-surveys/geography/data/interactive-maps.html</a></div><div><br></div><div>Zeke<br></div><div><br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 19, 2023 at 2:24 PM MoiraPrime via Talk-us <<a href="mailto:talk-us@openstreetmap.org">talk-us@openstreetmap.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Now that I think about it... if a census designated place... is <i>designated</i>
by the census, and the census is the one giving us the data, that
sounds like it's the most verifiable and accurate data you can
get. Am I wrong here? 🤔<br>
</p>
<div>On 1/19/2023 11:03 AM, Brian M.
Sperlongano wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I personally wish we would stop re-defining
perfectly working dictionary words. I understand that sometimes
the word used in a *tag* has to include a broader or narrower
concept to make mapping work. But a boundary that comes from an
authoritative data source is perfectly VERIFIABLE. It is not
OBSERVABLE on the ground, and let's not mix those things up. A
boundary is a boundary because some political authority or
authorities say it is.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 19, 2023 at 2:57
AM stevea <<a href="mailto:steveaOSM@softworkers.com" target="_blank">steveaOSM@softworkers.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nice,
Elliott. +1 to everything!<br>
<br>
Things in OSM get mapped because "they are real enough to
verify." NEARLY ALL of the time, that's because "well,
everybody can see them." (Including the mapper who did).
With boundaries, no, we must wave our hands in the air a bit
here. We must talk about these in terms of "already agreed
upon" so that we can "well state them, like on a map." Today,
we find that reality really very good, even excellent, but it
has its real-world "can't do that, border is in dispute" or
"despite our best efforts since 1905 (pick a date), the two
(maybe more) countries cannot seem to come to agreement about
exactly where a or the boundary line is."<br>
<br>
Census boundaries are not that, they are "wobbly,
numerically-defined things" that change, and rapidly. They
are essentially stale as quickly as they are published. They
exist for a reason, as they are a snapshot of a something.
Very much depending on local variability and reasoning (and
the reasons change everywhere we go) a census boundary might
or might not be "agreeable" to remain in OSM (sometimes for
reasons closer to OSM, sometimes for reasons closer to "the
people on the land who say so").<br>
<br>
This a social process, where sometimes "local rules dictate"
and sometimes "that's the method the rest of the world uses."
Where and how that unfolds seems to be a constant saga in
OSM. Certainly more often than not, a harmonious method is
found and applied.<br>
<br>
Realize: "deep rabbit holes exist" and "sometimes people
disagree" and "I stand corrected, I regret my error" and
"that's how that should be tagged around here" and "that's how
the rest of the world tags" and "well, that's true, but there
are exceptions..." are all true. At the same time. It's not
rancor or disharmony, it is discussion. More often than not,
it becomes harmonious. Really, we are harmonious. There are
skirmishes on edges, yes, and we grow.<br>
<br>
And a great many people say "that's a pretty good chunk of map
data we have here, OSM," nodding our heads.<br>
_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a><br>
</blockquote>
</div>
</blockquote>
</div>_______________________________________________<br>
Talk-us mailing list<br>
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a><br>
</blockquote></div>