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

[Ian Dees]

Hi everyone on this thread. It seems conversation has gotten way off topic
and heated, so I put a moderation hold on the list and won't let this
thread through for 24 hours or so.

Thanks,
Ian
talk-us moderator
___
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 Fri, Sep 25, 2020 at 11:49 AM Volker Schmidt  wrote:

> (this comment is only regardinbg the "lanes" part of the thread)
>
> Date: Thu, 24 Sep 2020 09:30:15 -0500
>> From: Paul Johnson 
>> To: OpenStreetMap talk-us list 
>> Subject: Re: [Talk-us] While we're fixing things in iterations
>>
>
>
>> > > Can we finally fix two other longstanding problems, then?
>> > >
>> > > 1. The wiki being incorrect about not counting bicycle lanes.
>
> The wiki is correctly reflecting the practice in many places, for example
> in Italy. Almost all users here count the car lanes and not bicycle, foot,
> combined foot-cycle lanes.
> If there are different  approaches prevalent in other places, then at
> worst the wiki is incomplete by not listing diverging approaches.
>
>> > >That's
>> > > not reflective of how validators deal with lanes, how data consumers
>> > > like Osmand or Magic Earth deal with lanes,
>
> Can you point more precisely where Osmand and Magic Earth differ from the
> wiki.
>

They actually treat all lanes as lanes when all lanes are mapped.  They're
automatically providing incorrect lane guidance when tagged to the wiki, as
the wiki specifically asks people to omit lanes.


> or how ground truth works.
>>
> Ground truth depends on how you define lanes.
> If you count bike lanes this
> <https://www.mapillary.com/map/im/5ZIOO4PlfSIhbmfveSXnnw> is a 4-lane
> road, if not it's a two-lane road.
>

It's a 4 lane road.  That's how lanes works in the real world.


> > > 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.
>>
> In this argument you forget that hundreds of thousends of roads have been
> inserted in the OSM database using the wiki definition.
>

Just because it's time consuming to fix doesn't mean we shouldn't bother
fixing it.  Or we'd have just thrown in the towel after the OBDL
relicensing.


> > 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.
>>
> As far as I know (rom riding a lot ib California, we are not talking about
> bike lanes, but, at best, about shared lanes.
> Example: bike lane
> <https://www.mapillary.com/map/im/5ZIOO4PlfSIhbmfveSXnnw> disappers, and 
> becomes
> (unsigned) shared lane
> <https://www.mapillary.com/map/im/fXPRLaU0nxEtRp_93TYhgw>.
>

It didn't disappear so much as it became motor_vehicle=yes.  Probably a
good situation where mode:turn:lanes (ie, bicycle:turn:lanes,
motor_vehicle:turn:lanes) may need to come into existence.

> Apparently some mappers
>> > only count through lanes but exclude turn lanes.
>>
> That seems fine to me especially if the turn lanes are short (ike  in the
> above example in LA.
>

Except this breaks data consumers from being able to provide accurate lane
guidance.


> The editor won't solve the problem of existing mapping.
>

Maproulette can help organize fixing this.


> 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 is no migration path. I would, from my European perspective at
> least, stick with the present usage and not count any bike/pedestrian
> lane/horse lanes.
>
> The number of lanes is a rough indication for the capacity for motor
> vehicles of a road.
>

"Fuck accuracy, fuck ground truth" --you.
___
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

[Volker Schmidt]

(this comment is only regardinbg the "lanes" part of the thread)

Date: Thu, 24 Sep 2020 09:30:15 -0500
> From: Paul Johnson 
> To: OpenStreetMap talk-us list 
> Subject: Re: [Talk-us] While we're fixing things in iterations
>


> > > Can we finally fix two other longstanding problems, then?
> > >
> > > 1. The wiki being incorrect about not counting bicycle lanes.

The wiki is correctly reflecting the practice in many places, for example
in Italy. Almost all users here count the car lanes and not bicycle, foot,
combined foot-cycle lanes.
If there are different  approaches prevalent in other places, then at worst
the wiki is incomplete by not listing diverging approaches.

> > >That's
> > > not reflective of how validators deal with lanes, how data consumers
> > > like Osmand or Magic Earth deal with lanes,

Can you point more precisely where Osmand and Magic Earth differ from the
wiki.

or how ground truth works.
>
Ground truth depends on how you define lanes.
If you count bike lanes this
<https://www.mapillary.com/map/im/5ZIOO4PlfSIhbmfveSXnnw> is a 4-lane road,
if not it's a two-lane road.

> > 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.
>
In this argument you forget that hundreds of thousends of roads have been
inserted in the OSM database using the wiki definition.

> 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.
>
As far as I know (rom riding a lot ib California, we are not talking about
bike lanes, but, at best, about shared lanes.
Example: bike lane <https://www.mapillary.com/map/im/5ZIOO4PlfSIhbmfveSXnnw>
disappers, and becomes (unsigned) shared lane
<https://www.mapillary.com/map/im/fXPRLaU0nxEtRp_93TYhgw>.

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

Yes but that statement " Many ways have not yet been tagged with the total
number of lanes at all points, but only with the number of through lanes of
a longer section. Therefore, data consumers can mostly treat the lanes tag
as a minimum rather than an exact number." refers specifically to turn
lanes and similar situations.

> Apparently some mappers
> > only count through lanes but exclude turn lanes.
>
That seems fine to me especially if the turn lanes are short (ike  in the
above example in LA.

>
> Fortunately, editors will automatically fix this and make lanes=* be the
> total of lanes:forward=*, lanes:backward=* and lanes:both_ways=*,

I think JOSM only complains in case of a n odd numberof lanes. and missing
forward/backaward counts


> so this
> is something that isn't hard to solve long term.


The editor won't solve the problem of existing mapping.

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 is no migration path. I would, from my European perspective at least,
stick with the present usage and not count any bike/pedestrian lane/horse
lanes.

The number of lanes is a rough indication for the capacity for motor
vehicles of a road.
If you want to be more precise you can use the second version of the lanes
key as described in this separate wiki page
<https://wiki.openstreetmap.org/wiki/Lanes>.

Volker
Italy, Europe



<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
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] 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] 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] 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

[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