Il me semble qu'on doit pouvoir gérer des "diffs" entre le géocodage dans OSM et celui dans une source. Pour effectuer les rapprochements dans des recherches, l'Overpass API permet de trouver des objets sans faire nécessairement référence à leur id ni même leur géolocalisation courante, pourvu que les objets soient correctement qualifiés avec des attributs suffisamment sélectifs (on peut toutefois augmenter la sélectivité de l'Overpass API au moyen d'une "bounding-box" même si les attributs sont insuffisants; la "bounding box" peut être indiquée non pas sous forme des 4 coordonnées, mais sur une coordonnée centrale et une distance si cela facilite le travail: voir le dernier paragraphe ci-dessous).
En conséquence on se retrouvera avec deux objets à rapprocher : celui de la source mise à jour (ou pas) et celui d'OSM. Le diff contiendra les deux : si les positions sont proches ou en dessous d'un seuil de distance, on peut les éliminer ou les placer en fin de liste ou dans une liste séparée (rapprochement acceptable), ou prévoir dans l'interface d'accès au diff une colonne "statut" indiquant que le rapprochement a été fait (dans une version historisée d'un objet OSM ou à une date indiquée), ce qui ensuite facilite le travail de "purge" de cette liste d'objets à rapprocher et effectuer un suivi (il n'est pas inutile en plus du "statut" ou de la date de rapprochement de la source, d'ajouter une colonnes "notes" en cas de désaccord, pour l'expliquer : ce peut être une erreur ou une trop grossière approximation de la source et on ne doit pas modifier OSM . Les objets d'une source en erreur et qu'on ne trouve pas automatiquement dans OSM pourraient être mentionnés dans cette colonne de notes (là encore par un lien Overpass avec quelques tags sélecteurs et une "bounding box", si on ne veut pas utiliser les ids d'objets OSM qui peuvent changer en cas de scissions/fusions ou en cas de changement de type "noeud"/"chemin"/"relation"). Reste ensuite à savoir où gérer ces "diffs" : ce sont des essentiellement des tableaux d'avancement, qu'on peut mettre dans un outil séparé (Osmose par exemple, qui cependant ne propose aucune fonction de gestion d'un tableau d'avancement avec des statuts, dates et notes) ou si les données ne sont pas trop volumineuses dans une page du wiki. Je pense que pour ce type d'usage (qui va devenir de plus en plus nécessaire) il nous manque un tel outil destiné aux projets de suivis des mises à jour et à leur rapprochement et destiné aussi à coordonner les sources entre elles (on l'a vu dans le cas de BANO ce n'est pas du tout évident de suivre les sources quand elles sont chacune leurs différences et leurs mises à jour à des dates séparées imprévisibles). Le 21 novembre 2016 à 11:46, Nicolas Dumoulin <[email protected]> a écrit : > Bonjour, > > Le Sun, 20 Nov 2016 08:10:37 -0700 (MST), > Trufovent <[email protected]> a écrit : > > Cette manip m'intéresse beaucoup, merci pour ce partage ! Mais > > comment faire pour automatiser la mise à jour des latitudes et > > longitudes, une fois les adresses saisies ? Soit par le biais d'un > > script (mais alors là je sais pas comment faire pour l'intégrer sur > > umap ?), soit directement sur framacalc. > > En l'état, je ne connais pas de moyen simple pour faire cette mise à > jour. Donc soit il faut le faire à la main, soit utiliser le script php > que j'avais soumis mais c'est un peu bourrin … > Une solution entre les deux peut être envisageable, un script qui > envoie le tableur pour géocodage et l'upload sur une adresse ou pointe > umap. À moins qu'il y ait une API pour importer une couche dans umap, > il faut donc un espace hébergé quelquepart pour stocker le fichier > géocodé. > > -- > Nicolas Dumoulin > > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
