Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata

2020-06-11 Par sujet Nicolas Bétheuil 
J'en étais resté à "utiliser une instance overpass publique pour des
requêtes sur de grandes régions n'est pas recommandé"
Et ce ne serait pas à faire qu'une fois mais à chaque nouvelle mise à jour
du jeu de données d'origine.

Après pré mâcher le travail en montant un overpass "perso", charger la zone
souhaitée, la requêter pour trouver ce qui est intéressant puis éteindre,
ça peut être une option.

Le mar. 2 juin 2020 à 22:21, Marc M.  a écrit :

> osmose monte en effet une base osm en local pour ses analyses.
> vu que l'étape 1 n'est à faire qu'une fois, une requête overpass
> sur l'étendue du jeux de donnée opendata est aussi possible.
>
> Le 02.06.20 à 09:57, Nicolas Bétheuil a écrit :
> > Bonjour,
> >
> > Effectivement on a pas la même définition de petit : je ne vois pas
> > comment faire la 1ère étape sans monter une base OSM (ou ses données et
> > comparer point par point). Conflation dans josm ? Analyse osmose, qui va
> > devoir monter une base OSM ? Une telle analyse sur un département c'est
> > en minutes voir dizaines de minutes sur mon poste (pour voir si ça
> > tourne) du coup je trouve ça gros.
> > Quand je parlais de petit c'était des changeset fait par un humain, du
> > coup moins d'une dizaine de point par changeset au fur à mesure.
> >
> > Salutations
> > Nicolas
> >
> > Le mar. 2 juin 2020 à 06:53, Marc M.  > > a écrit :
> >
> > Bonjour,
> >
> > Le 31.05.20 à 15:27, Nicolas Bétheuil a écrit :
> > > Diviser le travail en plus petit morceaux pour pouvoir avancer.
> >
> > c'est justement ce que je proposais et qui apparemment est mal
> compris
> > 1) intégrer tous points dont la position est connue dans osm
> > pour rajouter les infos opendata (import à discuter)
> > 2a) utiliser une image "rue" pour ajouter les points inexistant
> > dans osm mais dont une photo permet de le voir (contribution
> classique)
> > 2b) utiliser un éditeur sur le terrain pour ajouter les points
> > inexistants dans osm dont on n'a pas de photo (contribution
> classique)
> >
> > mais proposer une image sat parce que la localisation
> > n'est pas bonne, c'est comme un tournevis pour un clou :
> > si on ne voit pas la borne, on ne sait pas corriger la localisation,
> > correction estimé nécessaire pour justifier la revue humaine.
> >
> > Cordialement,
> > Marc
> >
> > ___
> > 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
> >
>
>
> ___
> 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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata

2020-06-02 Par sujet Marc M. 
osmose monte en effet une base osm en local pour ses analyses.
vu que l'étape 1 n'est à faire qu'une fois, une requête overpass
sur l'étendue du jeux de donnée opendata est aussi possible.

Le 02.06.20 à 09:57, Nicolas Bétheuil a écrit :
> Bonjour,
> 
> Effectivement on a pas la même définition de petit : je ne vois pas
> comment faire la 1ère étape sans monter une base OSM (ou ses données et
> comparer point par point). Conflation dans josm ? Analyse osmose, qui va
> devoir monter une base OSM ? Une telle analyse sur un département c'est
> en minutes voir dizaines de minutes sur mon poste (pour voir si ça
> tourne) du coup je trouve ça gros.
> Quand je parlais de petit c'était des changeset fait par un humain, du
> coup moins d'une dizaine de point par changeset au fur à mesure.
> 
> Salutations
> Nicolas
> 
> Le mar. 2 juin 2020 à 06:53, Marc M.  > a écrit :
> 
> Bonjour,
> 
> Le 31.05.20 à 15:27, Nicolas Bétheuil a écrit :
> > Diviser le travail en plus petit morceaux pour pouvoir avancer.
> 
> c'est justement ce que je proposais et qui apparemment est mal compris
> 1) intégrer tous points dont la position est connue dans osm
> pour rajouter les infos opendata (import à discuter)
> 2a) utiliser une image "rue" pour ajouter les points inexistant
> dans osm mais dont une photo permet de le voir (contribution classique)
> 2b) utiliser un éditeur sur le terrain pour ajouter les points
> inexistants dans osm dont on n'a pas de photo (contribution classique)
> 
> mais proposer une image sat parce que la localisation
> n'est pas bonne, c'est comme un tournevis pour un clou :
> si on ne voit pas la borne, on ne sait pas corriger la localisation,
> correction estimé nécessaire pour justifier la revue humaine.
> 
> Cordialement,
> Marc
> 
> ___
> 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
> 


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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata

2020-06-02 Par sujet Yves P. 
> c'est justement ce que je proposais et qui apparemment est mal compris
> 1) intégrer tous points dont la position est connue dans osm
> pour rajouter les infos opendata (import à discuter)
Ok

> 2a) utiliser une image "rue" pour ajouter les points inexistant
> dans osm mais dont une photo permet de le voir (contribution classique)
Ok

> 2b) utiliser un éditeur sur le terrain pour ajouter les points
> inexistants dans osm dont on n'a pas de photo (contribution classique)
Je n'utilise pas Vepucci sur mon téléphone. Je prends des photos, des notes et 
de retour à la maison je me retrouve à point 2a)

> mais proposer une image sat parce que la localisation
> n'est pas bonne, c'est comme un tournevis pour un clou :
> si on ne voit pas la borne, on ne sait pas corriger la localisation,
> correction estimé nécessaire pour justifier la revue humaine.
Oui, tout comme avec Osmose, JOSM, iD…

Le "terrain"[1], rien que le terrain :)

__
Yves

[1] terrain "virtuel", ç.-à-d. une image "rue" (Mapillary, OpenStreetCam, tes 
photos perso…) ou terrain physique


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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata

2020-06-02 Par sujet Jacques Lavignotte 



Le 02/06/2020 à 06:53, Marc M. a écrit :


2b) utiliser un éditeur sur le terrain pour ajouter les points
inexistants dans osm dont on n'a pas de photo (contribution classique)


Allez sur place, c'est joli :

https://i.postimg.cc/hGVPjSq3/Pic-1591084380150-2.png


Cordialement,
Marc


J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata

2020-06-02 Par sujet Nicolas Bétheuil 
Bonjour,

Effectivement on a pas la même définition de petit : je ne vois pas comment
faire la 1ère étape sans monter une base OSM (ou ses données et comparer
point par point). Conflation dans josm ? Analyse osmose, qui va devoir
monter une base OSM ? Une telle analyse sur un département c'est en minutes
voir dizaines de minutes sur mon poste (pour voir si ça tourne) du coup je
trouve ça gros.
Quand je parlais de petit c'était des changeset fait par un humain, du coup
moins d'une dizaine de point par changeset au fur à mesure.

Salutations
Nicolas

Le mar. 2 juin 2020 à 06:53, Marc M.  a écrit :

> Bonjour,
>
> Le 31.05.20 à 15:27, Nicolas Bétheuil a écrit :
> > Diviser le travail en plus petit morceaux pour pouvoir avancer.
>
> c'est justement ce que je proposais et qui apparemment est mal compris
> 1) intégrer tous points dont la position est connue dans osm
> pour rajouter les infos opendata (import à discuter)
> 2a) utiliser une image "rue" pour ajouter les points inexistant
> dans osm mais dont une photo permet de le voir (contribution classique)
> 2b) utiliser un éditeur sur le terrain pour ajouter les points
> inexistants dans osm dont on n'a pas de photo (contribution classique)
>
> mais proposer une image sat parce que la localisation
> n'est pas bonne, c'est comme un tournevis pour un clou :
> si on ne voit pas la borne, on ne sait pas corriger la localisation,
> correction estimé nécessaire pour justifier la revue humaine.
>
> Cordialement,
> Marc
>
> ___
> 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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata

2020-06-01 Par sujet Marc M. 
Bonjour,

Le 31.05.20 à 15:27, Nicolas Bétheuil a écrit :
> Diviser le travail en plus petit morceaux pour pouvoir avancer.

c'est justement ce que je proposais et qui apparemment est mal compris
1) intégrer tous points dont la position est connue dans osm
pour rajouter les infos opendata (import à discuter)
2a) utiliser une image "rue" pour ajouter les points inexistant
dans osm mais dont une photo permet de le voir (contribution classique)
2b) utiliser un éditeur sur le terrain pour ajouter les points
inexistants dans osm dont on n'a pas de photo (contribution classique)

mais proposer une image sat parce que la localisation
n'est pas bonne, c'est comme un tournevis pour un clou :
si on ne voit pas la borne, on ne sait pas corriger la localisation,
correction estimé nécessaire pour justifier la revue humaine.

Cordialement,
Marc

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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

2020-05-31 Par sujet osm . sanspourriel 

Le 31/05/2020 à 10:46, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

je ne souhaite pas "nous tirer dans les pattes"
au contraire, je pense que tu poses le bon diagnostic :
un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
mais je pense étrangement ton outil n'est pas adapté pour cela.

je pense qu'il y a 3 cas :

1) les objets dont la position existe dans osm et auquel on ajoute des
infos opendata : à mon avis on n'a pas besoin d'un contributeur
qui fait un clic par objet sans aucune plus-value.
ex : il y une borne très proche dans osm et dans l'opendata.
l'opendata dit operator=A. c'est quoi la plus-value de le faire
à la main ? à mon avis on fait mieux de faire une procédure pour
importer tout cette donnée en une fois.


Non, cas des bornes 29 et 30 du SDIS17.

Une borne a été rapprochée (la 30), maintenant l'outil propose de
rapprocher la 29 et la 30.

Là il y a un soucis, je ne sais si c'est la 29 qui manquait dans OSM ou
la 30.

Mais c'est à voir sur le terrain (ou regarder à nouveau entre la 29 et
la 30 laquelle aurait dû être fusionnée avec la borne OSM).

