PTNA: news for Public Transport Network Analysis

General talk
, ,
362

If this off topic let me know: Maybe it’s a bug in JOSM, but I created 2 new trolleybus relations for the just launched La Verde in Pescara. The central part of the route has overhead wires, streets labelled with trolley_wire=yes, the end sections they drive on battery power charging while on the main section. Problem, JOSM tells it’s the wrong road for the parts they drive on battery i.e. no trolley_wire tags on the end sections.

image

JOSM validation bug? Tried in ID Editor by splitting a way section to invoke the validator in that editor but nothing gets flagged. Happy as a clam.

363

Could actually be a wrong assumption in JOSM that trolley_buses always need a trolley_wire.

364

All the road sections but for the 5 very long trolley wired ways (former railroad which served as ‘Strada Parco’ for 25 years) are flagged, so think that’s highly probable. Will ask the JOSM maintainers, for now, ignore while doing the various touch ups in the coming week.

365

You can try to add trolley_wire=no + trolleybus=yes although it might have zero effect on JOSM’s validator.

1 Like
366

I found the code responsible for this, it seems to be from the “PT Assistant” plugin. This is the relevant code: WayChecker.java

The relevant part:

if (relation.hasTag(RouteUtils.TAG_ROUTE, "trolleybus")) {
    if (!(RouteUtils.isWaySuitableForBuses(way) && way.hasTag("trolley_wire", "yes"))) {
        isCorrectRoadType = false;
    }
    // ...
}

So it’s as you said - the validator expects trolley_wire=yes for the ways of the trolleybus.

If this is really a false positive (I really wouldn’t know), then PT Assistant is where you should open a ticket, not JOSM.

Edit: ah, I didn’t realize that this plugin is actually made by JOSM.

1 Like
367

Sorry for the long delay to answer your poke, I’m not very active in the osm transportation world for the moment. If you are looking for a not too big PT network that has its own PTNA wiki csv Analysis, I can propose the Orizo network in Avignon. It is not a part of a bigger wiki page and therefore the PTNA GTFS and PTNA Analysis have the same area network (several Analysis in the south east of France are joining several small PT networks so that the PTNA GTFS File and PTNA Analysis File are not corresponding).

I’m not a technical expert and I don’t understand a lot of what is being presented in this feed. But please let me know if I can help you and may be give me a hint of how specifically.

368

Thinking of proposing to just test for the trolley_wire tag presence, be it yes/no. There’s no reason to use the tag on any way but on those that are part of a specific route.

Interestingly all crossings along the wired section have have traffic_signals. They’re always on red for the trolleybus, turn green from sensor loops in the paving. The wired sections are TB exclusive, not even foot is allowed to use but to cross at designated points as indicated by bright yellow band with Italian/English text. It is all is set up to give a fast connection from the Montesilvano Congress Centre and Pescara Centrale and back.

The crossing streets always blink orange also because there’s parallel sidewalks and a bi-directional cycleway. Some have also crossing lights, not all. Not looked for button activation, but suspect so to make crossing motor_vehicles to stop. Anyway, when the trolleybus direction turns green, the sidestreets go from yellow to red. (Green is inactive for these).

369

You may have seen strange reports yesterday/today (DE-NW-WT > 300k changes).

“no space left on device” was the cause.

The hard disk was full. I deleted some GTFS feeds to make space again.
I may have proceeded very rigorously and overshot the mark here and there.

Sorry for any inconvenience.

1 Like
370

Funny, I just had the same problem on my laptop!

371

I just added analysis support for gtfs data of

based on PM by @matheusgomesms

372

