Just a heads up, if you’re looking for challenges, thanks to @ToniE, PTNA for Estonia is available
https://ptna.openstreetmap.de/results/EE
https://ptna.openstreetmap.de/results/EE/EE-Koik-Analysis.html
At this point as OSM data validation, but there are plans to add GTFS validation from peatus.ee
Starting from the top, with trains, I already have some questions.
GTFS has “ELRON”. I hope if PTNA validates/uses operator names for matching, it’s possible to map them manually there.
(also, somewhat related, is parcel locker operator AS Eesti Post or Omniva?)
Also a quick look at buses:
Yeah, good idea. We have the same approach here with DE-Bahnverkehr, covering all train, light_rail and monorail specific stuff - allowing any ‘network’ value.
No, that would requite too many configuration. Most authorities/association (those who define tariffs, …) have contracts with various operators, which then operate the buses, trains, trams, … hire bus drivers, …
PTNA can print ‘network’, ‘operator’, and many other keys and their values in the ‘Notes’ columns (if the analysis option --positive-notes is set, which usually is).
If the head-sign of the bus includes “9E”, then ref=9E is OK, otherwise not.
PTv2 defines that name = “…ref: from => to” or “…ref: from => via … => to”
So the name/setting could be
PTv2 defines the usage of ‘via’ and using that in ‘name’: use this only to distinguish two or more route variants which have same start and end stops.
So: mostly not necessary to repeat all stop names also in ‘via’, they’re listed as stop/platform members though.
My idea of ‘network’ is: list all authority/association names who’s tickets are valid on this vehicle (at least on parts of its tour)
I suggest to have a train, light_rail and monorail specific analysis covering the State of Estonia, even though you seem to have only one ‘network’
Secondly, I suggest having ‘network’ specific analysis covering all vehicles - also train, … if for instance a “Tallinna Transport” ticket is valid in a regional “Elron” train inside the boundary of the Tallinn area (Harju maakond)
This will
I will then provide template CSV lists in the OSM wiki (location? your choice) which afterwards can be maintained by local mappers. Locations could be
Thank you, your answers are appreciated. Though don’t feel obliged to help with Estonia-specific questions, PTNA configuration help is more than enough.
It’s a bit complicated. It is printed on the bus, but it’s more like a property of the route and it it’s not considered a part of bus number. It’s impossible to have both 9 and 9E. While it would be possible to have, for example both 9 and 9a (currently Tallinn has no active lines with letter suffix).
Also see how this ‘E’ is displayed on the timetable Routes and Schedules
It took me a while to understand which CSV files you meant. I think I missed something on your website. In the end I’ve found this example München/Transportation/MVV-Linien-gesamt - OpenStreetMap Wiki and then found the separate analysis.
This is what your are talking about, right?
I think maybe some general description what they are could be useful. Also, may I suggest to invent some name for them different than just “CSV file”, maybe “PTNA CSV config”? Because GTFS is CSV too and it’s hard to understand what CSV are you talking about.
Do I understand correctly that these are manually edited files which contain manual mapping of each line to GTFS? Are the initial files manually generated? Looks like quite a thing to support. But then you mention “search areas”. What are those?
Sorry, I probably missed something, maybe you just need to provide a link 
WikiProject_Estonia/Public_Transport/PTNA/$network-liinid looks good to me
I’m more familiar with trains and Tallinn’s public transport, so maybe from them? How are new files created? Do we need to contact you for them to be picked up by PTNA?
Is this a suggestion for CSV file name?
Also, why do we care about ASCII? UTF-8 is well supported nowadays.
We don’t have any lines that run only in the city and Tallinn’s public transport and trains have different ticket systems (though you can upload them to the same card, also for Tallinn residents public transport is free, including trains as long as you don’t leave the city).
Yeah, OK. PTNA doesn’t care about that, even a single route_master with ref=“9;9a” and a mix of routes having ref=“9” and/or ref=“9a” is possible in PTNA. So: quite flexible.
That’s correct.
Yes, I see. GTFS and its CSV files came much later into the game and for me as the insider it was obviously clear. Sorry.
Yes, they get created manually. If we have GTFS, PTNA supports creation of the list from GTFS.
But afterwards, the initial layout with sections, … and the maintenance remains manual.
The effort is not a big deal, the routes usually change once a year.
The history of PTNA was to replace OSM wiki tables with manually maintained status information about routes (like this) by a more simple CVS structured list and PTNA does a status analysis and creates the tables. Besides this the PTNA CVS config allows a small set of layout stuff.
The OSM wiki tables for Munich were never up-to-date, because they required every route relation mapper to take care of them.
The PTNA CSV config can be maintained by few people, that’s the advantage and it is not too much effort: once in a year when time tables change?
This is the area where PTNA searches route relations using the Overpass-API. It does not make sense to search for Tallinn buses in Great Britain. “small is beautiful”. Usually this is a set (1 … n) of admin_level=6 i.e. “county” level areas: see the the search area for my home region: Region München = 12 “counties”. Every pt route relation with at least one node (lat/lon of a stop, platform or way-node) in this area will be found.
So, for “Tallinna Transport” that could be https://wiki.openstreetmap.org/wiki/WikiProject_Estonia/Public_Transport/PTNA/Tallinna_Transport-liinid
I configure the location in PTNA and local mappers or I can create the file as “c&p and modify” from another analysis config. The link to the location is provided in the last column of the county specific table - don’t use the current one for EE, subject to change.
No, that’s an internal name in PTNA and will be seen only in the table EE. UTF-8 is used everywhere else.
I limit this to ASCII for security checks, not allowing strange characters in Linux file names “/ ; < > | & % ! ? * …” using a positiv list of allowed characters (ASCII) rather than a negative list of forbidden characters.
But your concerns are valid. PTNA could do better here by allowing UTF-8 in all visible strings in the Web pages. For instance by replacing critical characters by underscore before using them in a file name.
Hmm, maybe my link between OSM ‘network’ and tickets was not well chosen? My understanding of the ‘network’ is: who (autority, administraion, company, …) decides which lines to have and where they circulate which colour the vehicles have, … and who signs contracts with the operators. … In my region, the MVV is in the public hands of the 12 counties, the operators are mostly private companies providing service for 1 or more bus, … lines.
But PTNA does not require to organize the analysis files using ‘network’ names. That can also be the name of a city, a region, a country.
Kindly see the first part for “Tallinna Transport” on the Estonia page, with a small PTNA CSV config file.
Looks good, can we try adding GTFS to it or do you want me to do something first?
Next step would have been: adding GTFS
I’ve added network to bus routes in Tallinn.
Though I wonder if network really is required for routes with a master route and if it’s an error.
It’s kind of strange that proposal and wiki agree that operator can be inferred from master route, but in wiki network is recommended, while in proposal it’s optional.
There might be some tools out there which do not recognize/know route_master, namely “SketchLine” from the Overpass-API. So adding ‘network’ to all relations is “safe”.
Similar for other keys/values.
PTNA defines many things as ‘mandatory’ which are "recommended’ or ‘optional’ in the PTv2 approved version. This strict handling can partly be disabled though, but not for all.
About bus networks:
I think we should use the same division as here
https://web.peatus.ee/aikataulut
Kuressaare town and Saaremaa maybe could have one network - same municipality deals with it.
Alternatively, we could have a look into the “agencies” of the GTFS and use them?
I’m not sure companies are useful to choose networks. It’s possible for them to change, but the lines stay.
I see a button to get CSVs. Is this the next step? If the line is missing in OSM or has a different ref, will it display it as an error? What about an opposite situation - if the line in OSM is present, but not found in GTFS, will I see this in PTNA? Could be useful to find disused lines.
Yes. You can sort the table on EE-GTFS by “Agency” and then “Download as CSV for PTNA”.
Then split the file by “Agency” and you’ll have separate “PTNA CSV config” files for the OSM wiki.
The idea of the “PTNA CSV config” list is, that this one represents the reality, lists all public transport vehicles which exist.
Yes.
Yes, each line which is in OSM but not listed in the “PTNA CSV config” list will be listed in the analysis result in section “Other Public Transport Lines” (usually section number is “3”).
Also, a typo in the ‘network’ value will pop up in the table “Not Considered ‘network’-Values”