Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

[stevea]

Thanks, Richard.  That's valuable input and I've updated the USBRS wiki, which 
effectively puts the (informal) proposal for 
proposed:route=bicycle into a sort of stalemate.

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Large fire perimeter tagging?

[stevea]

Clifford Snow  wrote:
> Just a reminder, landuse is to tag what the land is used for. landuse=forest 
> is for areas that have harvestable wood products, ie trees. Just because 
> there was a fire doesn't mean the landuse changes. Landcover is a better tag 
> for burnt areas as well as areas just clearcut.

This thread likely shouldn't have been cross-posted by me to talk-us and is now 
(substantially) continued at the tagging list.
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Large fire perimeter tagging?

[Clifford Snow]

Steve,
Just a reminder, landuse is to tag what the land is used for.
landuse=forest is for areas that have harvestable wood products, ie trees.
Just because there was a fire doesn't mean the landuse changes. Landcover
is a better tag for burnt areas as well as areas just clearcut.



On Thu, Sep 24, 2020 at 2:31 PM stevea  wrote:

> I didn't get a single reply on this (see below), which I find surprising,
> especially as there are currently even larger fires that are more
> widespread all across the Western United States.
>
> I now ask if there are additional, appropriate polygons with tags I'm not
> familiar with regarding landcover that might be added to the map (as
> "landuse=forest" might be strictly true now only in a 'zoning' sense, as
> many of the actual trees that MAKE these forests have sadly burned down, or
> substantially so).
>
> Considering that there are literally millions and millions of acres of
> (newly) burned areas (forest, scrub, grassland, residential, commercial,
> industrial, public, private...), I'm surprised that OSM doesn't have some
> well-pondered and actual tags that reflect this situation.  My initial
> tagging of this (simply tagged, but enormous) polygon as "fire=perimeter"
> was coined on my part, but as I search wiki, taginfo and Overpass Turbo
> queries for similar data in the map, I come up empty.
>
> First, do others think it is important that we map these?  I say yes, as
> this fire has absolutely enormous impact to what we do and might map here,
> both present and future.  The aftermath of this fire (>85,000 acres this
> fire alone) will last for decades, and for OSM to not reflect this in the
> map (somehow, better bolstered than a simple, though huge, polygon tagged
> with fire=perimeter, start_date and end_date) seems OSM "cartographically
> misses something."  I know that HOT mappers map the "present- and
> aftermath-" of humanitarian disasters, I've HOT-participated myself.  So,
> considering the thousands of structures that burned (most of them homes),
> tens of thousands of acres which are burn-scarred and distinctly different
> than their landcover, millions of trees (yes, really) and even landuse is
> now currently tagged, I look for guidance — beyond the simple tag of
> fire=perimeter on a large polygon.
>
> Second, if we do choose to "better" map these incidents and results (they
> are life- and planet-altering on a grand scale) how might we choose to do
> that?  Do we have landcover tags which could replace landuse=forest or
> natural=wood with something like natural=fire_scarred?  (I'm making that
> up, but it or something like it could work).  How and when might we replace
> these with something less severe?  On the other hand, if it isn't
> appropriate that we map any of this, please say so.
>
> Thank you, especially any guidance offered from HOT contributors who have
> worked on post-fire humanitarian disasters,
>
> SteveA
> California (who has returned home after evacuation, relatively safe now
> that this fire is 100% contained)
>
>
> On Aug 29, 2020, at 7:20 PM, stevea  wrote:
> > Not sure if crossposting to talk-us is correct, but it is a "home list"
> for me.
> >
> > I've created a large fire perimeter in OSM from public sources,
> http://www.osm.org/way/842280873 .  This is a huge fire (sadly, there are
> larger ones right now, too), over 130 square miles, and caused the
> evacuation of every third person in my county (yes).  There are hundreds,
> perhaps thousands of structures, mostly residential homes, which have
> burned down and the event has "completely changed" giant redwoods in and
> the character of California's oldest state park (Big Basin).
> >
> > This perimeter significantly affects landuse, landcover and human
> patterns of movement and activity in this part of the world for a
> significant time to come.  It is a "major disaster."  I'm curious how HOT
> teams might delineate such a thing (and I've participated in a HOT fire
> team, mapping barns, water sources for helicopter dips and other human
> structures during a large fire near me), I've simply made a polygon tagged
> fire=perimeter, a name=* tag and a start_date.  I don't expect rendering,
> it's meant to be an "up to right about here" (inside the polygon is/was a
> burning fire, outside was no fire).  I wouldn't say it is more accurate
> than 20 to 50 meters on any edge, an "across a wide street" distance to be
> "off" is OK with me, considering this fire's size, but if a slight skew
> jiggles the whole thing into place better, feel free to nudge.  It's the
> tagging I'm interested in getting right, and perhaps wondering if or even
> that people enter gigantic fires that will significantly change landscape
> for some time into OSM, as I have done.  This will affect my local mapping,
> as a great much has burned.  Even after starting almost two weeks ago, as
> of 20 minutes ago this fire is 33% contained, with good, steady progress.
> These men and women are heroes.
> >
> > 

Re: [Talk-us] Large fire perimeter tagging?

[stevea]

I didn't get a single reply on this (see below), which I find surprising, 
especially as there are currently even larger fires that are more widespread 
all across the Western United States.

I now ask if there are additional, appropriate polygons with tags I'm not 
familiar with regarding landcover that might be added to the map (as 
"landuse=forest" might be strictly true now only in a 'zoning' sense, as many 
of the actual trees that MAKE these forests have sadly burned down, or 
substantially so).

Considering that there are literally millions and millions of acres of (newly) 
burned areas (forest, scrub, grassland, residential, commercial, industrial, 
public, private...), I'm surprised that OSM doesn't have some well-pondered and 
actual tags that reflect this situation.  My initial tagging of this (simply 
tagged, but enormous) polygon as "fire=perimeter" was coined on my part, but as 
I search wiki, taginfo and Overpass Turbo queries for similar data in the map, 
I come up empty.

