[Talk-us] Updating tagging of public transport

[stevea]

>Saikrishna Arcot wrote:
>Part of the problem between the tagging schemes and the rendering is 
>that it's a chicken-and-egg problem; a new tagging scheme is 
>created, but rendering support isn't there yet (partly because it's 
>a somewhat complex structure), so people might not use that scheme. 
>However, if there were many instances of using the newer scheme, 
>then it would be justified for the renderers to add support for that 
>scheme.

This is a helpful data point to know (and so thank you) but it still 
feels lacking in what we might do about it.  "Create more instances" 
(using a new tagging scheme)?  Sure, that couldn't hurt, but it may 
also not be enough -- it seems quite random as to what gets 
implemented vs. not.  Maybe, in a crowdsourced project like OSM, 
that's just the way that it is:  people do what they want to do.

>A slightly bigger issue I see is that there are two formats for 
>tagging transportation routes, which will not only require data 
>consumers to code for both formats, but will also make it harder to 
>link a bus route tagged using the newer format be "connected" to 
>another bus route using the older format. I feel that this should be 
>resolved quickly.

Yes, I agree:  this is not only a "bigger issue" but it is also an 
immediate issue.  The Transport layer is Right There in our faces as 
we browse the map as an available layer.  There should be a stronger 
connection between what renderers are made available there (the five 
we have are a nice mix, but again we can do better and should strive 
to do so) and what syntax/tagging "is supported" in each of those 
renderers.  More visibility into what might be called a "project 
plan" for each of those renderers?  (Could also be too much to ask, I 
realize).

I still feel like "auxiliary" renderers (Transport, Humanitarian...) 
which are not "Standard" are a big mystery in OSM.  I'd like better 
documentation (wiki, github, whereever...I don't care so long as it 
is available) about what these do, why, how they get updated with 
"better" or "newer" rules (or even if they do) and so on.  It is 
great that we have additional renderers, I'm just asking for greater 
visibility into them.  I think that plants good seeds for better, 
different and newer renderers to emerge, and even better ways to do 
them.  Those newer methods/processes can feed back to improve all 
renderers, I believe.

OSM without renderers is simply a database.  Renderers really are a 
crucial component of how our data get used, and whether those uses 
are more useful or less useful.  Yes, I know:  many folks use OSM 
data with custom rendering software only for their application.  But, 
while important, those users are in the vast minority.  "Most of us" 
use "off the shelf" renderers, and are essentially at their mercy. 
Let's address that with greater visibility into how they get improved.

Thanks for your answers,
SteveA
California