[Talk-transit] Public transport validator+generator from Maps.Me

Alexey Zakharenkov eulenspiegel at list.ru
Mon Jun 17 14:51:59 UTC 2019



> 12 июня 2019 г., в 23:43, Tijmen Stam <mailinglists at iivq.net> написал(а):
> 
> On 11-06-19 18:13, Alexey Zakharenkov via Talk-transit wrote:
> 
> Thank you for the list!
> 
> There are a few I have questions about, either about your validator or about the general use of the transit tags.
> 
>> *) "Missing station=<mode> on a feature".
>> Requires that railway=station/halt object be tagged with 'station=subway/light_rail/monorail' or have '<mode>=yes’. ’train’ mode is silently assumed for railways.
> 
> I am not convinced that a station-tag is necessary on subway/lr/mr stations.

Yes, there is some data redundancy, but, firstly, it's a significant validation aspect, and secondly, it simplifies data processing. E.g., with this tag it’s easy to fetch all subway (not monorail) stations in a region with a simple overpass query:
nwr[railway=station][station=subway]({{bbox}});
And to answer the question «Does this station serve a subway?» having only the station’s tags is sufficient.

> 
>> *) "Angle between stops around <station> is too narrow, <number> degrees".
>> A sharp twist of a route most probably indicates incorrect stops order.
> 
> I don't understand what exactly is measured with this. E.G. the relation https://www.openstreetmap.org/relation/7786749#map=16/50.6893/3.1734 (France->Lille), Euroteleport is given as having a too narrow angle, 34 degrees. 34 degrees between what and what? And what is the cutoff?

When imaginarily connected with straight lines, the stations form a polygonal line, where each three consecutive stations form an angle. The validator considers an angle of 45 degrees as suspicious enough to warn about, and 20 degrees as erroneous. This fits the rapid transit systems we support and is very fruitful in detecting wrong station order.

> 
>> *) "Route has different network from master"
> 
> Why would you include a network in a route if the route has a master?

We do not include, we just check that if a route is assigned to a network that the network should be the same as route_master’s one.

> 
>> *) "Stop area belongs to multiple interchanges"
> 
> What do you mean with this?

An interchange is a place where several stations (more precisely, several stop_areas) are within walking distance from each other. So, if there exist bus station B, subway stations S1 and S2 and train station T at a transport hub, it’s an error to create several overlapping interchanges, say (B+S1+T) and (S1+S2). The stop_areas should be combined into one (B+S1+S2+T) stop_area_group. Or, e.g. if metro is far from other stations, two separate interchanges (S1+S2) and (B+T) should be created.

> 
>> *) "Only one route in route_master. Please check if it needs a return route".
>> Non-circular route must have a reversed one. For circular route this is a warning.
> 
> As Jo already said, there are many one-way routes. E.g. our routes 250 <https://www.openstreetmap.org/relation/6735888> and 612 <https://www.openstreetmap.org/relation/8465089> in North-Holland are one-way routes (in both cases because they are a morning-peak reinforcement of another route, namely the 350 and 412)

Ok, it won’t be hard to convert the error into warning. Till now the check has helped us to find and augment routes with reverse itineraries and route_masters.


>> *) The validator also compares the number of found stations/routes in a network with predefined values from CSV. This kind of checksumming helps to detect station/route disappearing or opening new ones.
> 
> Good!
> 
>> **) Warnings are generated about missing/wrong station/line colour, different colour/ref of route and route_master, holes in rails,  "Subway entrance is not a node", "Stop position in a 'platform' role in a route", "Platform in a 'stop' role in a route", "Stop is too far from tracks", "Stop position is not on tracks", "Tracks seem to go in the opposite direction to stops".
> 
> Speaking about colours: there are some interesting colouring systems in the Netherlands.
> 
> U-OV (Utrecht city bus) does not have "line" colours, but "destination" colours.
> All buses going to the Uithof would be orange, while all buses going to Vleuten are blue and to Utrecht central station are Red.
> So a line 28 that runs from Vleuten via the central station to Uithof has orange as line colour, while the opposite direction, which is also line 28, is blue. A short working from the Uithof to the central station has red, while it's opposite (going to the Uithof) would still be orange.
> See <http://wiki.ovinnederland.nl/wiki/Concessie_Regio_Utrecht#Bestemmingskleuren> for the list of colours.
> 
> In Amsterdam, the subway has line coulours, but the tram lines don't have colours on the trams, but colour combinations.
> Originally designed for illiterates, this system continues to work today and is shown on all trams.
> See <http://schomakers.net/Website-Arial-NL/Lijnkleurcombinaties-Arial-NL.html> for the list of all combinations and <https://www.iamsterdam.com/media/transportation-and-schiphol/trams-cs-2015nc.jpg> for a photo of three trams showing it (the older ones are even refitted with an electronic LED-display being able to show much more, such as a crown for the special "kingsday-lines" or a sailboat for "sail"-festival lines. (But those are one-day-a-year lines not mapped on OSM).

Thank God we don’t face such routes so far! We'll deal with that when we get to it.

Best regards,
Alexey


> greetings,
> 
> Tijmen/IIVQ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20190617/a792c1e7/attachment.html>


More information about the Talk-transit mailing list