Re: [OSM-talk-fr] Point adresse à Montpellier

2012-02-09 Par sujet Pieren
2012/2/9 isnogoud :

> - la licence décrite ici est-elle effectivement compatible avec OSM ? Il
> s'agit de la licence adoptée par ETALAB.

Rien n'indique d'incompatibilité avec OSM dans ce que j'ai pu lire. Il
faut juste respecter leur demande de mentionner la paternité et la
date de fraicheur (tag 'source').

>     - le code postal pour chaque adresse n'est pas fourni à Montpellier

Le code postal n'est pas nécessaire sur chaque adresse.

>     - quelle mention pour la source ?  Ville de Montpellier 02/2012 ?
Si c'est mentionné nul part, il faudrait contacter la source pour le savoir.

Pieren

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


Re: [OSM-talk-fr] Point adresse à Montpellier

2012-02-09 Par sujet rldhont

Avant tout import, une petite analyse des données brutes est nécessaire.

La ville de Montpellier fourni aussi son référentiel de rue ainsi que 
l'ensemble des passages piétons de la ville. J'avais déjà pratiqué une 
petite analyse des données des passages piétons et il se trouve que la 
position peut laisser à désirer.
Dans le référentiel de rue, chaque rue est découpé en tronçon reliant 2 
intersections qui se suivent. Ensuite chaque tronçon porte un CODE_VOIE 
qui permet d'identifier la voie et qui sert de clef étrangère pour lier 
d'autres éléments dont les passages piétons et les adresses.
Et donc si on utilise ce CODE_VOIE pour lier un passage piéton ou une 
adresse à sa rue on peut avoir quelques surprises. C'est ainsi que 26323 
adresses se trouvent à plus de 11 mètres de la rue à laquelle elle est 
associé d'après le CODE_VOIE. D'ailleurs ce CODE_VOIE à servi à créer 
l'adresse.


Pour finir l'analyse :
* la majorité des adresses se trouvent à moins de 100 mètres
* 5215 adresses se trouvent à plus de 500 mètres de leur rue
* 2245 adresses se trouvent à plus de 1 km de leur rue
* 524 adresses se trouvent à plus de 2 km de leur rue
* 70 adresses se trouvent à plus de 3 km de leur rue
* 5 adresses se trouvent à plus de 5 km de leur rue

Avant tout import il faut déjà supprimer tous les points mal placés, non ?

René-Luc
3Liz
Montpelliérain


Le 09/02/2012 09:24, Pieren a écrit :

2012/2/9 isnogoud:


- la licence décrite ici est-elle effectivement compatible avec OSM ? Il
s'agit de la licence adoptée par ETALAB.

Rien n'indique d'incompatibilité avec OSM dans ce que j'ai pu lire. Il
faut juste respecter leur demande de mentionner la paternité et la
date de fraicheur (tag 'source').


 - le code postal pour chaque adresse n'est pas fourni à Montpellier

Le code postal n'est pas nécessaire sur chaque adresse.


 - quelle mention pour la source ?  Ville de Montpellier 02/2012 ?

Si c'est mentionné nul part, il faudrait contacter la source pour le savoir.

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] JOSM 4878 & changelog en français + spam à gogo

2012-02-09 Par sujet teuxe
Bonjour,

Combien de temps avant que "le nécessaire" fasse effet ? Les spams sont 
toujours affichés...

Teuxe


- Mail Original -
De: "Marc SIBERT" 
À: "Discussions sur OSM en français" 
Envoyé: Mercredi 8 Février 2012 00h41:30 GMT +01:00 Amsterdam / Berlin / Berne 
/ Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] JOSM 4878 & changelog en français + spam à gogo


Vu, 

Christian Q. qui est sur place vient de faire ne nécessaire. 

A+ 


-- 
Marc Sibert 
m...@sibert.fr 


Le 7 février 2012 22:56, Christian Rogel < christian.ro...@club-internet.fr > a 
écrit : 






Le 7 févr. 2012 à 20:49, Vincent Privat a écrit : 


Bonsoir, 

Je profite de la toute récente apparition du nouveau format d'historique de 
versions de JOSM pour faire ma première contribution au site OSM-FR :) 

http://www.openstreetmap.fr/blogs/vincent-privat/josm-4878-disponible-changelog-en-fran-ais
 



Du coup, j'ai regardé la page des blogs. 


http://www.openstreetmap.fr/blog 


C'est passionnant, ça parle de Carlos Tevez et de chaussures Nike requin, pour 
faire des mapping parties le jour du carnaval? 


Qui est le mandataire anti-spam à OSM France? 




Christian (sans tirets) 
___
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] Openstreetmap chez les cm1 cm2

2012-02-09 Par sujet Nicolas Dumoulin
Salut,

Super retour d'expérience, ça fait envie :-)

Le Mardi 7 Février 2012 22:26:35 simon a écrit :
> Une seule limite me fait peur pour la prochaine intervention, le fait de ne
> pas pouvoir dessiner avec Openstreetbug, le groupe OSM Tours réfléchie a un
> un remplaçant qui inclurait ces fonctionnalités (Emmanuel les enfant
> attende une solution :D ), mais si un des gentil développeur de talk-fr se
> sentais motivé pour faire des miracles il serais le bienvenue.