Nicolas, ça veut dire que sur la carte tu ne devrais pas afficher que la
borne OD en cours mais aussi les autres (d'une autre forme et couleur)

Grosso modo on est d'accord : autant rapprocher automatiquement ce qu'on
peut rapprocher.

Sauf que l'outil permet aussi de gérer les conflits entre les valeurs
OSM et OD.

Il n'empêche ce serait autant de n'avoir à regarder que les conflits.


2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
bonne. ton outil ne permettant pas de voir la borne, il va falloir
ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
de n'avoir un outil ne nécessitant pas de basculer avec un autre.


Non, l'outil a maintenant l'imagerie aérienne. On peut imaginer que l'on
puisse créer une note afin que quelqu'un sur le terrain puisse chercher
la borne afin de la positionner.

Sinon oui pic4Review, etc...

Et pourquoi ne pas faire X % dans un outil et quand ce qui était
faisable dans cet outil a été fait, passer à un autre.

C'est à dire faire ce que l'on peut faire avec un outils sans en changer
puis passer à une autre outil pour la suite.

Par exemple quand on dit non rapprochable on peut dire :
- n'existe pas sur le terrain
- à chercher avec de l'imagerie de rue (pic4review)
- à chercher sur place.

Les deux derniers points sont peut-être confondus : on passe le reste à
pic4review et pour ceux pour qui on fait choux blanc on passe à la revue
sur le terrain. Et on peut mettre ça dans Osmose éventuellement.

Jean-Yvon



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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

2020-05-31 Par sujet Nicolas Bétheuil 
Effectivement c'est mon initiative.

Antonin a eu plus de facilité à utiliser mon outil pour son jeu de données.
Je ne crois pas qu'il lui avait été présenté pic4review, mais osmose ou
josm.

J'ai créé mon outil avec un premier jeu de données probablement plus adapté.

@Marc: Pour reprendre tes différents points
J'avais noté que les imports était plutôt (très) mal vue, positionnement
imprécis : ne pas mettre un borne incendie au milieu de la route par
exemple ou au milieu d'un bâtiment ...
L'interprétation de l'open data en tag OSM peut être compliqué : sur mon
jeu de données, il y a des commentaires dans lequel il y a pleins de choses
(horaires, précisions sur les livraisons ...)
Plutôt que de bloquer le traitement de tout l'import pour quelques-un, ou
d'importer n'importe quoi n'importe comment, autant compter sur
l'intelligence humaine et l'expérience des contributeurs pour traiter ces
exceptions (sur lesquel je n'ai pas assez de recul pour arbitrer, mais au
cas par cas, c'est plus simple). C'est un partit pris de l'outil.
Diviser le travail en plus petit morceaux pour pouvoir avancer.

Concernant le positionnement des points inexistant dans OSM, pour des
resto, des bars ... l'outil est suffisant. pour des bornes incendies, les
photos IGN peuvent aider. On va peut être pas pouvoir traiter les 12 000
points comme ça mais peut être 70% ? ou 20 % ?
En regardant l'autre jour pic4review, j'étais sur une missions des
coiffeurs de mémoire, à peine 50% pouvaient avoir une photo, du coup ce
n'est pas non plus "idéal".

On est d'accord que les relevés terrain sont la meilleur alternative, mais
vu le volume, si on peut déjà en traiter 50% ? Je sais pas trop.
Pour le premier jeu de données, on doit pouvoir en traiter 90% ou 95%.

Mon "positionnement" est de proposer une alternative quand un utilisateur a
du mal à embrasser la richesse de l'écosystème OSM. Peut être cela ne va
mener à rien, et on aura juste un outil de plus, et encore plus de
complexité à dans l'écosystème OSM, ou d'autres opportunités. Partir d'une
feuille blanche m'a permis de proposer autre chose, alors que je n'arrivais
à rien faire avec l'existant (mais c'est un autre sujet). En voyant une
autre manière de faire, peut être que des idées vont émergés. Au moins une
doc arbitrant les alternatives sur laquelle pouvoir se référer plutôt que
de laisser ça aux experts OSM ? Mon "rêve" est de peut être réussir à faire
autre chose avec les meilleurs énergies présentes.

Nicolas

Le dim. 31 mai 2020 à 13:26, Antonin Delpeuch (lists) <
li...@antonin.delpeuch.eu> a écrit :

> Juste pour mettre les choses au clair: il ne s'agit pas de mon outil ;)
>
> Antonin
>
> On 31/05/2020 09:46, Marc M. wrote:
> > Bonjour,
> >
> > je ne souhaite pas "nous tirer dans les pattes"
> > au contraire, je pense que tu poses le bon diagnostic :
> > un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
> > mais je pense étrangement ton outil n'est pas adapté pour cela.
> >
> > je pense qu'il y a 3 cas :
> >
> > 1) les objets dont la position existe dans osm et auquel on ajoute des
> > infos opendata : à mon avis on n'a pas besoin d'un contributeur
> > qui fait un clic par objet sans aucune plus-value.
> > ex : il y une borne très proche dans osm et dans l'opendata.
> > l'opendata dit operator=A. c'est quoi la plus-value de le faire
> > à la main ? à mon avis on fait mieux de faire une procédure pour
> > importer tout cette donnée en une fois.
> >
> > 2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
> > bonne. ton outil ne permettant pas de voir la borne, il va falloir
> > ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
> > de n'avoir un outil ne nécessitant pas de basculer avec un autre.
> >
> > 2a) si on a une photo libre de l'endroit. à ce moment là une mission
> > pic4review serrait bien adapté. encore mieux si elle peux récupérer
> > toutes les points opendata sans sortir de l'outil. histoire justement
> > de rester dans un seul outil.
> > https://pic4review.pavie.info/#/mission/copy
> > mission de type "intégrating fire hydrant"
> >
> > 2b) on n'a pas de photo libre de l'endroit. il faudra aller voir
> > sur le terrain, c'est en ce sens que Vespucci est adapté.
> > surtout qu'il permet de se connecter sur osmose, donc avoir
> > tout, tout en restant dans un seul outil.
> > il manque juste l'équivalent ios de Vespucci (dans le sens
> > un éditeur osm connectable sur osmose, afin de valider
> > la position sur le terrain)
> >
> > Cordialement,
> > Marc
> >
> >
> > Le 30.05.20 à 14:30, Antonin Delpeuch (lists) a écrit :
> >> L'outil peut être utile pour intégrer toutes sortes de jeux de données:
> >> il n'est évidemment pas conçu spécifiquement pour les PEI comme tu l'as
> >> remarqué.
> >>
> >> Dans le cas spécique des PEI, c'est utile pour un contributeur qui
> >> souhaite ajouter des métadonnées à des PEIs repérés sur le terrain,
> >> qu'ils aient déjà des nœuds correspondant dans OSM ou pas.
> >>
> >> L'absence

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