First, do others think it is important that we map these?  I say yes, as this 
fire has absolutely enormous impact to what we do and might map here, both 
present and future.  The aftermath of this fire (>85,000 acres this fire alone) 
will last for decades, and for OSM to not reflect this in the map (somehow, 
better bolstered than a simple, though huge, polygon tagged with 
fire=perimeter, start_date and end_date) seems OSM "cartographically misses 
something."  I know that HOT mappers map the "present- and aftermath-" of 
humanitarian disasters, I've HOT-participated myself.  So, considering the 
thousands of structures that burned (most of them homes), tens of thousands of 
acres which are burn-scarred and distinctly different than their landcover, 
millions of trees (yes, really) and even landuse is now currently tagged, I 
look for guidance — beyond the simple tag of fire=perimeter on a large polygon.

Second, if we do choose to "better" map these incidents and results (they are 
life- and planet-altering on a grand scale) how might we choose to do that?  Do 
we have landcover tags which could replace landuse=forest or natural=wood with 
something like natural=fire_scarred?  (I'm making that up, but it or something 
like it could work).  How and when might we replace these with something less 
severe?  On the other hand, if it isn't appropriate that we map any of this, 
please say so.

Thank you, especially any guidance offered from HOT contributors who have 
worked on post-fire humanitarian disasters,

SteveA
California (who has returned home after evacuation, relatively safe now that 
this fire is 100% contained)


On Aug 29, 2020, at 7:20 PM, stevea  wrote:
> Not sure if crossposting to talk-us is correct, but it is a "home list" for 
> me.
> 
> I've created a large fire perimeter in OSM from public sources, 
> http://www.osm.org/way/842280873 .  This is a huge fire (sadly, there are 
> larger ones right now, too), over 130 square miles, and caused the evacuation 
> of every third person in my county (yes).  There are hundreds, perhaps 
> thousands of structures, mostly residential homes, which have burned down and 
> the event has "completely changed" giant redwoods in and the character of 
> California's oldest state park (Big Basin).
> 
> This perimeter significantly affects landuse, landcover and human patterns of 
> movement and activity in this part of the world for a significant time to 
> come.  It is a "major disaster."  I'm curious how HOT teams might delineate 
> such a thing (and I've participated in a HOT fire team, mapping barns, water 
> sources for helicopter dips and other human structures during a large fire 
> near me), I've simply made a polygon tagged fire=perimeter, a name=* tag and 
> a start_date.  I don't expect rendering, it's meant to be an "up to right 
> about here" (inside the polygon is/was a burning fire, outside was no fire).  
> I wouldn't say it is more accurate than 20 to 50 meters on any edge, an 
> "across a wide street" distance to be "off" is OK with me, considering this 
> fire's size, but if a slight skew jiggles the whole thing into place better, 
> feel free to nudge.  It's the tagging I'm interested in getting right, and 
> perhaps wondering if or even that people enter gigantic fires that will 
> significantly change landscape for some time into OSM, as I have done.  This 
> will affect my local mapping, as a great much has burned.  Even after 
> starting almost two weeks ago, as of 20 minutes ago this fire is 33% 
> contained, with good, steady progress.  These men and women are heroes.
> 
> To me, this is a significant polygon in my local mapping:  it is a "huge 
> thing" that is a major feature on a map, especially right now.  I firmly 
> believe it belongs in OSM for many reasons and want it tagged "correctly."  
> Yes, there are other maps that show this, I believe OSM should have these 
> data, too, as this perimeter will affect much (in the real world) and 

Re: [Talk-us] place=neighborhood on subdivisions?

[Mark Wagner]

The problem with "suburb" is like the problem with "football": there
are two meanings, and a very large population that doesn't know about
the other meaning.  That guarantees widespread misuse.

-- 
Mark

On Thu, 24 Sep 2020 11:55:55 -0400
Brian Stromberg  wrote:

> If suburb is a commonly understood and useful concept in other
> countries then it seems good to keep it around. I don't really know
> what the implications are of retirement or what the process would be.
> I would instead advocate for country-specific guidance on its usage.
> 
> --
> Brian
> 
> 
> On Thu, Sep 24, 2020 at 11:38 AM Paul Johnson 
> wrote:
> 
> > On Thu, Sep 24, 2020 at 8:32 AM Brian Stromberg
> >  wrote:
> >  
> >> This contradicts the OSM wiki but seems like the only way to avoid
> >> confusion.
> >>  
> >
> > Much like sport=american_football vs sport=soccer, this makes sense.
> > Maybe it's time to retire place=suburb as a tag due to its
> > ambiguity?
> >
> >  
> >> The only reason I can think of to use 'suburb' as a tag in the
> >> context of the United States would be if a tag indicating 'central
> >> city' or something similar was introduced.
> >>  
> >
> > Ostensibly, that's what place=city was supposed to be, but not
> > helping OSM would be that some places have cities and towns of
> > different legal importance (Oklahoma), or "it's a city or it's not
> > a city" with no room for nuance (Oregon).  Not making things any
> > easier is how lopsided populations are in the US, a midsize
> > municipality is about 5500 people.  Once you get to about 90,000,
> > you're in the top 2% largest anything in the US.
> > ___ Talk-us mailing list
> > Talk-us@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-us
> >  


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[stevea]

I'd like to clarify my take-aways from this discussion, hopefully yours, too.  
Thank you for reading and your patience.

Brian says that a common (THE common) definition of "suburb" in the US is 
(roughly) "a smaller city next to or near a much larger one as part of a 
conurbation."  I agree that is a very frequent understanding of how the word 
"suburb" is both used and understood in the USA, even most or almost all of the 
time.

I also assert that there is a (much less-common, agreed) usage for "suburb" in 
the US that is more in line with how OSM tags with place=suburb, as a kind of 
"district of a larger city."  Magnolia (in Seattle) is tagged place=suburb, 
believed correctly as to how that tag should be used, even though Magnolia is 
CALLED a "neighborhood" in local vernacular.  It seems these two usages of 
"suburb" can co-exist simultaneously (OSM tagging and local vernacular) while 
disagreeing slightly, though with some confusion unless and until this 
clarification is understood.  OK, we've discussed it, I hope it is less 
confusing.