Qu'entends-tu par « dessiner » ? Tu veux dire pouvoir dessiner et annoter un 
polygone, une polyligne (ça faisait longtemps ;-) ) en plus du point déjà 
possible ?

Merci encore

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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


Re: [OSM-talk-fr] JOSM 4878 & changelog en français + spam à gogo

2012-02-09 Par sujet Marc SIBERT
Le 7 février 2012 22:56, Christian Rogel
a écrit :

>
> Le 7 févr. 2012 à 20:49, Vincent Privat a écrit :
>
> Bonsoir,
>
> Je profite de la toute récente apparition du nouveau format d'historique
> de versions de JOSM pour faire ma première contribution au site OSM-FR :)
>
>
> http://www.openstreetmap.fr/blogs/vincent-privat/josm-4878-disponible-changelog-en-fran-ais
>
>
> Du coup, j'ai regardé la page des blogs.
>
> http://www.openstreetmap.fr/blog
>
> C'est passionnant, ça parle de Carlos Tevez et de chaussures Nike requin,
> pour faire des mapping parties le jour du carnaval?
>
> Qui est le mandataire anti-spam à OSM France?
>
>
> Christian (sans tirets)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
> Voilà, c'est corrigé. Merci de ta vigilance.

Le captcha en place à l'air un peu faible.

A+

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


[OSM-talk-fr] Traduction des toponymes et lieux assistée par Wikipedia

2012-02-09 Par sujet Ab_fab
Bonjour,

Je suis tombé sur ce changeset via OWL ce matin :
http://www.openstreetmap.org/browse/changeset/10530670

qui donne comme référence de contribution cette page du Toolserver :
http://toolserver.org/~kentaur/osm_wp/show_osm_wp.php

L'idée est de trouver la correspondance de la balise "name" avec un article
de Wikipedia, et de tirer profit des traductions existantes pour ce même
article pour assister l'ajout des balises dans d'autres langues (par
exemple name:fr)

L'idée est sympa, et ce genre de démarche m'a déjà trotté dans la tête.
On s'aperçoit vite de quelques limitations de l'outil, qu'il faut manipuler
avec pas mal de pincettes :

Pour un édifice public, le titre de l'article Wikipedia doit préciser la
ville où il se situe. Ici pour Hanovre
Or, la description de la balise "name" existante n'indique que la nature de
l'édifice (Opera, ou gare centrale) car il est évident à la lecture de la
carte qu'on se trouve à Hanovre.

4816459 de
Hannover_Hauptbahnhof 
Hauptbahnhof*Gare centrale de Hanovre*
4816458 de
Opernhaus_Hannover 
Opernhaus*Opéra de Hanovre*

Pour les cours d'eau, la règle qui fait précéder le nom par un article : **
la ** Seine n'est pas respectée dans Wikipedia.
En cliquant (trop vite) sur OK, le risque est donc de se retrouver avec une
balise name:fr qui apporte une info de moins bonne qualité que la balise
"name"
(et qui plus est inutile puisque dans la même langue)

73338097 fr
Altier_(rivière) 
L'Altier*Altier*

L'outil mériterait un champ pour proposer manuellement une description
alternative à celle proposée qui permettrait d'avoir une valeur juste dans
OSM et de retirer la ligne de la liste.

L'outil est puissant et potentiellement utile. On peut peut être le
regarder plus dans le détail pour trouver des améliorations.
Mais également être vigilant sur les contributions un peu trop hâtives, en
particulier quand elles viennent de l'étranger.

-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Traduction des toponymes et lieux assistée par Wikipedia

2012-02-09 Par sujet Pieren
2012/2/9 Ab_fab 

>
> (et qui plus est inutile puisque dans la même langue)
>
>
>
Cet outil ne devrait pas ajouter de "name:fr" en France. C'est
contre-productif et dangereux (doublon, risque de dichotomie, à l'encontre
des pratiques actuelles et des éditeurs).
Moi, je serais partisan de les supprimer systématiquement dans l'hexagone.

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


Re: [OSM-talk-fr] Traduction des toponymes et lieux assistée par Wikipedia

2012-02-09 Par sujet Vincent de Chateau-Thierry

> De : "Pieren" 

> 2012/2/9 Ab_fab 
> 
> >
> > (et qui plus est inutile puisque dans la même langue)
> >
> >
> >
> Cet outil ne devrait pas ajouter de "name:fr" en France. C'est
> contre-productif et dangereux (doublon, risque de dichotomie, à l'encontre
> des pratiques actuelles et des éditeurs).
> Moi, je serais partisan de les supprimer systématiquement dans l'hexagone.
> 

Dans l'hexagone d'accord, mais peut-être pas au bord :-)

Taginfo France compte un millier de name:fr :
http://taginfo.openstreetmap.fr/keys/name:fr#values

et les 3 valeurs les plus récurrentes sont sur des objets frontaliers :
"Frontière franco-suisse", "Le Rhin" et "La Moselle".