This is actually bad news, some more gtfs feeds which cannot be downloaded automatically - see the GTFS download logs:

  • New failed attempts to get latest updates

    • CH-Alle - Data is protected by CloudFlare - no access
    • FR-BRE-CORALIE - Connection denied by Geolocation - PTNA server is in Finland, Finland is blocked
    • FR-BRE-KorriGo - Connection denied by Geolocation - PTNA server is in Finland, Finland is blocked
    • FR-BRE-TILT - Connection denied by Geolocation - PTNA server is in Finland, Finland is blocked
    • FR-PAC-Orizo - Connection denied by Geolocation - PTNA server is in Finland, Finland is blocked

  • Attempts which failed for a longer period

    • BR-MG-BHTrans-Convencional - HTTP/2 403 - protected by a Captcha (I’m not a roboter)
    • BR-MG-BHTrans-Suplementar - HTTP/2 403 - protected by a Captcha (I’m not a roboter)
    • GB-IOW-SV - HTTP/2 403 - protected by CloudFlare - no access
    • US-NPS-DCC - HTTP/2 404 - unknown new location
    • others: DE-BW-*, DE-SPNV - HTTP/2 404 - no longer provided by NVBW
4 Likes
373

Is it possible to use another source here?

  • NVBW provides zips for every network here.
  • Daten-BW has a API and a ZIP here, both is OSM licensed.
  • Or the website mobidata-bw seems to update at least once a month.
374

Thanks,

DE-BW-* is a bit misleading since most of them are still available as you can see from NVBW link

  • I already take the GTFS feeds from NVBW
  • I’ll check the other sources. I prefer to have small, dedicated *.zip.
1 Like
375

I don’t know if it makes any sense for you (because you know I’m not the IT expert), but for the french GTFS most of the feeds download URL can be read from the french Ministry of Transportation (https://transport.data.gouv.fr).
In the feed itself you are currently using a dataset ID from which you are getting somehow the right URL from the API in order to download the GTFS feed.

For the network FR-PAC-Orizo there is currently a fix GTFS feed Address https://exs.tcra2.cityway.fr/ in the PTNA GTFS config files for this network, which corresponds to the resource_url:

image
image1087×597 26.2 KB

And this URL is pointing a different server as the ministry of transportation.

But there is also a permanent_url which can be IMHO used if the resource_url is not working. And this URL is also somehow linked to the ministry of transportation (and other networks like Altigo seems to work well).

  • FR-BRE-CORALIE has a different pattern the JSON structure is different (maybe there is no solution for this one as there is only one URL original_url)
  • FR-BRE-KorriGo has the same pattern as FR-PAC-Orizo.
  • FR-BRE-TILT has the same pattern as FR-PAC-Orizo.
376

Thanks.
For most French feeds I read the gouvernment dataset via the datasetID and filter for resouce[] + format=GTFS, first element and take original_url. This worked pretty well until last week. I decided to not read information from the history[] section - “smells” like “outdated” - but I will check for those feeds and permanent_url - “smells” like a good idea.

1 Like
377

You are right about the history. I mean if the first attempt is failing (because the original_url is pointing to another server which for some obscur reason doesn’t permit a server in Finland to get the data, you can try to get the [history][0][permanent_url] if available. But that is probably not so easy I give you that.

I hope this phenomenon is only temporary and will not extend.

378

That’s quite easy using jq

curl --connect-timeout 30 -s $JSON_URL -o -                       | \
jq -r '.history[] | select(.format=="GTFS") | (.permanent_url)'   | \
sort                                                              | \
head -1

Yeah, let’s see.

379

Good news on this for KORRIGO, maybe for the others also

if check of ‘last-modified’ for the URL from resources[] | select(.format="GTFS") | .original_url fails, I try .history[] | .payload | select(.format=="GTFS") | .permanent_url and take the most recent URL - the date and time is coded in the URL ( …20250314.120927… )

1 Like
380

@mga_geo @Patchi

Good news now for

  • FR-BRE CORALIE
  • FR-BRE-Korrigo
  • FR-BRE-TILT

Bad news for

  • FR-PAC-Orizo
    • government data does not provide history[]
1 Like
381

I see a history in the dataset. Do you mean you still have an geolock even if the permanent_url seems to use a government server?