Re: [OSM-talk-fr] date de l'imagerie

[Brice Person]

On 30/08/2018 08:15, Christian Quest wrote:
Le mer. 29 août 2018 à 19:40, Brice Person <mailto:br...@ideeslibres.org>> a écrit :


On 29/08/2018 18:59, Christian Quest wrote:

Je viens de regarder, ça me semble furieusement inexploitable.


Ça fait plusieurs années que j'exploite ce fichier en ce qui me
concerne ;-)


Il a sûrement d'autres utilité... je parlais uniquement par rapport à 
notre besoin sur l'ortho.


Mon usage est d'afficher les attributions du calque 
"ORTHOIMAGERY.ORTHOPHOTOS" sur un leaflet (sans me soucier des dates).






1) on n'a que des boudingbox... donc des rectangles, alors que les
dates de mises à jour suivent à peu près les limites de départements


Ça, ça dépend de ce que tu veux, les dates de BD ORTHO ou les dates
de l'imagerie en production sur le géoportail. Mais je débarque donc
je n'ai peut-être pas bien compris.


On veut pouvoir savoir de quand date chaque visible de la BD Ortho, donc 
en fonction du x/y et du zoom car on a parfois des prises de vues plus 
anciennes aux zooms les plus élevés.


Il y aura sans doute un travail d'étude et d'appariement dans ce cas.

Après si vous constatez que le fichier correspond au besoin et que ça 
mérite une automatisation, il peut suffire de tester que la géométrie 
d'un département est complètement contenue dans un bbox particulier 
(avec une tolérance), pour pallier au "problème" des bounding box mais 
c'est à vérifier.





2) le minT / maxT qui indique la plage de date est
systématiquement: maxT="2018-05-29" minT="2008-06-18"


Tu n'as pas du utiliser la version de l'autoconf avec la clé du
géoportail. Cherche RGD 73-74 par exemple, les dates sont très
largement variables d'une manière générale.


Fort possible... mais comme je ne sais pas ce qu'il faut passer ni 
comment, je n'ai pas cherché plus loin. Si tu as l'info, je suis preneur 
car je doute que ça soit documenté et facile à trouver.


C'est ma faute, je pensais que la clé "choisirgeoportail" était d'un 
usage connu sur cette liste. Elle permet d'avoir accès à des ressources 
de base du Géoportail sans créer de compte (pour un usage très limité en 
terme de hits).


Donc pour avoir accès au fichier complet, il suffit juste de remplacer 
"choisirgeoportail" par la clé du geoportail de prod dans cette url :

https://wxs.ign.fr/choisirgeoportail/autoconf/?output=json

Le fichier fait environ 2.5Mo et je ne connais pas leur politique de 
mise en cache. Donc à utiliser avec parcimonie ;-)


L'usage d'une clé obtenue via l'espace pro ne donnant pas toutes les 
sources.


Il y a un peu de doc ici :
https://depot.ign.fr/geoportail/api/develop/tech-docs-js/fr/developpeur/geodrm.html


--
@bjperson
http://www.IdeesLibres.org

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

Re: [OSM-talk-fr] date de l'imagerie

[Brice Person]

On 29/08/2018 18:59, Christian Quest wrote:

Je viens de regarder, ça me semble furieusement inexploitable.


Ça fait plusieurs années que j'exploite ce fichier en ce qui me concerne ;-)



1) on n'a que des boudingbox... donc des rectangles, alors que les 
dates de mises à jour suivent à peu près les limites de départements


Ça, ça dépend de ce que tu veux, les dates de BD ORTHO ou les dates de 
l'imagerie en production sur le géoportail. Mais je débarque donc je 
n'ai peut-être pas bien compris.


2) le minT / maxT qui indique la plage de date est systématiquement: 
maxT="2018-05-29" minT="2008-06-18"


Tu n'as pas du utiliser la version de l'autoconf avec la clé du 
géoportail. Cherche RGD 73-74 par exemple, les dates sont très largement 
variables d'une manière générale.




Ceci dit, tout n'est peut être pas à jeter... le maxT bien que global 
et unique est potentiellement utile et permettrai peut être de savoir 
de quand date le dernier changement "quelque part" sur la BDOrtho et 
donc le besoin de remettre à jour notre couche de datation ;)



Le mer. 29 août 2018 à 18:31, Brice Person <mailto:br...@ideeslibres.org>> a écrit :


Bonjour,

Je découvre votre discussion sur le tard mais avez-vous pensé à
utiliser
l'autoconf du géoportail ?

Il y a les dates, les emprises (des bbox), et les min/max scale
denominator pour chaque sources.

Ça se présente comme ça :

https://wxs.ign.fr/choisirgeoportail/autoconf/?output=json

Par contre pour avoir l'exhaustivité des sources, bizarrement,
j'ai du
utiliser la clé d'api du geoportail (facilement trouvable dans la
console). Car il en manquait avec ma clé aussi (notamment RGD 73
74 près
de chez moi). Peut-être un bug.

Brice


On 28/08/2018 20:03, Frédéric Rodrigo wrote:
> Il s'agit de trouver dans quelle zone est une tuile pour
retourner une
> valeur. Le proxy du cadastre fait déjà :
> https://github.com/osm-fr/cadastre-joker/blob/master/whoots.rb#L23
>
>
> Le 28/08/2018 à 19:32, Vincent Privat a écrit :
>> Dans les metadata se serait effectivement mieux. Le format Bing
est
>> déjà géré par JOSM, ce serait donc le candidat idéal. Sinon on
a un
>> ticket pour gérer le format ESRI mais personne n'a encore
travaillé
>> dessus:
>> https://josm.openstreetmap.de/ticket/15604
>> Si on retient le format Bing, ça revient à rajouter le header
>> X-VE-TILEMETA-CaptureDatesRange
>> Pour la valeur du header on ne fait aucun contrôle dessus, le
format
>> est libre.
>> Vincent
>>
>> Le mar. 28 août 2018 à 17:16, Christian Quest
>> mailto:cqu...@openstreetmap.fr>
<mailto:cqu...@openstreetmap.fr <mailto:cqu...@openstreetmap.fr>>>
a écrit :
>>
>>     Super boulot, ne reste plus qu'à trouver comment intégrer
ça dans le
>>     proxy et faire en sorte que JOSM puisse afficher l'info...
>>
>>     Je vois deux options:
>>
>>     - un rendu transparent qui indique la date des tuiles
d'ortho au
>> meme
>>     x/y/z... simple à mettre en oeuvre,
>>
>>     - un bout de script python qui injecte dans les entêtes l'info
>>     entre le
>>     proxy et le géoportail, et faire en sorte que JOSM puisse
l'afficher
>>     comme pour Bing (sûrement plus complexe)
>>
>>     Autre suggestion ?
>>
>>
>>     Le 24/08/2018 à 21:56, deuzeffe a écrit :
>>     > Un premier bilan donne :
>>     >
>>     > - 5 m : https://lite.framacalc.org/bd-ortho-millesime-par-dep
>>     > - 50 cm :
>> https://lite.framacalc.org/bd-ortho-millesime-par-dep-50cm
>>     > - 20 cm :
>> https://lite.framacalc.org/bd-ortho-millesime-par-dep-20cm
>>     >
>>     > À voir comment est-ce exploitable...
>>     > --
>>     > deuzeffe, qui aimerait bien que Christian revienne de
vacances et
>>     > donne son avis.
>>     >
>>     > On 17/08/2018 12:36, Christian Quest wrote:
>>     >> La source de l'umap ce sont les shapefile de mosaique de la
>>     BDORtho
>>     >> 5m... republiés dans OpenEventDatabase
>>     >>
>>     >> Par contre, il faut aussi prévoir la mise à jour de cette
>>     source, car
>>     >> là ça commence à dater. Ce n'est pas parfait non plus
car c'est
>>     la BD
>>     >> Ortho 5m (donc gros pixels) alors qu'on a maintenant des
zones
>>     avec
>>    

Re: [OSM-talk-fr] date de l'imagerie

[Brice Person]

Bonjour,

Je découvre votre discussion sur le tard mais avez-vous pensé à utiliser 
l'autoconf du géoportail ?


Il y a les dates, les emprises (des bbox), et les min/max scale 
denominator pour chaque sources.


Ça se présente comme ça :

https://wxs.ign.fr/choisirgeoportail/autoconf/?output=json

Par contre pour avoir l'exhaustivité des sources, bizarrement, j'ai du 
utiliser la clé d'api du geoportail (facilement trouvable dans la 
console). Car il en manquait avec ma clé aussi (notamment RGD 73 74 près 
de chez moi). Peut-être un bug.


Brice


On 28/08/2018 20:03, Frédéric Rodrigo wrote:
Il s'agit de trouver dans quelle zone est une tuile pour retourner une 
valeur. Le proxy du cadastre fait déjà :

https://github.com/osm-fr/cadastre-joker/blob/master/whoots.rb#L23


Le 28/08/2018 à 19:32, Vincent Privat a écrit :
Dans les metadata se serait effectivement mieux. Le format Bing est 
déjà géré par JOSM, ce serait donc le candidat idéal. Sinon on a un 
ticket pour gérer le format ESRI mais personne n'a encore travaillé 
dessus:

https://josm.openstreetmap.de/ticket/15604
Si on retient le format Bing, ça revient à rajouter le header 
X-VE-TILEMETA-CaptureDatesRange
Pour la valeur du header on ne fait aucun contrôle dessus, le format 
est libre.

Vincent

Le mar. 28 août 2018 à 17:16, Christian Quest 
mailto:cqu...@openstreetmap.fr>> a écrit :


    Super boulot, ne reste plus qu'à trouver comment intégrer ça dans le
    proxy et faire en sorte que JOSM puisse afficher l'info...

    Je vois deux options:

    - un rendu transparent qui indique la date des tuiles d'ortho au 
meme

    x/y/z... simple à mettre en oeuvre,

    - un bout de script python qui injecte dans les entêtes l'info
    entre le
    proxy et le géoportail, et faire en sorte que JOSM puisse l'afficher
    comme pour Bing (sûrement plus complexe)

    Autre suggestion ?


    Le 24/08/2018 à 21:56, deuzeffe a écrit :
    > Un premier bilan donne :
    >
    > - 5 m : https://lite.framacalc.org/bd-ortho-millesime-par-dep
    > - 50 cm : 
https://lite.framacalc.org/bd-ortho-millesime-par-dep-50cm
    > - 20 cm : 
https://lite.framacalc.org/bd-ortho-millesime-par-dep-20cm

    >
    > À voir comment est-ce exploitable...
    > --
    > deuzeffe, qui aimerait bien que Christian revienne de vacances et
    > donne son avis.
    >
    > On 17/08/2018 12:36, Christian Quest wrote:
    >> La source de l'umap ce sont les shapefile de mosaique de la
    BDORtho
    >> 5m... republiés dans OpenEventDatabase
    >>
    >> Par contre, il faut aussi prévoir la mise à jour de cette
    source, car
    >> là ça commence à dater. Ce n'est pas parfait non plus car c'est
    la BD
    >> Ortho 5m (donc gros pixels) alors qu'on a maintenant des zones
    avec
    >> du 5cm (Paris).
    >>
    >> Sinon, l'IGN publie les années de prises de vues de la BD Ortho
    >> département par département, ce qui peut être largement suffisant
    >> comme info: http://professionnels.ign.fr/mises-a-jour
    >>
    >> Pour 2017 on trouve:
    >>
    >> 21-24-25-39-47-87-971-972-978 à 20cm
    >>
    >> 21-24-25-39-75-92-93-971-972-978 06-07-21-47 56
    13-25-39-47-87-971 à
    >> 50cm
    >>
    >> Malheureusement, ces tableaux ne sont pas très simple à lire
    car on a
    >> des millésimes différent en fonction des niveaux de zoom.
    >>
    >> Si un courageux veut remettre ça au propre dans un beau CSV ça
    serait
    >> fort utile.
    >>
    >>
    >> Le 15/08/2018 à 02:26, marc marc a écrit :
    >>> Le 15. 08. 18 à 02:16, Jérôme Seigneuret a écrit :
     la date de la prise de vu comme on peut l'avoir sur Google
    Earth ou
    >>> il y a les 2 lorsque les 2 sont disponibles.
    >>> la date de capture dans josm s'affiche chez moi avec
    >>> comme mention "métadonnée capture date"
    >>> et est visible par exemple avec la couche Bing
    >>> oui je sais c'est triste comme exemple :)
    >>>
    >>> Mais si quelqu'un est motivée pour coder l'injection des infos
    >>> dans les headers du proxy BDOrtho osm-fr, c'est techniquement
    possible
    >>> et un coup de main n'est jamais refusé :)
    >>> sinon c'est sur ma longue liste de chose à faire... et pas la
    moindre
    >>> idée de ce que cela va impliquer en boulot (j'ai pas encore
    regardé
    >>> la source de l'umap de Christian)
    >>> ___
    >>> 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

    --     Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Banque de Données Urbaines

[Brice Person]

Le 08/10/2014 20:03, Christian Quest a écrit :
Tu devrais te rapprocher de Fred Moine qui est dans le coin et tout 
près de chez toi il y a aussi Brice.


Héhé j'avais également vu passer l'article en question. J’habite Thonon 
depuis peu.


Je dois d'ailleurs recontacter un des conseillers municipaux niveau Open 
Data...


@Felix et Fred : N'hésitez pas à me contacter en cas de besoin, suivant 
le timing je peux peut-être venir donner un coup de main lors de ce 
rendez-vous. C'est surement une bonne idée de mettre Loic (EPN) dans la 
boucle aussi.


Le bon cocktail c'est toujours volonté interne + volonté politique ;-)

Brice




Le 8 octobre 2014 17:33, Ab_fab gamma@gmail.com 
mailto:gamma@gmail.com a écrit :


J'oubliais
_ les cartes thématiques http://www.itoworld.com/static/map.html
d'ITO World
_ overpass Turbo (à condition d'avoir un exemple pratique qui
fonctionne bien à portée de main)

Avec ce genre d'exemples sous la main, tu as de quoi tenir un bon
moment, et surtout tu peux rebondir facilement sur des centres
d'intérêt de tes interlocuteurs

Le 8 octobre 2014 15:41, Ab_fab gamma@gmail.com
mailto:gamma@gmail.com a écrit :

Pour ce qui concerne l'âge, si en face de toi tu as quelqu'un
de professionnel, cela ne devrait poser aucun souci.

Et annoncer la couleur en disant que ton approche tourne
principalement autour de la contribution et que tu ne
maîtrises pas tous les aspects du traitement et du contrôle
des données, c'est légitime.
Cela n'empêche pas pour autant de prendre note des points à
éclaircir de son côté et de venir les soumettre ici par la suite,.
Ce ne sont pas les exemples qui manquent pour ensuite donner
une réponse complète et structurée.

Mon petit doigt me dit que la teneur des questions devrait
s'approcher de ce qu'on peut lire dans ce message :
https://lists.openstreetmap.org/pipermail/talk-fr/2011-April/032320.html

Si tu as l'opportunité d'avoir accès à un ordinateur connecté,
quelques sites qui sont parlants :
_ Whodidit http://simon04.dev.openstreetmap.org/whodidit/ :
montrer que les contributions sont tracées, et les auteurs pas
totalement anonymes
_ osmose http://osmose.openstreetmap.fr/fr/map/:
identification des produits *et* aide à l'intégration de données
_ LizPOI http://www.ville-orange.fr/sortir01.htmà Orange
_ http://live.openstreetmap.fr/


Le 8 octobre 2014 14:29, Félix Marty felixma...@outlook.com
mailto:felixma...@outlook.com a écrit :

Bonjour,

Voilà un sujet qui va probablement vous faire sourire...

Je contribue à OpenStreetMap depuis quelques mois.

Suite à un article paru dans le journal municipal sur un
service de la mairie de Thonon-les-Bains, la Banque de
Données Urbaines, j'ai pensé que leur envoyer un mail leur
présentant le projet OpenStreetMap et leur proposant de
mettre à disposition une partie ou l'ensemble de leur base
de donnée pour collaborer avec OSM serait une idée
intéressante.
Je vous mets à ce propos l'article du journal

http://image.noelshack.com/fichiers/2014/41/1412769973-2014-10-08-135842.png
et mon mail

http://image.noelshack.com/fichiers/2014/41/1412770433-2014-10-08-1410382.png
envoyé (inspiré pour certaines parties de la page wiki
correspondante).

J'ai aujourd'hui reçu une réponse, à mon sens favorable,
m'invitant à un rendez-vous pour présenter /«
[les]objectif et [les] méthode d’acquisition, traitement
et contrôle des données »/.

Le fait que je ne sache rien niveau traitement et contrôle
des données n'est pas vraiment le problème, j'aurais pu
regarder sur le wiki ou demander conseil ici...

Mon seul vrai problème — et c'est là que vous allez
sourire — est mon âge. Contrairement à une large partie
(la totalité ?) d'entre vous, je suis mineur et ne me vois
vraiment pas aller à la mairie présenter OpenStreetMap. A
moins que la responsable de la BDU ait une grande
ouverture d'esprit, j'ai du mal à croire que je serai pris
au sérieux.
J'ai commencé à contribuer cet été par ennui, et il faut
dire que ça m'a plu. Ce mail à la mairie était peut-être
de trop, parce que du coup je ne sais vraiment pas quoi faire.

Auriez-vous une idée ?

Merci.

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




   

Re: [OSM-talk-fr] Prix des carburants ?

[Brice Person]

Le 07/10/2014 09:25, Yves Pratter a écrit :

Bonjour,

Le 20 sept. 2014 à 15:16, Brice Person brice.per...@zenordi.fr 
mailto:brice.per...@zenordi.fr a écrit :

Je viens d'en faire un CSV tout neuf ;-)
https://www.data.gouv.fr/fr/datasets/stations-services-en-france/

Merci, c’est plus lisible pour un humain ;-)

Le 25 sept. 2014 à 23:15, Frédéric Rodrigo fred.rodr...@gmail.com 
mailto:fred.rodr...@gmail.com a écrit :
J'ai finalement refait la conversion pour l'avoir dans un format qui 
me va mieux : une colonne = une donnée.

+1
C’est plus facile aussi pour utiliser les fonctions de filtrage d’un 
tableur.


Ça ne me choque pas pour les jours de fermeture, mais ce n’est pas 
pratique pour la colonne service.
Peux-tu mettre une colonne par service et une croix/Oui dans la ligne 
correspondante de point de vente ?




Tous les fichiers que je met à disposition sont dans le format dont j'ai 
l'usage, désolé (ça me permet de faire du multi-valued field avec Solr 
en l’occurrence).


Néanmoins il semble que Frédéric en a réalisé un dans le format que tu 
souhaites :

https://github.com/osm-fr/osmose-backend/raw/master/merge_data/fuel_FR.csv.bz2


Sur ta page data.gouv.fr 
https://www.data.gouv.fr/fr/datasets/stations-services-en-france/ tu 
indiques :
« Heureusement, beaucoup de pompes sont aujourd'hui équipées en carte 
bleue. *Mais malheureusement cette information n'est pas précisée 
dans le XML*. »


Il me semble que c’est le tag serviceAutomate CB/service qui 
indique ça ;-)
Par contre, on ne connait pas effectivement le type de cartes 
utilisées, ni si l’automate accepte les billets.


Sur le coup j'ai pensé que c'était pour les distributeurs d'argent mais 
vu qu'il y en a plus de 6000 sur près de 11000 stations il faut croire 
que je me suis trompé ;-)


Brice



« On ne peux donc pas non plus faire complètement confiance aux 
horaires d'ouverture. Le modèle du XML source ne se prêtant d'ailleurs 
pas à la précision. »
On peut leur suggérer le format de opening_hours 
http://wiki.openstreetmap.org/wiki/Key:opening_hours ?
Certes, pas facile à saisir mais hyper fiable. L’outil opening_hours 
evaluation 
http://openingh.openstreetmap.de/evaluation_tool/?setLng=fr#check tool 
est très pratique pour se faire la main et vérifier ses valeurs avant 
de les intégrer dans OSM.


—
Yves

PS: Peux-tu aussi trier les pdv par département et par ville ?






___
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] Belle carto des accidents

[Brice Person]

Le 23/09/2014 22:48, DH a écrit :

Le 23/09/2014 22:40, Vincent de Château-Thierry a écrit :

Ça a donné cette carto :
http://rue89.nouvelobs.com/2014/06/25/carte-presque-tous-les-accidents-route-2012-253113 



(warning : c'est du BANO sur fond Google)



C'est pour cela que ça pique autant les yeux !
Tous ne sont pas habitués.


Oui, on les a juste aidé pour le géocodage, on a pas eu notre mot à dire 
pour le fond de carte ;-)



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

Re: [OSM-talk-fr] Belle carto des accidents

[Brice Person]

Le 23/09/2014 22:19, Eric Debeau a écrit :
Belle réalisation présentant des accidents de la route qui date 
d'avril 2014


Merci :-)



http://www.ideeslibres.org/Accidents/Gravite/#bbox=41.1290213474951,-7.80029296875,51.34433866059924,22.21435546875lgd=1

Utilisation des tuiles MapQuest et bonnes attributions ;-)

Les noms de  voie se basent sur les codes Rivoli.
Ce serait bien de mettre à jour avec les données BANO qui sont plus 
précises ;-)


Eric


Oui, le travail est entamé : sur 129 141 accidents potentiellement 
géocodables de manière stricte (ou on a numéro + libellé de rue + code 
insee), le géocodeur (utilisant BANO et Solr) en trouve 68 552.


Pour faire mieux, il faudrait que je réalise un pré-traitement sur les 
libellés de rues qui ne sont pas formidables tels quels. Il faut que je 
m'y remette ;-)


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

Re: [OSM-talk-fr] Prix des carburants ?

[Brice Person]

Salut Frédéric et à tous,

Je viens d'en faire un CSV tout neuf ;-)
https://www.data.gouv.fr/fr/datasets/stations-services-en-france/

Brice

Le 19/09/2014 22:36, Frédéric Rodrigo a écrit :
Oui bien sûr, j'ai prévu de l'ajouter à Osmose. On peut même avoir le 
type de carburant.

Je suis preneur de toute aides.

Frédéric.


Le 19/09/2014 20:58, Jean-Baptiste Holcroft a écrit :

Bonjour, pensez-vous qu'on puisse croiser ce jeu de données avec osm
pour améliorer les tags, les corriger et/ou détecter les stations
manquantes/en trop ?

http://www.data.gouv.fr/fr/dataset/prix-des-carburants-en-france



___
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] Géocodage IGN un peu plus libre

[Brice Person]

Le 14/02/2014 11:44, Pieren a écrit :

2014-02-13 22:35 GMT+01:00 Frédéric Rodrigo fred.rodr...@gmail.com:


Donc dans le cadre d'un fichier dispo en opendata, thématique,
relativement partiel, cela ne semble pas poser de problème. Le
problème pour le côté substantielle c'est qu'à force de géocoder des
fichiers limités, l'ensemble peut devenir substantiel.

Juridique je crois qu'une thématique peut déjà être considéré comme
substantielle.

Pas sûr. Le problème est ailleurs.
On peut avoir par exemple deux administrations qui géocodent et
publient leurs résultats à partir de l'IGN : un les écoles, l'autres
les casernes de pompiers. C'est thématique mais ça reste des
publications séparées et non substantielles.
Maintenant, avec OSM. Un contributeur géocode les écoles, un autre les
casernes de pompiers. Le problème est que les deux résultats sont
ensuite intégrés dans la même base de donnée OSM. En cummulant les
travaux thématiques, on reconstitue petit à petit la base originelle :
ça devient du substantiel. Le terme prend toute sa signification dans
l'accumulation et la reconstitution.
Je ne suis pas sûr d'avoir été très clair mais pour moi, c'est
incompatible avec OSM.

Pieren


C'est clair que dans un projet comme OSM avec une base unique, par 
accumulation, ça peut vite devenir substantiel sans cadrer un minimum.


Là je viens de tester avec un bout de Banatic pour voir, et ce qui 
serait bloquant pour moi (hors OSM) c'est surtout que ça ne fourni pas 
(encore?) d'indication de précision du géocodage. Donc sur des gros 
fichiers ça serait fastidieux de faire les vérifications nécessaires 
mais sur des petits ça peut le faire quand même.


En tout cas le logiciel fonctionne parfaitement sur ma Debian avec wine. 
Pour les pertes de données, je n'ai rien constaté, ils ont peut-être 
tenu compte de tes observations Christian.


PS: un peu passionnel le sujet de l'IGN sur la liste ;-)


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

[OSM-talk-fr] Géocodage IGN un peu plus libre

[Brice Person]

Salut à tous,

Une bonne surprise ce matin, le logiciel visualiseur d'adresses que 
l'IGN met à disposition gratuitement permet désormais une mise sous 
licence ouverte du géocodage réalisé (CSV - kml).


Extrait:

/Le résultat du géocodage de fichiers est librement réutilisable dès lors :/

/- qu'il ne permet pas à des utilisateurs non autorisés au titre de leur 
licence de procéder, soit à l'extraction et/ou la réutilisation d'une 
partie substantielle, soit à l'extraction et/ou la réutilisation répétée 
et systématique de parties non substantielles des données de l'IGN. //

//
//- que les fichiers résultant du géocodage soient republiés sous 
licence ouverte ---sauf s'ils n'excèdent pas 250 adresses---./


http://logiciels.ign.fr/?Visualiseur-d-adresses,59

Donc quelqu'un qui réutilise un fichier généré et mis à disposition sous 
LO par ce biais peut parfaitement l'intégrer dans un projet sous ODbL


Après il faut y aller doucement quand même à cause de la première 
condition...


Perso ça va me permettre de géocoder proprement les adresses de la bdd 
de service-public.fr entre autres (on verra si c'est substantiel).


Brice

PS: Le logiciel (win) fonctionne aussi sous wine

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

Re: [OSM-talk-fr] Données publiques des noms de rue

[Brice Person]

Le 29 déc. 2013 02:14, Christian Quest cqu...@openstreetmap.fr 
mailto:cqu...@openstreetmap.fr a écrit


L'idée est de prendre une commune et d'analyser son contenu, de le
croiser avec des sources extérieurs (FANTOIR pour les noms de rue,
la BPE de l'INSEE pour les équipements et d'autres trucs en
opendata), y compris avec nos autres outils comme Osmose. Ca
permettra à un contributeur de savoir où en est le mapping d'une
commune (souvent la sienne) et d'aller au delà d'une carte qui a
l'air remplie.



J'exploite la BPE dans un projet, c'est une base très intéressante pour 
ce type d'usage. Elle le sera encore plus quand les contours IRIS 
INSEE/IGN seront libérés. Si c'est pour de la vérification, peut-être 
qu'ils vous autoriseraient à les utiliser en attendant ?


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

Re: [OSM-talk-fr] codes postaux...

[Brice Person]

Le 23/12/2013 11:24, Jean Couteau a écrit :

Le Sun, 22 Dec 2013 09:44:14 +0100,
Christian Quest cqu...@openstreetmap.fr a écrit :


Je suis en train de vérifier les codes postaux sur les communes.

Un peu d'harmonisation ne ferait pas de mal car on a un mélange de
addr:postcode=* et postal_code=* parfois sur la relation parfois sur
le noeud place=*

En combinant tout les cas, il n'en manquait qu'un peu plus de 300.
J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur
les relations.

Ne reste plus que les Côtes d'Armor... 139 CP manquants ;)

Ensuite vérification globale avec une extraction des codes postaux de
wikipédia pour voir où on a des différences... si vous avez d'autres
sources de CP pour vérifier, je suis preneur !


Je prends le train en marche, mais pour le boulot, j'avais commencé un
chantier en ce sens.

Je suis parti d'un fichier planet saucissonné avec osmosis et le
fichier du COG et ensuite traités avec une moulinette en Java.

J'obtiens un fichier csv qui reprend le COG complété par le(s) code(s)
postal(ux) de la commune et le centre de la commune et un fichier qui
prend les codes postaux manquants.

J'étais arrivé à un fichier incomplet (manquait environ 600 codes
postaux). J'ai complété ces codes manquants (à partir de wikipedia ou
j'ai noté des codes erronés qui y ont été modifiés), et suis arrivé à un
fichier complet (par code insee), mais environ 300 codes postaux
incohérents. Il me restait ces 300 codes à modifier (en général code
différent entre l'admin center et la relation donc vérification à faire
sur wikipedia et le service en ligne de la poste), un heureux évènement
dans la famille a un peu bouleversé le planning :D.

Le code de la moulinette est ici (crassou, pas commenté, bref du POC
dans un premier temps) :
http://svn.nuiton.org/svn/sandbox/referentielCommunesOsm/

Je peux filer mon CSV a qui veux (1,8Mo).

Jean


Pour ma part, j'ai commencé ça : 
http://www.ideeslibres.org/blog/2013/12/24/carte-des-codes-postaux-reconstituee-grace-a-service-public-fr/


Passez de bonnes fêtes,

Brice

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

Re: [OSM-talk-fr] codes postaux...

[Brice Person]

Salut,

Le 22/12/2013 10:02, Christophe Merlet a écrit :

Le 22/12/2013 09:44, Christian Quest a écrit :

Je suis en train de vérifier les codes postaux sur les communes.

Un peu d'harmonisation ne ferait pas de mal car on a un mélange de
addr:postcode=* et postal_code=* parfois sur la relation parfois sur le
noeud place=*

En combinant tout les cas, il n'en manquait qu'un peu plus de 300.
J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur les
relations.

Ne reste plus que les Côtes d'Armor... 139 CP manquants ;)

Ensuite vérification globale avec une extraction des codes postaux de
wikipédia pour voir où on a des différences... si vous avez d'autres
sources de CP pour vérifier, je suis preneur !



Ben ya la source officiel de la Poste
http://www.laposte.fr/Particulier/Utiliser-nos-outils-pratiques/Outils-et-documents/Trouvez-un-code-postal 


Mais c'est un formulaire Web

Sinon j'ai déjà constaté à quelques reprises que les infos de la poste 
divergeait des infos compilé par galichon.com


Par exemple pour Paris, selon la Poste, le code postal 75000 n'existe 
pas...



Librement,


Niveau source possible de comparaison, il y a aussi Service-Public.fr

Comme Frédéric Rodrigo l'avait intégré à Osmose à l'époque, il suffirait 
peut-être de récupérer également la variable 
/Organisme/Adresse/Accessibilité/CodePostal (d'ailleurs il y a 
également /Organisme@codeInsee).

https://lists.openstreetmap.org/pipermail/talk-fr/2013-June/059519.html

Sinon je n'ai pas encore pris le temps de me pencher sur la mise à jour 
auto de ça 
http://www.ideeslibres.org/service-public-fr-annuaire-de-ladministration-base-de-donnees-locales-v2/ 
mais je peux relancer mon script manuellement si vous en avez l'utilité.


Brice

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

Re: [OSM-talk-fr] codes postaux...

[Brice Person]

Le 22/12/2013 12:53, Brice Person a écrit :

Salut,

Le 22/12/2013 10:02, Christophe Merlet a écrit :

Le 22/12/2013 09:44, Christian Quest a écrit :

Je suis en train de vérifier les codes postaux sur les communes.

Un peu d'harmonisation ne ferait pas de mal car on a un mélange de
addr:postcode=* et postal_code=* parfois sur la relation parfois sur le
noeud place=*

En combinant tout les cas, il n'en manquait qu'un peu plus de 300.
J'ai complété à l'aide de wikipédia an ajoutant un addr:postcode sur 
les

relations.

Ne reste plus que les Côtes d'Armor... 139 CP manquants ;)

Ensuite vérification globale avec une extraction des codes postaux de
wikipédia pour voir où on a des différences... si vous avez d'autres
sources de CP pour vérifier, je suis preneur !



Ben ya la source officiel de la Poste
http://www.laposte.fr/Particulier/Utiliser-nos-outils-pratiques/Outils-et-documents/Trouvez-un-code-postal 


Mais c'est un formulaire Web

Sinon j'ai déjà constaté à quelques reprises que les infos de la 
poste divergeait des infos compilé par galichon.com


Par exemple pour Paris, selon la Poste, le code postal 75000 n'existe 
pas...



Librement,


Niveau source possible de comparaison, il y a aussi Service-Public.fr

Comme Frédéric Rodrigo l'avait intégré à Osmose à l'époque, il 
suffirait peut-être de récupérer également la variable 
/Organisme/Adresse/Accessibilité/CodePostal (d'ailleurs il y a 
également /Organisme@codeInsee).

https://lists.openstreetmap.org/pipermail/talk-fr/2013-June/059519.html

Sinon je n'ai pas encore pris le temps de me pencher sur la mise à 
jour auto de ça 
http://www.ideeslibres.org/service-public-fr-annuaire-de-ladministration-base-de-donnees-locales-v2/ 
mais je peux relancer mon script manuellement si vous en avez l'utilité.


Brice


Je viens de me rappeler qu'il y a aussi 
http://public.opendatasoft.com/explore/dataset/correspondance-code-insee-code-postal/#?tab=table 
sous licence ouverte


PS: je me suis aussi trompé de variable, c'est 
/Organisme/Adresse/CodePostal


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

Re: [OSM-talk-fr] codes postaux...

[Brice Person]

Le 22/12/2013 14:52, Vincent de Château-Thierry a écrit :


Le 22/12/2013 14:37, Christian Quest a écrit :

Ces codes postaux proviennent de wikipédia, je les utilise déjà pour
contrôle, mais je cherche une autre source que WP.

Celle de services-publics.fr http://services-publics.fr est 
intéressante.


L'idéal ce sont des sources même partielles avec code INSEE, code
postal, nom de commune, nom de bureau distributeur


Pourtant, contrôler une source WP avec elle même, ça assure du 100% de 
match, le graâl :-)


Il y a des sources partielles, comme l'adresse des mairies de Paca :
https://www.data.gouv.fr/fr/dataset/maires-de-la-region-op
mais pas exempt de Cedex, donc ménage à faire.
On a aussi les 16000 bureaux de poste, bien sûr.
Faute de source globale (à moins que service-public.fr le permette), 
on pourrait fusionner toutes les communes ayant le même CP, et voir si 
certains codes sont répartis sur plusieurs polygones disjoints, ce qui 
(hors les îles maritimes) pourrait indiquer un soupçon d'erreur ?


Enfin, car je suppose que la finalité est de publier ça sur 
data.gouv.fr, ce serait bien de traiter le cas des communes à CP 
multiples, histoire de publier quelque chose d'abouti avec une vraie 
valeur ajoutée.

Des partants pour qu'on s'y colle ?

vincent


Avec service-public.fr, à mon avis il y a moyen d'arriver à quelque 
chose de bien (mais peut-être pas global), il y a les infos cedex et les 
types d'adresses (mais inutile à mon avis pour cet usage). Je pense 
qu'il suffirait d'agréger les codes postaux possibles par codes insee en 
excluant d'abord les cedex (avec une regex dans un grep sur le csv 
initial par exemple).


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

Re: [OSM-talk-fr] codes postaux...

[Brice Person]

Le 22/12/2013 15:08, Brice Person a écrit :

Le 22/12/2013 14:52, Vincent de Château-Thierry a écrit :


Le 22/12/2013 14:37, Christian Quest a écrit :

Ces codes postaux proviennent de wikipédia, je les utilise déjà pour
contrôle, mais je cherche une autre source que WP.

Celle de services-publics.fr http://services-publics.fr est 
intéressante.


L'idéal ce sont des sources même partielles avec code INSEE, code
postal, nom de commune, nom de bureau distributeur


Pourtant, contrôler une source WP avec elle même, ça assure du 100% 
de match, le graâl :-)


Il y a des sources partielles, comme l'adresse des mairies de Paca :
https://www.data.gouv.fr/fr/dataset/maires-de-la-region-op
mais pas exempt de Cedex, donc ménage à faire.
On a aussi les 16000 bureaux de poste, bien sûr.
Faute de source globale (à moins que service-public.fr le permette), 
on pourrait fusionner toutes les communes ayant le même CP, et voir 
si certains codes sont répartis sur plusieurs polygones disjoints, ce 
qui (hors les îles maritimes) pourrait indiquer un soupçon d'erreur ?


Enfin, car je suppose que la finalité est de publier ça sur 
data.gouv.fr, ce serait bien de traiter le cas des communes à CP 
multiples, histoire de publier quelque chose d'abouti avec une vraie 
valeur ajoutée.

Des partants pour qu'on s'y colle ?

vincent


Avec service-public.fr, à mon avis il y a moyen d'arriver à quelque 
chose de bien (mais peut-être pas global), il y a les infos cedex et 
les types d'adresses (mais inutile à mon avis pour cet usage). Je 
pense qu'il suffirait d'agréger les codes postaux possibles par codes 
insee en excluant d'abord les cedex (avec une regex dans un grep sur 
le csv initial par exemple).


Je viens de tester avec ma version pas à jour, ça me donne 37 168 codes 
postaux différents sur 59 348 organismes et effectivement pas mal de 
codes insee qui partagent le même code postal.


Du coup ça me motive à mettre à jour le csv :-)

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

Re: [OSM-talk-fr] Qui était à Carnac cet été ? Map F4

[Brice Person]

Et puis ces données ne font pas partie de celles faisant l'objet d'une 
redevance, le ministère de la culture n'ayant rien déclaré dans les 
temps impartis http://www.data.gouv.fr/Redevances


Qu'il y ai de la demande pourrait sans doute accélérer leur passage sous 
licence libre.


Brice

Le 24/09/2013 12:34, Fionn Halleman a écrit :
Le texte actuel est effectivement un bijou. Ceci dit, il donne la 
marche à suivre. Il semblerait

qu'il faille demander.

L'idéal qu'ils réécrivent leur licence d'une manière plus conforme au 
droit en vigueur et à la politique du gouvernement, récemment rappelée 
par le Premier ministre 
(http://www.etalab.gouv.fr/m/article-120117507.html)



une autorisation de

Le mardi 24 septembre 2013, Philippe Verdy a écrit :

Le 24 septembre 2013 00:48, Jérôme Amagat
jerome.ama...@gmail.com a écrit :

 A ce titre, il est interdit, sous peine de se rendre coupable de
contrefaçon, de reproduire la base ou une partie substantielle de
celle-ci

On s'arrête à cette seule phrase. Cette base n'est PAS libre et sa
licence permettant uniquement une utilisation strictement privée
est incompatible avec l'ODbL.

Notez que OSM définit déjà pour lui-même ce qui constitue une
partie substantielle de celle-ci. Cela s'arrête à moins de 100
points ou features et une couverture de moins de 1000 habitants.
Bref il ne reste que l'usage strictement privé masi pas de droit
pour utiliser davantage de données.

Que va-ton faire ce cette base avec seulement 100 POIs ou features
et une zone de moins de 1000 habitants, dans une base OSM de
couverture mondiale où même pour n'importe quelle zone de 1000
habitants on cumule des centaines ou des milliers de noeuds ou de
features (y compris les tags individuels comme les noms) ? Rien
sans autorisation explicite.





___
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] Qui était à Carnac cet été ? Map F4

[Brice Person]

Ces données ne sont pas éligibles à cette exception.

Ca concerne les oeuvres (données culturelles = abus de langage).

Le 24/09/2013 13:26, Fionn Halleman a écrit :
Je précise mon idée parce que mon mail est parti un peu vite : ils ont 
bien le droit -actuel- pour eux, puisqu'il existe une exception à la 
loi de 1978 pour les données culturelles, du moins jusqu'à sa révision 
pour mise en conformité avec la directive ISP.


Ils sont donc libres d'imposer des conditions autres que le droit 
commun des données publiques (sans doute avec des bémols).


Mais rien ne les y oblige non plus. Donc peut-être qu'ils pourraient 
faire une réponse favorable à une demande de réutilisation, d'autant que :

- le climat est à l'ouverture
- il n'y a pas de perte financière à la clé, les données étant déjà 
gratuites.
- les données sont déjà structurées et téléchargeables dans des 
formats réutilisables.


Mais peut-être que d'ici là les alignements auront été reportés sur la 
carte OSM sans leur concours.


FH

Le mardi 24 septembre 2013, Fionn Halleman a écrit :

Le texte actuel est effectivement un bijou. Ceci dit, il donne la
marche à suivre. Il semblerait
qu'il faille demander.

L'idéal qu'ils réécrivent leur licence d'une manière plus conforme
au droit en vigueur et à la politique du gouvernement, récemment
rappelée par le Premier ministre
(http://www.etalab.gouv.fr/m/article-120117507.html)


une autorisation de

Le mardi 24 septembre 2013, Philippe Verdy a écrit :

Le 24 septembre 2013 00:48, Jérôme Amagat
jerome.ama...@gmail.com a écrit :

 A ce titre, il est interdit, sous peine de se rendre
coupable de contrefaçon, de reproduire la base ou une partie
substantielle de celle-ci

On s'arrête à cette seule phrase. Cette base n'est PAS libre
et sa licence permettant uniquement une utilisation
strictement privée est incompatible avec l'ODbL.

Notez que OSM définit déjà pour lui-même ce qui constitue une
partie substantielle de celle-ci. Cela s'arrête à moins de
100 points ou features et une couverture de moins de 1000
habitants. Bref il ne reste que l'usage strictement privé masi
pas de droit pour utiliser davantage de données.

Que va-ton faire ce cette base avec seulement 100 POIs ou
features et une zone de moins de 1000 habitants, dans une base
OSM de couverture mondiale où même pour n'importe quelle zone
de 1000 habitants on cumule des centaines ou des milliers de
noeuds ou de features (y compris les tags individuels comme
les noms) ? Rien sans autorisation explicite.





___
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] Nominatim et les articles

[Brice Person]

Salut,

Vu que c'est un besoin courant, il y a déjà les listes de stopwords 
utilisées par les moteurs de recherche libres tel que Solr ou autres :

http://svn.tartarus.org/snowball/trunk/website/algorithms/

Après c'est sur que c'est du boulot à mettre en place

Brice

Le 15/08/2013 15:15, Christian Quest a écrit :

Je pense que d'une manière plus générale Nominatim n'accepte pas assez
de variation sur les textes.

De plus, les mots à ignorer dans une langue peuvent très bien ne pas
devoir être ignorés dans une autre... il faudrait donc les définir
pour chaque langue, mais la langue d'un toponyme n'est pas toujours
évidente à déterminée non plus.

Ca a l'air simple, mais c'est quand même bien compliqué !


Le 15 août 2013 14:43, Cyrille Giquello cyrill...@gmail.com a écrit :

Salut,

La recherche sur osm.org est inefficiente pour les gens: si l'on
oublie un article dans un nom il n'y a pas de résultat.

Par exemple:
Prieuré de Saint-Cosme, La Riche = OK
Prieuré Saint-Cosme, La Riche = Rien

Donc les gens retournent sur maps.google.fr car osm.org ne les aide
pas à trouver un lieu.

Question pour les codeurs: est-ce compliqué de contribuer à Nominatim
pour ce genre de modification ? Est-ce simplement un genre de fichier
avec des mots à ignorer par langue ? Ou une modif plus lourde ?

--
Cyrille.

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





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

Re: [OSM-talk-fr] Nominatim et les articles

[Brice Person]

il y a un ticket récent d'ailleurs
https://trac.openstreetmap.org/ticket/4895

Le 15/08/2013 15:49, Brice Person a écrit :

Salut,

Vu que c'est un besoin courant, il y a déjà les listes de stopwords 
utilisées par les moteurs de recherche libres tel que Solr ou autres :

http://svn.tartarus.org/snowball/trunk/website/algorithms/

Après c'est sur que c'est du boulot à mettre en place

Brice

Le 15/08/2013 15:15, Christian Quest a écrit :

Je pense que d'une manière plus générale Nominatim n'accepte pas assez
de variation sur les textes.

De plus, les mots à ignorer dans une langue peuvent très bien ne pas
devoir être ignorés dans une autre... il faudrait donc les définir
pour chaque langue, mais la langue d'un toponyme n'est pas toujours
évidente à déterminée non plus.

Ca a l'air simple, mais c'est quand même bien compliqué !


Le 15 août 2013 14:43, Cyrille Giquello cyrill...@gmail.com a écrit :

Salut,

La recherche sur osm.org est inefficiente pour les gens: si l'on
oublie un article dans un nom il n'y a pas de résultat.

Par exemple:
Prieuré de Saint-Cosme, La Riche = OK
Prieuré Saint-Cosme, La Riche = Rien

Donc les gens retournent sur maps.google.fr car osm.org ne les aide
pas à trouver un lieu.

Question pour les codeurs: est-ce compliqué de contribuer à Nominatim
pour ce genre de modification ? Est-ce simplement un genre de fichier
avec des mots à ignorer par langue ? Ou une modif plus lourde ?

--
Cyrille.

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





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



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

Re: [OSM-talk-fr] Projet adresses

[Brice Person]

Le 13/06/2013 13:52, Christian Quest a écrit :

Nous sommes plusieurs d'OSM-FR présents depuis mardi aux rencontres
SIG La Lettre qui se déroulent comme chaque année à l'ENSG.

L'occasion d'établir et de réveiller des contacts avec de nombreux
acteurs et responsable locaux gérant de l'information géographique.

Après une journée sur place, nous avons identifié un sujet serpent de
mer qui patine depuis des années et où OSM peut être un outil pour
enfin faire avancer les choses.

Il s'agit de l'adresse.

En 2002, le CNIG publiait un rapport sur le sujet, en 2011 un autre
rapport était publié, il y a quelques mois encore un autre rapport
sortait... mais à part faire des réunions et écrire des rapports, il
ne se passe finalement rien de concret. L'IGN et La Poste font des
annonces, mais c'est sûrement plus pour occuper le terrain et ne pas
être dépossédé d'un gagne-pain, que de mettre en réel libre partage
cette information basique et indispensable à un très grand nombre
d'acteurs publics et privés.

D'un autre côté, on a des collectivités ouvertes pour partager ces
informations. Certaines l'ont déjà fait en opendata. On se souvient de
l'exemple de Nantes et du travail de fourmis d'intégration des
adresses par la communauté OSM nantaise. Depuis on a eu d'autres gros
jeux de données adresse qui ont été libérés: Montpellier, Bordeaux,
Lyon, etc.

Nous allons avoir accès à des jeux encore plus importants via les
fichiers EDIGEO du cadastre vectoriel. En effet, la vectorisation du
cadastre a été financée par les collectivités locales qui en sont
co-propriétaires et qui ont la possibilité de nous fournir
gratuitement ces données que nous pouvons utiliser dans les mêmes
termes que les données du cadastre que nous utilisons déjà (citation,
millésime, non reproduction à l'identique du cadastre, intégration
dans une base composite).


Salut,

D'après l'étude Pricing Of Public Sector Information Study 2012 de la 
commission européenne [1], en 2010 la revente de leurs infos ne couvre 
que 0.55% de ce que ca coute au contribuable...


Je ne sais pas à quelle heure tu passes mais si tu estimes que tu peux 
le placer sans te faire trop d'ennemis ;-)


Bref, je trouve que la moindre des chose serait qu'ils publient sous 
licence libre...


Brice

[1] Voir p24 et détails p34 
http://ec.europa.eu/information_society/policy/psi/docs/pdfs/report/11_2012/summary.pdf



  Ceci a été confirmé lors de notre réunion à
la DGFiP au sujet du futur accès au cadastre en WMS. Les données
EDIGEO ont juste l'avantage d'être vectorielles et qu'il est beaucoup
plus facile d'en extraire des infos que par la méthode actuelle.

J'ai eu le feu vert de la part de 6 départements et d'autres risquent
de suivre rapidement.

La méthode d'intégration pour être peut être un peu plus automatisée
que celle utilisée à Nantes. Ca sera sûrement plus facile sur des
territoires où il n'existe aucune adresse actuellement.

Les rencontres SIG La Lettre se terminent par notre présentation
OSM... et j'ai donc mis l'accent sur ce sujet en lançant une sorte
d'appel à libérer globalement ces données et à faire d'OSM le pot
commun de la donnée adresse... Elle est consultable ici:
http://prezi.com/qburiba538fz




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

Re: [OSM-talk-fr] Encore un lot de nouveautés dans Osmose

[Brice Person]

Salut Frédéric,

Moi qui pensais que c'était mon travail qui t'avait inspiré ;-) (je 
l'avais évoqué pour l'accessibilité)

http://www.ideeslibres.org/blog/2013/05/03/base-de-donnees-geolocalisee-des-administrations-francaises/

Pour la précision du géocodage ce sont donc lesmêmes valeurs que Google 
Maps.


En parlant d'accessibilité d'ailleurs, j'ai regardé vite fait ton code, 
tu pourrais récupérer également /Organisme/Adresse/Accessibilité/@type 
qui indique le caractère accessible de l'organisme, 
/Organisme/Adresse/Accessibilité que tu récupère étant le texte qui le 
précise.


Bien à toi,

Brice

PS: il y a une nouvelle version de ce jeu de données datée du 07/06 qui 
est dispo


Le 11/06/2013 00:21, Frédéric Rodrigo a écrit :

Bonsoir,

J'ai ajouté l'affichage de l'adresse et de la précision du géocodage 
mais c'est numérique et je ne sais pas à quoi ça correspond.


Frédéric.


Le 08/06/2013 20:05, Francescu GAROBY a écrit :

SUPER !

Bon, par contre, faites gaffe : comme toujours la géolocalisation des
données n'est pas tip-top du tout.
J'ai un bien bel exemple ici, avec le Pôle Emploi de Caen Nord
http://lannuaire.service-public.fr/services_locaux/basse-normandie/calvados/pole_emploi-14566-01.html 


(située en fait sur une commune limitrophe de Caen), placée à 1km à vol
d'oiseau de sa véritable adresse (et pas du tout dans le même 
lotissement !


Francescu



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





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

Re: [OSM-talk-fr] Erreurs importantes concernant la superficie des communes de l'Aude

[Brice Person]

A noter que le champ SUPERFICIE du Geofla peut aussi servir à comparer 
puisque d'après sa description :


Type : entier
Superficie de la commune en hectares. C'est la somme des surfaces des 
faces BD CARTO®
composant la commune (avant allégement géométrique et suppression des 
îles et enclaves).


Brice

Le 11/06/2013 12:00, Bruno Cortial a écrit :


Le formulaire osm.fr http://osm.fr semble indiquer la bonne 
superficie, mais est-elle basée sur le polygone OSM ?

http://openstreetmap.fr/outils/etat-commune?insee=66011

Bruno

Le 11 juin 2013 11:57, Nicolas Moyroud nmoyr...@free.fr 
mailto:nmoyr...@free.fr a écrit :


J'étais en train de le faire au moment même de l'envoi de ton
mail. :-)
Pas de différence majeure sur les communes incriminées... Je
commence vraiment à avoir des doutes sur l'algo de calcul des
superficies de QGIS ! Je vais tester tout ça avec PostGIS pour
voir ce que ça donne.

Nicolas

Le 11/06/2013 11:45, Ab_fab a écrit :

Une superposition avec Geofla pour localiser rapidement des
grosses différences ?



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




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


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

Re: [OSM-talk-fr] Fwd: French cadastre source tags

[Brice Person]

Bonjour,

Le 28/04/2013 18:25, yvecai a écrit :

En fait, la question est simple.

Est-ce que j'ai le droit de vendre ça sous license odbl:
http://www.opensnowmap.org/download/condamine-la-doye.osm
[ ] oui
[ ] non

C'est un extrait du cadastre


D'OSM plutôt non ? Je pars du principe que oui.

, vectorisé, sourcé, importé, vérifié, exporté et duquel j'ai enlevé 
le tag source.


La réponse serait oui si on parlait de n'importe quelle base de données 
sous licence ODbL, son résumé est assez clair là dessus :

http://vvlibri.org/fr/licence/odbl/10/fr

Le problème ici c'est qu'il faudrait renégocier les accords passés 
avec la DGFiP car les 2 conditions exigées par eux ne sont pas 
compatibles à l'import dans une base de donnée sous ODbL.


La seule citation qui devrait leur être garantie ne pourrait être que de 
la forme :
Contient des données de la Direction Générale des Finances Publiques 
(DGFIP) 2008 - 2013

Sur la page http://www.openstreetmap.org/copyright

Quand à cette histoire de produit composite, ne sont ils pas en train de 
vouloir imposer le seul moyen de déroger à leur règle ? (dans 
l'hypothèse ou ça serait possible).


Bref, au final tout le monde serait content de respecter l'ODbL imho.

Si quelqu'un veut se lancer pour leur faire un courrier, je veux bien 
donner un coup de main.


Brice




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





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

Re: [OSM-talk-fr] Fwd: French cadastre source tags

[Brice Person]

En effet, si on suit la license à la lettre, il est impossible 
d'importer des données externes aussi en ODbL (on ne peut garantir la 
mention d'attribution), un comble pour une license ouverte.


Bonjour,

Pour clarifier, l'ODbL impose simplement de citer les autres bases ODbL 
utilisées, mais pas sur chaque objets.

cf : http://www.vvlibri.org/fr/Analyse/open-database-license-10-analyse

Donc en faire mention dans la page 
http://www.openstreetmap.org/copyright est suffisant. Aux 
ré-utilisateurs ensuite d'en tenir compte.


Il faut juste veiller à ce que les contributeurs soient bien au courant 
qu'ils doivent itérer sur la page en question dès qu'il y a import 
provenant de nouvelles sources compatibles.


Et pour la Licence Ouverte c'est pareil puisque celle ci indique 
explicitement être compatible avec les licences Open Data Commons d'OKF 
dans son texte.


Donc la question de bien sourcer l'information via les tags relève 
surtout du bon fonctionnement du projet mais n'a rien d'imposé par ces 
licences. Et pour revenir au sujet initial du fil, ce n'est donc pas le 
genre de condition qui peut être imposée à une intégration dans une base 
sous licence ODbL.


Brice


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

Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses =?iso-8859-15?q?_donn=E9s=3F?=)

[Brice Person]

Le 03/04/2013 10:23, Pieren a écrit :
A ce compte là, il faut tout de suite arrêter d'utiliser le cadastre. 
En effet, la condition la plus restrictive du cadastre est que le 
produit final soit un produit composite. Hors, on ne peut garantir 
que localement le cadastre soit l'unique source d'information 
cartographique.


Le cadastre est concerné par Inspire mais je trouve que l'interprétation 
de cette directive par l'IGN (qui publie un tms limité et pas les 
données vecteur) laisse à désirer... (pour être poli)


Il faudrait plutôt arrêter les arrangements avec les fournisseurs et 
leur pointer les bonnes pratiques. J'estime qu'OSM joue un rôle très 
important de ce côté là.


Il ne faut pas perdre de vue l'objectif d'une licence. Cette clause de 
non altération sert avant tout à protéger le fournisseur de tous 
recours en cas de litiges (si la donnée est fausse parce que 
modifiée, c'est pas ma faute).


Je dirais que ce qu'il ne faut pas perdre de vue c'est la volonté de 
l'acteur qui libère ses données, celui ci a plutôt envie de faire les 
choses bien à la base. Il faut donc faire de la pédagogie. Cette clause 
on la retrouve dès que l'APIE est consultée... ou son site qui contient 
toujours tout ce qu'il faut pour perdre un néophyte.


Mais si ce genre de clause va à l'encontre de l'opendata, je ne sais 
pas si elle est prise en compte dans les textes actuels (directive 
inspire). Les restrictions sur la libération des données doivent avoir 
une réelle justification. L'avis d'un spécialiste serait bienvenue ici.


Je cite La directive n'impose pas de ne publier que des données 
parfaites : elle demande seulement que le niveau de qualité des données 
soit indiqué de façon sincère et précise dans les métadonnées.


Le problème avec cette directive c'est plutôt que la redistribution à 
l'identique (share alike) peut être vue comme une restriction 
injustifiée de la part d'un acteur (ce qui me parait une erreur 
monumentale, mais à l'époque les enjeux n'avaient peut-être pas été 
identifiés).


Ce qui permet le discours de l'IGN :
http://www.ign.fr/publications-de-l-ign/Institut/Publications/IGN_Magazine/68/IGNmag68.pdf
Qui fait comme si l'ODbL n'existait pas et n'était donc pas une solution 
aux problèmes qu'ils relèvent.



L'ODbL n'était pas encore traduite en droit Français et Etalab
n'existait pas.


Je ne sais pas trop ce que veut dire traduite en droit français. Si 
c'est pour dire, elle est validée par un texte de loi ou fait 
référence à des textes de lois français, ça n'est pas le cas. Si 
c'est pour dire, elle est validée par un juge, ça n'est pas le cas 
non plus. Tout ce qu'on peut dire, c'est qu'elle a été validée par des 
experts juridiques au niveau de certaines administrations qui ont 
décidé d'adopter cette licence pour leurs données.


C'était à interpréter au sens propre : 
http://vvlibri.org/fr/licence/odbl/10/fr


Quant à la licence LO/OL d'Etalab, elle peut aussi poser problème dans 
OSM si on veut couper les cheveux en quatre (puisqu'on en arrive là). 
En effet, elle contient, comme ODbL, une obligation de mentionner la 
source. Hors, cette mention est souvent attachée aux objets eux-mêmes 
(tag source) et rien ne garantit leur pérennité dans la bdd.


Là c'est couper les cheveux en quatre oui ;-)

Brice



Pieren


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


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

Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses =?iso-8859-15?q?_donn=E9s=3F?=)

[Brice Person]

Le 02/04/2013 13:12, sly (sylvain letuffe) a écrit :

On mardi 2 avril 2013, Pieren wrote:

2013/4/1 Brice Person brice.per...@zenordi.fr


  Demander des autorisations spécifiques, d'une manière générale, me parait
inapproprié lorsqu'on est pas de simples ré-utilisateurs finaux. Les
données convoitées ne peuvent qu'être sous une licence compatible ou dans
le domaine public sinon on fait reposer le risque sur le ré-utilisateur
d'OSM.


Quel risque si on reçoit une autorisation explicite des détenteurs et que
c'est public ?

Pieren

Je partage un peu la prudence de Brice, j'ai l'impression que l'aura du osm
c'est bien fait oublier à certains donneurs de données que donner à osm ça
n'a juste pas de sens.

Quand je vois des licences qui disent (je caricature un peu) : la
modification des données n'est pas autorisée, mais elles peuvent-être
intégrées dans OSM je me dis que y'en a un qui n'a pas lu l'odbl jusqu'au
bout, qu'il a juste obéi à une mouvance et que ça peut faire bizarre lorsque
osm sera encore plus ré-utilisé qu'il ne l'ait actuellement.

bref, une autorisation qui mentionne oui vous pouvez importer et améliorer
nos données dans osm me semble bien légère, et je trouve plus clair qu'il y
soit fait mention de :
Oui, nos données sont sous licence ODBL ou compatible ODBL, donc, oui, vous
pouvez les importer dans OSM, et nous avons bien compris que tout le monde
peut alors les ré-utiliser sous les conditions de cette licence


Pour éviter toutes ambiguïtés, il faut que les acteurs soient ok pour 
que les données soient redistribuées sous les conditions de l'ODbL. Donc 
pour la France il vaut mieux que les acteurs utilisent directement 
l'ODbL ou une licence reconnue pour être compatible comme la LO d'Etalab 
(plus permissive). Je sais ça ne fait pas des masses de choix mais c'est 
tant mieux :-)


Rennes qui a été pionnière sur l'OpenData en France s'était 
naturellement tournée vers l'APIE à l'époque. L'ODbL n'était pas encore 
traduite en droit Français et Etalab n'existait pas.


Espérons qu'à l'avenir les différentes initiatives adoptent les licences 
au cas par cas et non une licence pour l'ensemble de leurs données (ce 
qui je pense a été une étape nécessaire à une maturation du mouvement). 
Ce que je conseille c'est ODbl pour des données dont on veut éviter la 
privatisation, et LO ou domaine public pour le reste.


Brice



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

Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses donnés?)

[Brice Person]

Le 31/03/2013 12:15, Pieren a écrit :
2013/3/30 Brice Person brice.per...@zenordi.fr 
mailto:brice.per...@zenordi.fr


C'est la conclusion que nous avions eu à l'époque de sa sortie. De
plus, il ne faut pas confondre la licence de l'APIE avec celle du
ministère de la justice (bravo l'APIE) voir :

http://www.regardscitoyens.org/licences-opendata-lapie-grille-la-priorite-a-etalab-et-invente-le-pseudo-libre/

Tout cela est bien dommage car il semble que DRC soit de très
bonne volonté.


A noter que Corine Land Cover de l'ifen était disponible dans une 
license similaire avec une clause de non-altération. Il suffit de 
s'adresser à eux en leur demandant si on peut importer leurs données 
dans OSM en les informant clairement qu'on ne pourra pas garantir la 
non-altération. On peut aller au delà de cette clause si on reçoit une 
autorisation spécifique (qu'il faut rendre publique et archivée, 
évidemment).


Pieren


Je regrette mais le cas du Corine Land Cover serait plutôt emblématique 
de ce qu'il ne faut pas faire. Si on suit la logique jusqu'au bout il 
n'aurait pas du être importé... (heureusement sa dernière version est 
désormais disponible en by [1]).


Si le projet OSM ne faisait que réutiliser les données ça irait mais il 
redistribue aussi les données.


Demander des autorisations spécifiques, d'une manière générale, me 
parait inapproprié lorsqu'on est pas de simples ré-utilisateurs finaux. 
Les données convoitées ne peuvent qu'être sous une licence compatible ou 
dans le domaine public sinon on fait reposer le risque sur le 
ré-utilisateur d'OSM.


D'ailleurs si on fait reposer le risque sur le ré-utilisateur d'OSM, 
qu'est ce qui empêche celui ci à son tour de se retourner contre OSM si 
lui même a eu des ennuis ? A part la mauvaise pub ;-)


Bref je ne sais pas vous mais pour moi ça fait un peu trop d'incertitudes.

Pour revenir à DRC, si quelqu'un veut battre le fer tant qu'il est 
chaud, il vaudrait mieux leur pointer que les administrations ayant 
choisi cette licence avaient été mal conseillées à l'époque et ont du 
corriger le tir par la suite [2] (l'OpenData c'est encore nouveau pour 
plein de gens, juristes compris).


Brice

[1] 
http://www.eea.europa.eu/data-and-maps/data/clc-2006-vector-data-version-2
[2] 
http://www.lagazettedescommunes.com/151375/open-data-la-cu-de-bordeaux-change-de-licence-esperant-ainsi-generer-des-emplois/





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


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

Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses donnés?)

[Brice Person]

Bonjour,

On 29/03/2013 21:13, Vincent de Chateau-Thierry wrote:

Bonsoir,

Le 29/03/2013 19:54, sly (sylvain letuffe) a écrit :

On vendredi 29 mars 2013, Romain MEHUT wrote:
Par contre quelqu'un d'autre a indiqué que la licence IP serait 
incompatible
avec l'Open Data étant donné la clause de non altération. Est-ce 
vraiment un
élément qui rend incompatible ces données pour une réutilisation 
dans OSM?


Et j'emmétrais moi même un fort doute.
En effet, si la licence IP oblige une non altération des données, 
cela n'en
fait plus une licence libre, et donc, elle n'est plus compatible avec 
ODBL.


C'est la conclusion que nous avions eu à l'époque de sa sortie. De plus, 
il ne faut pas confondre la licence de l'APIE avec celle du ministère de 
la justice (bravo l'APIE) voir :

http://www.regardscitoyens.org/licences-opendata-lapie-grille-la-priorite-a-etalab-et-invente-le-pseudo-libre/

Tout cela est bien dommage car il semble que DRC soit de très bonne volonté.

Désolé pour un 1er message sur cette liste d'apporter des mauvaises 
nouvelles.


Brice
@bjperson




Mais l'interprétation du texte de la licence peut être sujette à 
plusieurs

manière de la lire (elle est pas clair pour moi en tout cas)

L'article wikipedia indique que c'est une licence libre, mais aucune 
citation
(à part un article de presse dont l'auteur me semble avoir confondue 
licence
du texte de la licence et licence elle même), ce que je me suis 
permis de

compléter/corriger/mettre en doute sur WP

Sur le wiki Openstreetmap VDB semble avoir conclu que c'était bon :
http://wiki.openstreetmap.org/wiki/WikiProject_France/G%C3%A9oLittoral

Mais la licence IP oblige une étape d'enrichissement des données 
pour pouvoir
relicencier le travail dérivé sous une autre licence (et en 
l'occurrence,
c'est ce travail qui nous permet de faire le passage IP - CC BY-SA / 
ODbL à

terme)

Sauf que si je lis la licence :
http://www.rip.justice.fr/information_publique_librement_reutilisable
La présente licence précise les conditions juridiques de 
réutilisation des
informations publiques conformément à l’article 12 de la loi n°78-753 
du 17
juillet 1978 qui impose que les données  ne soient pas altérées, que 
leur
sens ne soit pas dénaturé et que leurs sources et leur date de mise à 
jour

soient mentionnées.

J'en arrive pas tout à fait à la même interprétation que lui.

Mais cette IP ressemble un peu à celle du cadastre, c'est à dire qu'elle
semble avoir pour but d'éviter que quelqu'un prenne, modifie et 
prétende que

les nouvelles données sont la responsabilité de l'organisme qui les a
libérées.
Genre : modifier si vous voulez, mais dites bien que c'est une version
dérivée de chez nous, pas la notre

Mais ça mériterait quand même un bon éclaircissement, de ce que je 
lis, dans

une posture de prudence, c'est non, on peut pas



Sur la page de téléchargement je lis :
Les données peuvent faire l’objet de traitements, notamment 
lorsqu’ils sont nécessaires à la réalisation d’une nouvelle 
application ou d’un nouveau produit ou service.
On entend notamment par traitement, le regroupement d’informations, le 
renseignement de métadonnées, l‘enrichissement, les modifications 
nécessaires pour permettre l’interopérabilité des données avec 
d’autres données.


Ça ouvre quand même l'usage, en permettant d'envisager dès le départ 
que la donnée va être modifiée, par les traitements. Modification et 
altération sont deux choses bien distinctes, la première n'implique 
pas qu'on va dégrader la source.


Concrètement si on envisage une intégration dans OSM, en rapprochant 
les tracés fournis des tracés highway=* existant dans notre base, que 
va-t-on faire ?
- découper ou agréger l'information pour la faire correspondre à la 
granularité des données OSM,
- déplacer l'information pour l'associer à des objets +/- distants, si 
le calage ou la précision géométrique de la source sont moindres que 
les tracés OSM correspondants.
Rien que par ces deux exemples, on rentre dans le cadre prévu par la 
licence : on regroupe, on enrichit (en combinant les infos à celles 
des highway=* par ex.), on modifie (au moins la géométrie), pour 
autant on ne dénature ni n'altère les données, et au final on les rend 
interopérables avec le reste des données OSM.


...mais je ne suis pas juriste.

vincent (qui voit le verre à moitié plein)

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



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