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

[Mateusz Konieczny via Talk-us]

Sep 23, 2020, 23:37 by stevea...@softworkers.com:

> Paul Johnson  wrote:
>
>> 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.
>>
>
> If it truly is the wiki that needs fixing, I'm all for fixing the wiki here.  
> Is there some reason the relatively low bar of making a change to the wiki 
> hasn't been done yet?
>
>> 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.
>>
>
> Yes, 100% agreement.  I think this is simply pure inertia (the kind that says 
> "broken process") on the part of renderers.
>
> Can anybody (renderer authors included, maybe even especially) are welcome to 
> offer reasons why "the old machinery" remains in place?
>
in case of OSM Carto: see 
https://github.com/gravitystorm/openstreetmap-carto/issues/596 - 
no one implemented it

(if you are unable to implement it, feel free to upvote original report to 
express desire for it,
but please do not make "+1"/"implement pls" on the issue tracker)  

> While I still find murky and mysterious exactly "how" to effect change in 
> renderers (who you gonna call?), 
>
The most effective  way is to implement them (I wanted names of bus stops, I 
proposed it
in https://github.com/gravitystorm/openstreetmap-carto/issues/195 and 
implemented it
after it was clear that it would be accepted - now since 2014 bus stops in 
default map style are
displaying names, I did similar with rendering of bridge areas and other issues 
then I become
inactive after fixing all thing that were important to me and relatively easy 
compared to their
importance).

