It turned out that there are many more constellations where a way crosses the rim of a roundabout and leads into or through the same. See the test data as OSM file (for JOSM).
My idea is to let PTNA report the OSM-IDs of missing data from objects (relations though) to its log-file.
Afterwards, a script (optional) can collect their IDs and append the IDs to a list of IDs which require a handling by ‘osmium get-id -r ...’. The list is handled by “... | sort -u ...” avoiding double entries.
The next time (next night) PTNA will check for the existence of this list and call ‘osmium get-id -r ...’ retrieving the objects from an extract who’s name is part of the list name (planet, europe, germany, … , region-upper-bavaria, …), ‘osmium merge’ the result with the original extract (DE-BY-MVV.osm.pbf) and then start the analysis.
This list of missing OSM-ID data can be maintained manually or by a script, can be checked, deleted, be temporary or even kept in GitHub
The search area for GB-GLG-SPT has been enlarged, too many missing routes which have not been found in the amdmin_level=6 area “City of Glasgow”
The search area is now defined as
CSV data in OSM wiki is not yet available, the location is not yet configured. I need some help from local mappers, where to store that in the OSM wiki.
Can you check the boundaries the tool is checking for TTC, please? PTNA - CA-ON-TTC includes some buses operating in neighbouring Mississauga (e.g. 9 Rathburn, 13 Glen Ein, 17 Hurontario) which is part of MiWay and not TTC.
Haven’t checked the query area, but those appears to be MiWay routes with segments crossing into Toronto city limits at Etobicoke. Maybe there should be a restriction for network values to be analyzed.
However, those MiWay relations are missing a network tag, so perhaps that’s why they’re being pulled in here? But they still probably should not be getting found in an analysis of TTC specifically. The TTC has a few lines that go beyond City of Toronto borders, but none that operate entirely beyond the city borders, as MiWay’s 13 and 17 do.
The search area is the Toronto relation stated above. Any route and route_master is found which has at least a single node (stop_position, platform node, node of platform way, node of member way) in this area. In addition to that, all parent relations (route_master of route, …) and sister/brother routes of same route_master will be downloaded. So, seeing border-crossing routes from other networks is normal.
There is a restriction in place. For CA-ON-TTC, PTNA accepts the long form ‘Toronto Transit Commission’ and the short form ‘TTC’ but also the empty string, i.e. network is not set.
So f.m.p.o.v., setting ‘network’ is always the first task suppressing analysis of ‘foreign’ network routes.
Further more, I would like to rename the analysis of CA-ON-Burlington-Transit to CA-ON-BT using the abbreviation ‘BT’. Are there any objections, concerns?
