For years Estonian GTFS-data was at peatus.ee/gtfs/gtfs.zip however some wise people have moved it to new place without proper redirect.
New place seems to be https://peatus.ee/content/teenusest and one compact file is split to 25 separate files. Does anyone know why all this SNAFU has happened?
Toni, let me thank you first for creating and running PTNA - this is extremely useful tool for handling public transport data in OSM. As data structure has also changed, then I would wait a bit until community members with better inside knowledge can confirm that this setup is final (as of now).
I found the new datalink at Ühistranspordiregistri avaandmed | Regionaal- ja Põllumajandusministeerium (Ministry of Regional Affairs and Agriculture) and that seems to be the new body responsible for public transport. Estonian Transport Administration seems not any more responsible for this. All this looks like making changes because of making changes. Even the word GTFS does not show up at ETA site search any more.
This page Ühistranspordiregistri avaandmed | Regionaal- ja Põllumajandusministeerium says “Avaandmed on kasutamiseks vabalt kättesaadavad kõigile huvilistele.“ which means “Open data is freely available to anyone interested in using it.“. I would assume this means Public Domain licence (Estonian “avaandmed” typically is PD).
I’ve asked around (I work at Ridango), and one person has found at https://eu-gtfs.remix.com/estonia_unified_gtfs.zip
They have just updated the system, so there will be no reverting to the old one.
Thanks for checking this out. So @ToniE and other interested parties can start using it.
That’ll take some time. I need to adapt the code.
This is the first GTFS feed ever which has more than one entry in feed_info.txt
Their entries aren’t even sorted by date or version.
I have to implement some kind of sorting based on “feed_version”, but this needs some conversion first before sorting and will be feed specific?
"Updated: Jan 21, 2026, 1:48 AM" → “202601210148” or “seconds since the epoch”I could not find information about their license though
Yes, it is confusing:
If anyone in community has law background, then it would be interesting to know if this kind of logic is correct.
That is strange - feed_info.txt used to have one content line only. And if I look at these 25 lines, then there is lo logic or references.
I can only guess that 25 links here https://peatus.ee/content/teenusest are related to 25 lines at feed_info.txt. Like the first one applies to the first link. But the trouble is that no order is defined (random order on page) and there is no clear way to match them.
@Zverik Does your contact have access to some kind of manual that could explain this?
I wonder if Google maps takes the same gtfs and if they are willing to adapt. Because there is a hope that gtfs may be changed back to the way it was to cater to Google.
I checked the wiki on GTFS - OpenStreetMap Wiki and found that the Estonian GTFS feed (or 25 feeds in the new scheme?) is not (yet) listed in List of GTFS feeds - OpenStreetMap Wiki - would it make sense to add it here, and if so, using which URL(s)?
The GTFS wiki page also discusses the tagging standard, and - among other things - lists gtfs_id as deprecated: Key:gtfs_id - OpenStreetMap Wiki This is used quite a bit on the Estonian stops, and also gtfs:id can be found. Would it make sense to change this to the current tagging standard? Apparently there exist different approaches, either using plain gtfs:stop_id and gtfs:stop_id:FEED_ID, where the latter is the ID of the feed in the list above. Is there any preference?
Up to you!
The tag 'gtfs:stop_id:FEED_ID' does not require a second tag 'gtfs:feed'='FEED_ID' being set also. That’s the main advantage. A Stop-ID without the information to which GTFS feed it belongs doesn’t help.
At least 'gtfs:stop_id:FEED_ID' is required if a stop is used by two or more networks/associations providing their own GTFS feeds.
Thanks! I think I’ll go with gtfs:stop_id:FEED_ID and come up with a suitable FEED_ID then - it seems indeed simpler to me.