(In the USA, we tend to CALL someplace like Bellevue a "suburb," though we 
correctly TAG it a place=city in OSM.  Such differences between "call" and 
"tag" are the source of much of the confusion about "suburb" and "neighborhood" 
or place=neighbourhood).

I fully support the use of place=neighbourhood tagging on nodes or polygons in 
the USA where it makes sense to do so.  In a previous post, I said the logic of 
using place=neighbourhood in Seattle makes less sense, as there is a hierarchy 
with using place=* (city, suburb, neighbourhood, among other values if greater 
granularity exists).  So, with what are CALLED neighborhoods being actually 
TAGGED place=suburb, there is "excess room" in that hierarchy:  with Seattle 
tagged "city" and Magnolia (and other so-called neighborhoods) tagged "suburb," 
tagging Magnolia (and others) with place=neighbourhood (because it is "called" 
that) would leave a gap between neighbourhood and city:  what suburb would 
Magnolia be a part of?  Yes, as it was said somewhere that Seattle's 
"neighborhoods" have specific boundaries, it could be a small OSM project to 
restructure Seattle from nodes-tagged-suburb to polygons-tagged-neighbourhood.  
That could happen, though I still ask what place=suburb tag, if any, would be 
appropriate to bridge the gap between neighbourhood and city.  Perhaps none, 
and that is OK, I'm not sure if this is "allowed" with place=* tagging, maybe 
it is.

In the example I gave in the city of Santa Cruz (Prospect Heights 
"neighborhood," now tagged with a relatively large landuse=residential PLUS 
smaller more-correct, "block-level" landuse=residential polygons), our county 
wiki outlines a strategy for the already-existing large landuse=residential 
polygons (older, less correct, "first draft") and the smaller 
landuse=residential polygons (newer, more correct, "corrections to first draft 
underway"):  when all the smaller, more correct polygons are completed, the 
landuse=residential tag on the larger, less correct is changed to 
place=neighbourhood!  Santa Cruz, a city of about 65,000, already has five 
nodes tagged place=suburb, (13,000 in a suburb seems about right, these suburb 
names are widely used), as well as five or so "smaller" (in identity) scattered 
place=locality nodes (slightly different than the suburb or neighborhood names).

This all works both in how the real world names things and in OSM:  the City 
(multipolygon) is tagged place=city, its five suburbs (in the less common 
sense) are nodes tagged place=suburb, the "residential neighborhoods" are NOW 
tagged landuse=residential, yet OSM is on track (and documents how) we're 
converting these to better-granularity "block-level" landuse=residential 
polygons inside of larger polygons, and these larger polygons will be changed 
from landuse=residential to place=neighbourhood when full "inner 
high-granularity" polygons are completed inside of the to-be-designated 
place=neighbourhood larger enclosing polygons.  (Additionally, there are some 
scattered nodes tagged place=locality, what might be considered "the bottom of 
the hierarchy," which have accrued and stabilized according to local 
convention).  Clear!

May this clarify similar strategies for better place=* tagging in the USA.  It 
is complicated when US English diverges from the more British (or Australian) 
English that strongly influences wiki definitions of tags, but with some 
discussion, we can both better understand these potentially confusing (but 
ultimately understandable) differences, and tag well, even in the USA.

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Kevin Kenny]

Another vote for Evin and Minh's interpretation.

I've been tagging named, signed, suburban (in the US sense)
subdivisions with landuse=residential and name=*.

I make no distinction among the subdivisions that consist of
apartments, terraces, or detached houses (except when mapping the
buildings themselves): thus, I've mapped 'Hillcrest Villaage' and 'Van
Antwerp Village' (apartment complexes), 'Village Meadow' and 'Country
Gardens' (condos), 'Orchard Park' (mixed condos and detached houses)
and 'Hawthorne Hill' (detached houses) all as landuse=residential
name=*.

I overlap natural=wood where appropriate, since the overlap of landuse
and landcover causes no conflict. I work similarly with
amenity=parking when the parking lot is part of the community. If
there's landuse=basin, landuse=religious, or something similar inside
the area, I make a cutout, since those are conflicting land uses, even
if the drainage basin or church is part of the planned community.

I've contemplated using place=neighbourhood (on either node or way)
with them, but eventually concluded that it was too subjective a
decision for whether residents would self-identify their neighbourhood
as being the same as their subdivision.  To someone from Niskayuna,
New York, I might say that I live in Orchard Park, or that Andrea
lives in Windsor Estates - the locals know most of the subdivision
names, and many of them have the names of the main entrance roads
match the name of the subdivision (Orchard Park Road, Windsor Drive).
To someone who isn't local, I'd more likely reference cross streets or
landmarks: "the subdivision on the north side of the high school". I
have no problem, though, with putting the name of the subdivision on
the landuse=residential polygon: the names are signed and
field-verifiable.

When I'm micromapping a neighbourhood, I do map private swimming pools
because the fire department appreciates it.

I try to respect privacy, and map landuse=residential on individual
lots only when the lot is completely surrounded by other land uses.
That case is hard to reconcile with privacy: if someone owns a parcel
that has park land (in the US sense) on two sides, a wastewater plant
on a third, and a river on the fourth, the parcel is going to be
visible in any case as the hole among the other land uses.  To have it
not be deducible, I'd have to refrain from mapping one or another of
the adjoining facilities, and I think we all agree that parks,
wastewater plants and rivers are objects that ought to be mapped.