You can also test submitted pull requests ( 
https://github.com/gravitystorm/openstreetmap-carto/pulls )
and express your opinions about this new changes.

You can also comment on new tickets, especially if some ideas are problematic.

You can also report issues or upvote reported issues, though it has smaller 
impact.

You can also implement your own rendering style and run it.

You can also hire someone to do stuff listed above (not sure whatever it ever 
happened,
it should be probably disclosed if someone is getting paid to make some 
specific pull
requests and there is no guarantee that change would be accepted by maintainers)

> my two best efforts along these lines are to "tag well" and "wiki well."  
> (And that can include a great deal of discussion and consensus building on 
> its own, no doubt).  Eventually, (and I've discovered it can take years), 
> renderers do catch up.
>
And also this - say man_made=bridge rendering was possible because there
was substantial use and good tagging proposal. It would not be added otherwise.

___
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

[Mateusz Konieczny via Talk-us]

Sep 24, 2020, 01:00 by ba...@ursamundi.org:

>
>
> On Wed, Sep 23, 2020 at 5:56 PM Andy Townsend <> ajt1...@gmail.com> > wrote:
>
>>
>>
>>
>> On 23/09/2020 23:01, Paul Johnson  wrote:
>>
>>>
>>>
>>> On Wed, Sep 23, 2020 at 4:37PM stevea <>>> 
>>> stevea...@softworkers.com>>> >wrote:
>>>
 Paul Johnson < ba...@ursamundi.org > wrote: 

 > 2. Tagging route information on ways.  It's about adecade 
 > too long at this point for ref=* on a way to becompletely 
 > disconnected from the entity the tag applies to: That's why 
 > route relations exist.  Biggest problem child onthis at the 
 > moment:  OSM's own tilesets.  Let's droprendering for ref=* 
 > on ways and just render the routerelations already, this and 
 > multipolygons are why relationscame to exist in the first 
 > place.
  
  Yes, 100% agreement.  I think this is simply pure inertia(the 
 kind that says "broken process") on the part ofrenderers.
  
  Can anybody (renderer authors included, maybe evenespecially) 
 are welcome to offer reasons why "the oldmachinery" remains in 
 place?  Are there legacy use casesthat remain unclear to the 
 wider community?  Please tell ushere, if so.

>>
>> The US is unusual in that it doesn't have a single ref per  section of 
>> road.  Most places in OSM map what they see on the  ground, and the 
>> current OSM Carto rendering works just fine for  them
>>
>>
> Right up until there's more than one kind of route on the way. 
>
???

As far as I can see it also works fine, 
see say https://www.openstreetmap.org/#map=17/50.08717/19.80950 
with ref=A4;7 and ref=S52;7

And in places where this rendering breaks due to large number of refs, rendering
from relations would also break

Rendering from ref on road and ref from relation would be displayed in exactly 
the same way,
so if current display is bad it would not be fixed by changing to rendering 
from relations


___
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 Wed, Sep 23, 2020 at 6:22 PM Andy Townsend  wrote:

> On 24/09/2020 00:00, Paul Johnson wrote:
>
>
>
> On Wed, Sep 23, 2020 at 5:56 PM Andy Townsend  wrote:
>
>>
>> On 23/09/2020 23:01, Paul Johnson wrote:
>>
>>
>>
>> On Wed, Sep 23, 2020 at 4:37 PM stevea  wrote:
>>
>>> Paul Johnson  wrote:
>>>
>> > 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.
>>>
>>> Yes, 100% agreement.  I think this is simply pure inertia (the kind that
>>> says "broken process") on the part of renderers.
>>>
>>> Can anybody (renderer authors included, maybe even especially) are
>>> welcome to offer reasons why "the old machinery" remains in place?  Are
>>> there legacy use cases that remain unclear to the wider community?  Please
>>> tell us here, if so.
>>>
>> The US is unusual in that it doesn't have a single ref per section of
>> road.  Most places in OSM map what they see on the ground, and the current
>> OSM Carto rendering works just fine for them
>>
> Right up until there's more than one kind of route on the way.
>
> No-one's disputing that this is a major problem for mappers in the US -
> I'm just saying that it's really not a major problem in most other places.
> That doesn't make it any less of a problem in the US but does help to
> explain why people elsewhere seem not to see it as a problem.
>
I don't mean just route=road, literally any other route.
___
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

[Andy Townsend]

On 24/09/2020 00:00, Paul Johnson wrote:



On Wed, Sep 23, 2020 at 5:56 PM Andy Townsend > wrote:



On 23/09/2020 23:01, Paul Johnson wrote:



On Wed, Sep 23, 2020 at 4:37 PM stevea mailto:stevea...@softworkers.com>> wrote:

Paul Johnson mailto:ba...@ursamundi.org>> wrote:

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

Yes, 100% agreement.  I think this is simply pure inertia
(the kind that says "broken process") on the part of renderers.

Can anybody (renderer authors included, maybe even
especially) are welcome to offer reasons why "the old
machinery" remains in place?  Are there legacy use cases that
remain unclear to the wider community?  Please tell us here,
if so.


The US is unusual in that it doesn't have a single ref per section
of road.  Most places in OSM map what they see on the ground, and
the current OSM Carto rendering works just fine for them

Right up until there's more than one kind of route on the way.


No-one's disputing that this is a major problem for mappers in the US - 
I'm just saying that it's really not a major problem in most other 
places.  That doesn't make it any less of a problem in the US but does 
help to explain why people elsewhere seem not to see it as a problem.




It's not strictly a Mapnik problem.  It's certainly possible to
render information from relations in Mapnik (I've done it, for
different sorts of relations, and written diary entries about
it).  There are a couple of tricky bits* though:

 1. You'd need to derive the shields from the ref and the road
itself from the way, and you're going to get some edge cases
where they "don't seem to match".
 2. I expect that it would be _really_ difficult to render refs
from relations in the one country where that's needed and refs
from ways in the other 190-odd.  The OSM style is a global
style, and that means that local edge cases (which is what the
US is here) can't get the "special-case handling" that might
be nice.

There's no reason the rest of the world shouldn't be mapping routes 
this way.  For the reason I gave above.


By all means try and persuade the entire rest of the world to do things 
differently, but I suspect that that will be unlikely to succeed when 
the problem you're trying to solve isn't visible there.


That's why I suggested trying other approaches that would at least 
enable people in the US to see route refs rendered as they would expect 
them to be.


Best Regards,

Andy


___
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 Wed, Sep 23, 2020 at 5:56 PM Andy Townsend  wrote:

>
> On 23/09/2020 23:01, Paul Johnson wrote:
>
>
>
> On Wed, Sep 23, 2020 at 4:37 PM stevea  wrote:
>
>> Paul Johnson  wrote:
>>
> > 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.
>>
>> Yes, 100% agreement.  I think this is simply pure inertia (the kind that
>> says "broken process") on the part of renderers.
>>
>> Can anybody (renderer authors included, maybe even especially) are
>> welcome to offer reasons why "the old machinery" remains in place?  Are
>> there legacy use cases that remain unclear to the wider community?  Please
>> tell us here, if so.
>>
> The US is unusual in that it doesn't have a single ref per section of
> road.  Most places in OSM map what they see on the ground, and the current
> OSM Carto rendering works just fine for them
>
Right up until there's more than one kind of route on the way.

> It's not strictly a Mapnik problem.  It's certainly possible to render
> information from relations in Mapnik (I've done it, for different sorts of
> relations, and written diary entries about it).  There are a couple of
> tricky bits* though:
>
>1. You'd need to derive the shields from the ref and the road itself
>from the way, and you're going to get some edge cases where they "don't
>seem to match".
>2. I expect that it would be _really_ difficult to render refs from
>relations in the one country where that's needed and refs from ways in the
>other 190-odd.  The OSM style is a global style, and that means that local
>edge cases (which is what the US is here) can't get the "special-case
>handling" that might be nice.
>
> There's no reason the rest of the world shouldn't be mapping routes this
way.  For the reason I gave above.

>
___
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

[Andy Townsend]

On 23/09/2020 23:01, Paul Johnson wrote:



On Wed, Sep 23, 2020 at 4:37 PM stevea > wrote:


Paul Johnson mailto:ba...@ursamundi.org>>
wrote:

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

Yes, 100% agreement.  I think this is simply pure inertia (the
kind that says "broken process") on the part of renderers.

Can anybody (renderer authors included, maybe even especially) are
welcome to offer reasons why "the old machinery" remains in
place?  Are there legacy use cases that remain unclear to the
wider community?  Please tell us here, if so.

The US is unusual in that it doesn't have a single ref per section of 
road.  Most places in OSM map what they see on the ground, and the 
current OSM Carto rendering works just fine for them.





While I still find murky and mysterious exactly "how" to effect
change in renderers (who you gonna call?), 

When it was clear that the direction of travel for OSM Carto wasn't 
going to be useful t me I forked what was there at the time and started 
going in a slightly different direction.




my two best efforts along these lines are to "tag well" and "wiki
well."  (And that can include a great deal of discussion and
consensus building on its own, no doubt).  Eventually, (and I've
discovered it can take years), renderers do catch up.


To be clear, I don't want to throw any humans under the bus on this, 
since the Carto folks really do make an elegant style for Mapnik.  
Though if this is a Mapnik issue that's preventing this, maybe it's 
time to either fix Mapnik or consider alternatives?


It's not strictly a Mapnik problem.  It's certainly possible to render 
information from relations in Mapnik (I've done it, for different sorts 
of relations, and written diary entries about it).  There are a couple 
of tricky bits* though:


1. You'd need to derive the shields from the ref and the road itself
   from the way, and you're going to get some edge cases where they
   "don't seem to match".
2. I expect that it would be _really_ difficult to render refs from
   relations in the one country where that's needed and refs from ways
   in the other 190-odd.  The OSM style is a global style, and that
   means that local edge cases (which is what the US is here) can't get
   the "special-case handling" that might be nice.
3. The infrequency with which OSM data is loaded now means that more
   has to be done "on the fly" rather than "at data load", which
   somewhat limits the options for how to solve the problem.

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


Best Regards,

Andy

* I've deliberately simplified things here for legibility - there's lots 
of discussion about these issues in OSM Carto's github, and there are 
also osm2pgsql options available now (see 
https://pavie.info/2020/03/09/openstreetmap-data-processing-osm2pgsql-flex/ 
) that weren't an option previously that may really help here.



___
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

[stevea]

Of course, I'm not pointing fingers or placing blame on any person / human in 
particular.  We agree:  a bit of cleaning some rust off of the toolchain.  
Change management.  Does that happen on this channel?  That's OK:  no need to 
answer that.

SteveA

___
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 Wed, Sep 23, 2020 at 4:37 PM stevea  wrote:

> Paul Johnson  wrote:
> > 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.
>
> If it truly is the wiki that needs fixing, I'm all for fixing the wiki
> here.  Is there some reason the relatively low bar of making a change to
> the wiki hasn't been done yet?
>

Proscriptivists end up changing it back and screaming that their word is
gospel, so everyone's just given up at this point.


> > 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.
>
> Yes, 100% agreement.  I think this is simply pure inertia (the kind that
> says "broken process") on the part of renderers.
>
> Can anybody (renderer authors included, maybe even especially) are welcome
> to offer reasons why "the old machinery" remains in place?  Are there
> legacy use cases that remain unclear to the wider community?  Please tell
> us here, if so.
>
> While I still find murky and mysterious exactly "how" to effect change in
> renderers (who you gonna call?), my two best efforts along these lines are
> to "tag well" and "wiki well."  (And that can include a great deal of
> discussion and consensus building on its own, no doubt).  Eventually, (and
> I've discovered it can take years), renderers do catch up.
>

To be clear, I don't want to throw any humans under the bus on this, since
the Carto folks really do make an elegant style for Mapnik.  Though if this
is a Mapnik issue that's preventing this, maybe it's time to either fix
Mapnik or consider alternatives?
___
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

[stevea]

Paul Johnson  wrote:
> 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.

If it truly is the wiki that needs fixing, I'm all for fixing the wiki here.  
Is there some reason the relatively low bar of making a change to the wiki 
hasn't been done yet?

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

Yes, 100% agreement.  I think this is simply pure inertia (the kind that says 
"broken process") on the part of renderers.

Can anybody (renderer authors included, maybe even especially) are welcome to 
offer reasons why "the old machinery" remains in place?  Are there legacy use 
cases that remain unclear to the wider community?  Please tell us here, if so.

While I still find murky and mysterious exactly "how" to effect change in 
renderers (who you gonna call?), my two best efforts along these lines are to 
"tag well" and "wiki well."  (And that can include a great deal of discussion 
and consensus building on its own, no doubt).  Eventually, (and I've discovered 
it can take years), renderers do catch up.

SteveA
___
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

[stevea]

On Sep 22, 2020, at 8:38 PM, Elliott Plack  wrote:
> Excellent! I see no problem keeping state=proposed with the lifecycle.

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"?  I'd love to see wider agreement 
that these tags together are a good way to move forward, as "state" continues 
the legacy rendering support by OCM and cyclosm and "proposed:route" is 
harmonious with tagging schemes that are more modern as they grow into sensible 
namespaces like Lifecycle.

> Another tag in that realm that I like to use is the `start_date` or in this 
> case the `opening_date`. The latter is for some future date, if known, when 
> the route would change to regular active status. Then you can add the 
> start_date. I find those useful when another mapper might not see something, 
> either on imagery or out in the world. If they see a recent start date, it 
> might help explain the discrepancy.

I do put start_date and end_date on objects in OSM (I just did on a 
fire=perimeter that covers a huge portion of my county and which burned for 
over five weeks).  But for proposed USBRs, predicting what to use as 
"start_date" requires predicting when AASHTO will complete the voting on its 
ballot for state's USBR applications during that AASHTO "round" (twice a year), 
and we simply can't do that.  It's easier to wait until "after the fact" (OSM 
receives news that the AASHTO ballot has completed and published results) and 
then simply remove the "state=proposed" tag:  that's how we've been doing it, 
it's well-understood, it's quite simple / straightforward and it "works" 
(causing OCM to render solid route lines from initially dashed route lines), 
but more importantly, as accurate route data in OSM as a database.  So while I 
agree with you it would be useful to do this, we don't have a crystal ball that 
allows it to predictably happen in this case.  I think the "state=proposed" and 
"proposed:route=bicycle" tags convey enough, especially as source=* tags and/or 
changeset comments often denote a pending USBR being part of a particular 
AASHTO ballot — "AASHTO Autumn 2020 round," for example.  The whole idea of 
these entering OSM is to have enough time to enter them (sometimes they are 
hundreds or even thousands of kilometers of route to enter) by the time they 
become approved.  Sometimes we "beat the clock" and end up with some dashed 
lines and we wait for approval, sometimes we lag a bit and they get approved 
first, THEN we complete our entry of them into OSM.

> Annotation geekery aside, it brings me great joy that OSM holds such a vast 
> repository of bicycle/pedestrian related data that are virtually unparalleled 
> by other commercial mapping products. Keep up the good work adding and 
> maintaining these networks.

Very kind of you to say.  There ARE other (often commercial) such 
"repositories" (e.g. RideWithGPS) but these tend towards the ephemeral, 
transitory-natured "I think this a good bike ride" GPX data, rather than "these 
are official or quasi-official (signed on the ground)" bicycle route data 
contained in OSM.  Happily. the Internet has room for both.  Is OSM 
"unparalleled" when it comes to "official" bicycle/pedestrian related data?  
Well, that's a great goal to shoot for, I'm delighted to receive the feedback 
you believe we're "getting there!"

SteveA
Simply "one more volunteer" doing this, there are many!
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[stevea]

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

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.

Some say that a "suburb" is a subset of an incorporated city, like a district 
of that city.  (For example, Magnolia to Seattle, or Mid-City to San Diego).  
These are often amorphous and imprecisely defined, though there might be 
agreement at a rough "center" or "town square that defines the central 
character of this suburb," but not always.

At least in the USA, I think many would nod our heads and say "yes" (both).  In 
short, both "definitions" (or really, "understandings") of "suburb" are 
correct, perhaps depending on context or a given region / locality.  I don't 
think that (at least these two, there may be more) this is a "very clear 
definition in the United States."

The "definition" of "neighborhood" in the USA is even less clear, though it is 
possible to draw the beginnings of a rough box around it.  We could spend some 
time trying to refine this, but I believe it would be difficult and possibly 
contentious, but it could also bear fruit for purposes of better tagging here.

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

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

[Brian Stromberg]

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  wrote:

> Below, I answer Paul (first) and Joseph (second), both with substantial
> detail, so "lengthy post ahead."
>
> Paul Johnson  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  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
> 

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

[Paul Johnson]

On Wed, Sep 23, 2020 at 11:34 AM stevea  wrote:

> > 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.'"
>

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.

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.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[stevea]

Below, I answer Paul (first) and Joseph (second), both with substantial detail, 
so "lengthy post ahead."

Paul Johnson  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  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 

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

[Matthew Woehlke]

On 23/09/2020 00.52, Paul Johnson 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.


I admit this threw me at first also, but read 
https://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb. To wit: "OSM's 
usage of 'suburb' is different than that used by North American English, 
where a suburb is 'an area, often residential, outside of a central city'."


In the US, we're used to a "suburb" being a separate town, village, or 
even city that is associated with a large city (New York City, Chicago, 
Houston, Los Angeles, Seattle, etc.), but that's not the definition that 
OSM uses. As I understand the wiki, the Seattle usage is correct.


--
Matthew

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