PTNA: news for Public Transport Network Analysis

General talk
, ,
402

@ToniE @NeatNit
sorry for late answer, I was absent/busy
you started with GTFS injection and I see there are some problems yet
tell me if I could help, and I’ll see what I can do

I think the S-Bahn Berlin is not similar S-Bahn otherwhere in germany (maybe except Hamburg, I don’t know Munich) S-Bahn Berlin – Wikipedia

403
404

I did some initial editing based on “operators” assuming that those operate in “their” counties and that mappers work county-based.

I’d like to change that to a “number” based structure assuming mappers want to find a certain bus number and see the report for that - this would be much easier with a “number” based sorting.

We did some county based sorting for DE-BY-MVV after three counties joined but came back to the number based sorting. It’s much easier now.

What do you think?

405

I assume you’re asking @bergaufsee. This should be decided by the people who use that analysis page the most.

1 Like
406

I think sorting by bus numbers makes no sense for VBB, some numbers blocks are used by different operators/counties and there seems no logic between numbers and counties. For example:
400ff Oderspree + Uckermark
337 BVG
338 Havelbus
for testing is ok to sort by operator, for the most counties it is only one, the others we have to sort manually later

407

I’ll just clarify the technical aspects:

  • You can write import statements in any order you like, and structure the page however you like. All the points below only apply to sorting within each import statement.
  • The default sorting method is basically:
    1. Sort by route_type according to the sort key defined in this file (lower numbers appear first).
      • I expected that in nearly all cases, each import statement would only include routes of the same route_type, making this sort key irrelevant. However, it seems like there are some cases where different route types end up in the same table.
    2. Sort by the non-numeric prefix in ref
      • e.g. for ref="A23", the second sort key would be “A”
    3. Sort by the first number in ref
      • e.g. for ref="A23", the third sort key would be 23
    4. Etc. if more letters and numbers appear in ref
    5. Identical refs - which generally should not occur, but might - will be sorted by operator and then by route_id
  • Currently, “manual sorting” can be done by using separate import statements. For example, if you want a specific line to appear at the top of the list, you can import just that one and then import the rest. An actual example:
    # custom order:
#@train
#@ref=FEX
#@@
#@train
#@ref~^R\D\d+$
#@@
#@train
#@ref=TES
#@@
# default order:
@train
@ref~^(FEX|TES|R\D\d+|I.+)$
@@
    See actual result at the CSV page and the analysis page.
  • It is technically very easy to change the default sort order described above with a very small amount of Python code. The only catch is that Toni has to put it in the right place in the PTNA servers, end users can’t fiddle with this by themselves like they can with the CSV templates. But Toni is awesome and always known for doing things like this really quickly, at least in my experience - so this would not be an issue. (Only the first time I might have to show him how I set up the code to do it)

So from my understanding, this discussion is about how best to organize the page (with headings and subheadings, etc.) and less about how each group is sorted internally. But if it is about how each group is sorted internally, then there are solutions for that - just say the word.

408

yes, and I think I could handle this

but indeed, the internally sorting I don’t understand not yet
e.g. train - FEX and IRE appear after RB74 but before RB10
or bus Havelbus - 338 normally the first because the lowest Nr., is nearly last, double numbers appear not following

409

some routes doesn’t appear in the correct list,
e.g. Havelbus 654, csv contains the route, the osm-route contains the gtfs:route_id but is listed on unassigned routes

410

That seems to be a problem with the GTFS data: Havelbus 654 (and others) appear(s) twice in the list on top of this section (this list is not sorted!)

That’s why 654 appears under “Not clearly assigned routes” PTNA - DE-BE-VBB

These duplicates can be sorted out most easily when structure is by numbers is used instead of structure by county/operator (currently: by operator)

411

Would it be appropriate to clean up the duplicates during PTNA’s GTFS import?

Either way, I added route_type to the importer which can be used to filter out the dupes. I’ll make a pull request.

412

Mmh, I want to avoid deleting things from the DB. Which one of the twins would be best to delete?

For the Havelbus 654, we have route_id=1924_700 and =1924_3
Same for 652 and same conditions: but why does PTNA show this twice and correctly?

*_700 indicates entry in gtfs_route_types.txt: 700,5000,“Bus Service”,bus
*_3 indicates entry in gtfs_route_types.txt: 3,5001,“Bus”,bus

Maybe the (all?) *_3 route_type values are artefacts, remainders from a cleanup of the GTFS feed: “do no longer use the basic route_type values 0 … 12 and migrate to using the extended route_type values 100 … 1799” ?

Edit: changed 1925_700 and 1925_3 to 1924_700 and 1924_3

413

these routes have different gtfs:route_id’s, could it help to use this to match the osm-routes?

I don’t understand why, but if this is a solution, feel free to do so. Maybe I understand more the logic then

414

@ToniE check GitHub :wink:

1 Like
415

there are real different routes in both parts of the twins, maybe not always, but it happens

416

Yes, I could do that but: example 654 shows identical bus trips (even shape_id) for different route_id with different departures times only. Seems like the migration from route_type = 3 to = 700 was not complete. Do we want to consider, repeat and map bugs of the GTFS by adding two route_masters for 654, simply because we have two route_ids?

417

Thanks, I can start that tomorrow afternoon.

418

I thought I made this on an example with different routes inside the twins in the past, unfortunatly I can’t find it. And no, I don’t want see map bugs or route-twins in OSM, and I don’t copy blind the gtfs data, I look also at the online timetables to verify the data
I think, e.g. for the bus 654 is ok to see 2 routes in PTNA and only 1 with data from OSM (for the moment, if you have a solution for the future - we’ll see)

419

@NeatNit made this quite flexible. We can always exclude things from the list

@type=bus
@ref~^6\d\d$
@route_id!=1924_3
...
@@

would list all 6xx buses except the second one of the 654.
So, by doing this, local mappers can decide what to include and what not.

1 Like
420

With the latest version (or an equivalent tweak in the commandline) you’ll also be able to use:

@type=bus
@ref~^6\d\d$
@route_type!=3
@@

(assuming this is the desired result)

421

This would exclude all route_type=3 routes, which is more than just the second one of bus 654.
In the end, this might be the final solution for DE-BE-VBB, we’ll have to investigate.
However, for DE-BW-bodo this would be wrong as it deletes some routes completely - they do only exist as route_type=3 flavours.

1 Like