On Thu, Sep 24, 2020 at 11:48 AM Evin Fairchild  wrote:
>
> I totally agree with Minh here. I always thought that it was standard 
> parctice in OSM to add the name tag to a landuse=residential way that 
> encompasses the subdivision. Subdivision names aren't always used in common 
> parlance (especially if it's a smaller subdivision) so most people wouldn't 
> necessarily consider the subdivision name to be the name of the neighborhood 
> that they live in.
>
> On Thu, Sep 24, 2020, 12:44 AM Minh Nguyen  
> wrote:
>>
>> Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:
>> >
>> >
>> > On Tue, Sep 22, 2020 at 8:36 PM Mike N
>> > > > > wrote:
>> >
>> > On 9/22/2020 9:26 PM, Paul Johnson wrote:
>> >  > The extra hamlet nodes are import remainders that haven't
>> > yet been
>> >  > converted to landuse areas.   The general landuse zones for
>> > that area
>> >  > have been identified, but do not exactly correspond to the named
>> >  > subdivisions.   As I get a chance to survey, I divide the
>> > landuse into
>> >  > subdivisions and convert the node to a named area for the
>> > subdivision.
>> >  >
>> >  >
>> >  > Please don't expand these as landuse, please expand them as
>> >  > place=neighborhood instead.  Landuse polygons should be congruent
>> > to the
>> >  > actual land use.
>> >
>> > 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).
>> >
>> >
>> > 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.
>>
>> It's common, intuitive, and IMO beneficial to map a planned,
>> suburban-style residential development as a single named
>> landuse=residential area. These developments have well-defined
>> boundaries and are primarily residential in character. If there are some
>> wooded lots in the subdivision, it's perfectly fine to map a
>> natural=wood area inside of or partially overlapping the
>> landuse=residential area, ideally without being connected 

Re: [Talk-us] place=neighborhood on subdivisions?

[Brian Stromberg]

If suburb is a commonly understood and useful concept in other countries
then it seems good to keep it around. I don't really know what the
implications are of retirement or what the process would be. I would
instead advocate for country-specific guidance on its usage.

--
Brian


On Thu, Sep 24, 2020 at 11:38 AM Paul Johnson  wrote:

> On Thu, Sep 24, 2020 at 8:32 AM Brian Stromberg 
> wrote:
>
>> This contradicts the OSM wiki but seems like the only way to avoid
>> confusion.
>>
>
> Much like sport=american_football vs sport=soccer, this makes sense.
> Maybe it's time to retire place=suburb as a tag due to its ambiguity?
>
>
>> The only reason I can think of to use 'suburb' as a tag in the context of
>> the United States would be if a tag indicating 'central city' or something
>> similar was introduced.
>>
>
> Ostensibly, that's what place=city was supposed to be, but not helping OSM
> would be that some places have cities and towns of different legal
> importance (Oklahoma), or "it's a city or it's not a city" with no room for
> nuance (Oregon).  Not making things any easier is how lopsided populations
> are in the US, a midsize municipality is about 5500 people.  Once you get
> to about 90,000, you're in the top 2% largest anything in the US.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Evin Fairchild]

I totally agree with Minh here. I always thought that it was standard
parctice in OSM to add the name tag to a landuse=residential way that
encompasses the subdivision. Subdivision names aren't always used in common
parlance (especially if it's a smaller subdivision) so most people wouldn't
necessarily consider the subdivision name to be the name of the
neighborhood that they live in.

On Thu, Sep 24, 2020, 12:44 AM Minh Nguyen 
wrote:

> Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:
> >
> >
> > On Tue, Sep 22, 2020 at 8:36 PM Mike N
> >  > > wrote:
> >
> > On 9/22/2020 9:26 PM, Paul Johnson wrote:
> >  > The extra hamlet nodes are import remainders that haven't
> > yet been
> >  > converted to landuse areas.   The general landuse zones for
> > that area
> >  > have been identified, but do not exactly correspond to the
> named
> >  > subdivisions.   As I get a chance to survey, I divide the
> > landuse into
> >  > subdivisions and convert the node to a named area for the
> > subdivision.
> >  >
> >  >
> >  > Please don't expand these as landuse, please expand them as
> >  > place=neighborhood instead.  Landuse polygons should be congruent
> > to the
> >  > actual land use.
> >
> > 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).
> >
> >
> > 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.
>
> It's common, intuitive, and IMO beneficial to map a planned,
> suburban-style residential development as a single named
> landuse=residential area. These developments have well-defined
> boundaries and are primarily residential in character. If there are some
> wooded lots in the subdivision, it's perfectly fine to map a
> natural=wood area inside of or partially overlapping the
> landuse=residential area, ideally without being connected to it. This
> approach is supported by longstanding documentation [1], old threads
> [2], and good support in both renderers [3] and search engines.
>
> There have also been old discussions where folks have conflated the
> concept of landcover with landuse. [4] But I find this approach overly
> academic. Taking it to the logical extreme, landuse=residential would
> only be coincident to each house in a subdivision, given that the yards
> are non-dwellings.
>
> I don't see the need for a fundamental distinction between planned
> residential developments consisting of multi-family apartments and those
> consisting of single-family houses, such that the former would be mapped
> as a coherent landuse area but the latter would be a shapeless place
> point. Where there's no such distinction, the landuse areas lend
> themselves to ab intuitive rendering that's good for navigating suburban
> sprawl. [5]
>
> If a planned development truly is actually mixed-use, and not only in a
> garden-level micromapping sense, then something other than landuse=*
> would be reasonable, since a particular landuse doesn't characterize
> that development anyways. Named landuse=residential areas also don't
> tend to make as much sense in urban areas, older inner suburbs, and
> rural areas. But the areas in changeset 91255294 aren't mixed-use
> developments; they're residential areas in a suburban setting.
>
> [1] https://wiki.openstreetmap.org/wiki/Special:Diff/1087300
> [2] I previously wrote on this topic in
> 
> and
> it seemed like other respondents were taking the same approach.
> [3] https://github.com/gravitystorm/openstreetmap-carto/issues/351
> [4]
> https://lists.openstreetmap.org/pipermail/talk-gb/2017-January/019811.html
> [5] https://osm.org/go/ZTVSa4OB
>
> --
> m...@nguyen.cincinnati.oh.us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Paul Johnson]