2020-05-31 Par sujet Antonin Delpeuch (lists) 
Juste pour mettre les choses au clair: il ne s'agit pas de mon outil ;)

Antonin

On 31/05/2020 09:46, Marc M. wrote:
> Bonjour,
>
> je ne souhaite pas "nous tirer dans les pattes"
> au contraire, je pense que tu poses le bon diagnostic :
> un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
> mais je pense étrangement ton outil n'est pas adapté pour cela.
>
> je pense qu'il y a 3 cas :
>
> 1) les objets dont la position existe dans osm et auquel on ajoute des
> infos opendata : à mon avis on n'a pas besoin d'un contributeur
> qui fait un clic par objet sans aucune plus-value.
> ex : il y une borne très proche dans osm et dans l'opendata.
> l'opendata dit operator=A. c'est quoi la plus-value de le faire
> à la main ? à mon avis on fait mieux de faire une procédure pour
> importer tout cette donnée en une fois.
>
> 2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
> bonne. ton outil ne permettant pas de voir la borne, il va falloir
> ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
> de n'avoir un outil ne nécessitant pas de basculer avec un autre.
>
> 2a) si on a une photo libre de l'endroit. à ce moment là une mission
> pic4review serrait bien adapté. encore mieux si elle peux récupérer
> toutes les points opendata sans sortir de l'outil. histoire justement
> de rester dans un seul outil.
> https://pic4review.pavie.info/#/mission/copy
> mission de type "intégrating fire hydrant"
>
> 2b) on n'a pas de photo libre de l'endroit. il faudra aller voir
> sur le terrain, c'est en ce sens que Vespucci est adapté.
> surtout qu'il permet de se connecter sur osmose, donc avoir
> tout, tout en restant dans un seul outil.
> il manque juste l'équivalent ios de Vespucci (dans le sens
> un éditeur osm connectable sur osmose, afin de valider
> la position sur le terrain)
>
> Cordialement,
> Marc
>
>
> Le 30.05.20 à 14:30, Antonin Delpeuch (lists) a écrit :
>> L'outil peut être utile pour intégrer toutes sortes de jeux de données:
>> il n'est évidemment pas conçu spécifiquement pour les PEI comme tu l'as
>> remarqué.
>>
>> Dans le cas spécique des PEI, c'est utile pour un contributeur qui
>> souhaite ajouter des métadonnées à des PEIs repérés sur le terrain,
>> qu'ils aient déjà des nœuds correspondant dans OSM ou pas.
>>
>> L'absence de dépendance à un éditeur externe est un gros plus pour moi,
>> car le passage répété entre les deux a un coût vraiment non-négligeable.
>>
>> Je pense que c'est bien de respecter la diversité des approches et des
>> outils, évitons de nous tirer dans les pattes…
>>
>> Antonin
>>
>> On 30/05/2020 11:21, Marc M. wrote:
>>> Bonjour,
>>>
>>> je prend mon clavier pour reposer la question tant évitée :
>>> la position est suposée mauvaise au point de ne pas vouloir d'import.
>>> et l'imagerie sat ne permet pas de voir la borne,
>>> du coup que fait le contributeur avec sa souris ?
>>>
>>> le positionement de ton outil m'échappe.
>>>
>>> Cordialement,
>>> Marc qui penche pour osmose+pic4review+vespucci
>>>
>>> Le 30.05.20 à 11:51, Nicolas Bétheuil a écrit :
 Et bah voilà 12000 points de chargé

 amis contributeur, à vos souris



 Le ven. 29 mai 2020 à 22:21, Antonin Delpeuch (lists)
 mailto:li...@antonin.delpeuch.eu>> a écrit :

 Salut Nicolas,

 Voilà la version complète:

 http://pintoch.ulminfo.fr/pei_sdis71.osm.geojson

 Antonin

 On 29/05/2020 17:07, Nicolas Bétheuil wrote:
> Les évolutions / correctifs avancent. Je pousse régulièrement.
> Écrivez moi directement, je verrais si je fais une diffusion
> spécifique pour vous gardez informé des nouveautés.
>
> Christian a ajouté od2osm au proxy IGN ! Merci !
>
> @Jean-Yvon j'ai des mails qui reviennent, les machinent veulent
> plus qu'on cause ensemble, je te propose de continuer en issue github
> @Antonin Le jeu de données que tu m'avais envoyé avait moins de 90
> points, loin des 12 000 points que tu avais évoqué.
>
> Le mer. 27 mai 2020 à 12:02, Yves P.  > a écrit :
>
>> Les "name" ont été enlevés du jeu de données et l 'outil
>> affiche maintenant soit name soit ref (en fonction de ce qui
>> existe)
>> J'ai ajouté le fond de carte BD Ortho
> Merci :)
>
>>  (j'ai laissé un mot sur le forum pour autorisé od2osm sur le
>> proxy
>> 
>> https://forum.openstreetmap.fr/viewtopic.php?f=5=4715=19681#p19681)
> ici ça marche aussi ;)
>
> Pour info, MyOSMatic (maposmatic) sort des carte
>  des PEIs :
> le résultat est plutôt bien :)
> Il faut revoir la taille des réserves incendie et des DAE, et
> éventuellement l'adapter avec les symboles utilisés en

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

2020-05-31 Par sujet Marc M. 
Bonjour,

je ne souhaite pas "nous tirer dans les pattes"
au contraire, je pense que tu poses le bon diagnostic :
un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
mais je pense étrangement ton outil n'est pas adapté pour cela.

je pense qu'il y a 3 cas :

1) les objets dont la position existe dans osm et auquel on ajoute des
infos opendata : à mon avis on n'a pas besoin d'un contributeur
qui fait un clic par objet sans aucune plus-value.
ex : il y une borne très proche dans osm et dans l'opendata.
l'opendata dit operator=A. c'est quoi la plus-value de le faire
à la main ? à mon avis on fait mieux de faire une procédure pour
importer tout cette donnée en une fois.

2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
bonne. ton outil ne permettant pas de voir la borne, il va falloir
ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
de n'avoir un outil ne nécessitant pas de basculer avec un autre.

2a) si on a une photo libre de l'endroit. à ce moment là une mission
pic4review serrait bien adapté. encore mieux si elle peux récupérer
toutes les points opendata sans sortir de l'outil. histoire justement
de rester dans un seul outil.
https://pic4review.pavie.info/#/mission/copy
mission de type "intégrating fire hydrant"

2b) on n'a pas de photo libre de l'endroit. il faudra aller voir
sur le terrain, c'est en ce sens que Vespucci est adapté.
surtout qu'il permet de se connecter sur osmose, donc avoir
tout, tout en restant dans un seul outil.
il manque juste l'équivalent ios de Vespucci (dans le sens
un éditeur osm connectable sur osmose, afin de valider
la position sur le terrain)

Cordialement,
Marc


Le 30.05.20 à 14:30, Antonin Delpeuch (lists) a écrit :
> L'outil peut être utile pour intégrer toutes sortes de jeux de données:
> il n'est évidemment pas conçu spécifiquement pour les PEI comme tu l'as
> remarqué.
> 
> Dans le cas spécique des PEI, c'est utile pour un contributeur qui
> souhaite ajouter des métadonnées à des PEIs repérés sur le terrain,
> qu'ils aient déjà des nœuds correspondant dans OSM ou pas.
> 
> L'absence de dépendance à un éditeur externe est un gros plus pour moi,
> car le passage répété entre les deux a un coût vraiment non-négligeable.
> 
> Je pense que c'est bien de respecter la diversité des approches et des
> outils, évitons de nous tirer dans les pattes…
> 
> Antonin
> 
> On 30/05/2020 11:21, Marc M. wrote:
>> Bonjour,
>>
>> je prend mon clavier pour reposer la question tant évitée :
>> la position est suposée mauvaise au point de ne pas vouloir d'import.
>> et l'imagerie sat ne permet pas de voir la borne,
>> du coup que fait le contributeur avec sa souris ?
>>
>> le positionement de ton outil m'échappe.
>>
>> Cordialement,
>> Marc qui penche pour osmose+pic4review+vespucci
>>
>> Le 30.05.20 à 11:51, Nicolas Bétheuil a écrit :
>>> Et bah voilà 12000 points de chargé
>>>
>>> amis contributeur, à vos souris
>>>
>>>
>>>
>>> Le ven. 29 mai 2020 à 22:21, Antonin Delpeuch (lists)
>>> mailto:li...@antonin.delpeuch.eu>> a écrit :
>>>
>>> Salut Nicolas,
>>>
>>> Voilà la version complète:
>>>
>>> http://pintoch.ulminfo.fr/pei_sdis71.osm.geojson
>>>
>>> Antonin
>>>
>>> On 29/05/2020 17:07, Nicolas Bétheuil wrote:
 Les évolutions / correctifs avancent. Je pousse régulièrement.
 Écrivez moi directement, je verrais si je fais une diffusion
 spécifique pour vous gardez informé des nouveautés.

 Christian a ajouté od2osm au proxy IGN ! Merci !

 @Jean-Yvon j'ai des mails qui reviennent, les machinent veulent
 plus qu'on cause ensemble, je te propose de continuer en issue github
 @Antonin Le jeu de données que tu m'avais envoyé avait moins de 90
 points, loin des 12 000 points que tu avais évoqué.

 Le mer. 27 mai 2020 à 12:02, Yves P. >>> > a écrit :

> Les "name" ont été enlevés du jeu de données et l 'outil
> affiche maintenant soit name soit ref (en fonction de ce qui
> existe)
> J'ai ajouté le fond de carte BD Ortho
 Merci :)

>  (j'ai laissé un mot sur le forum pour autorisé od2osm sur le
> proxy
> 
> https://forum.openstreetmap.fr/viewtopic.php?f=5=4715=19681#p19681)
 ici ça marche aussi ;)

 Pour info, MyOSMatic (maposmatic) sort des carte
  des PEIs :
 le résultat est plutôt bien :)
 Il faut revoir la taille des réserves incendie et des DAE, et
 éventuellement l'adapter avec les symboles utilisés en France.

 __
 Yves
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org