Below, I answer Paul (first) and Joseph (second), both with substantial detail,
so "lengthy post ahead."
Paul Johnson <ba...@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.eisenb...@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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