== début de HS ==
Cela dit, on peut de demander si sur une limite administrative, le tag "name" 
tout court 
est pertinent. Pour moi non, il devrait être déduit des noms des emprises
administratives auxquelles il participe, et pas stocké en dur. Libre à chaque 
utilisateur 
de construire le nom qu'il veut, dans la langue qu'il veut, et avec le niveau
administratif qu'il souhaite.
== fin de HS ==

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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


Re: [OSM-talk-fr] Contact avec un service SIG dans l'Aisne

2012-02-09 Par sujet Philippe Pary
Le 08/02/2012 23:02, Brice a écrit :
> A l'occasion d'un déplacement professionnel, j'ai
> discuté aujourd'hui avec le responsable SIG d'une ville moyenne.
> Il connaissait déjà relativement bien OSM.
> 
> Il serait, pour sa part, assez favorable à engager une démarche avec la
> communauté OSM mais doit bien évidemment au préalable en discuter avec
> sa hiérarchie (son directeur puis les élus). Je pense que mon passage
> l'encouragera à engager le dialogue avec ceux-ci.
> 
> Je le reverrai peut-être la semaine prochaine mais d'ici là il m'a
> demandé quelques éléments pour avancer dans sa réflexion :
> - des éléments sur le "contrôle qualité" dans OSM
> - le modèle de données d'OSM
> Quelles sont d'après vous les meilleures pages du wiki (ou autre ?) à
> transmettre pour répondre à ceci ?
> 
> Par ailleurs, y a t'il des OSMeurs, dans l'Aisne ou Nord-Aisne,
> intéressés pour suivre ce dossier ?

J'ai un intérêt sentimental pour cette zone (je suis natif de St
Quentin) et je vis pas méga-loin (Lille) donc ça m'intéresse.

Mais étant donné que je suis un professionnel ce n'est peut-être pas
opportun, je te laisse me dire quoi.

Philippe

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


Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

2012-02-09 Par sujet Philippe Verdy
Le 9 février 2012 06:35, Vincent de Chateau-Thierry  a écrit :
> Bonjour,
>
> Le 09/02/2012 01:28, Philippe Verdy a écrit :
>
>> Le 8 février 2012 20:55, Vincent de Chateau-Thierry  a
>> écrit :
>>>
>>>
>>>
>>> Le 08/02/2012 18:30, Philippe Verdy a écrit :


 (...)


  Notes ===

 Ne vous fiez pas forcément aux données affichées dans le mode plan
 vectoriel de Google Maps : il y a de nombreuses erreurs et
 approximations sur les noms de voies,
>>>
>>>
>>>
>>> Se fier à des données des plans sous copyright Google ou © Bing serait en
>>> effet une très mauvaise idée, et ce quelle que soit leur qualité ou leurs
>>> approximations. L'incompatibilité de licence intervient bien avant la
>>> qualité.
>>
>>
>> Là je ne parlais pas des données du plan, mais des *photos* de plein
>> pied prises par les "Google Cars",
>
>
> Soit. Mais dans ce cas, évite d'appeler "mode plan vectoriel" une photo :-)

Non je ne me suis pas trompé. Ta citation est incorrecte et mélange
les phrases hors contexte, pour leur faire dire le contraire.

J'ai parlé de deux choses séparées au moment où je disais de ne pas
utiliser le mode plan vectoriel comme source de données : car cela
n'excluait pas de consulter les photos de plein pied du mode "street
view" non pas pour y lire aussi un libellé ajouté par Google en
surimpression, mais pour regarder les plaques de rues ou la
signalisation qui sont sur les photos elles-mêmes.

On n'importe pas non plus ces photos (qui sont sous copyright,
concernant la prise de vue, mais pas ce qu'elles représentent qui sont
des objets dont Google n'est pas propriétaire).

On a le droit de regarder ces photos, ne serait-ce que pour contrôler
une orthographe, voire trouver un nom oublié dans OSM et qui n'est pas
forcément juste non plus dans le mode plan vectoriel de Google Maps
qui a aussi de nombreuses erreurs, malgré les photos. Google l'admet
lui-même, en mentionnant souvent "adresse approximative" ; car son
mode plan vectoriel (visible aussi en surimpression sur l'imagerie
aérienne et sous forme de libellés en perspective sur les photos du
mode streetview) est un gruyère avec des trous informes, bien qu'il
faut lui reconnaître une bonne qualité de sa géométrie (au moins sur
les rues qui ont été parcourues de plein pied, alors que les autres
voies dessinées sont parfois des approximations aussi depuis la vue
aérienne, avec des voies farfelues en surnombre).

Hors toi tu sembles dire que même regarder ces photos c'est "pécher".
Ce n'est qu'une source intéressante de comparaison, mais on n'en
prends directement aucune données. C'est un élément utile comme le
seraient d'autres sources. Lire une plaque de rue sur une photo, qui
que soit celui qui a pris la/les photo(s) et avec pour chacun son
copyright, ne change rien au statut de l'objet de la voie publique sur
la photo, c'est le même objet dont le photographe ne s'approprie pas
la propriété simplement par son cliché.

