Errors in openstreetmap VTA data

[shankari]

I am not sure what is the correct forum to report this on, but this was linked from VTA's open data page, so I hope this is right. I'm a PhD student at UC Berkeley, and I'm generating location traces from OSM data (see https://github.com/e-mission/e-mission-eval-public-data for more details)

For public transport data, I allow users to specify a "relation" and then I walk that relation to generate the lat, lon points using a script ported from https://wiki.openstreetmap.org/wiki/Relations/Relations_to_GPX

However, this works fine for BART (https://openstreetmap.org/relation/2851613), Caltrain (https://www.openstreetmap.org/relation/9605484) and even AC Transit (https://www.openstreetmap.org/relation/2630160), but almost every VTA relation I have looked at has had some problems.

• There does not appear to be a relation for the 181 from Warm Springs <-> San Jose. The bus stop (https://www.openstreetmap.org/node/6410476639) is not part of any public transit relation
• There is a relation for the VTA light rail, but it has no nodes, only ways (https://www.openstreetmap.org/relation/6205383)
• There is also a relation for the 52 bus (https://www.openstreetmap.org/relation/8094017) which has both nodes and ways, but alas, the ways don't appear to be in order although the spec (https://wiki.openstreetmap.org/wiki/Relation) clearly says that the members must be ordered (see quote below).
  • Concretely, the way order has

  Way West El Camino Real (516422275) as forward
  Way Castro Street (417101895) as forward
  Way North El Monte Avenue (52869637) as forward 
  

which is clearly incorrect since the 52 goes from Castro to El Monte via El Camino

To be more exact it is one of the core data elements that consists of one or more tags and also an ordered list of one or more nodes, ways and/or relations as members which is used to define logical or geographic relationships between other elements.

I can try to fix these piecemeal, but since it looks like somebody at VTA is maintaining these relations (https://www.openstreetmap.org/relation/8094017 was edited 10 days ago), it seems like having you make a more comprehensive fix is likely to result in more accurate values.