On Thu, Sep 24, 2020 at 8:32 AM Brian Stromberg 
wrote:

> This contradicts the OSM wiki but seems like the only way to avoid
> confusion.
>

Much like sport=american_football vs sport=soccer, this makes sense.  Maybe
it's time to retire place=suburb as a tag due to its ambiguity?


> The only reason I can think of to use 'suburb' as a tag in the context of
> the United States would be if a tag indicating 'central city' or something
> similar was introduced.
>

Ostensibly, that's what place=city was supposed to be, but not helping OSM
would be that some places have cities and towns of different legal
importance (Oklahoma), or "it's a city or it's not a city" with no room for
nuance (Oregon).  Not making things any easier is how lopsided populations
are in the US, a midsize municipality is about 5500 people.  Once you get
to about 90,000, you're in the top 2% largest anything in the US.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Paul Johnson]

On Thu, Sep 24, 2020 at 3:55 AM Minh Nguyen 
wrote:

> Vào lúc 10:45 2020-09-23, Paul Johnson đã viết:
> > Can we finally fix two other longstanding problems, then?
> >
> > 1. The wiki being incorrect about not counting bicycle lanes.  That's
> > not reflective of how validators deal with lanes, how data consumers
> > like Osmand or Magic Earth deal with lanes, or how ground truth works.
> > The whole "but you can't fit a motor vehicle down it" argument is
> > facile, that's what access:lanes=* and width:lanes=* is for.
>
> I agree that width is a poor argument for the status quo, especially
> given the common practice (in California, anyways) of bike lanes that
> double as right turn lanes for cars.
>
> For what it's worth, the lanes=* documentation has long included a
> passage recommending that data consumers treat lanes=* as a minimum
> value rather than a reliable exact lane count. Apparently some mappers
> only count through lanes but exclude turn lanes.
>

Fortunately, editors will automatically fix this and make lanes=* be the
total of lanes:forward=*, lanes:backward=* and lanes:both_ways=*, so this
is something that isn't hard to solve long term.  Hopefully when id gets
lane tools, it does the same thing JOSM does in this regard.


> I'm pretty sure existing routers would have no problem with including
> bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=*
> are both present. So I think a reasonable migration path would be to use
> the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the
> non-auto-centric approach you're advocating.
>

There's no need.  We already have access:lanes=* for this.  Lanes are
lanes, regardless of access, and it takes a very narrowly motorist-centric
view in order to break this already fairly universally implemented
assumption.


> > 2. Tagging route information on ways.  It's about a decade too long at
> > this point for ref=* on a way to be completely disconnected from the
> > entity the tag applies to:  That's why route relations exist.  Biggest
> > problem child on this at the moment:  OSM's own tilesets.  Let's drop
> > rendering for ref=* on ways and just render the route relations already,
> > this and multipolygons are why relations came to exist in the first
> place.
>
> I'm as excited about route relations as anyone, especially because route
> relations are required for more nuanced route shield selection in
> renderers and routers. But for all the problems route relations solve,
> there are still some unresolved issues:
>
> * Even once rendered maps display pictioral route shields [2], there
> will still be situations where plain text is more appropriate, just as
> on the ground. It isn't always obvious how to transform a particular
> network=* value into a human-readable ref prefix to display in prose or
> read aloud during turn-by-turn navigation. Signposted ref prefixes can
> be pretty idiosyncratic, like "CC" for network=US:NV:Clark. I'm slowly
> building up Wikidata's coverage of signposted road networks and linking
> it to OSM Wiki data items, to make it easier for data consumers to look
> up the human-readable ref prefix on demand [3] or export a lookup table
> like [4] to hard-code. Incidentally, I've also proposed a road name
> formatter property at Wikidata [5], so that data consumers can expand
> network=US:NV:Clark to "Clark County Route", but it hasn't gotten much
> traction yet.
>

Honestly it isn't that hard to include modifier=* for bannered routes (ie,
Business, Bypass, Truck, Express, etc) and match against network on that to
get a good starting place without having to look up the whole thing.  So,
for example, (using NA as an abbreviation for the fictional state of
Nebrahoma), US:NA:Nebrahoma with no modifier would be easy to assume
"County Route".  US:NA:Nebrahoma:Nebrahoma City would be "City Route",
US:NA:Business with modifier=Business would be "State Business Route"...


> * A way's ref=* key is an ordered list, whereas there's no explicit
> ordering of a way's membership in multiple route relations. (A relation
> explicitly contains its members but not the other way around.) A data
> consumer either has to hard-code some heuristics that may not always be
> accurate [3] or infer the order from the way refs, as OSRM does. [6]
> There's a parallel situation with route numbers associated with a bus
> stop. The route_ref=* key on the stop node makes the order explicit,
> since some agencies don't sort the routes numerically on signage.
>

Perhaps we can get some insight from Osmand.


> * The destination:ref=* key uses the same prefixed syntax as way refs.
> No structured alternative has been formally proposed, but
> destination:network=* is common in Australia (where network=* is common
> on ways) and I've begun using destination:ref:wikidata=* in some parts
> of the U.S. I don't think it's too outlandish to imagine a future where
> navigation software uses destination:wikidata=* to detect street names
> that 

Re: [Talk-us] While we're fixing things in iterations

[Kevin Kenny]

On Thu, Sep 24, 2020 at 6:04 AM Minh Nguyen
 wrote:
> More recently, Kevin Kenny reimplemented the shield renderer using a
> more robust approach [3] and has discussed route relation support with
> the openstreetmap-carto developers. [4]
>
> OSMUS is interested in offering an Americentric renderer replete with
> shields. If anyone would like to help with the server situation, let's
> get in touch. Also I'm sure Kevin would welcome any pull requests to his
> osm-shields project, which would probably be a good starting point for
> this renderer if we go with Mapnik and raster tiles.

Everything Minh said here is true. I'd welcome all the help I can get!

The project has been on hold for quite some time, because I got
tremendously frustrated with it.  There are a lot of moving parts that
all need to come together to make it work. It touches a many
components in the rendering chain.

