Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add GTFS feeds for Addis Ababa #31

Open
FloEdelmann opened this issue Jun 18, 2024 · 5 comments
Open

Add GTFS feeds for Addis Ababa #31

FloEdelmann opened this issue Jun 18, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@FloEdelmann
Copy link

FloEdelmann commented Jun 18, 2024

I'm not sure if they are useful or already used at https://ptna.openstreetmap.de/results/ET/index.php, but I wanted to share it with you anyway.

@osm-ToniE
Copy link
Owner

Thanks, I'm currently on vacation and will take care of that when I'll be back.

@osm-ToniE osm-ToniE transferred this issue from osm-ToniE/ptna Jun 29, 2024
@osm-ToniE
Copy link
Owner

Thanks,

I had a closer look into the data and, from PTNA's automation process point of view, the data misses important information.

  • curl -sI "https://gitlab.com/digitaltransport/data/africa/addis-ababa/-/raw/master/Addis%20Ababa%20GTFS_2023/et-addisababa.zip" does not show the "last modified" header for the data
  • when downloading the *.zip, the file date stamps show "01.01.1980" which is also not helpful
    • I want to avoid downloading the *.zip just to see the creation/modification date

So I can't figure out when the data has been created / last modified. This is essential for PTNA.

@FloEdelmann
Copy link
Author

curl … does not show the "last modified" header for the data

Indeed, that seems to be a missing GitLab feature. But I see that they send an etag header, which could be used to check for changes since the last fetch. But I understand if you don't want to implement that extra check only for this feed. So feel free to just close this issue.

@osm-ToniE
Copy link
Owner

Yeah, the etag could be an option, but the release-date (defined by the feed owner) is essential for PTNA.

So, PTNA could read the release-date either

  • from the "last-modified" HTTP header
    • as suggest by "best practice for GTFS"
  • or the time stamps (GNU tool stat -c '%y' filename) of the files in the *.zip
    • having always 1.1.1980 here is "bad coding" for me
  • or a time stamp in the feed_info.txt column 'feed_version'
    • which is "1.0" at the moment

@FloEdelmann
Copy link
Author

I created an issue: https://gitlab.com/digitaltransport/data/africa/addis-ababa/-/issues/1
Let's see if they can change anything to make this usable in PTNA.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants