I see. There is probably a way to programmatically detect the duplicates in Python, we could add it as a separate property for feeds that need it. Let me know if you want to pursue that route.
Then the filter would be:
@type=bus
@ref~^6\d\d$
@duplicate!=yes
@@
Or something like that, depending on how we implement it.
Edit: actually, it might even be possible to output both route_id values in a single CSV line, similar to what’s currently being done for IL-MOT. Will need a bit of code rethinking on my end, but should be doable.
Edit: already got a solid plan for how to do it but really not sure when I’ll have the time to do it.
I also spent some thoughts on that. I’ll come back this afternoon.
Just in brief: PTNA has an analysis option which controls how to handle double, tripple, … appearances in the CSV : --multiple-ref-type-entries=
“analyze” this is standard and analyzes operator, from and to to distinguish
“allow” simply take as is from csv an do not try to distinguish (handy if you want to list the same bus multiple times)
“ignore” as it says: ignore any further entry for the same ref,type combination
I was thinking of a similar @duplicates= command
ignore - which one shall be ignored?
list (default)
join = creates a single entry with multiple route_id values
Both will be transparent to the mappers, are individual settings, under the control by me and mappers, and in combination could privide enough flexibility without manipulating the GTFS data.
If this becomes unmanageable - like if there’s too many duplicate routes or they change too often - then the issue should be brought up here and we’ll figure out a more automated solution.
Oh yeah, I forgot to mention that anything which has been de-selected before will pop-up in the “Rest” section. Maybe, after the test phase, we can delete the “Rest” section completely.
I believe you can already delete it - the comment after </pre> will show them anyway in the wiki source code and in the template test page, but not in PTNA or in the rendered wiki page.
Edit: perhaps you could clarify it with a comment in German. Also, for fun, you can replace “all” in the filter @!~$all with something in German that conveys the same meaning as long as it’s an impossible regex, it’ll list all routes. (The simpler @!= is good too but technically, hypothetically, might not list a route if it has a property with blank key and blank value - which will never happen, but I’m always more comfortable when something can’t fail instead of just that it won’t fail)
I disabled some twin routes, but this is unfortunately not the solution. I found some routes with different variants in both route_id’s.
for example: 640, 657, 802, 948, 951
For the time being, you could disable them completely and add them manually after the final @@ statement for Havelbus. But that’s only a dirty workaround. The entry should include both route_ids in the CSV field for “route_id” as “xxx;yyy”.
We’ll have to think about a @%duplicates= solution again.
One reason for twin routes seems to be more than one operator. Therefor we need all route id’s. E.g. Havelbus route 657, routeID 252090993 is only served by “Bürgerbus”, another one by both. You can find these “Bürgerbus” routes under ‘10296_3’. I added all gtfs data in osm. PTNA seems to have a problem with trips with 2 ref_trips/gtfs:trip_id:sample on gtfs/compare-routes.php. Maybe you can fix this or have ideas for another solution.
It is by intention to have and support only one trip_id per OSM route. I does not make sense to me to list two trip_ids here which are, except the id, identical regarding the stops and ways used.
It should also be irrelevant whether the bus a 10:00 is operated by “A” and the bus at 10:30 is operated by “B”.
but really not sure when I’ll have the time to do it.
as long as it’s an impossible regex, it’ll list all routes. (The simpler 
Bus, so it’s contain only in 10296_3