Enquête données TER mise à jour

NicolasBerthelot commented 3 years ago

Google soulève que le jeu de données sur le TER (https://transport.data.gouv.fr/datasets/horaires-des-lignes-ter-sncf/) n'est pas mis à jour depuis février. Or nous avons calculé un nouveau hash chaque jour jusqu'au 30 mars.

thbar commented 3 years ago

Je vais enquêter, j'ajoute des éléments techniques ici pour revenir dessus un peu plus tard:

$ curl -I https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip
HTTP/2 200 
server: nginx
date: Fri, 09 Apr 2021 15:17:58 GMT
content-type: application/zip
content-length: 2326263
last-modified: Thu, 08 Apr 2021 18:02:40 GMT
etag: "606f4540-237ef7"
accept-ranges: bytes

thbar commented 3 years ago

Le code utilise du sha256, et je note pour aujourd'hui:

$ curl --silent https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip | shasum -a 256
a8fb60646454d2599cf48e19edbea273387caf6a8c02a3ec7ad12cddca33761e  -

thbar commented 3 years ago

Curieusement le code qui calcule le sha256 chez nous lève une erreur:

$ iex -S mix
> Hasher.compute_sha256("https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip")
** (CaseClauseError) no case clause matching: {:error, %Mint.HTTP2{buffer: "", client_settings: %{enable_push: true, max_concurrent_streams: 100, max_frame_size: 16384}, client_settings_queue: {[], []}, decode_table: %Mint.HTTP2.HPACK.Table{entries: [{"last-modified", "Thu, 08 Apr 2021 18:02:40 GMT"}, {"content-length", "2326263"}, {"content-type", "application/zip"}, {"date", "Fri, 09 Apr 2021 16:41:09 GMT"}, {"server", "nginx"}], length: 5, max_table_size: 4096, size: 294}, encode_table: %Mint.HTTP2.HPACK.Table{entries: [], length: 0, max_table_size: 4096, size: 0}, headers_being_processed: nil, hostname: "eu.ftp.opendatasoft.com", mode: :active, next_stream_id: 5, open_client_stream_count: 0, open_server_stream_count: 0, ping_queue: {[], []}, port: 443, private: %{}, ref_to_stream_id: %{}, scheme: "https", server_settings: %{enable_push: true, initial_window_size: 65536, max_concurrent_streams: 128, max_frame_size: 16777215, max_header_list_size: :infinity}, socket: {:sslsocket, {:gen_tcp, #Port<0.2415>, :tls_connection, :undefined}, [#PID<0.11232.0>, #PID<0.11231.0>]}, state: :open, streams: %{}, transport: Mint.Core.Transport.SSL, window_size: 2147483647}, %Mint.HTTPError{module: Mint.HTTP2, reason: {:stream_not_found, 3}}, [{:done, #Reference<0.3074820735.2939158531.543>}, {:data, #Reference<0.3074820735.2939158531.543>, <<110, 159, 64, 90, 190, 42, 105, 145, 232, 20, 129, 183, 72, 133, 78, 90, 36, 244, 51, 180, 69, 98, 58, 107, 145, 161, 62, 82, 163, 147, 22, 25, 218, 118, 152, 41, 75, 210, 241, 187, 190, ...>>}]}
    (shared 0.1.0) lib/http_stream.ex:55: HTTPStream.handle_async_resp/1
    (elixir 1.10.4) lib/stream.ex:1421: Stream.do_resource/5
    (elixir 1.10.4) lib/enum.ex:3383: Enum.reduce/3
    (shared 0.1.0) lib/hasher.ex:41: Hasher.compute_sha256/1

C'est peut-être juste lié à la façon dont j'invoque la commande, mais je note pour vérifier.

thbar commented 3 years ago

Le checksum aujourd'hui est:

$ curl --silent https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip | shasum -a 256
225a0a68de61dad01a5412d5a30f1e1966e662583eeea59730ccc27b3b2db21a  -

Il est différent. Toutefois je vais aller comparer les données.

thbar commented 3 years ago

Les données sont différentes elles aussi:

$ diff <(head -5 2021-04-09/stop_times.txt) <(head -5 2021-04-12/stop_times.txt)
2,5c2,5
< OCESN13100F290738:2021-04-06T18:37:49Z,05:58:00,05:58:00,StopPoint:OCETrain TER-87415604,0,,0,1,
< OCESN13100F290738:2021-04-06T18:37:49Z,06:10:00,06:12:00,StopPoint:OCETrain TER-87381509,1,,0,0,
< OCESN13100F290738:2021-04-06T18:37:49Z,06:54:00,06:54:00,StopPoint:OCETrain TER-87384008,2,,1,0,
< OCESN13100F326695:2021-04-08T18:48:13Z,05:38:00,05:38:00,StopPoint:OCETrain TER-87415604,0,,0,1,
---
> OCESN13100F290738:2021-04-09T18:47:21Z,05:58:00,05:58:00,StopPoint:OCETrain TER-87415604,0,,0,1,
> OCESN13100F290738:2021-04-09T18:47:21Z,06:10:00,06:12:00,StopPoint:OCETrain TER-87381509,1,,0,0,
> OCESN13100F290738:2021-04-09T18:47:21Z,06:54:00,06:54:00,StopPoint:OCETrain TER-87384008,2,,1,0,
> OCESN13100F326695:2021-04-09T12:21:31Z,05:38:00,05:38:00,StopPoint:OCETrain TER-87415604,0,,0,1,

thbar commented 3 years ago

@NicolasBerthelot les données ont bien changé, toutefois notre suivi de checksum ne le rapporte pas, on a donc un bug chez nous au moins sur cette partie:

2021-04-12 at 08 13

thbar commented 3 years ago

Le content hash en base de notre côté est:

e06087ce3940287644a8b0cdf91ba0813c52ed27a75ab29067dd29f41831e765

thbar commented 3 years ago

En local le calcul remonte une erreur !

resource = DB.Repo.get(DB.Resource, 26872)
Hasher.get_content_hash_http(resource.url)
** (CaseClauseError) no case clause matching: {:error, %Mint.HTTP2{buffer: "", client_settings: %{enable_push: true, max_concurrent_streams: 100, max_frame_size: 16384}, client_settings_queue: {[], []}, decode_table: %Mint.HTTP2.HPACK.Table{entries: [{"last-modified", "Mon, 12 Apr 2021 18:02:48 GMT"}, {"content-length", "2327266"}, {"content-type", "application/zip"}, {"date", "Tue, 13 Apr 2021 09:24:46 GMT"}, {"server", "nginx"}], length: 5, max_table_size: 4096, size: 294}, encode_table: %Mint.HTTP2.HPACK.Table{entries: [], length: 0, max_table_size: 4096, size: 0}, headers_being_processed: nil, hostname: "eu.ftp.opendatasoft.com", mode: :active, next_stream_id: 5, open_client_stream_count: 0, open_server_stream_count: 0, ping_queue: {[], []}, port: 443, private: %{}, ref_to_stream_id: %{}, scheme: "https", server_settings: %{enable_push: true, initial_window_size: 65536, max_concurrent_streams: 128, max_frame_size: 16777215, max_header_list_size: :infinity}, socket: {:sslsocket, {:gen_tcp, #Port<0.21>, :tls_connection, :undefined}, [#PID<0.734.0>, #PID<0.733.0>]}, state: :open, streams: %{}, transport: Mint.Core.Transport.SSL, window_size: 2147483647}, %Mint.HTTPError{module: Mint.HTTP2, reason: {:stream_not_found, 3}}, [{:done, #Reference<0.654208956.1076363265.198150>}, {:data, #Reference<0.654208956.1076363265.198150>, <<187, 214, 190, 99, 245, 242, 249, 140, 95, 199, 214, 254, 255, 80, 75, 1, 2, 30, 3, 20, 0, 0, 0, 8, 0, 86, 160, 140, 82, 134, 81, 36, 10, 182, 215, 23, 0, 204, 160, 18, 1, ...>>}, {:data, #Reference<0.654208956.1076363265.198150>, <<2, 23, 93, 139, 70, 229, 40, 68, 215, 162, 241, 180, 127, 234, 90, 244, 10, 107, 17, 157, 186, 18, 61, 163, 237, 26, 209, 181, 104, 20, 223, 139, 174, 69, 163, 215, 234, 68, 215, 162, ...>>}]}
    (shared 0.1.0) lib/http_stream.ex:55: HTTPStream.handle_async_resp/1
    (elixir 1.10.4) lib/stream.ex:1421: Stream.do_resource/5
    (elixir 1.10.4) lib/enum.ex:3383: Enum.reduce/3
    (shared 0.1.0) lib/hasher.ex:41: Hasher.compute_sha256/1

thbar commented 3 years ago

Bon après enquête je pense avoir compris.

Le souci décrit dans #1593, que j'ai découvert au passage, n'est en fait pas du tout pas la cause, car le calcul du hash n'intervient pas dans l'affichage de la date de rafraichissement.

@NicolasBerthelot m'indique que le symptôme de départ est la date de dernière mise à jour affichée ici au 4 avril:

2021-04-13 at 16 03

Comme Nicolas l'a indiqué, cette donnée vient normalement directement de Data Gouv.

J'ai été voir pour ma culture:

Le dataset est accessible via l'API sur https://www.data.gouv.fr/api/1/datasets/53835289a3a72906c7ec5c58/
Le dataset retourné en JSON contient les ressources, avec chacune son last_modified:

2021-04-13 at 16 09

La première ressource est en CSV:

$ curl -I "https://ressources.data.sncf.com/explore/dataset/sncf-ter-gtfs/download?format=csv&timezone=Europe/Berlin&use_labels_for_header=false" | grep disposition
content-disposition: attachment; filename="sncf-ter-gtfs.csv"

La ressource ne contient pas vraiment la donnée, mais un fichier qui contient une url:

$ curl "https://ressources.data.sncf.com/explore/dataset/sncf-ter-gtfs/download?format=csv&timezone=Europe/Berlin&use_labels_for_header=false"

Qui donne:

donnees;format;download
Horaires des lignes TER;GTFS;https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip

Donc mon hypothèse est la suivante: c'est peut-être juste ce fichier CSV (qui contient l'url de la vraie ressource) qui n'a pas changé depuis le 4 avril, car l'url vers laquelle cela pointe, elle, a bien vu son contenu évoluer:

# il y a quelques jours (voir plus haut)
$ curl --silent https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip | shasum -a 256
225a0a68de61dad01a5412d5a30f1e1966e662583eeea59730ccc27b3b2db21a  -

# aujourd'hui
$ curl --silent https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip | shasum -a 256
4e4e32fb81ad9af42ea6c9a322218be38e208352cd112728b12d335c3dd84629  -

Il faut que je comprenne pourquoi on a cette sorte de "redirection" maison:

est-ce un pattern fréquent ?
comment faisons-nous pour avoir la vraie url actuellement de notre côté
peut-on supprimer pour retrouver une fiabilité sur la méta-donnée ?

thbar commented 3 years ago

@NicolasBerthelot je ferme ce ticket pour en ouvrir un "propre" maintenant que j'ai compris que c'est lié au fonctionnement d'OpenDataSoft.

etalab / transport-site

Enquête données TER mise à jour #1592