MKuranowski / WarsawGTFS

Creates GTFS feed from ZTM Warsaw data
https://mkuran.pl/gtfs/
MIT License
33 stars 10 forks source link

L lines zoning #4

Closed 1116574 closed 4 years ago

1116574 commented 4 years ago

https://github.com/MKuranowski/WarsawGTFS/blob/93c3c58107ac756f8082189e6c6b9c69d6099729/src/parser.py#L308

There is separate zone for Otwock since different price tickets. Thing is all L lines have a special tarriff just for their trips. Instead of zone "2/O" a "2/LT-S" should be used to indicate that it is zone 2 bus but only long term and special tickets (sold onboard) are accepted. (long term meaning 24h, 72h, monthly etc.)

Then there is fact that some L lines work for free for residents of given area, but no structured data about this exists (only some pdf iirc)

MKuranowski commented 4 years ago

"2/LT-S" should be used to indicate that it is zone 2 bus but only long term and special tickets (sold onboard)

Then, what would be the correct zone for stops where both 7×× and L×× line stop?

That's not a correct solution. The fact that L× lines accept only its own tickets & 24h-and-longer would be represented in fare_rules, not by zone_id.


Also, this script doesn't even output zone and fare information. I plan to add it later, but the GTFS fare implementation doesn't map one-to-one to ZTM tickets. It's also necessary to do some weird shenanigans to exclude L×× routes from short-term tickets.


but no structured data about this exist

GTFS is only meant to provide the generic fare price. Reduced fare prices / free public transit rules can maybe be implemented in NeTEx.


So, what's the exact issue here? Try to answer these 2 questions: "What did the script do?" and "What it should have done instead?"

1116574 commented 4 years ago

You are right. My first proposal isn't a correct solution. But you asked what would be correct zone if stop had L line and normal line, but its already the case with L20 & L22 right? (eg. Park miejski id: 223702 which has both L20 and 702)

From what i understand in code, zones are currently parsed, but not saved to final stops.txt file?

My guess as to what zone should it be: simply zone 2. The fact that cheaper ticket for those lines are available, and not all normal ZTM tickets work should be in fare rules or something, which I realise wouldn't be possible after looking at spec lol, but that seems the 'correct' way to me.

In my eyes the 'purest' solution would be creating separate gtfs feed, this would solve many problems with fare rules, but would introduce main problem of having one transit authority split up (also some tickets probably).

MKuranowski commented 4 years ago

But you asked

That was a rhetorical question pointing out that your solution is incorrect. Fun fact, Sulejówek Mariańska 01 is in zone 1 according to route 173 stop list, but in zone 2 in route L48 stop list.

simply zone 2

Then, cheaper tickets within Otwock municipality on L20 & L22 would be impossible to map out. That's why I left out the fake 2/O zone_id.

Basically, if a there is a different price depending on which stops an itinerary passes through, this has to be represented in GTFS using zone_id with fare_rules contains_id.

It is possible to map out ZTM tickets using the GTFS spec, it's just not that intuitive and pretty complicated.

zones are currently parsed, but not saved to final stops.txt file?

Correct. stops.txt is saved after the end of section ZP (stop groups) of ZTM file, while the zone data is inside section LW (list of stops of a variant of a route).

In my eyes the 'purest' solution would be creating separate gtfs feed

And then there's the ZTM-KM-WKD combined ticket…

1116574 commented 4 years ago

Then, cheaper tickets within Otwock municipality on L20 & L22 would be impossible to map out. That's why I left out the fake 2/O zone_id.

I realize that, but currently this implies only L20 and L22 have cheaper fares, while in reality all L lines have special cheaper fares. L-4 for example has 1PLN one time ticket, applieble just to it, purchased on board, yet this cheaper fare is not accounted for like in L20 example. Hence my first proposition to make all L lines' stops be 2/Special zone, not only 2/O for Otwock.

My problem isn't your solution, but rather discrimination (lol) of some L lines having this accounted for, and others not.

Coming back to routes 173 and L48, the correct way to map it would be zone 1/2? Idk how would this be implemented, perhaps by checking if said stop already has a zone or whatever.

MKuranowski commented 4 years ago

L-4 for example has 1PLN one time ticket

Unless the WTP website is incorrect, 1 zł ticket is a reduced fare. Reduced fares are not part of the GTFS spec.

Again, as I read the WTP website, only L20 and L22 have different normal fare prices depending on which stops passenger's itinerary goes through. All other L×× routes have a flat fare, no matter if you travel one stop, the whole line, trough one municipality or through many.

Or, phrased differently: Most of the lines have a flat fare, and don't care about zones, with the exception of L20 & L22 which have a flat fare of 4zł, but when used within Otwock municipality, the price goes down to 3zł.

The way of representing L×× ticket prices in GTFS would be as such (imagine each row being a different fare_id).

fare_rules.route_id fare_rules.contains_id fare_attributes.price
L-1 (empty) 2.00
L-2 (empty) 5.00
L-3 (empty) 2.00
L20 2/O 3.00
L20 (empty) 4.00
L21 (empty) 3.60
L22 2/O 3.00
L22 (empty) 4.00
L23 (empty) 4.00

And, yeah 1/2 should work fine for Sulejówek Mariańska 01.

1116574 commented 4 years ago

Ah I see. Thanks for the link it really cleared it up for me.