OSM-Carto is not the main problem.  Its developers are quite
responsive indeed to the idea. (I know that it would eventually bog
down for a while in controversy, but if we're talking about a
US-centric openstreetmap.us server, we could fork the style.) It's not
been my #1 priority, simply because I use the shield rendering for
some of my own maps, and I don't use the OSM style for them.

For OSM-Carto to do the shield rendering, Carto itself would have to
handle it.  That requires support in Carto for the GroupSymbolzer in
Mapnik. [5] I don't imagine this would be all that hard a problem, and
again the Carto developers are interested and would most likely accept
a well-done PR.

Mapnik is a non-issue. For my maps, I was able to use Mapnik itself
'out of the box', except for the fact that I render in two layers, one
for fill colour and one to overlay linear features, icons and labels.
(I work it this way because I interrupt linear features with
transparent cutouts for labels, and I want the fill colour to show in
the transparent areas.) This is easy enough in Python; I have no idea
what the impact would be on Carto because at present I don't use it.

The shield placement in Mapnik depends on quite a complex piece of
SQL. [6] The reason for the complexity is that readable shield
placement is extremely difficult when considering a route as a bucket
of discrete ways. It gets much easier if ways can be grouped into the
longest possible linear sequences that share a set of markers (this
happens at [7]). The SQL in turn depends on a couple of extra tables
in the rendering database: 'planet_shieldroute', which enumerates the
route relations that require shields; and 'planet_shieldway', which
enumerates the ways that are members of the routes and gives their
roles.

Because of the complexity of composing the shielded routes at the time
of rendering, Paul Norman and Sarah Hoffmann are convinced that the
approach I'm using would be far too slow if it were tried on an OSM
tile server, and demand a different one. Neither of them has, so far,
sketched an alternative design, and I have so far not been able to
come up with one myself. Paul, in one message, hinted that developing
a renderer for concurrent routes that would satisfy all his
constraints may not, in fact, be possible. Unfortunately for me, this
discussion spilled over into the changes that would be required for
osm2pgsql; I sketched what osm2pgsql would need for the two auxiliary
tables to be created, and drafted a formal proposal [8] for the idea.
(Note that in that proposal I proposed no changes whatsoever to OSM's
main renderer.) The developers of osm2pgsql unambiguously indicated
that a PR implementing the change would not be considered. As a
result, I decided that the project would have to switch to another
database importer, likely imposm3. [9] Maintaining a fork of osm2pgsql
indefinitely was not an acceptable approach to me! Making the switch
would require me to retool quite a lot of unrelated work, so I
reluctantly decided to put the project on hold.

Since then, Joseph Eisenberg and Jochen Topf have stepped in on the
osm2pgsql project and committed the 'Flex' backend. [10] I have not
had the time to try to use the Flex backend to develop an importer for
the tables that I need, but quickly scanning the documentation
suggests that it has everything that the project would require - and
was found acceptable to the osm2pgsql developers. I think, therefore,
that particular roadblock may have been removed.

So the limiting factor, then, is my time - which is in
catastrophically short supply at the moment. I'm facing clamouring
demands at work because people seem finally to be getting the idea
that I'm retiring - with only five weeks left to go.  Once I've
finally left the workplace and had a little bit of time to rest, I
might take another run at the hill.

In the meantime, the Github for the project has some further notes on
what needs to be done to make the shaped rendering and route relation
handling scalable. [11]

On Wed, Sep 23, 2020 at 6:57 PM Andy Townsend  wrote:
> 1. 

Re: [Talk-us] place=neighborhood on subdivisions?

[Brian Stromberg]

>
> I don't know that I agree with "suburbs have had a very clear definition
> in the United States for decades."  To wit, some would say that a "suburb"
> can be an incorporated city that is smaller than, but "associated with"
> (and maybe even sharing a partial contiguous boundary with) a larger city,
> of which it "is a suburb."  (For example, Bellevue to Seattle, or El Cajon
> to San Diego).  These are quite precisely defined as incorporated cities
> with rather exact boundaries.
>

This is the only definition I've ever encountered in the US. I don't think
anyone who lives in Seattle would consider Wallingford, Fremont, or
Magnolia to be suburbs, much like nobody would consider the Upper East Side
or SoHo to be suburbs of New York City.

The all-knowing Wikipedia agrees with Minh [1], it looks like OSM uses the
UK/Aus/NZ/Ireland definition of suburb. That usage does not reconcile well
with the American usage which is more of a relational definition (Y is a
suburb of X). It seems like the proper procedure is to avoid using the tag
at all and use neighbourhood instead (if a tag is required). This
contradicts the OSM wiki but seems like the only way to avoid confusion.
The only reason I can think of to use 'suburb' as a tag in the context of
the United States would be if a tag indicating 'central city' or something
similar was introduced.

Just my two cents.

[1] https://en.wikipedia.org/wiki/Suburb

--
Brian


On Thu, Sep 24, 2020 at 5:37 AM Minh Nguyen 
wrote:

> Vào lúc 11:02 2020-09-23, stevea đã viết:
> > On Sep 23, 2020, at 10:51 AM, Brian Stromberg 
> wrote:
> >> 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.
> >
> > I believe it is UK-derived, as are many OSM "definitions" (usually /
> often clarified in wiki for that key).
>
> If I'm not mistaken, the definition on the wiki seems to align more
> closely with the meaning of "suburb" in Australian English, in which
> it's understood to be anywhere within the city, even near the central
> business district. [1] place=suburb was originally proposed by an
> Australian mapper in 2006. [2] Also, around early 2008, Australia jumped
> from 7.8% to 29% of global place=suburb usage, which could have helped
> to reinforce that definition. [3]
>
> The wiki says place=suburb is "in a place=town or place=city", but that
> doesn't necessarily say it has to lie within the administrative boundary
> that contains the place=town/city as a label. place=town/city is mapped
> as a POI, not as an area with distinct boundaries. But even so, it is
> pretty far from how Americans associate suburbs with distinct
> incorporated municipalities or unincorporated areas on the outskirts of
> the city.
>
> [1] https://en.wiktionary.org/wiki/suburb#English
> [2] https://wiki.openstreetmap.org/wiki/Special:Diff/55503
> [3] https://ohsome.org/apps/dashboard/
>
> --
> m...@nguyen.cincinnati.oh.us
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Minh Nguyen]

