[OSM-talk-fr] Certificat Osmose expiré

2016-12-02 Par sujet Francois Gouget 

Le certificat d'Osmose a expiré le 01/12/2016 à 23:05. Du coup Firefox 
se plaint lorsque j'essaie d'accéder au site :

https://osmose.openstreetmap.fr/

A-t-on quelqu'un sur le problème ?

-- 
Francois Gouget   http://fgouget.free.fr/
   Cahn's Axiom: When all else fails, read the instructions.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fwd: Re: Noms d'arrondissements dans OSM

2016-12-02 Par sujet Philippe Verdy 
Le 2 décembre 2016 à 23:34,  a écrit :

>
>
>
> https://www.insee.fr/fr/metadonnees/cog/commune/COM29019-brest
>
> *Informations du code officiel géographique*
>
>-
>   - *Le code officiel géographique de la commune de Brest est 29019*
>   - * Région : Bretagne (53)
>   **
>   dont le chef lieu est la commune de **Rennes (35238)
>   *
>   - * Département : Finistère (29)
>   **
>   dont le chef lieu est la commune de **Quimper (29232)
>   *
>   - * Arrondissement : Brest (291)
>   **
>   dont le chef lieu est la commune de **Brest (29019)
>   *
>   - *Canton(s) :*
>  - *Brest-1 (2901)
>  **
>  dont le bureau centralisateur de canton est la commune de **Brest
>  (29019) 
> *
>  - *Brest-2 (2902)
>  **
>  dont le bureau centralisateur de canton est la commune de **Brest
>  (29019) 
> *
>  - *Brest-3 (2903)
>  **
>  dont le bureau centralisateur de canton est la commune de **Brest
>  (29019) 
> *
>  - *Brest-4 (2904)
>  **
>  dont le bureau centralisateur de canton est la commune de **Brest
>  (29019) 
> *
>  - *Brest-5 (2905)
>  **
>  dont le bureau centralisateur de canton est la commune de **Brest
>  (29019) 
> *
>
> Tu remarqueras que seule la commune est appelée Brest, l'arrondissement
> est noté "Arrondissement : Brest" car par défaut quand on parle de Brest,
> on parle de la commune de Brest.
>
Dans l'exemple aussi tu as "Région : Bretagne", "Département : Finistère".
Ce n'est pas propre à l'arrondissement et même pour la commune c'est
précisé chaque fois aussi en complément.

Tu veux renommer "Bretagne" en "Région Bretagne", et "Finistère" en
"Département du Finistère" ???

Ils n'écrivent pas "Commune : Brest".
>

Non sans blague ! Il écrivent à chaque fois et séparément le nom générique,
puis le nom propre (suivi du code entre parenthèse, lui aussi séparément).
Les trois éléments assemblés en tête de ligne forment un seul lien mais
c'est une présentation.

Et pour rappele encore, les arrondissement ne sont pas tous nommés comme
leur chef-lieu (raison aussi pour laquelle l'INSEE le précise explicitement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Drones et reconnaissance automatique

2016-12-02 Par sujet Philippe Verdy 
Le 2 décembre 2016 à 18:21, Christian Quest  a
écrit :

> Le 02/12/2016 à 16:56, Stéphane Péneau a écrit :
>
> Le 02/12/2016 à 15:44, Christian Rogel a écrit :
>
> Aujourd’hui, l’open data, la télédétection, les algorithmes et les drones
> réduisent l’espace dévolu aux contributeurs bénévoles. Jusqu’où peut aller
> cette évolution ?
>
>
> Je ne pense pas que ces nouvelles techniques réduisent la contribution des
> bénévoles.
>
> La communauté OSM n'acceptera jamais l'intégration en masse de données
> provenant de reconnaissance de panneau, ou de drone, ou de quoique ce soit.
> Ces données sont juste une source d'informations supplémentaires.
> En revanche, cela risque de diminuer le relevé sur le terrain, et
> augmenter le "chair-mapping"
>
>
> Je pense que ces technologies permettront surtout de décharger les
> contributeurs des tâches répétitives et ingrates.
>

Je le pense aussi. A condition encore de ne pas tout automatiser en import.
Ce qui fera la qualité de la carte ce n'est pas la complétude d'un import
mais le fait d'avoir qualifié diverses sources et les avoir comparées pour
en tirer le meilleur. Les relevés de terrain c'est pas mal pour des
éléments locaux mais pas suffisant pour la complétude et cela n'interdit
pas d'utiliser des moyens techniques complémentaires.

Tout le travail dans OSM est là:  savoir se servir de toutes les sources,
tout en sachant qu'aucune ne sera parfaite ni complète ni forcément plus à
jour. Le terrain sert surtout alors quand on a des ambiguïtés à lever
(surtout des ambiguités de placement relatif, sachant que la précision des
relevés varie constamment: une photo sur place peut faciliter les choses et
un drone peut aussi prendre des photos de terrain plus facilement, sachant
que son autonomie est limitée et l'utilisateur pas loin).

Tous les clichés pris par un drone ne seront pas utiles. Reste à avoir les
autorisations et habilitations nécessaires pour les faire voler en France !

Je pense qu'en France les relevés de terrain systématiques seront moins
fréquents mais qu'on les planifiera en fonction d'une carte préparée à
l'avance et contenant des points à vérifier sur place ou suite à certains
événements ou réaménagements pour lesquels on n'a pas encore de source
fiables à jour.

Un bon exemple est de remplir les blancs restants pour les adresses BANO
(mais même là ça peut être difficile, les numéros ne sont pas toujours
visibles ou alors il faut regarder les boites à lettres de très très près,
mais là encore les numéros ne sont pas toujours visibles, on n'a que les
noms des occupants !), ou l'intégration de SIREN (qui va demander plein de
vérifications pour voir s'il y a bien quelque chose de visible sur place ou
si ce n'est pas une simple adresse postale qu'on ne peut réellement
constater qu'en entrant dans des espaces privés avec la "clé du facteur"
mais qui ne sont en fait pas ouverts du tout au public).

Quant aux données concernant les travaux en court non terminés, ils sont
souvent interdits d'accès au public: on ne peut se fier qu'aux données
publiées par des tiers ou des photos aériennes plus ou moins datées si on
veut une géométrie "acceptable" (qu'on ne peut pas mesurer correctement en
allant voir "sur place" par des observations faite en fin de compte de loin
depuis quelques points de vue souvent limités, ou par des manœuvres
dangereuses comme le franchissement de palissades. En fin de compte pour
OSM on s'intérese avant tout à ce qui est accessible et visible par le
public et pour le reste on se contente d'estimations de ce qui sera un jour
ouvert mais pas dans l'état qu'on peut voir. Faire voler des drones au
dessus des chantiers interdits d'accès au public est tout autant interdit
si on n'est pas autorisé par le maître d'oeuvre et si on n'informe pas non
plus les personnels sur place de leur présence sur le site.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fwd: Re: Noms d'arrondissements dans OSM

2016-12-02 Par sujet osm . sanspourriel 



Le 18/11/2016 à 22:39, Vincent de Château-Thierry - osm.v...@free.fr a 
écrit :


Le 18/11/2016 à 22:08, osm.sanspourr...@spamgourmet.com a écrit :


Pour en revenir au nommage, vu qu'il y a confusion entre /XXX /et
/arrondissement de XXX/ (aux exceptions près) et pour les raisons
invoquées (les villes ne sont pas toujours dans ces arrondissements et
surtout les arrondissements ne sont pas dans les villes, je suis pour
écrire /arrondissement de XXX/.


Vu qu'il y a confusion entre XXX (arrondissement) et XXX (commune) je 
suis pour écrire "Commune de XXX"

Je blague, mais à peine.

Quand on consulte le COG je ne vois nulle part de nom sous la forme 
"Arrondissement de XXX", pas plus que "Commune de XXX".

Par exemple :
http://www.insee.fr/fr/methodes/nomenclatures/cog/fichecommunale.asp?codedep=85&codecom=050 

=> Arrondissement figure dans la colonne "Niveau administratif", pas 
dans la colonne "Nom".
Après, oui, il y a des homonymies, et dans le cas des arrondissements 
plus qu'ailleurs. Mais stocker comme tag name "Arrondissement de " 
revient à stocker non pas l'information, mais une mise en forme de 
l'information. Gardons les soucis de mise en forme pour les 
applications clientes d'OSM. Dit autrement : à chaque client 
d'organiser le *rendu* de l'information, ici pourquoi pas en 
concaténant "Arrondissement de" au contenu du tag name.


vincent

Il me semble normal que tu ne trouves pas dans une fiche *communale* le 
nom de l'arrondissement comme nom mais comme division de niveau 
arrondissement qui plus est son numéro INSEE et non son nom.


https://www.insee.fr/fr/metadonnees/cog/commune/COM29019-brest
/
/
/Informations du code officiel géographique/

 *
 o /Le code officiel géographique de la commune de Brest est 29019/
 o /Région : Bretagne (53)
   //dont
   le chef lieu est la commune de //Rennes (35238)
   /
 o /Département : Finistère (29)
   
//dont
   le chef lieu est la commune de //Quimper (29232)
   /
 o /Arrondissement : Brest (291)
   
//dont
   le chef lieu est la commune de //Brest (29019)
   /
 o /Canton(s) :/
 + /Brest-1 (2901)
   
//dont
   le bureau centralisateur de canton est la commune de //Brest
   (29019)
   /
 + /Brest-2 (2902)
   
//dont
   le bureau centralisateur de canton est la commune de //Brest
   (29019)
   /
 + /Brest-3 (2903)
   
//dont
   le bureau centralisateur de canton est la commune de //Brest
   (29019)
   /
 + /Brest-4 (2904)
   
//dont
   le bureau centralisateur de canton est la commune de //Brest
   (29019)
   /
 + /Brest-5 (2905)
   
//dont
   le bureau centralisateur de canton est la commune de //Brest
   (29019)
   /

Tu remarqueras que seule la commune est appelée Brest, l'arrondissement 
est noté "Arrondissement : Brest" car par défaut quand on parle de 
Brest, on parle de la commune de Brest.


Ils n'écrivent pas "Commune : Brest".
Ce n'est que quand on parle exclusivement des arrondissements que l'on 
peut s'en passer : 
https://www.insee.fr/fr/statistiques/fichier/2114819/arrond2016-txt.zip.


Quant à déléguer le boulot au client (ou au moteur de rendu, graphique 
ou textuel), ça veut dire qu'il faut déporter la logique administrative 
de tous les niveaux de tous les pays sur tous les clients.
Par exemple il faudrait écrire "arrondissement départemental" en niveau 
7 en France et par exemple Stadtbezirk en niveau 9 en Allemagne ?

http://www.openstreetmap.org/relation/56393
Là le nom est /Stadtbezirk 05 Au-Haidhausen/ pas /05 Au-Haidhausen/.
Et il faut aussi faire comprendre à Nominatim que quand tu cherches une 
gare à Brest, tu cherches une gare dans la commune de Brest, pas dans le 
département.


L'ergonomie de l'INSEE est assez précisément ce que l

Re: [OSM-talk-fr] Drones et reconnaissance automatique

2016-12-02 Par sujet osm . sanspourriel 

Le 02/12/2016 à 18:21, Christian Quest - cqu...@openstreetmap.fr a écrit :
Il faut par contre bien s'assurer d'une bonne intégration pour qu'il 
n'y ait pas rejet et qu'on puisse bien profiter de ces outils plutôt 
que d'avoir la sensation de les subir. Là, les enjeux économiques de 
certains peuvent faire prendre quelques raccourcis qui poseront 
sûrement problème.

En particulier une entreprise que l'on risque un jour de surnommer MadBox.
Ça me semble le plus gros danger : non pas de plus rien avoir à 
cartographier (ne serait-ce que les horaires d'ouverture, les numéros de 
téléphones sauf à analyser les pages web... en vérifiant la 
compatibilité ODbL) mais ne plus avoir envie de cartographier pour voir 
le bénéfice accaparé par quelques uns.


Le fait d'utiliser les trajets usuels pour suggérer des interdictions de 
tourner induit des comportements moutoniers.
Par exemple une interdiction de tourner "sauf moins de 3,5 t" avait été 
proposée comme simple "interdiction de tourner" par Osmose. Pas de 
soucis tant que c'est fait par un connaisseur.

Je m'étais étonné que OSMAND ne propose pas de passer par là.
Est-ce que suite à Osmose quelqu'un avait mis une interdiction 
inconditionnelle ? Non.
C'est un raccourci fait pour court-circuiter un rond-point, certes la 
mairie peu inspirée a mis un stop sur le raccourci le rendant peu 
efficace mais sauf aux heures de forte affluence ce ribine 
 est 
pratique, le Christian du message initial n'aura pas besoin de suivre le 
lien pour comprendre ;-). Peut-être que le stop est plus pénalisant que 
le cédez-le-pas du rond-point vu la distance gagnée.


"Interdiction de tourner à droite, sauf 3,5 t".
J'aurais bien mis juste un except=hgv sur la relation.
J'ai trouvé un
except=bicycle;moped;motorcar;psv
restriction=no_right_turn

Il me semble que si je décrypte bien le wiki qu'il faudrait :
restriction:conditional=no_right_turn@ (weight>3.5)
poeut être aussi restriction=no_right_turn.
mais le validateur braille sur la clé restriction:conditional (syntaxe 
incorrecte).

Il n'est pas à jour ou je me trompe ?

Fonctionnellement un hgv=no sur la route dans ce sens est équivalent (un 
poids-lourd ne peut y arriver) mais je préfèrerais mettre le bon signe.


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

Re: [OSM-talk-fr] Drones et reconnaissance automatique

2016-12-02 Par sujet Christian Quest 

Le 02/12/2016 à 16:56, Stéphane Péneau a écrit :

Le 02/12/2016 à 15:44, Christian Rogel a écrit :
Aujourd’hui, l’open data, la télédétection, les algorithmes et les 
drones réduisent l’espace dévolu aux contributeurs bénévoles. 
Jusqu’où peut aller cette évolution ?


Je ne pense pas que ces nouvelles techniques réduisent la contribution 
des bénévoles.


La communauté OSM n'acceptera jamais l'intégration en masse de données 
provenant de reconnaissance de panneau, ou de drone, ou de quoique ce 
soit. Ces données sont juste une source d'informations supplémentaires.
En revanche, cela risque de diminuer le relevé sur le terrain, et 
augmenter le "chair-mapping"




Je pense que ces technologies permettront surtout de décharger les 
contributeurs des tâches répétitives et ingrates.


Nous le faisons déjà sans nous en rendre compte quand nous utilisons 
osmose qui à l'aide d'une grosse batteries de tests et d'algorithmes 
nous décharge de la détection d'anomalies et nous permet de consacrer 
notre temps à les corriger plutôt qu'à les chercher.


Il faut par contre bien s'assurer d'une bonne intégration pour qu'il n'y 
ait pas rejet et qu'on puisse bien profiter de ces outils plutôt que 
d'avoir la sensation de les subir. Là, les enjeux économiques de 
certains peuvent faire prendre quelques raccourcis qui poseront sûrement 
problème.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Drones et reconnaissance automatique

2016-12-02 Par sujet Stéphane Péneau 

Le 02/12/2016 à 15:44, Christian Rogel a écrit :
Aujourd’hui, l’open data, la télédétection, les algorithmes et les 
drones réduisent l’espace dévolu aux contributeurs bénévoles. Jusqu’où 
peut aller cette évolution ?


Je ne pense pas que ces nouvelles techniques réduisent la contribution 
des bénévoles.


La communauté OSM n'acceptera jamais l'intégration en masse de données 
provenant de reconnaissance de panneau, ou de drone, ou de quoique ce 
soit. Ces données sont juste une source d'informations supplémentaires.
En revanche, cela risque de diminuer le relevé sur le terrain, et 
augmenter le "chair-mapping"


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

[OSM-talk-fr] Sommet OGP 2016 - Paris 8 décembre 2016 : "Opendata, OpenStreetMap et Géomatique libre pour l'action humanitaire et l'aide au développement au Sud" à l'événement IRD/Convergence Café Lab

2016-12-02 Par sujet nicolas chavent 
Bonjour à tous et à toutes,


Dernier WE avant d'entrer de plein pied dans le 4e Sommet mondial du
Partenariat pour un gouvernement ouvert (OGP) qui se tiendra à Paris la
semaine prochaine du 7 au 9 décembre 2016, une brève annonce d'événement
Opendata (OSM et Libre) en Afrique de l'Ouest ce 8-décembre de 9  11h00 à
la délégation régionale de l’IRD de Bondy, bonne lecture et bon WE.


Parmi les événements centrés sur les pratiques opendata, logiciel libre et
OpenStreetMap au sud pour l'action humanitaire et l'aide au développement,
se tiendra le 8 décembre 2016 de 9h à 11h à la délégation régionale de
l’IRD de Bondy un événement Lab laboo (table ronde) 100% Open Data organisé
par Convergences et l'Institut de Recherche pour le Développement (IRD) sur
le thème de l’exploitation des données ouvertes au service du développement
durable mobilisant des panélistes issus de l'Organisation Internationale de
la Francophonie (OIF), de l'Agence Française pour le Développement (AFD),
de l'IRD, du Bond'Innov et des Libres Géographes (LLG). [1]


Les panélistes échangeront autour de leurs expériences mobilisant les
données ouvertes, OpenStreetMap et la géomatique libre dans les champs de
l’aciton humanitaire et de l'aide au développement en abordant les thèmes
suivants :

- cartographier (en rendant possible une approche de gestion intégrée des
risques) les migrations, les faits de santé (notamment les problématiques
mère-enfants), les accidents de la route, la biodiversité, les pêcheries –
IRD UMR Résilience, Mivegec

- appuyer l’affirmation de communautés OpenStreetMap au sud capables
d’actions opendata locales autonomes et articulées aux programmes des
acteurs de développement (dont l’enseignement supérieur et la recherche) et
de réponses de crise (exemples d’Haïti et de l’Afrique de l’Ouest) - LLG

- Appuyer la production de biens communs numériques libres (OIF DFEN),
favoriser et cartographier l’innovation au sud via projet Carte Innov (OIF
DFEN) et carte des incubateurs Bond’Innov et Patent2net.

- cartographier les projets d’aide au développement et agréger
l’information (AFD)


Exposés et échanges aborderont les problématiques suivantes :

– Comment développer une approche globale/locale d’empowerment
communautaire et de terrain autour du libre, de l’Open Data et d’OSM  au
sud dans un contexte de pauvreté et de crise ?

– Quelles sont les difficultés rencontrées par les acteurs du développement
afin d’opérer dans une logique de contribution volontaire des pays en
développement ? A quelles contraintes locales doivent-ils faire face ? Sur
quelles ressources peuvent-ils s’appuyer ?

– Quelles sont les solutions les plus innovantes en matière de données
ouvertes ? Comment contribuent-elles à la construction d’un monde Zéro
exclusion, Zéro carbone, Zéro pauvreté ?


Pour assister et participer à ces échanges, inscrivez-vous en ligne [2] et
rejoignez la délégation régionale de l’IRD de Bondy accessible depuis la
Gare d’Aulnay par navettes toutes les 10 mn (8h15-11h35).

Adresse :
Campus de l'Innovation pour la Planète
32, avenue Henri Varagnat
93143 Bondy


Excellente fin de journée à tous et toutes
Nicolas


[1] : https://fr.ogpsummit.org/events/cafe-lab-laboo-100-open-data/
[2] : https://www.eventbrite.fr/e/billets-cafe-lab-laboo-100-
open-data-29747406293

-- 
Nicolas Chavent
Projet OpenStreetMap (OSM)
Projet Humanitarian OpenStreetMap Team (HOT)
Projet Espace OSM Francophone (EOF)
Mobile (FRA): +33 (0)6 52 40 78 20
Mobile (CIV): +225 89 97 98 45

Email: nicolas.chav...@gmail.com
Skype: c_nicolas
Twitter: nicolas_chavent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Drones et reconnaissance automatique

2016-12-02 Par sujet Christian Rogel 
Selon Bloomberg, non seulement Apple veut améliorer sa cartographie mondiale 
(visible par « Plans »), mais, elle veut explorer la mise à jour par drones 
pour lesquels elle a demandé une autorisation.
Elle s’intéresse à la cartographie in door (comme Google).
Par ailleurs, il n’y a pas que Mapillary pour s’intéresser à la reconnaissance 
automatique des panneaux routiers. Telenav (anciennement Skobbler) explique que 
la précision de la cartographie sera capitale pour les véhicules autonomes et 
qu’elle ne pourra se contenter d’une mise à jour tous les ans ou plus. 
L’objectif est la mise à jour quotidienne des principaux itinéraires.
Pour cela, il faut relever ce qu’OSM donne de manière très incomplète, les 
panneaux et surtout les restrictions de direction.
L’avenir est donc dans la détection et la construction de cartes basées sur les 
images et l’utisation du deep learning 


Article de blog (en anglais) par Philipp Kandal, « Improve OSM », 
http://blog.improve-osm.org/en/2016/11/a-glimpse-into-the-future-of-mapmaking-with-osm-2/
 . Indiqué dans le dernier Résumé hebdo OSM (n°328)

Ces perspectives amènent à mesurer le chemin parcouru par OSM depuis 2004 :
Au tout début, il n’était question que de s’appuyer sur un appareil 
relativement rustique, le GPS, et uniquement pour la géométrie linéaire de la 
voirie et des bâtiments. Tout le reste était amené par l’observation visuelle 
sur le terrain.
Aujourd’hui, l’open data, la télédétection, les algorithmes et les drones 
réduisent l’espace dévolu aux contributeurs bénévoles. Jusqu’où peut aller 
cette évolution ?
Peut-on se contenter de dire que la Terre est si immense et le nombre d’objets 
à qualifier est si grand qu’il restera toujours un espace de jeu, même pour le 
contributeur lambda ?

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

Re: [OSM-talk-fr] Orthophotographie Hauts-de-Seine

2016-12-02 Par sujet Christian Quest 
Si tu as un contact, il ne faut pas oublier de leur dire qu'on peut
diffuser nous même pour l'usage des contributeurs OSM si c'est la mise en
place d'un tuilage qui leur pose problème.

Le 1 décembre 2016 à 22:53, Donat ROBAUX  a écrit :

> Bonjour à tous,
>
> Une bonne nouvelle se profile pour l'année prochaine! Enjoy!
>
> @ suivre
>
>
>
>
>
>
>
> *L'ouverture en Open data des orthophotographies départementales est
> actuellement à l'étude. Cette ouverture de données géographiques pose des
> problématiques techniques importantes notamment liées à la volumétrie des
> données à traiter ainsi qu'à la définition d'un mode d'ouverture adapté à
> tous : Grand public et professionnels de l'information géographique. Nous
> travaillons activement à la définition de ce scénario de mise en ligne en
> tenant compte des différentes contraintes afin de vous proposer ce volume
> important de données sur la plateforme open data. Le Département prévoit
> leur ouverture dans le courant du 1er semestre 2017.En espérant avoir
> répondu à vos attentes,Bien cordialement,L'équipe Open data du Département
> des Hauts-de-Seine*
>
> ___
> 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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Prochaine ouverture de la base SIRENE...

2016-12-02 Par sujet Christian Quest 
Bonjour,

J'ai fait ça TRES rapidement (genre 1h). C'est donc très expérimental et
surtout redondant avec les outils d'intégration opendata d'osmose.

Le géocodage peut être effectivement approximatif et ne pas trouver une
pharmacie sur la seule proximité géographique. Il faut ajouter un
rapprochement par le nom et/ou le code SIRET (ref:FR:SIRET et pas
ref:fr:SIRET, FR=France, fr=français).

Malgré ces limitations, j'ai pu compléter en grande partie les pharmacies
sur le 89, le 94, le 77 là où l'adresse d'origine contient un numéro à
quelques exceptions près.

L'absence de pharmacie dans OSM est en plus un bon indicateur indirect
d'une zone pas trop entrenue... il m'est souvent arrivé de compléter du
coup beaucoup de choses aux alentours parfois sur des villes de taille
moyenne.


Le 1 décembre 2016 à 22:39, Laurent Combe  a écrit :

> qu'est ce qui est attendu ?
> un exemple :
> http://osmose.openstreetmap.fr/fr/map/#item=7170&class=99&;
> zoom=18&lat=43.840323&lon=1.390494&layer=Mapnik&overlays=
> T
>
> on a un signalement osmose
> en bas de page et la pharmacie correspondante en haut
>
> - le géocodage est erroné alors que la voie 'impasse de la halle' est
> correctement nommé
> - approximativement 250m d'écart entre les 2 points
> - que faire : signaler un faux positif sur osmose ?
> - mais sur quoi se fait le rapprochement ?
> dans OSM seul le nom de la pharmacie (visible depuis le terrain) a été
> saisie dans le point issu de la base SIRENE je ne vois rien de
> ressemblant
>
> Laurent
>
> Le 15 novembre 2016 à 19:48, Christian Quest  a
> écrit :
> > Voilà un rapide exemple de croisement OSM/SIRENE qui montre dans osmose
> les
> > pharmacies présentes dans SIRENE, mais absente dans OSM.
> >
> > http://osmose.openstreetmap.fr/fr/map/#item=7170&class=99&;
> zoom=10&lat=47.3518&lon=0.711
> >
> > Bien sûr, ce n'est pas fiable à 100%:
> > - la position déterminée par le géocodage de l'adresse présente dans
> SIRENE
> > peut être incorrecte
> > - l'adresse dans SIRENE peut être différente du réel lieu d'activité
> (même
> > si en principe c'est pas la cas)
> > - les données SIRENE datent du mois de juin, ça a pu changer sur le
> terrain
> > entre temps, mais à partir de janvier on aura des données au jour le
> jour...
> >
> > J'ai fait ça ce matin pendant le hackathon où je n'ai pas pu rester
> > (rencontre géo des SDIS l'après-midi à Dunkerque avec Gaël).
> > C'est à affiner et à généraliser à d'autres type de POI. Un autre
> croisemet
> > à faire est l'inverse... un POI présent dans OSM, mais absent de
> SIRENE...
> >
> >
> > Le 10 novembre 2016 à 19:41, Christian Quest  a
> > écrit :
> >>
> >> Les mises à jour de la base seront... quotidiennes !
> >>
> >> Par contre, la longueur du tuyau est courte pour les créations, mais
> bien
> >> plus longue pour les suppressions.
> >>
> >> Quand un établissement apparaît dans la base, il peut ne démarrer son
> >> activité qu'un peu plus tard, mais quand il cesse d'activité, ça peut
> >> prendre pas mal de temps avant que ça sorte de la base SIRENE.
> >>
> >> C'est donc une source à confirmer sur le terrain, d'où l'idée d'une
> appli
> >> thématique.
> >>
> >>
> >> Le 10 novembre 2016 à 19:35, Tyndare  a écrit :
> >>>
> >>>
> >>> Super nouvelle cette ouverture !
> >>>
> >>> J'ai la sensation que les commerces sont une des données d'OSM qui se
> >>> périment le plus vite, la durée avant un déménagement, un changement
> de nom
> >>> et de propriétaire ou malheureusement une fermeture est assez courte en
> >>> moyenne.
> >>>
> >>> Je ne sais pas comment est structurée la base, mais si certains se
> >>> lancent dans un outil, je pense qu'il serait très utile de prévoir de
> >>> détecter et mettre en valeur les changements au cours du temps,
> notamment
> >>> les enregistrements qui disparaissent de la base...
> >>>
> >>> Tyndare.
> >>>
> >>>
> >>>
> >>> On 10/11/2016 18:25, Christian Quest wrote:
> 
>  La base SIRENE de l'INSEE sera disponible en opendata début janvier
>  prochain.
> 
>  Cette base contient plus de 10 millions d'enregistrements concernant
> les
>  "personnes morales": sociétés, entreprises, associations, etc.
> 
>  Un hackathon aura lieu mardi prochain (15/11) à Paris un peu en avant
>  première de l'ouverture du jeu de données.
> 
>  Ce sera une source très intéressante pour compléter et mettre à jour
> OSM
>  sur les commerces et artisans. Je n'ai pas encore regardé ce que ça
>  donnait, je suis en train de terminer son géocodage (avec BAN et
> BANO).
> 
>  Il y a de quoi alimenter soit osmose, soit un outil dédié, le plus
>  simple possible, si possible mobile pour faire de la validation sur le
>  terrain... un peu comme ce dont parle Florian dans son billet de blog
> du
>  jour:
>  http://florian.lainez.fr/la-fin-de-google-map-maker-et-le-
> futur-des-outils-carto/
> 
>  A suivre !
> 
>  --
>  Christian Quest - OpenStreetMap France
> >