Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-18 Par sujet Marc M. 
Bonjour,

Le 16.04.20 à 17:45, Marc M. a écrit :
> j'ai soumis la question à legal-questi...@osmfoundation.org

J'ai eu un retour de Simon Pool sur irc (donc pas au titre
de la fondation même s'il est l'une des personne bien impliquée
sur ce genre de question).

pour lui il y a un soucis moral à utiliser une source qu'on sait entaché
par un manque de consentement envers ses utilisateurs,
mais il n'y aurait peut-être pas de problème légal.
Mais s'il venait à être confirmé qu'une seule modif a été faite
ave une source fermée (tel que GoogleMap), aucune blanchiment
de licence ne tiendrait,

Puis que problème éthique ne gène pas cro,
je laisse tomber ce point, c'est de l'énergie perdue.

Cordialement,
Marc

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-16 Par sujet Marc M. 
Bonjour,

Le 16.04.20 à 17:14, Baptiste Jonglez a écrit :
> Si je résume les avis exprimés sur la liste

j'ai soumis la question à legal-questi...@osmfoundation.org
histoire d'avoir un avis un peu plus neutre que "c'est covid19
donc c'est légal"

hélas j'imagine que cela prendra un peu de temps.

Cordialement,
Marc

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-16 Par sujet Baptiste Jonglez 
Bonjour,

Si je résume les avis exprimés sur la liste, concernant uniquement
l'intégration déjà réalisée des commentaires venant de Dokomaps :

- 2 avis "il faut revert les données déjà intégrées"
- 4 avis "il faut conserver les données déjà intégrées"

Les arguments donnés pour revert : le statut juridique n'est pas
acceptable puisqu'il manque l'accord des contributeurs originaux ;
l'intégration s'est faite de manière trop cavalière ; la licence ODbL sans
provision de future changement de licence ne permet pas d'intégrer des
données dans OSM.

Les arguments donnés pour conserver : on a bien l'accord du propriétaire
de la base de données (Dokomaps) ; ces données ont un intérêt général et
sanitaire qui justifie l'intégration malgré l'incertitude juridique ; les
données seront de toute façon effacées d'OSM à la fin de la crise.

Y a-t-il d'autres avis sur la question ?

Pour ce qui est de finir d'intégrer les données restantes, ce n'est
évidemment plus considéré, et ça n'a de toute façon plus vraiment
d'intérêt (les données sont maintenant trop vieilles).

Baptiste

On 11-04-20, Baptiste Jonglez wrote:
> Bonjour,
> 
> Tout d'abord, je n'ai pas l'impression d'avoir fermé la discussion.  Il y
> a eu une première discussion sur
> https://github.com/osmontrouge/caresteouvert/issues/81 avec des retours
> positifs (je tiens à noter que je ne suis pas l'initiateur de cette
> discussion).
> 
> Puis une seconde discussion ici, où tu as très justement pointé du doigt
> certains problèmes avec l'origine des données.  Quelques personnes ont
> participé à la discussion.  Après je suis d'accord que le début de
> l'intégration a été précipité vis-à-vis de l'annonce sur talk-fr (j'ai
> considéré à tord que les principales personnes concernées avaient déjà eu
> vent de la discussion via le ticket github, ouvert depuis plusieurs jours
> et avec de nombreux retours).
> 
> Maintenant sur les données elles-mêmes, il y a deux cas :
> 
> - les données provenant de Google (nom des POI et localisation) :
>   clairement, il n'y a pas lieu de les intégrer, ça semble faire
>   consensus.  Merci d'avoir remonté ce problème.  Aucune intégration n'a
>   été faite sur ces données.
> 
> - les données d'ouverture en temps de confinement, venant des
>   contributeurs de Dokomaps : il y a effectivement un flou sur la relation
>   entre Dokomaps et ses utilisateurs, Dokomaps aurait dû chercher de façon
>   plus explicite la permission de ses utilisateurs.  Ceci dit, il ne me
>   semble pas y avoir de consensus dans la discussion sur l'intégration de
>   ces données, ni dans un sens ni dans l'autre.  Ça ne me semble pas
>   justifié de reverter l'intégration de ces données (surtout qu'elles sont
>   généralement croisées avec des informations apportées par ailleurs par
>   des contributeurs sur çaresteouvert)
> 
> En tout cas, vu ces oppositions, j'ai désactivé les données restantes à
> intégrer sur umap (ce que j'aurais effectivement dû faire avant).
> 
> Si un consensus émerge sur la nécessité de reverter les données déjà
> intégrées, ce sera à contre-coeur mais je m'en chargerais, il n'est pas
> question que ça demande du travail à d'autres contributeurs...
> 
> Baptiste
> 
> On 11-04-20, althio wrote:
> > En l'absence de clarification complète ou d'autres éléments convaincants
> > sur le statut des données Doko Maps, leur propriété et leur licence, je
> > considère que ces données ne sont pas valables pour un ajout dans OSM.
> > 
> > La discussion avec les différents auteurs de cet ajout de données et le
> > reste de la communauté n'a pas eu lieu (en tout, pas aussi détaillée et
> > conclusive qu'on aurait pu espérer), ni ici sur talk-fr, ni sur
> > https://github.com/osmontrouge/caresteouvert/issues/81
> > 
> > J'ai fait une demande aux auteurs de cet ajout de données de reverter leurs
> > contributions, ce qui a été ignoré pour l'instant.
> > cf.
> > https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-611299417
> > 
> > Je lance donc un dernier appel sur cette liste, si quelqu'un :
> > - veut exprimer son opinion en faveur ou défaveur de la validité de ces
> > données dans OSM, et pour ou contre des reverts
> > - voire un appel à volontaires pour effectuer les reverts si les auteurs
> > initiaux ne s'en chargent pas
> > 
> > On Sat, 4 Apr 2020 at 21:52, althio  wrote:
> > 
> > > Bonjour,
> > >
> > > Merci pour le suivi, les renseignements complémentaires et la mise à jour
> > > des informations.
> > >
> > > > Alors, en regardant plus en détails, sur les deux catégories de données 
> > > > :
> > >> >
> > >> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
> > >> de
> > >> >   Terms of Services ou équivalent, donc c'est effectivement une zone
> > >> >   grise.  Je vais demander.
> > >>
> > >> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut 
> > >> considérer
> > >> qu'ils nous ont accordé une licence et que la base juridique de cet 
> > >> accord
> > >> vis-à-vis de leurs utilisateurs

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-11 Par sujet Philippe Verdy 
La cas des tags "*:covid19=*" devrait être une exception globale
acceptée du fait de la situation d'urgence et son caractère
"temporaire" (sans date de fin précise mais pas destiné à durer plus
que nécessaire).
Faire un revert massif ne posera aucun problème en fin de crise
officielle, zone par zone, mais on peut admettre que ces tags sont là
et valables pendant un an sans intervenir; ces tags ne gèneront pas
s'ils restent plus longtemps et que les restrictions sont pourtant
levées : au fur et à mesure des réouvertures générales (si le commerce
existe encore) on pourra remettre les tags classiques (mis à jour avec
les nouveaux horaires et conditions) On est déjà dans un régime légal
d'exception pour l'intérêt général.

En revanche pour tout le reste, on peut exiger les règles normales
d'attribution et licence (donc aussi pour l'ajout des POI manquants
qui passe par les "contributor terms" usuels, ce qu'on ne peut pas
faire directement dans l'appli "caresteouvert"). Je ne vois donc aucun
problème réel.


Le sam. 11 avr. 2020 à 14:17, Pierre-Olivier GREGOIRE
 a écrit :
>
> Bonjour,
>
> Étant donné que
> * les données d'ouverture sont bien en provenance des utilisateurs et non de 
> google,
> * qu'une décision assez équilibrée de compléter seulement les établissements 
> ayant déjà existé dans openstreetmap
> * qu'en plus la donnée a une portée temporaire durant le temps du confinement 
> avec un intérêt sanitaire
> * qu'on a bien l'accord du propriétaire de la base de donnée ("la personne 
> qui prend l'initiative et le risque des investissements correspondants")
> je trouve exagéré de supprimer ces données
>
> Pierre-Olivier
>
>
> Le sam. 11 avr. 2020 à 13:17, Marc M.  a écrit :
>>
>> Le 11.04.20 à 12:06, althio a écrit :
>> > Je lance donc un dernier appel sur cette liste, si quelqu'un :
>> > - veut exprimer son opinion en faveur ou défaveur de la validité de ces
>> > données dans OSM, et pour ou contre des reverts
>>
>> il y a hélas pas le choix :(
>>
>> si je met à disposition la base d'osm, mon accord pour le choix
>> d'une autre licence ne vaux rien, le choix ne m'appartient pas.
>>
>> Donc on ne peux pas intégrer des données sans licence ouverte dans osm,
>> même si le gars qui fait l’intermédiaire dit qu'il est d'accord
>>
>> la question se limite à est-ce l'auteur fait son revert lui-même
>> proprement ou il joue la montre, ce qui ne ferra qu'au
>> final un revert plus douleureux (parce que risque de perdre
>> toutes les modifs suivantes sur les objets concernés) ?
>>
>> C'est vraiement domage cette non prise en compte ce qui est
>> pourtant une des bases du projet :(
>>
>> ___
>> 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] #caresteouvert Intégration données dokomaps en opendata

2020-04-11 Par sujet Baptiste Jonglez 
Bonjour,

Tout d'abord, je n'ai pas l'impression d'avoir fermé la discussion.  Il y
a eu une première discussion sur
https://github.com/osmontrouge/caresteouvert/issues/81 avec des retours
positifs (je tiens à noter que je ne suis pas l'initiateur de cette
discussion).

Puis une seconde discussion ici, où tu as très justement pointé du doigt
certains problèmes avec l'origine des données.  Quelques personnes ont
participé à la discussion.  Après je suis d'accord que le début de
l'intégration a été précipité vis-à-vis de l'annonce sur talk-fr (j'ai
considéré à tord que les principales personnes concernées avaient déjà eu
vent de la discussion via le ticket github, ouvert depuis plusieurs jours
et avec de nombreux retours).

Maintenant sur les données elles-mêmes, il y a deux cas :

- les données provenant de Google (nom des POI et localisation) :
  clairement, il n'y a pas lieu de les intégrer, ça semble faire
  consensus.  Merci d'avoir remonté ce problème.  Aucune intégration n'a
  été faite sur ces données.

- les données d'ouverture en temps de confinement, venant des
  contributeurs de Dokomaps : il y a effectivement un flou sur la relation
  entre Dokomaps et ses utilisateurs, Dokomaps aurait dû chercher de façon
  plus explicite la permission de ses utilisateurs.  Ceci dit, il ne me
  semble pas y avoir de consensus dans la discussion sur l'intégration de
  ces données, ni dans un sens ni dans l'autre.  Ça ne me semble pas
  justifié de reverter l'intégration de ces données (surtout qu'elles sont
  généralement croisées avec des informations apportées par ailleurs par
  des contributeurs sur çaresteouvert)

En tout cas, vu ces oppositions, j'ai désactivé les données restantes à
intégrer sur umap (ce que j'aurais effectivement dû faire avant).

Si un consensus émerge sur la nécessité de reverter les données déjà
intégrées, ce sera à contre-coeur mais je m'en chargerais, il n'est pas
question que ça demande du travail à d'autres contributeurs...

Baptiste

On 11-04-20, althio wrote:
> En l'absence de clarification complète ou d'autres éléments convaincants
> sur le statut des données Doko Maps, leur propriété et leur licence, je
> considère que ces données ne sont pas valables pour un ajout dans OSM.
> 
> La discussion avec les différents auteurs de cet ajout de données et le
> reste de la communauté n'a pas eu lieu (en tout, pas aussi détaillée et
> conclusive qu'on aurait pu espérer), ni ici sur talk-fr, ni sur
> https://github.com/osmontrouge/caresteouvert/issues/81
> 
> J'ai fait une demande aux auteurs de cet ajout de données de reverter leurs
> contributions, ce qui a été ignoré pour l'instant.
> cf.
> https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-611299417
> 
> Je lance donc un dernier appel sur cette liste, si quelqu'un :
> - veut exprimer son opinion en faveur ou défaveur de la validité de ces
> données dans OSM, et pour ou contre des reverts
> - voire un appel à volontaires pour effectuer les reverts si les auteurs
> initiaux ne s'en chargent pas
> 
> On Sat, 4 Apr 2020 at 21:52, althio  wrote:
> 
> > Bonjour,
> >
> > Merci pour le suivi, les renseignements complémentaires et la mise à jour
> > des informations.
> >
> > > Alors, en regardant plus en détails, sur les deux catégories de données :
> >> >
> >> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
> >> de
> >> >   Terms of Services ou équivalent, donc c'est effectivement une zone
> >> >   grise.  Je vais demander.
> >>
> >> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut considérer
> >> qu'ils nous ont accordé une licence et que la base juridique de cet accord
> >> vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr que c'est
> >> problématique.  Dans ce cas particulier, vu la situation et le caractère
> >> d'utilité publique de ces données, je ne pense pas qu'il faille bloquer /
> >> reverter le travail d'import pour autant.
> >>
> >
> > Tu ne le penses pas, certes, mais il faudrait demander à la communauté,
> > voire demander des conseils de manière plus large (liste
> > impo...@openstreetmap.org, Data WG, Legal WG...).
> >
> > "Du point de vue d'OSM, on peut considérer qu'ils nous ont accordé une
> > licence et que la base juridique de cet accord vis-à-vis de leurs
> > utilisateurs les regarde"
> > C'est un peu cavalier, ça ressemble à du recel : la donnée n'a pas de
> > licence valable, on le sait, mais on la garde quand même.
> > D'autre part, si on veut intégrer dans OSM, la licence et la base
> > juridique nous regarde aussi, beaucoup.
> > OpenStreetMap est un projet collaboratif international avec des valeurs,
> > un partage des données, un partage des méthodes, et un certain partage des
> > risques.
> > Ce n'est pas une start-up qui bidouille dans son coin pour son propre
> > compte.
> >
> > Pour ma part, je pense que cette source de données est un bien faible
> > gain, au regard des conditions problématiques.
> > Pour ce qui est de bloquer ou d'annuler les

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-11 Par sujet Pierre-Olivier GREGOIRE 
Bonjour,

Étant donné que
* les données d'ouverture sont bien en provenance des utilisateurs et non
de google,
* qu'une décision assez équilibrée de compléter seulement les
établissements ayant déjà existé dans openstreetmap
* qu'en plus la donnée a une portée temporaire durant le temps du
confinement avec un intérêt sanitaire
* qu'on a bien l'accord du propriétaire de la base de donnée ("la personne
qui prend l'initiative et le risque des investissements correspondants")
je trouve exagéré de supprimer ces données

Pierre-Olivier


Le sam. 11 avr. 2020 à 13:17, Marc M.  a écrit :

> Le 11.04.20 à 12:06, althio a écrit :
> > Je lance donc un dernier appel sur cette liste, si quelqu'un :
> > - veut exprimer son opinion en faveur ou défaveur de la validité de ces
> > données dans OSM, et pour ou contre des reverts
>
> il y a hélas pas le choix :(
>
> si je met à disposition la base d'osm, mon accord pour le choix
> d'une autre licence ne vaux rien, le choix ne m'appartient pas.
>
> Donc on ne peux pas intégrer des données sans licence ouverte dans osm,
> même si le gars qui fait l’intermédiaire dit qu'il est d'accord
>
> la question se limite à est-ce l'auteur fait son revert lui-même
> proprement ou il joue la montre, ce qui ne ferra qu'au
> final un revert plus douleureux (parce que risque de perdre
> toutes les modifs suivantes sur les objets concernés) ?
>
> C'est vraiement domage cette non prise en compte ce qui est
> pourtant une des bases du projet :(
>
> ___
> 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] #caresteouvert Intégration données dokomaps en opendata

2020-04-11 Par sujet Marc M. 
Le 11.04.20 à 12:06, althio a écrit :
> Je lance donc un dernier appel sur cette liste, si quelqu'un :
> - veut exprimer son opinion en faveur ou défaveur de la validité de ces
> données dans OSM, et pour ou contre des reverts

il y a hélas pas le choix :(

si je met à disposition la base d'osm, mon accord pour le choix
d'une autre licence ne vaux rien, le choix ne m'appartient pas.

Donc on ne peux pas intégrer des données sans licence ouverte dans osm,
même si le gars qui fait l’intermédiaire dit qu'il est d'accord

la question se limite à est-ce l'auteur fait son revert lui-même
proprement ou il joue la montre, ce qui ne ferra qu'au
final un revert plus douleureux (parce que risque de perdre
toutes les modifs suivantes sur les objets concernés) ?

C'est vraiement domage cette non prise en compte ce qui est
pourtant une des bases du projet :(

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-11 Par sujet althio 
En l'absence de clarification complète ou d'autres éléments convaincants
sur le statut des données Doko Maps, leur propriété et leur licence, je
considère que ces données ne sont pas valables pour un ajout dans OSM.

La discussion avec les différents auteurs de cet ajout de données et le
reste de la communauté n'a pas eu lieu (en tout, pas aussi détaillée et
conclusive qu'on aurait pu espérer), ni ici sur talk-fr, ni sur
https://github.com/osmontrouge/caresteouvert/issues/81

J'ai fait une demande aux auteurs de cet ajout de données de reverter leurs
contributions, ce qui a été ignoré pour l'instant.
cf.
https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-611299417

Je lance donc un dernier appel sur cette liste, si quelqu'un :
- veut exprimer son opinion en faveur ou défaveur de la validité de ces
données dans OSM, et pour ou contre des reverts
- voire un appel à volontaires pour effectuer les reverts si les auteurs
initiaux ne s'en chargent pas

On Sat, 4 Apr 2020 at 21:52, althio  wrote:

> Bonjour,
>
> Merci pour le suivi, les renseignements complémentaires et la mise à jour
> des informations.
>
> > Alors, en regardant plus en détails, sur les deux catégories de données :
>> >
>> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
>> de
>> >   Terms of Services ou équivalent, donc c'est effectivement une zone
>> >   grise.  Je vais demander.
>>
>> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut considérer
>> qu'ils nous ont accordé une licence et que la base juridique de cet accord
>> vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr que c'est
>> problématique.  Dans ce cas particulier, vu la situation et le caractère
>> d'utilité publique de ces données, je ne pense pas qu'il faille bloquer /
>> reverter le travail d'import pour autant.
>>
>
> Tu ne le penses pas, certes, mais il faudrait demander à la communauté,
> voire demander des conseils de manière plus large (liste
> impo...@openstreetmap.org, Data WG, Legal WG...).
>
> "Du point de vue d'OSM, on peut considérer qu'ils nous ont accordé une
> licence et que la base juridique de cet accord vis-à-vis de leurs
> utilisateurs les regarde"
> C'est un peu cavalier, ça ressemble à du recel : la donnée n'a pas de
> licence valable, on le sait, mais on la garde quand même.
> D'autre part, si on veut intégrer dans OSM, la licence et la base
> juridique nous regarde aussi, beaucoup.
> OpenStreetMap est un projet collaboratif international avec des valeurs,
> un partage des données, un partage des méthodes, et un certain partage des
> risques.
> Ce n'est pas une start-up qui bidouille dans son coin pour son propre
> compte.
>
> Pour ma part, je pense que cette source de données est un bien faible
> gain, au regard des conditions problématiques.
> Pour ce qui est de bloquer ou d'annuler les contributions déjà
> effectuée... c'est sûr que c'est maintenant compliqué, il aurait été plus
> facile de prendre son temps et de tirer les choses au clair avant
> d'intégrer les données.
>
> "vu la situation et le caractère d'utilité publique de ces données" n'est
> pas un argument recevable pour justifier d'un ajout de données
> problématique.
>
> La conflation des données s'appuie toujours - je suppose - sur les données
> initiales (nom, localisation, ...).
> Il y a une tolérance du côté d'OSM pour permettre cela à d'autres
> utilisateurs vers d'autres bases.
> Je ne pense pas que cela soit autorisé aussi clairement par Google pour
> ses services et données.
>
> Franchement, avec ou sans conflation, la problématique est peut-être la
> même. Ces données sont teintées Google Maps, nous ne devrions pas y toucher
> - à mon avis - pour compléter OSM.
>
> Et vous devriez arrêter cette contribution, avec ou sans conflation, pour
> étudier proprement la question, arriver à un consensus sur la démarche à
> suivre, et l'appliquer.
>
> - althio
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-04 Par sujet althio 
Bonjour,

Merci pour le suivi, les renseignements complémentaires et la mise à jour
des informations.

> Alors, en regardant plus en détails, sur les deux catégories de données :
> >
> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
> de
> >   Terms of Services ou équivalent, donc c'est effectivement une zone
> >   grise.  Je vais demander.
>
> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut considérer
> qu'ils nous ont accordé une licence et que la base juridique de cet accord
> vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr que c'est
> problématique.  Dans ce cas particulier, vu la situation et le caractère
> d'utilité publique de ces données, je ne pense pas qu'il faille bloquer /
> reverter le travail d'import pour autant.
>

Tu ne le penses pas, certes, mais il faudrait demander à la communauté,
voire demander des conseils de manière plus large (liste
impo...@openstreetmap.org, Data WG, Legal WG...).

"Du point de vue d'OSM, on peut considérer qu'ils nous ont accordé une
licence et que la base juridique de cet accord vis-à-vis de leurs
utilisateurs les regarde"
C'est un peu cavalier, ça ressemble à du recel : la donnée n'a pas de
licence valable, on le sait, mais on la garde quand même.
D'autre part, si on veut intégrer dans OSM, la licence et la base juridique
nous regarde aussi, beaucoup.
OpenStreetMap est un projet collaboratif international avec des valeurs, un
partage des données, un partage des méthodes, et un certain partage des
risques.
Ce n'est pas une start-up qui bidouille dans son coin pour son propre
compte.

Pour ma part, je pense que cette source de données est un bien faible gain,
au regard des conditions problématiques.
Pour ce qui est de bloquer ou d'annuler les contributions déjà effectuée...
c'est sûr que c'est maintenant compliqué, il aurait été plus facile de
prendre son temps et de tirer les choses au clair avant d'intégrer les
données.

"vu la situation et le caractère d'utilité publique de ces données" n'est
pas un argument recevable pour justifier d'un ajout de données
problématique.

La conflation des données s'appuie toujours - je suppose - sur les données
initiales (nom, localisation, ...).
Il y a une tolérance du côté d'OSM pour permettre cela à d'autres
utilisateurs vers d'autres bases.
Je ne pense pas que cela soit autorisé aussi clairement par Google pour ses
services et données.

Franchement, avec ou sans conflation, la problématique est peut-être la
même. Ces données sont teintées Google Maps, nous ne devrions pas y toucher
- à mon avis - pour compléter OSM.

Et vous devriez arrêter cette contribution, avec ou sans conflation, pour
étudier proprement la question, arriver à un consensus sur la démarche à
suivre, et l'appliquer.

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-04 Par sujet Baptiste Jonglez 
On 04-04-20, Baptiste Jonglez wrote:
> Alors, en regardant plus en détails, sur les deux catégories de données :
> 
> - données des contributeurs (commentaire) : je n'ai pas trouvé non plus de
>   Terms of Services ou équivalent, donc c'est effectivement une zone
>   grise.  Je vais demander.

Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut considérer
qu'ils nous ont accordé une licence et que la base juridique de cet accord
vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr que c'est
problématique.  Dans ce cas particulier, vu la situation et le caractère
d'utilité publique de ces données, je ne pense pas qu'il faille bloquer /
reverter le travail d'import pour autant.

> - données des POIs (nom, adresse, localisation) : effectivement, après
>   vérification, ça a bien l'air de venir de Google :((  malgré les
>   assurances de l'éditeur que les données sont « sans aucune donnees
>   Google »...

C'est confirmé que ça vient de Google, donc on laisse tomber l'import des
points non-rapprochés par la conflation.

J'ai mis à jour https://wiki.openstreetmap.org/wiki/France/Covid-19/Imports
avec ces deux informations.

> Pour l'instant on intègre seulement les données que j'ai pu rapprocher
> avec OSM, donc on exploite uniquement le commentaire (on garde le nom et
> localisation existant dans OSM).
> 
> Par contre, pour les données non-rapprochées avec OSM, les intégrer
> reviendrait à se baser sur des données Google pour le nom et la
> localisation.  Je vais donc supprimer ces données, merci de ta
> vigilance...


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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-04 Par sujet Baptiste Jonglez 
Hello,

On 03-04-20, althio wrote:
> D'abord, en mode TL;DR, un résumé pour le cas présent :
> 
> Les points d'améliorations pour cette intégration/import et les suivantes :
> 
> 1. Clarifier la situation juridique
> 1a. Avoir une certitude sur la provenance et la propriété des données
> 1b. Un lien vers la licence, sur une page ou un courrier sans ambiguïté et
> avec une bonne valeur juridique.
> 
> 2. Ne pas faire l'annonce de la volonté d'import et le début de l'import le
> même jour.
> 2a. Attendre plus longtemps, plus que quelques heures, pour recueillir les
> commentaires sur le principe (validation de la licence, qualité des
> données, ...).
> 2b. Attendre plus longtemps, pour recueillir les commentaires sur les
> procédures détaillées (choix des tags...)

Merci du retour, c'est vrai que ça a été un peu vite (une discussion a
bien eu lieu en amont sur le github de çaresteouvert, mais n'implique pas
toute la communauté)

> > On a eu une proposition d'intégration de données d'une autre carte
> > collaborative, sous licence Open Database License
> 
> 
> (souvent contribuée par les propriétaires eux-mêmes).
> 
> 
> 
> 1. Attention, ce n'est pas intuitif, mais la compatibilité d'une licence
> ODbL est un peu grise pour l'ajout dans OSM.
> cf. https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility
> cf. https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility

Euh, j'avoue que ça me dépasse.

> 2. Où est disponible publiquement la licence des données externes ? Un
> lien, une copie sur le wiki OSM ?
> On a seulement :
> https://wiki.openstreetmap.org/wiki/France/Covid-19/Imports
> qui pointe vers
> https://github.com/osmontrouge/caresteouvert/issues/81
> où en fouillant on peut trouver
> https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-606699637
> C'est un peu bancal et assez informel comme manière de partager de la
> donnée et sa licence.

J'ai exporté l'accord ici : 
https://wiki.openstreetmap.org/wiki/France/Covid-19/Imports#Situation_juridique

> De plus j'ai un doute sur la clarté de la propriété de la donnée, entre les
> éditeurs/contributeurs, la plateforme, les services tiers.
> 
> Est-ce que, en plus de la licence sur les données par Doko Maps, il existe
> un accord/termes des contributeurs sur le site Doko Maps, qui signifie sous
> quelles conditions et licence les personnes participent ? (Je n'ai pas
> trouvé).
> 
> Sachant que pour ne rien arranger, Doko Maps utilise aussi Google pour
> certains données, il me semble potentiellement dangereux d'utiliser ces
> données alors certaines ont été géocodées avec les services Google Maps.

Alors, en regardant plus en détails, sur les deux catégories de données :

- données des contributeurs (commentaire) : je n'ai pas trouvé non plus de
  Terms of Services ou équivalent, donc c'est effectivement une zone
  grise.  Je vais demander.

- données des POIs (nom, adresse, localisation) : effectivement, après
  vérification, ça a bien l'air de venir de Google :((  malgré les
  assurances de l'éditeur que les données sont « sans aucune donnees
  Google »...

Pour l'instant on intègre seulement les données que j'ai pu rapprocher
avec OSM, donc on exploite uniquement le commentaire (on garde le nom et
localisation existant dans OSM).

Par contre, pour les données non-rapprochées avec OSM, les intégrer
reviendrait à se baser sur des données Google pour le nom et la
localisation.  Je vais donc supprimer ces données, merci de ta
vigilance...

> Est-ce que les règles d'import automatique [1] s'appliquent, sachant que
> > ce n'est que semi-automatique et que les données seront intégrées
> > manuellement par plusieurs contributeurs ?
> >
> 
> Oui, c'est comme ça que je le perçois.
> Attention à la confusion entre "import" et "automatique".
> 
> Une opération avec des données externes doit suivre les règles d'import au
> mieux (même si l'édition est manuelle ou semi-automatique).
> https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines
> https://wiki.openstreetmap.org/wiki/Import/Guidelines
> 
> Il existe aussi des règles pour les modifications automatisées, qui
> couvrent d'autres précautions.
> https://wiki.openstreetmap.org/wiki/FR:Code_de_conduite_des_modifications_automatis%C3%A9es
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> 
> Quand quelqu'un prépare un "import plan (en)" (idéalement pour tout ajout
> des données provenant d'une source externe, il est demandé de le partager
> sur avec la communauté locale, puis avec la communauté internationale sur
> la liste dédiée).
> C'est dans beaucoup de cas pour une intégration à plusieurs personnes, avec
> une revue des données en amont ou au fur et à mesure.
> Si quelqu'un présente un plan d'import/intégration sans revue des données,
> ce n'est pas acceptable. La notion d'automatisme est à prendre à part.
> 
> On peut par exemple nettoyer les données en amont jusqu'à la qualité
> correcte pour OSM et ensuite ajouter les données de manière automatisée.
> 
>

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-03 Par sujet althio 


> Bonjour,
>

Bonjour,

D'abord, en mode TL;DR, un résumé pour le cas présent :

Les points d'améliorations pour cette intégration/import et les suivantes :

1. Clarifier la situation juridique
1a. Avoir une certitude sur la provenance et la propriété des données
1b. Un lien vers la licence, sur une page ou un courrier sans ambiguïté et
avec une bonne valeur juridique.

2. Ne pas faire l'annonce de la volonté d'import et le début de l'import le
même jour.
2a. Attendre plus longtemps, plus que quelques heures, pour recueillir les
commentaires sur le principe (validation de la licence, qualité des
données, ...).
2b. Attendre plus longtemps, pour recueillir les commentaires sur les
procédures détaillées (choix des tags...)

--- FIN du TL;DR

Mon intention n'est pas de vous arrêter dans cet ajout de données, juste
faire quelques commentaires ou remarques et demander des précisions, et
s'améliorer pour les prochaines fois.


> On a eu une proposition d'intégration de données d'une autre carte
> collaborative, sous licence Open Database License


(souvent contribuée par les propriétaires eux-mêmes).



1. Attention, ce n'est pas intuitif, mais la compatibilité d'une licence
ODbL est un peu grise pour l'ajout dans OSM.
cf. https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility
cf. https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility

2. Où est disponible publiquement la licence des données externes ? Un
lien, une copie sur le wiki OSM ?
On a seulement :
https://wiki.openstreetmap.org/wiki/France/Covid-19/Imports
qui pointe vers
https://github.com/osmontrouge/caresteouvert/issues/81
où en fouillant on peut trouver
https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-606699637
C'est un peu bancal et assez informel comme manière de partager de la
donnée et sa licence.

De plus j'ai un doute sur la clarté de la propriété de la donnée, entre les
éditeurs/contributeurs, la plateforme, les services tiers.

Est-ce que, en plus de la licence sur les données par Doko Maps, il existe
un accord/termes des contributeurs sur le site Doko Maps, qui signifie sous
quelles conditions et licence les personnes participent ? (Je n'ai pas
trouvé).

Sachant que pour ne rien arranger, Doko Maps utilise aussi Google pour
certains données, il me semble potentiellement dangereux d'utiliser ces
données alors certaines ont été géocodées avec les services Google Maps.


Avant ça, est-ce qu'il y a une opposition sur le principe ?  Comment
> visibiliser la source ? (tag "source", commentaire sur le changeset...)
>

tag source sur le changeset, avec une page ou un lien qui permet de trouver
au minimum la licence d'origine et si possible la description du plan
d'ajout des données.


Est-ce que les règles d'import automatique [1] s'appliquent, sachant que
> ce n'est que semi-automatique et que les données seront intégrées
> manuellement par plusieurs contributeurs ?
>

Oui, c'est comme ça que je le perçois.
Attention à la confusion entre "import" et "automatique".

Une opération avec des données externes doit suivre les règles d'import au
mieux (même si l'édition est manuelle ou semi-automatique).
https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines
https://wiki.openstreetmap.org/wiki/Import/Guidelines

Il existe aussi des règles pour les modifications automatisées, qui
couvrent d'autres précautions.
https://wiki.openstreetmap.org/wiki/FR:Code_de_conduite_des_modifications_automatis%C3%A9es
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

Quand quelqu'un prépare un "import plan (en)" (idéalement pour tout ajout
des données provenant d'une source externe, il est demandé de le partager
sur avec la communauté locale, puis avec la communauté internationale sur
la liste dédiée).
C'est dans beaucoup de cas pour une intégration à plusieurs personnes, avec
une revue des données en amont ou au fur et à mesure.
Si quelqu'un présente un plan d'import/intégration sans revue des données,
ce n'est pas acceptable. La notion d'automatisme est à prendre à part.

On peut par exemple nettoyer les données en amont jusqu'à la qualité
correcte pour OSM et ensuite ajouter les données de manière automatisée.

On peut choisir de ne pas agir avec un bot automatique, mais avec des
contributions revues individuellement.

En tout cas, de mon point de vue, le choix de faire par une méthode
automatique ou manuelle est un point séparé, avec des vérifications et
contraintes à part.

Il reste que, quand on ajoute des données de sources externes, il est
fortement recommandé de respecter les guides et règles d'import,
indépendamment du niveau d'automatisme. Certaines communautés diront que
c'est absolument obligatoire.

Il faut quand même détailler la procédure pour les contributeurs de
l'intégration, afin de savoir comment les données doivent être vérifiées,
et pour les observateurs et futurs contributeurs, afin de savoir comment
les données ont été vérifiées.
Je pense ça correspond avec ton idée initiale ("je

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata, étape 1 : contributions bienvenues !

2020-04-02 Par sujet Baptiste Jonglez 
On 02-04-20, Yves P. wrote:
> 
> > C'est parti, si vous souhaitez contribuer en mettant à jour les
> > informations d'ouverture, toutes les informations sont ici :
> > 
> >  
> > https://wiki.openstreetmap.org/wiki/France/Covid-19/Imports#Int.C3.A9gration_dokomaps
> 
> J’ai regardé un POI  mais en 
> cliquant dessus je reste perplexe :
> 
> Un lien vers le POI sous OSM et/ou JOSM serait pratique :)

En effet, peut-être que c'est possible avec umap ?

En pratique je charge la zone dans JOSM et j'utilise la recherche sur le
nom du POI.

> Qu’est-ce qu’on doit rajouter ici ?
> "note:address"="118 Rue de Genève, 74240 Gaillard, France"
> "note:city"=Gaillard
> "note:name"=Spar
> 
> Quel est l’intérêt de rajouter ces notes ? Les tags déjà renseignés sont 
> suffisant ?

Ce sont les données provenant du jeu de données, que je visibilise comme
ça pour pouvoir comparer aux tags OSM et vérifier que la conflation ne
s'est pas trompée.  Le but n'est évidemment pas d'intégrer ces notes dans
l'objet OSM.

> Je n’ai rien compris, ou bien ??

Non c'est sûrement normal, je débute en intégration de données...

Cet objet en particulier a beaucoup de tags existants donc en plus ces
"faux-tags" sont un peu noyés dans la masse.

> __
> Yves
> actionmodify
> marker-color  #ee
> osm_id200400323
> osm_type  way
> ref_distance  18.5
> ref_id5
> tags.addr:cityGaillard
> tags.addr:housenumber 118
> tags.addr:postcode74240
> tags.addr:street  Rue de Genève
> tags.brand:wikidata   Q610492
> tags.building retail
> tags.building:levels  1
> tags.contact:phone+33 4 50 38 80 40
> tags.contact:website  https://magasins.spar.fr/fr/s/spar-supermarche-gaillard 
> 
> tags.name Spar
> tags.opening_hoursMo-Sa 08:30-20:00; Su 08:30-12:15
> tags.operator Spar
> tags.shop supermarket
> tags.source   Bing;Orthophotos 2011 du SITG (Système d'Information du 
> Territoire Genevois)
> tags.wheelchair   yes
> tags_new.note:address 118 Rue de Genève, 74240 Gaillard, France
> tags_new.note:cityGaillard
> tags_new.note:comment Supermarché de quartier
> tags_new.note:nameSpar
> 

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



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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata, étape 1 : contributions bienvenues !

2020-04-02 Par sujet Yves P. 

> C'est parti, si vous souhaitez contribuer en mettant à jour les
> informations d'ouverture, toutes les informations sont ici :
> 
>  
> https://wiki.openstreetmap.org/wiki/France/Covid-19/Imports#Int.C3.A9gration_dokomaps

J’ai regardé un POI  mais en 
cliquant dessus je reste perplexe :

Un lien vers le POI sous OSM et/ou JOSM serait pratique :)
Qu’est-ce qu’on doit rajouter ici ?

"note:address"="118 Rue de Genève, 74240 Gaillard, France"
"note:city"=Gaillard
"note:name"=Spar

Quel est l’intérêt de rajouter ces notes ? Les tags déjà renseignés sont 
suffisant ?
Je n’ai rien compris, ou bien ??

__
Yves
action  modify
marker-color#ee
osm_id  200400323
osm_typeway
ref_distance18.5
ref_id  5
tags.addr:city  Gaillard
tags.addr:housenumber   118
tags.addr:postcode  74240
tags.addr:streetRue de Genève
tags.brand:wikidata Q610492
tags.building   retail
tags.building:levels1
tags.contact:phone  +33 4 50 38 80 40
tags.contact:websitehttps://magasins.spar.fr/fr/s/spar-supermarche-gaillard 

tags.name   Spar
tags.opening_hours  Mo-Sa 08:30-20:00; Su 08:30-12:15
tags.operator   Spar
tags.shop   supermarket
tags.source Bing;Orthophotos 2011 du SITG (Système d'Information du 
Territoire Genevois)
tags.wheelchair yes
tags_new.note:address   118 Rue de Genève, 74240 Gaillard, France
tags_new.note:city  Gaillard
tags_new.note:comment   Supermarché de quartier
tags_new.note:name  Spar

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata, étape 1 : contributions bienvenues !

2020-04-02 Par sujet Baptiste Jonglez 
Bonjour,

C'est parti, si vous souhaitez contribuer en mettant à jour les
informations d'ouverture, toutes les informations sont ici :

  
https://wiki.openstreetmap.org/wiki/France/Covid-19/Imports#Int.C3.A9gration_dokomaps

Il y a 27 zones, et l'idée est de se répartir le travail sur la base de
ces zones (en me prévenant soit par mail, soit sur le ticket github
mentionné ci-dessous).

On fera la deuxième partie (ajout des POI manquants) dans un second temps
pour ne pas mélanger.

Merci,
Baptiste

On 02-04-20, Baptiste Jonglez wrote:
> Bonjour,
> 
> On a eu une proposition d'intégration de données d'une autre carte
> collaborative, sous licence Open Database License, cf. ce ticket :
> 
>   https://github.com/osmontrouge/caresteouvert/issues/81
> 
> C'est intéressant parce que c'est de la donnée récente et a priori assez
> fiable (souvent contribuée par les propriétaires eux-mêmes).  À court
> terme, ça permet d'enrichir les horaires d'ouvertures pendant le
> confinement, et à long terme ça permet d'ajouter des POI manquants à
> OpenStreetMap.
> 
> J'ai utilisé osm_conflate pour recouper les données avec OSM, le code et
> les données sont ici : https://github.com/zorun/integration-osm-covid19
> C'est pas toujours très propre, c'est ma première conflation et les
> données sont parfois difficiles à exploiter...
> 
> J'obtiens 221 POIs rapprochés (avec quelques faux positifs) et 387 POIs
> non rapprochés (avec sûrement quelques faux négatifs).  Évidemment je n'ai
> rien importé automatiquement dans OSM, il faut de toute façon repasser sur
> chaque point pour structurer la donnée.
> 
> Je propose de se coordonner par secteur pour intégrer ces données.  Ça
> tombe bien, les données sont déjà organisées par ville.  En passant par
> des layers umap + JOSM ça peut fonctionner, je détaillerai une idée de
> processus quand on sera d'accord sur le principe.
> 
> Avant ça, est-ce qu'il y a une opposition sur le principe ?  Comment
> visibiliser la source ? (tag "source", commentaire sur le changeset...)
> Est-ce que les règles d'import automatique [1] s'appliquent, sachant que
> ce n'est que semi-automatique et que les données seront intégrées
> manuellement par plusieurs contributeurs ?
> 
> Merci,
> Baptiste
> 
> [1] https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines



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



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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-02 Par sujet Marc M. 
Le 02.04.20 à 16:08, Baptiste Jonglez a écrit :
> On 02-04-20, Marc M. wrote:

>> PS: ne pas oublier qu'osmose propose l'intégration sirene..
>> il y a surement déjà une partie de ces POI facile à intégrer sans rien
>> coder d'autre que ouvrir osmose avec l'url de la localisation
> 
> Tu aurais un lien ou de la documentation sur cette intégration SIRENE ?
> 
> Je pense avoir tout activé mais je ne vois rien qui y ressemble :
> 
> http://osmose.openstreetmap.fr/en/map/#zoom=17=45.745975=4.933762==1%2C2%2C3==

c'est en dev, caché :)
https://github.com/osm-fr/osmose-backend/pull/338#issuecomment-504931161
https://osmose.openstreetmap.fr/fr/errors/?item=8310=all
http://osmose.openstreetmap.fr/fr/map/#item=8310=all

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-02 Par sujet Baptiste Jonglez 
On 02-04-20, Marc M. wrote:
> Bonjour,
> 
> Le 02.04.20 à 13:45, Baptiste Jonglez a écrit :
> > il y a une opposition sur le principe ?
> 
> sur le principe, je suis totalement pour.
> encore plus si on averti les contributeurs initiaux
> de où "vont" leur donnée afin qu'ils puissent à l'avenir
> mettre eux-même à jour, afin d'éviter d'avoir une bdd
> a garder à synchroniser dans les 2 sens, ce qui est mauvais
> pour tout le monde

En effet !

> > Comment visibiliser la source ? (tag "source", commentaire sur le 
> > changeset...)
> sur le changeset:
> commmentaire = intégration donnée DokoMaps
> source=opendata DokoMaps
> source:url=https://dokomaps.com/...

Ok, merci.

> > Est-ce que les règles d'import automatique [1] s'appliquent, sachant que
> > ce n'est que semi-automatique et que les données seront intégrées
> > manuellement par plusieurs contributeurs ?
> 
> cela dépend du volume et de l'importance des critères conflate.
> importer des milliers d'objets même si chacun n'en fait qu'un,
> reste un import.
> par contre, si on passe en revue chaque objet, c'est une intégration
> (comme on est supposé le faire via osmose ou pour le cadastre)
> 
> j'aurais tendance à diviser le tas en 2 :
> - ceux que tu peux rapprocher "parfaitement" (y compris avec un rayon
> maxi assez limité). ce serra vite vérifié manuellement et on en parle
> plus :)

Oui, c'est l'idée pour les 221 POI rapprochés, c'est pas parfait mais j'ai
essayé de limiter le plus possibles les faux positifs (match partiel sur
le nom, et rayon de 30 mètres maxi).

L'idée serait de mettre tout les POI rapprochés sur un umap pour
visualiser, groupé par zone.  Chaque contributeur déclare qu'il traite une
zone et charge le geojson dans une couche sur JOSM pour identifier les
points, ensuite il met à jour la donnée OSM à partir du commentaire (sur
umap ou dans la couche JOSM).

Si il y a plus efficace je suis preneur...

> - les autres... c'est p'tre pas motivant de demander un import pour un
> si petit nombre. alors j'aurais tendance à voir si on peux pas faire
> de l'intégration (vérifier visuellement la position sur la carte,
> regarder un doublon qui ne serrait pas rapproché à cause d'une typo
> PS: ne pas oublier qu'osmose propose l'intégration sirene..
> il y a surement déjà une partie de ces POI facile à intégrer sans rien
> coder d'autre que ouvrir osmose avec l'url de la localisation

Tu aurais un lien ou de la documentation sur cette intégration SIRENE ?

Je pense avoir tout activé mais je ne vois rien qui y ressemble :

http://osmose.openstreetmap.fr/en/map/#zoom=17=45.745975=4.933762==1%2C2%2C3==

Merci,
Baptiste


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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-02 Par sujet Marc M. 
Bonjour,

Le 02.04.20 à 13:45, Baptiste Jonglez a écrit :
> il y a une opposition sur le principe ?

sur le principe, je suis totalement pour.
encore plus si on averti les contributeurs initiaux
de où "vont" leur donnée afin qu'ils puissent à l'avenir
mettre eux-même à jour, afin d'éviter d'avoir une bdd
a garder à synchroniser dans les 2 sens, ce qui est mauvais
pour tout le monde

> Comment visibiliser la source ? (tag "source", commentaire sur le 
> changeset...)
sur le changeset:
commmentaire = intégration donnée DokoMaps
source=opendata DokoMaps
source:url=https://dokomaps.com/...

> Est-ce que les règles d'import automatique [1] s'appliquent, sachant que
> ce n'est que semi-automatique et que les données seront intégrées
> manuellement par plusieurs contributeurs ?

cela dépend du volume et de l'importance des critères conflate.
importer des milliers d'objets même si chacun n'en fait qu'un,
reste un import.
par contre, si on passe en revue chaque objet, c'est une intégration
(comme on est supposé le faire via osmose ou pour le cadastre)

j'aurais tendance à diviser le tas en 2 :
- ceux que tu peux rapprocher "parfaitement" (y compris avec un rayon
maxi assez limité). ce serra vite vérifié manuellement et on en parle
plus :)
- les autres... c'est p'tre pas motivant de demander un import pour un
si petit nombre. alors j'aurais tendance à voir si on peux pas faire
de l'intégration (vérifier visuellement la position sur la carte,
regarder un doublon qui ne serrait pas rapproché à cause d'une typo
PS: ne pas oublier qu'osmose propose l'intégration sirene..
il y a surement déjà une partie de ces POI facile à intégrer sans rien
coder d'autre que ouvrir osmose avec l'url de la localisation

Cordialement,
Marc

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

[OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-02 Par sujet Baptiste Jonglez 
Bonjour,

On a eu une proposition d'intégration de données d'une autre carte
collaborative, sous licence Open Database License, cf. ce ticket :

  https://github.com/osmontrouge/caresteouvert/issues/81

C'est intéressant parce que c'est de la donnée récente et a priori assez
fiable (souvent contribuée par les propriétaires eux-mêmes).  À court
terme, ça permet d'enrichir les horaires d'ouvertures pendant le
confinement, et à long terme ça permet d'ajouter des POI manquants à
OpenStreetMap.

J'ai utilisé osm_conflate pour recouper les données avec OSM, le code et
les données sont ici : https://github.com/zorun/integration-osm-covid19
C'est pas toujours très propre, c'est ma première conflation et les
données sont parfois difficiles à exploiter...

J'obtiens 221 POIs rapprochés (avec quelques faux positifs) et 387 POIs
non rapprochés (avec sûrement quelques faux négatifs).  Évidemment je n'ai
rien importé automatiquement dans OSM, il faut de toute façon repasser sur
chaque point pour structurer la donnée.

Je propose de se coordonner par secteur pour intégrer ces données.  Ça
tombe bien, les données sont déjà organisées par ville.  En passant par
des layers umap + JOSM ça peut fonctionner, je détaillerai une idée de
processus quand on sera d'accord sur le principe.

Avant ça, est-ce qu'il y a une opposition sur le principe ?  Comment
visibiliser la source ? (tag "source", commentaire sur le changeset...)
Est-ce que les règles d'import automatique [1] s'appliquent, sachant que
ce n'est que semi-automatique et que les données seront intégrées
manuellement par plusieurs contributeurs ?

Merci,
Baptiste

[1] https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines


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