Vào lúc 15:56 2020-09-23, Andy Townsend đã viết:
I'm actually surprised that someone associated with the OSM US community 
hasn't created a proof-of-concept "good US road route rendering" variant 
of the OSM Carto style on a live server that people can use for 
reference (I'm guessing ongoing server costs wouldn't be huge - a couple 
of $ a day at one of the cheaper hosters).  Of the issues above (1) you 
can ignore in a proof of concept (or deal with some of the edge cases), 
(2) isn't an issue if you're just rendering the US and (3) isn't a 
problem if you can live with downtime at the occasional reload (or have 
two databases - one live, one available to be reloaded if you can't).


In 2012, Phil Gold and Richard Weait developed a "shield renderer" and 
set it up on an OSMUS server. [1] The renderer not only eschewed way 
refs in favor of route relations but also used the network=*, ref=*, and 
modifier=* keys to choose accurate shields consistent with road signage 
-- not a small feat for the U.S.


It was something of a proof of concept, apparently taking an approach to 
processing the relations and generating shields that would've been a 
nonstarter for the openstreetmap-carto project. The project did get 
pretty far in terms of supporting not only state-specific shield designs 
but even plenty of county-specific shield designs and some one-off 
shields. [2] However, the server isn't maintained. It ran out of disk 
space, so it hasn't kept up with OSM planet updates.


More recently, Kevin Kenny reimplemented the shield renderer using a 
more robust approach [3] and has discussed route relation support with 
the openstreetmap-carto developers. [4]


OSMUS is interested in offering an Americentric renderer replete with 
shields. If anyone would like to help with the server situation, let's 
get in touch. Also I'm sure Kevin would welcome any pull requests to his 
osm-shields project, which would probably be a good starting point for 
this renderer if we go with Mapnik and raster tiles.


[1] http://elrond.aperiodic.net/shields/
[2] https://bugs.launchpad.net/osm-shields/
[3] https://github.com/kennykb/osm-shields/
[4] https://github.com/gravitystorm/openstreetmap-carto/issues/596

--
m...@nguyen.cincinnati.oh.us
m...@openstreetmap.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 11:02 2020-09-23, stevea đã viết:

On Sep 23, 2020, at 10:51 AM, Brian Stromberg  wrote:

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.


I believe it is UK-derived, as are many OSM "definitions" (usually / often 
clarified in wiki for that key).


If I'm not mistaken, the definition on the wiki seems to align more 
closely with the meaning of "suburb" in Australian English, in which 
it's understood to be anywhere within the city, even near the central 
business district. [1] place=suburb was originally proposed by an 
Australian mapper in 2006. [2] Also, around early 2008, Australia jumped 
from 7.8% to 29% of global place=suburb usage, which could have helped 
to reinforce that definition. [3]


The wiki says place=suburb is "in a place=town or place=city", but that 
doesn't necessarily say it has to lie within the administrative boundary 
that contains the place=town/city as a label. place=town/city is mapped 
as a POI, not as an area with distinct boundaries. But even so, it is 
pretty far from how Americans associate suburbs with distinct 
incorporated municipalities or unincorporated areas on the outskirts of 
the city.


[1] https://en.wiktionary.org/wiki/suburb#English
[2] https://wiki.openstreetmap.org/wiki/Special:Diff/55503
[3] https://ohsome.org/apps/dashboard/

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Minh Nguyen]

Vào lúc 10:45 2020-09-23, Paul Johnson đã viết:

Can we finally fix two other longstanding problems, then?

1. The wiki being incorrect about not counting bicycle lanes.  That's 
not reflective of how validators deal with lanes, how data consumers 
like Osmand or Magic Earth deal with lanes, or how ground truth works.  
The whole "but you can't fit a motor vehicle down it" argument is 
facile, that's what access:lanes=* and width:lanes=* is for.


I agree that width is a poor argument for the status quo, especially 
given the common practice (in California, anyways) of bike lanes that 
double as right turn lanes for cars.


For what it's worth, the lanes=* documentation has long included a 
passage recommending that data consumers treat lanes=* as a minimum 
value rather than a reliable exact lane count. Apparently some mappers 
only count through lanes but exclude turn lanes.


I'm pretty sure existing routers would have no problem with including 
bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=* 
are both present. So I think a reasonable migration path would be to use 
the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the 
non-auto-centric approach you're advocating.


2. Tagging route information on ways.  It's about a decade too long at 
this point for ref=* on a way to be completely disconnected from the 
entity the tag applies to:  That's why route relations exist.  Biggest 
problem child on this at the moment:  OSM's own tilesets.  Let's drop 
rendering for ref=* on ways and just render the route relations already, 
this and multipolygons are why relations came to exist in the first place.


I'm as excited about route relations as anyone, especially because route 
relations are required for more nuanced route shield selection in 
renderers and routers. But for all the problems route relations solve, 
there are still some unresolved issues:


* Even once rendered maps display pictioral route shields [2], there 
will still be situations where plain text is more appropriate, just as 
on the ground. It isn't always obvious how to transform a particular 
network=* value into a human-readable ref prefix to display in prose or 
read aloud during turn-by-turn navigation. Signposted ref prefixes can 
be pretty idiosyncratic, like "CC" for network=US:NV:Clark. I'm slowly 
building up Wikidata's coverage of signposted road networks and linking 
it to OSM Wiki data items, to make it easier for data consumers to look 
up the human-readable ref prefix on demand [3] or export a lookup table 
like [4] to hard-code. Incidentally, I've also proposed a road name 
formatter property at Wikidata [5], so that data consumers can expand 
network=US:NV:Clark to "Clark County Route", but it hasn't gotten much 
traction yet.


