A short question of a lengthy response: What is the history behind that definition of 'suburb'? Is it a result of the term being used that way in UK/Europe/elsewhere? Seems like an odd usage, since "suburbs" have had a very clear definition in the United States for decades now, and it has nothing to do with neighborhoods.
-- Brian On Wed, Sep 23, 2020 at 12:36 PM stevea <[email protected]> wrote: > Below, I answer Paul (first) and Joseph (second), both with substantial > detail, so "lengthy post ahead." > > Paul Johnson <[email protected]> wrote: > > In terms of Seattle, I don't think Ballard or Magnolia are a suburb. > They're more of a neighborhood, both subordinate to Seattle. Mercer Island > or Bellvue are more suburbs as they're their own cities but really wouldn't > matter or properly stand on their own without Seattle being in the > immediate vicinity. Note that place=city, place=neighborhood and > place=suburb are all extant tags in common use already. > > I make the point in my previous post(s) and this one as well: let's use > care with differences between "Neighborhood" and "Suburb" (local > vernacular, I've no problem with how people describe their local areas) vs. > place=neighbourhood and place=suburb (OSM tagging, contrasted with > vernacular). In terms of Seattle, sure, Paul: you, Clifford and I all > likely agree that Ballard and Magnolia are CALLED "neighborhoods" by > citizens. However, TAGGING them place=suburb is not only correct > (according to our wiki, especially given the relative size of Seattle as a > larger city), it is what OSM correctly does. I believe it would be > incorrect to tag these place=neighbourhood ("a smaller named, > geographically localised place within a suburb of a larger city") for one > simple reason: if Ballard and Magnolia are indeed place=neighbourhood in > OSM, what is their "larger" place=suburb? Bzzzt: that doesn't work. > Rather, place=suburb does work. Go ahead and "call" them "Neighborhoods," > but please TAG them place=suburb. Oh, OSM already does tag like that. > > Again, Bellevue is a de facto "suburb" of Seattle: part of the > conurbation of "Greater Seattle" one might say in local vernacular, > according to Census Bureau conventions or by demographers in general who > speak US English. However, in OSM (both the idealized sense of what we > should tag and actual tagging that is done), Bellevue is certainly both a > "city" and place=city, with its population of perhaps 150,000. That is > most certainly NOT a place=suburb in the sense OSM defines it. Oh, OSM > already does tag like that. > > Paul further wrote: > > Landuse-residential fits better for the lots within a place, not as a > substitute for it.. > > I don't wholly disagree. (Meaning I agree). Although I might say > "blocks" rather than "lots," as the latter is far too granularly small and > gets too close to cadastral-level data, which many agree don't belong in > OSM. Let's acknowledge that data entered into OSM might "start rough" and > be refined over two, three or more iterations before being well-accepted as > "good enough" to remain in OSM with no need for further refinement / > improvement. I mean, it does: this actually happens. > > For example, in Santa Cruz California, areas smaller than a square > kilometer were drawn as polygons and added inside the city limits as the > "neighborhoods" as they are both known to locals and defined by the city's > website (but with no administrative representation, more like "areas > convenient to delineate like this as neighborhoods"). These are tagged > landuse=residential and name=*, for example Lighthouse/West Cliff [1] or > The Circles [2]. One such "neighborhood," Prospect Heights [3], has had > ADDITIONAL, "smaller granularity" landuse=residential polygons [4], [5] > drawn upon it that I believe most OSM contributors would agree is a very > correct usage of that tag: more-or-less "block-level" residential polygons > that don't completely surround a larger area (as does [3], which also > messily encloses a church, school and park). This sort of "draw a large > landuse=residential polygon that is a bit too inclusive and therefore > slightly imprecise, but a good first draft," then later improves to the > level we see here, is typical of OSM: "good" at first (though not > technically perfect), then much "better" with time and refinement. OSM can > be strict in its admonishments of "prescriptive" tagging (how we SHOULD > tag), but we shouldn't to the detriment of falling into the trap of "the > perfect is the enemy of the good." > > Joseph Eisenberg <[email protected]> wrote: > > Settlements which are mapped with the place=* key are usually mapped as > a node, not as an area. > > For his evidence here, Joseph uses "descriptive" OSM data (how we DO > tag). However, our key:place wiki (via "Populated settlements, urban" > table, its Element column) says both nodes and ways are supported data > structures for this tag. Whether they are "usually" tagged this or that > has relatively minor relevance and is poor support for an argument to > choose one or the other, especially as both data structures are supported > by our wiki documentation. > > > There are many place=city areas in the USA, but that's because the tag > was incorrectly added to many municipal boundaries when they were first > imported, years ago. > > Wait, what? Why is tagging the municipal boundaries of a city with > place=city incorrect? Perhaps I misunderstand as you say "many" and "when > they were first imported, years ago." Have these been corrected? More > importantly, what was wrongly tagged about them in the first place? > Perhaps they technically are incorporated cities, but with small > populations, like <3000 inhabitants — there are such "cities" — where I > might agree that place=village might be a better tag in OSM, > notwithstanding the technical truth of "incorporated city." > > Here, Joseph implicitly admonishes us to tag "prescriptively," (how we > SHOULD tag, according to wiki). Which of descriptive or prescriptive > tagging do we use to guide us, Joseph? That's rhetorical, as clearly we > "should" tag as we "should." However, there IS tagging how we DO tag, > those data are not to be wholly ignored. As we (Minh) says in United > States/Boundaries, "use common sense" (discretion), understanding > differences between prescriptive and descriptive tagging, why each is > important in its own way and that moving towards tagging as prescribed by > wiki is a longer-term goal. > > > Some neighborhoods have well-defined boundaries, such as > boundary=administrative relations, and can be mapped as such. > > Yes, I don't wholly disagree (meaning I agree). But let's be clear that > boundary=administrative is a tag rightly applied only to truly > administrative areas. Tagging admin_level=10 (in the USA, often called a > "neighborhood" in vernacular) really only happens in larger cities (see > United States/Boundaries/Municipal subdivisions for some examples) where > there are "neighborhood councils" in addition to rather precise boundaries > of these WITHIN a city (and so, subordinate to it, reflected by values 10 > and 8). The tag boundary=administrative (meaning exactly that) isn't > correctly applied to "informal" boundaries of neighborhoods, where there is > no actual administration or body politic at the neighborhood level. (When > these DO exist, they are often administratively small-scale: e.g. parks > administration for only the three parks in that neighborhood). > > > But most neighborhoods, like towns and villages, do not have a clear > place where the named place ends. Even in big cities with well-known > neighborhoods you will hard-pressed to get two locals to agree about the > exact place where one named neighborhood ends and another starts, unless > this is legally defined by the municipality (and even then, real estate ads > and locals will often change things). > > > > So it's best to use place=neighbourhood, like place=town and > place=suburb, on a node at the center of the place. > > I don't know about "best," but I'll agree "better" when (as you describe) > there are no clear-cut "boundaries" of a neighborhood that is widely agreed > upon. When there ARE such boundaries, a node can act as a good placeholder > pending boundary data being added to OSM, but a (multi)polygon is ACTUALLY > best if such data exist. Actual administrated "neighborhoods" do exist in > the USA, but are relatively rare. Again, United States/Boundaries notes > this, using as examples Cincinnati (use boundaries, these are well-known) > and San Jose (use nodes, these are amorphous) with a caution to "use common > sense" (discretion) when such "municipal subdivision" differences arise. > > > > Please don't expand these as landuse, please expand them as > > > place=neighborhood instead. Landuse polygons should be congruent to > the > > > actual land use. > > While I agree with this, too, especially the last sentence, SOMETIMES > landuse polygons are ARE (descriptive of actual OSM use, not prescriptive > of how we should tag) and end up being NOT perfectly congruent with > precise, actual landuse. They are "more inclusive" (e.g. including a > church or school in a residential neighborhood, as does [3]) and this is > understood to be a "first draft" of a neighborhood or residential area, > especially when named and displays in renderings. We can admonish not to > tag like this, but people do so in their zeal to get "some" of these data > into OSM. Yes, these should be improved to polygons more like [4] and [5], > I agree. But let's be clear that "first drafts" happen, and it isn't the > end of OSM when they do. > > > That's a good point: the subdivisions often contain one or more landuse > > basins, clusters of trees, etc. I've been thinking of them as one big > > blob, but it seem correct on a more micromap level to mark them as > > place=, and identify the smaller landuse areas (which are sometimes all > > residential). > > Use place=* according to its wiki, and I have no problem. Please consider > how there are data in OSM which do not strictly adhere to wiki, they might > be considered "rough" or "technically inaccurate on a minor level" but they > should not be called "absolutely wrong" at an informal, novice-level-mapper > level. This really is how OSM gets built: at first, sometimes roughly > (slightly wrong, but not absolutely), then these data are refined into > adherence to specification. Sure, we'd love the high-granularity, > absolutely correct data to enter the map "first, always and we're done," > but that doesn't always happen. > > > Exactly. My rule of thumb is if you're thinking about putting a name on > it, and it's not a shopping center, apartment complex or similar large but > contiguous landuse, then landuse=* probably isn't what your polygon should > be. > > At least initially, it MIGHT be. Let's acknowledge that and while we can > absorb complaints about it, I won't redact such data, it being a first > draft at completion (similar to TIGER roads and rail). We'll take decades > to clean that up, as OSM is a long-term project. Let's acknowledge that, > too: "the map is never 'done.'" > > SteveA > > Notes/References: > [1] https://www.osm.org/relation/7071337 > [2] https://www.osm.org/way/219988725 > [3] https://www.osm.org/way/220344508 > [4] https://www.osm.org/way/446025524 > [5] https://www.osm.org/way/446025531 > _______________________________________________ > Talk-us mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-us >
_______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
