Adapter le code pour permettre de modéliser des zones de transport hors de France

[FlxPo]

Pour le moment Mobility se base exclusivement sur des données INSEE / IGN françaises. La modélisation de zones frontalières comme la Suisse nécessite cependant d'y ajouter des données d'autres sources, avec une organisation différente.

Les modifications à apporter sont les suivantes :

• [x] Rendre la classe TransportZones plus générale, en s'appuyant sur des niveaux administratifs non spécifiques à un pays (comme les "Local Administrative Units" d'Eurostat), et en supprimant l'échelon "groupe de communes" (en remplaçant la fonctionnalité de sélection des EPCI par la possibilité de passer une liste d'identifiants administratifs).

• [x] Fusion des données IGN et SwissTopo et création de colonnes local_admin_id, local_admin_name (https://www.swisstopo.admin.ch/fr/modele-du-territoire-swissboundaries3d) pour les limites des zones de transport.

• [x] Récupération des données GTFS pour la Suisse (Open-Data-Plattform öV Schweiz.

• [x] Récupération des données OSM Geofabrik pour la Suisse.

• [x] Fusion des données INSEE et BFS sur la localisation des actifs et des emplois (https://www.bfs.admin.ch/bfs/de/home/statistiken/mobilitaet-verkehr/personenverkehr/pendlermobilitaet.assetdetail.27885388.html).

• [x] Modification de la fonction d'utilité pour prendre en compte les effets frontières (différence de revenu France - Suisse dans un premier temps, éventuellement affiner à un échelon local ensuite).

@Mind-the-Cap tu avais déjà commencé à travailler sur les données suisses, donc je veux bien ton avis sur ces différents points.

[FlxPo]

Suivi des modifications dans la branche https://github.com/mobility-team/mobility/tree/add-switzerland.

[Mind-the-Cap]

J'avais fait ça à l'ancienne, plusieurs classeurs dans le dossier CH.

En plus de ce que tu notes, il y a la superficie des communes (utilise pour les distances internes à une commune du modèle de radiation).

Il faudra aussi probablement publier une table (sur data.gouv.fr ?) pour faire la correspondance entre codes INSEE pour communes étrangères et codes locaux de ces communes.

Le revenu moyen suisse est environ 2 fois le revenu français, on peut donc doubler l'utilité pour commencer !

[FlxPo]

J'ai ajouté les communes suisses à la nouvelle classe LocalAdminUnits. Une question : est ce qu'on choisit un CRS de référence pour Mobility ? Lat / lon WGS 84 est le plus général mais on pourrait aussi choisir un standard européen comme le ETRS89 / 3035. Un avis @Mind-the-Cap ?

[Mind-the-Cap]

Je serais plutôt d'avis de prendre WGS 84, notamment pour être alignés avec OSM.

[FlxPo]

OK. Pour le moment j'ai choisi de rester sur ETRS89 / 3035, ce qui permet de calculer des distances et des aires directement, sans besoin de reprojection à chaque fois qu'on fait une opération géométrique (buffer, aire, distance...). Il faudrait vérifier si le niveau de distorsion est acceptable pour nos usages.

Je viens de faire un push avec l'intégration des "local admin units" dans la classe TransportZones.

Plusieurs breaking changes :

• On ne passe plus un "insee_city_id" mais un ou plusieurs "local_admin_unit_id".
• Suppression de la méthode "epci_rings" qui permettait de créer des zones de transport en incluant des EPCI concentriques. Les EPCI sont un concept français dont il faudrait trouver l'équivalent pour chaque pays ajouté. Peut à mon avis être externalisé à l'utilisateur pour le moment, s'il veut une liste spécifique de communes, grâce à la possibilité de passer une liste d'identifiants.

[FlxPo]

Nouveau push avec une classe GeofabrikRegions qui permet de gérer le téléchargement des extracts geofabrik.

Pour le moment on récupérait les données "latest", mais désormais ce sera à une date fixe ("240101" par exemple) pour éviter des soucis de désynchronisation que j'ai rencontrés en essayant de combiner des extracts français et suisses avec plusieurs mois d'écart.

[FlxPo]

Nouveau push avec l'ajout des données GTFS pour la Suisse. Pour le moment j'utilise l'aggrégation de tous les flux suisses produites par geOps. On pourrait aussi utiliser les données de opentransportdata.swiss mais le site ne fonctionnait pas hier. Je n'ai pas trouvé d'équivalent à transport.data.gouv.fr qui permettrait d'éviter de charger un GTFS de plus de 100 Mo qui couvre la Suisse entière (et les liaisons frontalières).

J'ai également remplacé tous les identifiants INSEE restants par les "local_admin_unit_ids". Tous les tests passent !

Une modification importante : j'ai changé la stratégie d'éxecution de la classe Asset pour être "lazy". Les données sont créées et chargées en mémoire uniquement si elles sont nécessaires (si on a besoin de la dataframe ou geodataframe pour faire qqc avec par exemple).

[FlxPo]

Nouveau push avec l'intégration des données OFS de répartition des emplois et des actifs, ainsi que de l'utilité apporté par le fait de travailler en Suisse plutôt qu'en France.