Je note aussi que même ceux qui vont sur place enquêter, ou qui
connaissent en apparence bien un lieu, se trompent aussi sur certains
noms, et on trouve des fautes d'orthographe à foison. On en trouve
aussi parmi les données interprétées en lisant le cadastre, qui
omettent des accents, insèrent des abréviations, confondent des
homonymes, délimitent mal une rue à une extrémité, ou associent une
voie parallèle au même nom que la rue principale quand ce n'est pas le
cas (ce cas est courant aussi sur les grandes places quand les
intersections et accès forment un système complexe de voies
principales, voies de service, chemins piétons : sans regarder la
signalisation sur place, difficile de se fier à un plan général,
surtout quand on est piéton, même avec une carte OSM qui privilégie
encore trop la circulation en voiture pour simplifier le reste).

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


Re: [OSM-talk-fr] Openstreetmap chez les cm1 cm2

2012-02-09 Par sujet Eric
Le temps de prise en compte des modifs sur le rendu Mapnik est
effectivement frustrant au début où je languissais de voir le résultat
pour contrôler si j'avais pas fait de bêtises. J'ai vu sur la liste la
procédure qui permettait via un "/DIRTY" de forcer une regénération
prioritaire de la tuile et ca, c'est pratique !

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


Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

2012-02-09 Par sujet Pieren
2012/2/9 Philippe Verdy :

> Non je ne me suis pas trompé. Ta citation est incorrecte et mélange
> les phrases hors contexte, pour leur faire dire le contraire.

Je vais donc reprendre le texte original exact:
"Ne vous fiez pas forcément aux données affichées dans le mode plan
vectoriel de Google Maps : il y a de nombreuses erreurs et
approximations sur les noms de voies, non corrigées malgré la présence
de photos dans son mode "Street View", et souvent Google Maps (Bing
aussi...)"

Pour reprendre ton vocabulaire, il n'y a pas à "se fier aux données
affichées dans le mode plan vectoriel qui contiendraient des
erreurs/approximations" parce que, comme l'ont dit les autres, on n'a
pas à s'en servir.
Le fait est que dans ton message, tu passes allègrement de gmaps à
streetview alors que, comme tu l'indiques justement plus-tard, leur
utilisation pour OSM peut être différenciée.
Il y a cependant deux points que je veux corriger:
- le contenu des photos streetview ne peuvent être réutilisées de
manière automatique ou massive. Car si le contenu des photos
n'appartient pas à Google comme tu le dis, ça n'est pas le cas de leur
collection et géoréférencement. Nous en avons d'ailleurs la
confirmation écrite par Ed Parsons lui-même ("so checking the odd
street names is OK.. but every street name I would suggest would
represent a bulk feed") comme cela a été mentionné à plusieurs
reprises sur cette liste.
- tu mentionnes les erreurs dans les diverses sources. Il faut aussi
mentionner les plaques de rues qui peuvent, elles aussi, parfois se
tromper (dans l'orthographe ou même dans la dénomination). C'est très
rare mais on doit pouvoir trouver quelques exemples dans les archives.
Il faut donc toujours prendre toutes nos sources avec précaution et ne
pas oublier que l'une de nos devises "c'est le terrrain qui prime"
s'applique "en cas de doute".

Pieren

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


Re: [OSM-talk-fr] Openstreetmap chez les cm1 cm2

2012-02-09 Par sujet monsieur a
Le 9 févr. 2012 10:31, "Nicolas Dumoulin" <
nicolas_openstreetmap@dumoulin63.net> a écrit :
>
> Salut,
>
> Super retour d'expérience, ça fait envie :-)
>
> Le Mardi 7 Février 2012 22:26:35 simon a écrit :
> > Une seule limite me fait peur pour la prochaine intervention, le fait
de ne
> > pas pouvoir dessiner avec Openstreetbug, le groupe OSM Tours réfléchie
a un
> > un remplaçant qui inclurait ces fonctionnalités (Emmanuel les enfant
> > attende une solution :D ), mais si un des gentil développeur de talk-fr
se
> > sentais motivé pour faire des miracles il serais le bienvenue.
>
> Qu'entends-tu par « dessiner » ? Tu veux dire pouvoir dessiner et annoter
un
> polygone, une polyligne (ça faisait longtemps ;-) ) en plus du point déjà
> possible ?
>
Oui c'est bien cela.

Dans ce cadre j'ai choisi délibérément de ne pas leur expliquer les outils
d'éditions et de priviligier une approche de type openstreetbug.
Pour l'instant uniquement sur papier et dans les prochaines séances en
ligne.

Je me suis rendu compte aussi que quelques adultes accompagnants étaient
prêt a contribuer sur openstreetbug, mais pas a prendre en main les outils
d'Edition.

> Merci encore
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> 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


[OSM-talk-fr] Re : Openstreetmap chez les cm1 cm2

2012-02-09 Par sujet THEVENON Julien
 De : Eric 

 Le temps de prise en compte des modifs sur le rendu Mapnik est
 effectivement frustrant au début où je languissais de voir le résultat
 pour contrôler si j'avais pas fait de bêtises. J'ai vu sur la liste la
 procédure qui permettait via un "/DIRTY" de forcer une regénération
 prioritaire de la tuile et ca, c'est pratique !

Et encore maintenant s en sort la plupart du temps en quelques secondes/minutes 
pour rafraichir une tuile
Quand je me suis inscrit sur le projet le rafraichissement avait lieu une fois 
par semaine !

Julien



>
> De : Eric 
>À : Discussions sur OSM en français  
>Envoyé le : Jeudi 9 février 2012 13h44
>Objet : Re: [OSM-talk-fr] Openstreetmap chez les cm1 cm2
> 
>Le temps de prise en compte des modifs sur le rendu Mapnik est
>effectivement frustrant au début où je languissais de voir le résultat
>pour contrôler si j'avais pas fait de bêtises. J'ai vu sur la liste la
>procédure qui permettait via un "/DIRTY" de forcer une regénération
>prioritaire de la tuile et ca, c'est pratique !
>
>___
>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] Vérification Osmose: nettoyage des imports routiers, champs redondants

