Re: [OSM-talk-fr] Site paristique

[Stéphane Péneau]

Le 21/11/2016 à 23:22, Vincent Bergeot a écrit :

Ce n'est pas fairplay je trouve !

Bonne soirée


J'ai aperçu ça aussi, mais pour ma part, je trouve que c'est assez comique.

Stf



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] umap + framacalc + adresses.data.gouv.fr

[Philippe Verdy]

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  a
écrit :

> Bonjour,
>
> Le Sun, 20 Nov 2016 08:10:37 -0700 (MST),
> Trufovent  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
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rencontre parisienne 24 novembre 2016

[Donat ROBAUX]

Dans la froideur de l'automne, qui est dispo ce jeudi à 19h30 pour se
rencontrer?

Nous nous rencontrons jeudi 24 novembre 2016 à partir de 19h30. Les locaux
peuvent être ouverts un peu avant je pense.
C'est ici: FPH, Fondation Charles-Léopold Mayer pour le Progrès de l'Homme
38 rue Saint-Sabin Paris 11

Pour le reste des infos, c'est par là:
http://www.agendadulibre.org/events/12349

Et la forum est toujours là pour en discuter.

Donat
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] umap + framacalc + adresses.data.gouv.fr

[Nicolas Dumoulin]

Bonjour,

Le Sun, 20 Nov 2016 08:10:37 -0700 (MST),
Trufovent  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
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr