j'ai l'impression qu'il manque la partie principale du journal.
Le but du journal est juste de montrer un exemple un peu avancé de bases de données géographiques dans un cadre d'utilisation réel qui ne se borne pas à une nomenclature. Donc je présente un peu le contexte — nouveau pour presque tout le monde — pour qu'on se représente comment les données sont relevées.
Pour information, ce genre d'études est également obligatoire pour les collectivités publiques (assistées des services de l'État) françaises avant une certaine date (m'en souviens plus, je ne suis pas un spécialiste métier). Il s'agit sans doute d'un cadre européen contre le bruit des infrastructures.
Exactement cf. la directive 2002/49/CE. La France et l'Allemagne ont joué un rôle très important dans l'élaboration des normes et des modèles de bruit, travail qui a servi de base aux directives européennes correspondantes. La mise en œuvre du programme se heurte à deux problèmes principaux, tout d'abord le relevé de données — qui est très coûteux — et tout bêtement le traitement, car il y a un manque d'offre de service (les cabinets sont saturés, si bien que des appelles d'offres arrivent au TÜV dont ce n'est pas la fonction principale).
Même si ce n'est pas mon but je donne des réponses rapides à tes questions:
Comment a été conduite l'étude ?
Avec diligence et exactitude! ☺
Quels sont les logiciels qui ont été utilisés (surtout si ces derniers sont libres) ?
Pour l'étude, des logiciels biens propriétaires ont été utilisés — ArcGIS et SoundPlan. J'ai écrit des scripts Python pour tirer parti d'une biblothèque GIS existant à l'époque. La bibliothèque s'est avérée être de très mauvaise qualité (très fragile) et j'aurais mieux fait d'écrire une bibliothèque en OCaml en une semaine (attention bitrot!), comme je l'ai fait pour la suite.
Quels sont les grandes lignes des traitements ou les requêtes SQL géographiques qui ont été employés ?
Le journal le mentionne: consolidation des données inexactes et consultation. Il n'y a que peu de requêtes relationnelle.
Quels ont été les trucs bien et les trucs qui ont posé problème ?
C'est un peu vague comme question! Ce qui a posé problème c'est que Python et la bilbiothèque choisie s'est avéré être un très mauvais choix pour le développement: les calculs sont très longs, et les erreurs ne sont détectées qu'à l’exécution (pas d'analyse statique des types comme en OCaml qui détecte les erreurs les plus grossières). La bibliothèque utilisée comportait pas mal d'erreurs aussi ou bien sa documentation était trop floue.
C'est quoi la suite (impact sur la collectivité publique) ?
C'est mentionné dans le journal.
Est-ce-qu'il existe des cartes en lignes consultables par le grand public ?
L'étude est publique et en lien dans le journal.
Est-ce-que les données de l'étude ont été publiées en opendata ?
Les données de base non, je suppose qu'elles sont la propriété de l'administration et sont sûrement consultables mais pas accessible par le net.
[^] # Re: Désolé mais il manque une partie à ce journal...
Posté par Michaël (site web personnel) . En réponse au journal Exemple: SIG et pollution sonore. Évalué à 5.
Le but du journal est juste de montrer un exemple un peu avancé de bases de données géographiques dans un cadre d'utilisation réel qui ne se borne pas à une nomenclature. Donc je présente un peu le contexte — nouveau pour presque tout le monde — pour qu'on se représente comment les données sont relevées.
Exactement cf. la directive 2002/49/CE. La France et l'Allemagne ont joué un rôle très important dans l'élaboration des normes et des modèles de bruit, travail qui a servi de base aux directives européennes correspondantes. La mise en œuvre du programme se heurte à deux problèmes principaux, tout d'abord le relevé de données — qui est très coûteux — et tout bêtement le traitement, car il y a un manque d'offre de service (les cabinets sont saturés, si bien que des appelles d'offres arrivent au TÜV dont ce n'est pas la fonction principale).
Même si ce n'est pas mon but je donne des réponses rapides à tes questions:
Avec diligence et exactitude! ☺
Pour l'étude, des logiciels biens propriétaires ont été utilisés — ArcGIS et SoundPlan. J'ai écrit des scripts Python pour tirer parti d'une biblothèque GIS existant à l'époque. La bibliothèque s'est avérée être de très mauvaise qualité (très fragile) et j'aurais mieux fait d'écrire une bibliothèque en OCaml en une semaine (attention bitrot!), comme je l'ai fait pour la suite.
Le journal le mentionne: consolidation des données inexactes et consultation. Il n'y a que peu de requêtes relationnelle.
C'est un peu vague comme question! Ce qui a posé problème c'est que Python et la bilbiothèque choisie s'est avéré être un très mauvais choix pour le développement: les calculs sont très longs, et les erreurs ne sont détectées qu'à l’exécution (pas d'analyse statique des types comme en OCaml qui détecte les erreurs les plus grossières). La bibliothèque utilisée comportait pas mal d'erreurs aussi ou bien sa documentation était trop floue.
C'est mentionné dans le journal.
L'étude est publique et en lien dans le journal.
Les données de base non, je suppose qu'elles sont la propriété de l'administration et sont sûrement consultables mais pas accessible par le net.