Ja.
Zunächst muss ich aber die Fehler einzelnen Fehlergruppen (hierarchisch?) zuweisen, den Code erweitern, das wird dauern, zumal: Urlaub, …
Die CSS-Anweisungen werde ich ins *.html einbetten, da ich beabsichtige nur diejenigen ${type} ins CSS einzubinden, die auch tatsächlich als Fehlermeldungen im *.html auftauchen.
Somit ist die Lister der CSS-Anweisungen individuell für jeden PTNA-Report, daher ohne *.css Dateien. Kann also am nächsten Tag für den selben Report anders aussehen.
Based on a pull request at Github by @Patchi, I just added analysis support for gtfs data to ptna for
Based on a discussion in the French forum Gtfs pour Angers Loire Métropole - Pays de la Loire - Forum OSM France, I just added analysis support for public-transport data of osm to ptna for
Based on a pull request at Github by @Patchi, I just added analysis support for gtfs data to ptna for
should bus=yes be added to the wiki as an optional tag for public_transport=platform ? I was confused as PTNA is the only tool that required me to add this tag on these POIs
I think it should be the other way round: PTNA should not complain.
Kindly tell me the analysis report name, so that I can switch off the analysis option ‘--check-platform’ (once being back from vacation).
thanks it’s on PTNA - FR-PDL-Irigo
It’s switched off now, active with next analysis.
PTNA is not the only tool.
If you add a point in iD and select ‘Bus Stop’, it will add the point with “bus=yes; highway=bus_stop; public_transport=platform”. Not sure what JOSM does.
Ah ok good to know, still it’s not documented anywhere, only documented for public_transport=stop_position
Also sometimes iD implements things that have never been approved…
PTNA is victim of an AI scraper creating a huge load on the server.
We’re working on a solution, but as I’m on vacation … this may take a while.
Admin is working on it.
PTNA maybe restarted soon and might be protected by “Anubis” later on - hopefully w/o side effects.
PTNA is up and running again in former environment.
We’ll monitor the load and take actions if necessary.
Edit: fix typo “an” → “and”
More than 50% of today’s traffic is caused by requests from Chrome on macOS from many, many different IP addresses.
All have in common, that they request GTFS single-trip information with a high rate.
The result of these requests is intended for human readers, it includes a map and some more information in tables.
The result is not intended to be read by bots!
So, if you feel this applies to you - your script and your behavior - please stop that!
I now understand the “workflow” of the attacks, at least I claim to understand them.
“Admin” currently attends the OSM-Hack-Weekend @ Geofabrik, Karlsruhe, DE (for other reasons) and might discuss this topic there.
As I have an idea on how the attacks work, I have counter measures in mind
I already implemented and tested some of them locally.
I also try to find a single place in the code where I can easily and quickly adjust the filters.
But: “You cannot make things foolproof because fools are so ingenious” (s/fool/attacker/)
Stay tuned
Edit: quote correctly with source
Yesterday, 2026-10-01 after 16:56:29, PTNA wasn’t reachable.
Admin did a reset on the server and that helped - for a while.
Problem persists, seems to be a HW problem.
Fighting the attacks, I have implemented a rate-limit for certain requests towards PTNA, where ever they come from.
This rate-limit should not affect the normal workflow of you, it is tailored for the attacks.
However, please get in touch with me if you see “429 Too many requests” directly coming from PTNA (not the pop-up windows reporting 429 or 504 from Overpass).