* A way's ref=* key is an ordered list, whereas there's no explicit 
ordering of a way's membership in multiple route relations. (A relation 
explicitly contains its members but not the other way around.) A data 
consumer either has to hard-code some heuristics that may not always be 
accurate [3] or infer the order from the way refs, as OSRM does. [6] 
There's a parallel situation with route numbers associated with a bus 
stop. The route_ref=* key on the stop node makes the order explicit, 
since some agencies don't sort the routes numerically on signage.


* The destination:ref=* key uses the same prefixed syntax as way refs. 
No structured alternative has been formally proposed, but 
destination:network=* is common in Australia (where network=* is common 
on ways) and I've begun using destination:ref:wikidata=* in some parts 
of the U.S. I don't think it's too outlandish to imagine a future where 
navigation software uses destination:wikidata=* to detect street names 
that should be prefixed by "onto" instead of "toward" (instead of using 
destination:street=*, which takes some destinations out of order) and 
uses destination:ref:wikidata=* to choose the right shield to display 
and the correct ref prefix to read aloud.


[1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
[2] https://github.com/gravitystorm/openstreetmap-carto/issues/508
[3] 
https://wiki.openstreetmap.org/wiki/SPARQL_examples#Human-readable_route_refs

[4] https://tinyurl.com/yxk5ux8h
[5] 
https://www.wikidata.org/wiki/Wikidata:Property_proposal/road_name_formatter

[6] https://github.com/Project-OSRM/osrm-backend/pull/4524

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] United States Bicycle Route System ballot(s) pending AASHTO approval

[Richard Fairhurst]

SteveA wrote:
> With both of us in agreement about tag "proposed:route=bicycle"
> (especially as it co-exists with "state=proposed") can we gain
> some more consensus (here, soon?) allowing us to move closer towards
> recommending in our wiki that we tag proposed USBRs with
> "proposed:route=bicycle"?

Honestly, please don't. state=proposed has been around since the very first 
days of route relations and everything supports it.

proposed:route=bicycle is wordier and has no advantage other than some people 
appear to think tags with a colon in are automatically superior, because XML 
has namespaces and therefore we must too.

Changing the tags will achieve nothing; will mean that data consumers have to 
support two schemes instead of one; and will needlessly break stuff.

On the positive side, great to see all these USBRs going into OSM as ever!

Richard
cycle.travel
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 21:47 2020-09-22, Paul Johnson đã viết:
On Tue, Sep 22, 2020 at 8:56 PM stevea 
> wrote:


If you MUST tag place=neighbourhood (note the u) see if you agree
with me that this tag makes most sense in a hierarchy where
place=suburb (and perhaps quarter, if applicable, is/are above) also
exist(s).  I'm not strictly saying I believe that
place=neighbourhood CANNOT exist without place=suburb, but it makes
me wrinkle my brow a bit at it not fitting as well as a
landuse=residential (multi)polygon might rather generically and
innocently (without any hierarchy required) fit in.


Landuse=residential fits better for the lots within a place, not as a 
substitute for it.


I've never gotten into mapping individual lots, but I agree that 
landuse=residential is a reasonable tag to use in conjunction with 
place=plot. [1] I don't think that needs to be mutually exclusive of 
mapping the surrounding subdivision as a named landuse=residential area.


[1] https://wiki.openstreetmap.org/wiki/Tag:place%3Dplot

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] place=neighborhood on subdivisions?

[Minh Nguyen]

Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:



On Tue, Sep 22, 2020 at 8:36 PM Mike N 
> wrote:


On 9/22/2020 9:26 PM, Paul Johnson wrote:
 >         The extra hamlet nodes are import remainders that haven't
yet been
 >     converted to landuse areas.   The general landuse zones for
that area
 >     have been identified, but do not exactly correspond to the named
 >     subdivisions.   As I get a chance to survey, I divide the
landuse into
 >     subdivisions and convert the node to a named area for the
subdivision.
 >
 >
 > Please don't expand these as landuse, please expand them as
 > place=neighborhood instead.  Landuse polygons should be congruent
to the
 > actual land use.

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).


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.


It's common, intuitive, and IMO beneficial to map a planned, 
suburban-style residential development as a single named 
landuse=residential area. These developments have well-defined 
boundaries and are primarily residential in character. If there are some 
wooded lots in the subdivision, it's perfectly fine to map a 
natural=wood area inside of or partially overlapping the 
landuse=residential area, ideally without being connected to it. This 
approach is supported by longstanding documentation [1], old threads 
[2], and good support in both renderers [3] and search engines.


There have also been old discussions where folks have conflated the 
concept of landcover with landuse. [4] But I find this approach overly 
academic. Taking it to the logical extreme, landuse=residential would 
only be coincident to each house in a subdivision, given that the yards 
are non-dwellings.


I don't see the need for a fundamental distinction between planned 
residential developments consisting of multi-family apartments and those 
consisting of single-family houses, such that the former would be mapped 
as a coherent landuse area but the latter would be a shapeless place 
point. Where there's no such distinction, the landuse areas lend 
themselves to ab intuitive rendering that's good for navigating suburban 
sprawl. [5]


If a planned development truly is actually mixed-use, and not only in a 
garden-level micromapping sense, then something other than landuse=* 
would be reasonable, since a particular landuse doesn't characterize 
that development anyways. Named landuse=residential areas also don't 
tend to make as much sense in urban areas, older inner suburbs, and 
rural areas. But the areas in changeset 91255294 aren't mixed-use 
developments; they're residential areas in a suburban setting.


[1] https://wiki.openstreetmap.org/wiki/Special:Diff/1087300
[2] I previously wrote on this topic in 
 and 
it seemed like other respondents were taking the same approach.

[3] https://github.com/gravitystorm/openstreetmap-carto/issues/351
[4] 
https://lists.openstreetmap.org/pipermail/talk-gb/2017-January/019811.html

[5] https://osm.org/go/ZTVSa4OB

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us