2012-02-09 Par sujet Emilie Laffray
+1 pour Pieren
On Feb 9, 2012 12:53 PM, "Pieren"  wrote:

> 2012/2/9 Philippe Verdy :
>
> > Non je ne me suis pas trompé. Ta citation est incorrecte et mélange
> > les phrases hors contexte, pour leur faire dire le contraire.
>
> Je vais donc reprendre le texte original exact:
> "Ne vous fiez pas forcément aux données affichées dans le mode plan
> vectoriel de Google Maps : il y a de nombreuses erreurs et
> approximations sur les noms de voies, non corrigées malgré la présence
> de photos dans son mode "Street View", et souvent Google Maps (Bing
> aussi...)"
>
> Pour reprendre ton vocabulaire, il n'y a pas à "se fier aux données
> affichées dans le mode plan vectoriel qui contiendraient des
> erreurs/approximations" parce que, comme l'ont dit les autres, on n'a
> pas à s'en servir.
> Le fait est que dans ton message, tu passes allègrement de gmaps à
> streetview alors que, comme tu l'indiques justement plus-tard, leur
> utilisation pour OSM peut être différenciée.
> Il y a cependant deux points que je veux corriger:
> - le contenu des photos streetview ne peuvent être réutilisées de
> manière automatique ou massive. Car si le contenu des photos
> n'appartient pas à Google comme tu le dis, ça n'est pas le cas de leur
> collection et géoréférencement. Nous en avons d'ailleurs la
> confirmation écrite par Ed Parsons lui-même ("so checking the odd
> street names is OK.. but every street name I would suggest would
> represent a bulk feed") comme cela a été mentionné à plusieurs
> reprises sur cette liste.
> - tu mentionnes les erreurs dans les diverses sources. Il faut aussi
> mentionner les plaques de rues qui peuvent, elles aussi, parfois se
> tromper (dans l'orthographe ou même dans la dénomination). C'est très
> rare mais on doit pouvoir trouver quelques exemples dans les archives.
> Il faut donc toujours prendre toutes nos sources avec précaution et ne
> pas oublier que l'une de nos devises "c'est le terrrain qui prime"
> s'applique "en cas de doute".
>
> 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


[OSM-talk-fr] Le Mans Métropole & Open Data

2012-02-09 Par sujet Romain MEHUT
Délibération aujourd'hui de la communauté urbaine...
http://www.lemainelibre.fr/actualite/le-virage-numerique-du-mans-08-02-2012-28761

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


Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

2012-02-09 Par sujet Christian Rogel

Le 9 févr. 2012 à 13:52, Pieren a écrit :

> Nous en avons d'ailleurs la
> confirmation écrite par Ed Parsons lui-même ("so checking the odd
> street names is OK.. but every street name I would suggest would
> represent a bulk feed") comme cela a été mentionné à plusieurs
> reprises sur cette liste.

Paroles verbales sans portée pour un ajout discontinu. 
Il pourrait tout juste faire semblant de se fâcher, si quelque faisait un 
import massif
("bulk feed") par détection automatique des noms, le tout dans une courte 
séquence de temps.

il ne faut pas croire tout ce que racontent les gens, surtout, ceux qui ont un 
monopole à défendre.
Orange laisse entendre que Free n'est pas au top, alors qu'eux sont les purs 
croisés
du service mobile.
Les croyez-vous, les uns et les autres?


Christian

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


[OSM-talk-fr] le projet openBmap à besoin d'aide

2012-02-09 Par sujet piratebab
Bonjour,
le projet openBmap est un projet libre qui consiste à relever les
antennes de téléphonie mobiles et les points wifi. L'objectif est
ensuite de s'en servir pour faire de la géolocalisation lorsque le GPS
n'est pas disponible.C'est un projet dont la philosophie se rapproche
d'OSM, et d'ailleurs il en utilise les cartes.
http://www.openbmap.org/with_osm6.php5?mcc=208&mnc=10&step=2

C'est un projet que je trouve très intéressant, qui permet d'obtenir des
données que les opérateurs ne diffusent pas (opendata, quand tu nous
tiens ...)

Mais le projet est à la recherche d'aide pour continuer.
Si cela vous intéresse: http://openbmap.org/openbmap_evolution.php5




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


Re: [OSM-talk-fr] Vérification Osmose: nettoyage des imports routiers, champs redondants

2012-02-09 Par sujet Philippe Verdy
Le 9 février 2012 13:52, Pieren  a écrit :
> Il y a cependant deux points que je veux corriger:
> - le contenu des photos streetview ne peuvent être réutilisées de
> manière automatique ou massive. Car si le contenu des photos
> n'appartient pas à Google comme tu le dis, ça n'est pas le cas de leur
> collection et géoréférencement.

Sauf que je n'ai pas dit le contraire, je n'ai justement fait que
défendre cela, le géoréférencement et toutes autres données ajoutées
au delà des prises de vues elles-mêmes est sujet à caution, d'abord
parce qu'effectivement ces données sont propriétaires, mais aussi
entâchées d'erreurs, ce que je 'ai souligné aussi.

Malgré tout, les plaques de rue sont certainement plus fiables que
bien d'autres sources (y compris le cadastre), et en attendant bien
plus fiables que ce qu'aurait noté par erreur quelqu'un sur le
terrain, et qui a introduit ses propres erreurs, ne serait-ce que de
façon involontaire par une faute de frappe. C'est d'ailleurs ce type
d'erreurs qui justement frappe aussi les labels affichés dans Google
Maps qui précise bien "adresse approximative" parce que Google ne les
a pratiquement jamais vérifiées par d'autres sources et qu'il attend
qu'on les lui signale.

Si une plaque de rue ou une signalisation est erronée c'est
extrêmement rarement une erreur : ce qui peut se passer est plus
souvent qu'une plaque a été oubliée et pas changée après un changement
de nom. C'est en revanche plus fréquent sur des panneaux indicateurs
vers des destinations plus lointaines, raison de plus pour aller
regarder une dénomination sur place.

De plus je ne qualifierait pas comme "erreur" le fait qu'une plaque de
rue ou un panneau d'entrée d'agglomération mentionne un nom ou une
orthographe alternative. Cela veut dire que ce nom reste en usage
aussi (et même bon nombre de collectivités continuent à utiliser des
graphies voire des noms alternatifs pour se désigner elles-mêmes dans
leurs publications, alors que l'enregistrement officiel (type Insee)
utilise un autre nom ou une autre graphie et omet celle utilisée par
la collectivité.

Car l'Insee peut aussi ne pas être (encore) à jour sur la dernière
version de sa base de données. Ensuite il n'y a pas que l'Insee même
si en principe le COG fait autorité pour les autres services de l'Etat
et des collectivités. Ces incohérences momentanées surviennent, et
alors il ne reste que la publication dans le Journal Officiel
mentionnant le texte de la décision de changement ou d'attribution de
nom.

Pour les autres noms qui ne désignent pas une collectivité publique,
notamment les tonomymes locaux, l'Insee n'établit pas de réference. Il
reste alors l'IGN en second lieu. Parfois l'IGN mentionne aussi des
noms différents pour les toponymes associés à une collectivité, parce
que cela correspond à une longue tradition, ou parce que ce nom a
longtemps été officiel, et parce qu'il est toujours utilisé et encore
référencé dans des documents qui font encore foi.

Dans tous ces cas, j'ai de très forts doutes sur la capacité de ceux
qui "vont sur le terrain" et rapportent des données en contradiction
avec ce qu'on trouve sur des plaques de rues et panneaux indicateurs,
ou se fient seulement à leur mémoire ou connaissance pour transcrire
des noms et orthographes approximatifs. Il faut admettre qu'eux aussi
font des erreurs, et même bien plus souvent que ce qu'on trouve sur
les panneaux (que moi je ne mettrai JAMAIS en doute SAUF si on me
donne un texte réellement officiel tel qu'un arrêté publié au JORF, et
qui prévaudra sur tout ce qui figure dans n'importe quelle base de
données, fusse-t-elle de l'Insee ou de l'IGN).

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


Re: [OSM-talk-fr] Point adresse à Montpellier

2012-02-09 Par sujet isnogoud

Le 09/02/2012 09:48, rldhont a écrit :

Avant tout import, une petite analyse des données brutes est nécessaire.

La ville de Montpellier fourni aussi son référentiel de rue ainsi que 
l'ensemble des passages piétons de la ville. J'avais déjà pratiqué une 
petite analyse des données des passages piétons et il se trouve que la 
position peut laisser à désirer.
Dans le référentiel de rue, chaque rue est découpé en tronçon reliant 
2 intersections qui se suivent. Ensuite chaque tronçon porte un 
CODE_VOIE qui permet d'identifier la voie et qui sert de clef 
étrangère pour lier d'autres éléments dont les passages piétons et les 
adresses.
Et donc si on utilise ce CODE_VOIE pour lier un passage piéton ou une 
adresse à sa rue on peut avoir quelques surprises. C'est ainsi que 
26323 adresses se trouvent à plus de 11 mètres de la rue à laquelle 
elle est associé d'après le CODE_VOIE. D'ailleurs ce CODE_VOIE à servi 
à créer l'adresse.


Pour finir l'analyse :
* la majorité des adresses se trouvent à moins de 100 mètres
* 5215 adresses se trouvent à plus de 500 mètres de leur rue
* 2245 adresses se trouvent à plus de 1 km de leur rue
* 524 adresses se trouvent à plus de 2 km de leur rue
* 70 adresses se trouvent à plus de 3 km de leur rue
* 5 adresses se trouvent à plus de 5 km de leur rue



Merci pour cette analyse détaillée qui m'a amené à regarder de plus près 
les résultats des traitements sur Montpellier.


Pour associer une adresse à une rue d'OSM, je procède comme suit :
- calculer le barycentre des adresses de chaque rue de l'opendata.
- calculer le barycentre de chaque rue d'OSM (highway avec un name 
renseigné sur le secteur de Montpellier)
- calculer la distance de l'adresse la plus éloignée du barycentre des 
adresses de la rue

- associer les rues d'OSM et les rues de l'opendata par proximité du nom.
Fabien Poulard m'a suggéré quelques pistes. J'ai retenu l'identité de 
SOUNDEX et une distance de Levenshtein < 3. Cela permet de tenir compte 
des fautes de frappe éventuelles.


Pour Montpellier, les calculs donnent :

2 663 rues avec des barycentres distants de moins de 100 m.
3 446 rues avec des barycentres distants de moins de 500 m
3 592 rues avec des barycentres distants de moins de 1 000 m
3 651 rues avec des barycentres distants de moins de 2 000 m
3 767 rues avec des barycentres distants de moins de 5 000 m

Pour terminer, j'essaye de gommer l'effet d'échelle lié à la longueur 
variable des rues en appliquant la condition suivante :
La distance entre les barycentres ne doit pas dépasser deux fois la 
distance de l'adresse la plus éloignée au barycentre des adresses.


Les résultats ont été assez satisfaisants sur la communauté urbaine de 
Nantes, d'autant qu'il y avait des rues homonymes situées dans des 
communes différentes.


Pour Montpellier, l'opendata fournit 2879 rues. Le script fait les 
associations de 2131 rues d'opendata avec 3551 rues d'OSM.

Il reste 748 rues sans association avec OSM.
L'import semi-automatique conduit les contributeurs à créer la rue dans 
OSM lorsqu'elle manque ou à corriger le nom.
Sur Nantes, des incohérences sont fréquentes sur le type de voie 
(rue/avenue/chemin/boulevard/impasse...).
D'autres corrections portent sur des doublons d'adresses ou des numéros 
manifestement mal associés à la rue d'après l'ordre des numéros dans la rue.


Avant tout import il faut déjà supprimer tous les points mal placés, 
non ?


René-Luc
3Liz
Montpelliérain



Comment définir qu'un point adresse est mal placé ?
Certains ont pris l'habitude de mettre le numéro en attribut de 
bâtiment. Le rendu est peut être satisfaisant mais ne permet pas de 
savoir de quel côté se trouve la boite au lettre ou l'entrée.
Apparemment, le point d'adresse de l'opendata est placé à proximité de 
la boite aux lettres en limite de parcelle cadastrale (c'est souvent le 
cas pour Nantes).


A Nantes, nous importons le point proposé par l'opendata mais cela est 
laissé à l'appréciation du contributeur, notamment lorsqu'il a une 
connaissance précise du terrain.
Avant de déplacer ou d'effacer des points existants, il est de bon ton 
de contacter l'auteur pour obtenir son assentiment.


Pour terminer, il est à noter que l'import semi-automatique sur Nantes 
permet d'identifier des anomalies dans les données de l'opendata mais 
aussi de corriger des erreurs d'OSM.
Pour Nantes, le traitement complet va prendre plusieurs mois. L'apport 
d'outils comme celui mis au point par Bruno se révèle indispensable pour 
faciliter la tâche.


D'ores et déjà, un peu de publicité pourrait susciter des applications 
auprès des acteurs gravitant autour de l'opendata.
Un des arguments à faire valoir est qu'OSM est meilleur que les données 
brutes de l'opendata grâce aux corrections apportées par les contributeurs.


Librement

Christophe

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


[OSM-talk-fr] [détente neuronale] philosophie sur la Carte

2012-02-09 Par sujet Cyrille Giquello
Un peu de phylo (en français) sur a Carte

http://towards.be/site/spip.php?page=blog-mots&id_mot=136

Suite à une rencontre sur le stand OSM au Fosdem2012
-- 
Cyrille.

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


[OSM-talk-fr] Re : [détente neuronale] philosophie sur la Carte

2012-02-09 Par sujet THEVENON Julien


 De : Cyrille Giquello 

 Un peu de phylo (en français) sur a Carte
 http://towards.be/site/spip.php?page=blog-mots&id_mot=136
 Suite à une rencontre sur le stand OSM au Fosdem2012



Sympa comme approche !
J ai ete vraiment soulage a la fin de voir qu ils etaient en lien avec OSM, je 
me disais que le contraire aurait ete dommage !

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


Re: [OSM-talk-fr] Point adresse à Montpellier

2012-02-09 Par sujet rldhont

Le 09/02/2012 23:07, isnogoud a écrit :

Le 09/02/2012 09:48, rldhont a écrit :

Avant tout import, une petite analyse des données brutes est nécessaire.

La ville de Montpellier fourni aussi son référentiel de rue ainsi que 
l'ensemble des passages piétons de la ville. J'avais déjà pratiqué 
une petite analyse des données des passages piétons et il se trouve 
que la position peut laisser à désirer.
Dans le référentiel de rue, chaque rue est découpé en tronçon reliant 
2 intersections qui se suivent. Ensuite chaque tronçon porte un 
CODE_VOIE qui permet d'identifier la voie et qui sert de clef 
étrangère pour lier d'autres éléments dont les passages piétons et 
les adresses.
Et donc si on utilise ce CODE_VOIE pour lier un passage piéton ou une 
adresse à sa rue on peut avoir quelques surprises. C'est ainsi que 
26323 adresses se trouvent à plus de 11 mètres de la rue à laquelle 
elle est associé d'après le CODE_VOIE. D'ailleurs ce CODE_VOIE à 
servi à créer l'adresse.


Pour finir l'analyse :
* la majorité des adresses se trouvent à moins de 100 mètres
* 5215 adresses se trouvent à plus de 500 mètres de leur rue
* 2245 adresses se trouvent à plus de 1 km de leur rue
* 524 adresses se trouvent à plus de 2 km de leur rue
* 70 adresses se trouvent à plus de 3 km de leur rue
* 5 adresses se trouvent à plus de 5 km de leur rue



Merci pour cette analyse détaillée qui m'a amené à regarder de plus 
près les résultats des traitements sur Montpellier.


Pour associer une adresse à une rue d'OSM, je procède comme suit :
- calculer le barycentre des adresses de chaque rue de l'opendata.
- calculer le barycentre de chaque rue d'OSM (highway avec un name 
renseigné sur le secteur de Montpellier)
- calculer la distance de l'adresse la plus éloignée du barycentre des 
adresses de la rue


Pourquoi utiliser un barycentre ? Dans PostGIS tu peux utiliser :
* ST_Line_Locate_Point qui renvoit un float entre 0 et 1 indiquant la 
position de la porjeté d'un point sur une ligne
* ST_Line_Interpolate_Point qui renvoit un point à partir d'une ligne et 
d'un float entre 0 et 1, peut servir avec ST_Line_Locate_Point pour 
créer le point de la projection sur la ligne
* ST_Length et St_MakeLine en réutilisant ST_Line_Interpolate_Point et 
ST_Line_Locate_Point pour calculer la distance

Tu obtiendrais ainsi quelque chose de précis


- associer les rues d'OSM et les rues de l'opendata par proximité du nom.
Fabien Poulard m'a suggéré quelques pistes. J'ai retenu l'identité de 
SOUNDEX et une distance de Levenshtein < 3. Cela permet de tenir 
compte des fautes de frappe éventuelles.


Pour Montpellier, les calculs donnent :

2 663 rues avec des barycentres distants de moins de 100 m.
3 446 rues avec des barycentres distants de moins de 500 m
3 592 rues avec des barycentres distants de moins de 1 000 m
3 651 rues avec des barycentres distants de moins de 2 000 m
3 767 rues avec des barycentres distants de moins de 5 000 m

Pour terminer, j'essaye de gommer l'effet d'échelle lié à la longueur 
variable des rues en appliquant la condition suivante :
La distance entre les barycentres ne doit pas dépasser deux fois la 
distance de l'adresse la plus éloignée au barycentre des adresses.


Les résultats ont été assez satisfaisants sur la communauté urbaine de 
Nantes, d'autant qu'il y avait des rues homonymes situées dans des 
communes différentes.


Pour Montpellier, l'opendata fournit 2879 rues. Le script fait les 
associations de 2131 rues d'opendata avec 3551 rues d'OSM.

Il reste 748 rues sans association avec OSM.
L'import semi-automatique conduit les contributeurs à créer la rue 
dans OSM lorsqu'elle manque ou à corriger le nom.
Sur Nantes, des incohérences sont fréquentes sur le type de voie 
(rue/avenue/chemin/boulevard/impasse...).
D'autres corrections portent sur des doublons d'adresses ou des 
numéros manifestement mal associés à la rue d'après l'ordre des 
numéros dans la rue.


Avant tout import il faut déjà supprimer tous les points mal placés, 
non ?


René-Luc
3Liz
Montpelliérain



Comment définir qu'un point adresse est mal placé ?


Pour Info les 5 adresses à plus de 5 km sont :
* 3 adresses d'une même rue
* 2 adresses d'une autre rue
Les rues et les points adresses sont à l'opposé l'un de l'autre.
J'ai des images pour le représenté mais ça ne passe pas sur la liste

Certains ont pris l'habitude de mettre le numéro en attribut de 
bâtiment. Le rendu est peut être satisfaisant mais ne permet pas de 
savoir de quel côté se trouve la boite au lettre ou l'entrée.
Apparemment, le point d'adresse de l'opendata est placé à proximité de 
la boite aux lettres en limite de parcelle cadastrale (c'est souvent 
le cas pour Nantes).


Pour Montpellier j'ai des doutes sur certains adresses ;-)



A Nantes, nous importons le point proposé par l'opendata mais cela est 
laissé à l'appréciation du contributeur, notamment lorsqu'il a une 
connaissance précise du terrain.
Avant de déplacer ou d'effacer des points existants, il est de bon ton 
de