Mon premier post ici, sur la reco de l’excellent Joël.
Je travaille au Parisien, et pas mal sur les accidents de la route, et j’aimerais bien pouvoir travailler sur les données antérieures à 2014-5, à Paris, quand la géolocalisation a été imposée, semble t il, aux forces de l’ordre qui abondent le fichier.
J’ai fait quelques modifications dans le champ adresse afin de pouvoir permettre à la ban de reconnaître « q de valmy » comme le quai de Valmy,par exemple.
J’ai cherché la façon la plus facile de faire rentrer par quelqu’un des coordonnées.
J’ai mis en place ce Google Doc https://docs.google.com/spreadsheets/u/0/d/1Yv-9yILBQNwYIa3Kdhtn_iepOKj2t_YZILhS9hQBVYA/htmlview#gid=943646158
L’idée est évidemment de proposer sur datagouv un fichier de données avec des coordonnées améliorées.
Beaucoup de croisements de rues, mal pris en compte actuellement par les géocodeurs.
C’est quelques chose que je compte ajouter sur mes géocodeurs (BAN/BANO/OSM) et qui nécessite de repartir du filaire de voirie pour calculer les intersections et générer des POI correspondants.
Ensuite, addok peut très bien indexer ça.
L’autre souci c’est la longueur insuffisante du champ (pour ne pas dépasser les 40 colonnes du Minitel ?) qui fait qu’on a souvent le deuxième nom tronqué. addok pourra le gérer en partie avec l’autocomplétion mais ça ne pourra pas faire de miracles.
Il y a par contre beaucoup d’adresses où un géocodage devrait passer sans problème, il faudrait déjà faire un géocodage du CSV et voir les scores insuffisants.
Merci Christian,
J’ai fait tourner les adresses sur banR, poke Joël et Paul Antoine, pas mal sont reconnues mais pas forcément où il faudrait.
Par exemple les porte de clichy sont tous mis avenue de la porte de Clichy.
C’est quoi addok ?
banR appelle une API… addok fait tourner cette API
« Porte de Clichy » n’est pas connu de la BAN, qui ne contient que des adresses au numéro. C’est un lieu-dit…
En gros toutes les adresses sans numéro sont à vérifier pour cette raison. On peut refaire une passe sur les POI d’OSM, exemple: http://poi.addok.xyz/search/?q=porte+de+clichy&citycode=75056 (75056 = code INSEE global de la Ville de Paris)
On trouve les stations de métro… c’est pas parfait.
Il faut que je complète ces POI avec les intersections, car ça on ne les a pas actuellement.
Si ça te prend du temps dans une de tes nombreuses activités d’utilité publique, je peux m’occuper de générer un geojson avec les intersections des rues de Paris.
En gros c’est ce qu’on obtient avec un coup de géocodage par addok qui fait entre autre la même chose mais quand même beaucoup plus aussi
Le résultat obtenu ne gère bien sûr pas les intersections, naturellement nombreuses dans ce jeu de données.
Je pense étendre cette liste d’intersections avec les références des routes pour trouver le croisement entre la D40 et la D118… car ce genre de choses est courant en zone rurale.
Autre amélioration en test… trouver les intersections des voies très proches mais qui ne sont pas directement reliées au niveau topologique dans OSM.
on va regarder ça @cquest je m’étais déjà posé la question d’ailleurs. Les arguments de l’API d’addok sont les mêmes que ceux de l’API Adresses ? c’est quoi du coup l’adresse à utiliser en prod ? demo.addok.xyz/search ?
Même fonctionnement, vu que c’est le même code derrière (addok).
Il n’y a que les données qui peuvent être différentes.
L’appel à l’API fait par banR devrait aussi désactiver l’autocomplétion qui lorsqu’on a une adresse complète (en général le cas sur les données opendata) ne fera que rajouter du bruit lors de la recherche. Permettre le passage de filtre comme citycode serait aussi un plus…
