[Talk-us] place=neighborhood on subdivisions?

Wed Sep 23 17:51:00 UTC 2020

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 <steveaOSM at softworkers.com> wrote:

> Below, I answer Paul (first) and Joseph (second), both with substantial
> detail, so "lengthy post ahead."
>
> Paul Johnson <baloo at ursamundi.org> 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 <joseph.eisenberg at gmail.com> 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
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20200923/88bd50a1/attachment-0001.htm>