Re: [OSM-talk-fr] Import semi-automatique du cadastre - anomalies

[isnogoud]

Le 30/12/2013 18:39, isnogoud a écrit :

Bonjour,

Il y a apparemment quelques soucis avec l'Interface de génération de 
fichiers .osm à partir du cadastre (http://cadastre.openstreetmap.fr/).


En sélectionnant le département dans la Vendée, ce sont des communes 
de la Sarthe et peut être d'ailleurs qui sont proposées. Les fichiers 
générés sont vides.


Librement

Christophe




Bonjour,

L'interface fonctionne à nouveau correctement depuis ce matin.

Librement

Christophe

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

[OSM-talk-fr] Import semi-automatique du cadastre - anomalies

[isnogoud]

Bonjour,

Il y a apparemment quelques soucis avec l'Interface de génération de 
fichiers .osm à partir du cadastre (http://cadastre.openstreetmap.fr/).


En sélectionnant le département dans la Vendée, ce sont des communes de 
la Sarthe et peut être d'ailleurs qui sont proposées. Les fichiers 
générés sont vides.


Librement

Christophe



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

Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[isnogoud]

Le 01/10/2013 09:25, Bruno Cortial a écrit :

Le 30 septembre 2013 21:05, Frédéric Rodrigo  a
écrit :


Autre chose, le nombre d'adresses manquantes à Nantes monte...

http://osmose.openstreetmap.fr/fr/errors/graph.png?source=1347&item=8080&class=



Bonjour,
Bonne remarque !
J'ai exploré les changesets et l'onglet history de
http://owl.apis.dev.openstreetmap.org, mais je n'ai pas trouvé de
suppression de noeuds adresses. Est-que les faux positifs d'Osmose sur ces
adresses n'auraient pas été remis à zéro ?

Bruno


Bonsoir,

Sauf erreur, les données actuelles sont celles mise à disposition par 
Nantes Métropole en janvier 2013.


Une nouvelle publication a eu lieu en juin dernier sur le site opendata. 
Si l'outil d'intégration se met à niveau, le graphe va grimper encore.


La mise à jour plus ou moins automatisée vers OSM reste un sujet à 
traiter. L'outil d'import est utile pour traiter des adresses à l'unité.
La mise à disposition des nouvelles rues au format xml pourrait 
faciliter le travail. Cela pourrait être avant la fin de l'année si j'ai 
le temps...


Librement

Christophe

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

Re: [OSM-talk-fr] Du Fantoir

[isnogoud]

Le 25/09/2013 19:20, Frédéric Rodrigo a écrit :

Le 23/09/2013 16:40, Pieren a écrit :

2013/9/23 Christian Quest :

57 995 ref:FR:fantoir (sur des nœuds en Bretagne)
12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon 
taginfo, mais

probablement ceux de Toulouse))
A Nantes, c'est d'abord "rivoli" qui avait été retenu puis, à l'exemple 
de Toulouse, la conversion a "ref:FR:FANTOIR" a eu lieu le 8/2/2013..
Le débat pour savoir si Nantes est en Bretagne semble évité mais si 
c'est pour mettre Nantes en Auvergne...


Concernant la valeur à mettre, l'opendata fournit généralement les 4 
caractères alphanumérique identifiant la voie dans la commune.
Le code FANTOIR complet comprend les codes du département et de la 
commune. Il peut donc être reconstitué à partir de la localisation de la 
rue sur OSM.
Le code à 4 caractères est à préconiser dans le wiki d'OSM puisqu'il 
évite de la redondance d'information.


Est-ce que la migration annoncée vers ref:FR:FANTOIR comporte également 
le recadrage de la valeur sur 4 caractères ?


Librement

Christophe


On essaye donc de documenter ça sur le wiki.
Puis de tout migrer vers ref:FR:FANTOIR.
Allez hop, c'est parti !

Frédéric.


___
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

[OSM-talk-fr] Free publie une carte des débits ADSL avec OSM

[isnogoud]

Bonjour à tous,

Ce matin, le site Freenews signale la mise en ligne d'une carte des débits ADS
par Free : http://www.freenews.fr/spip.php?article13585

La carte : http://www.free.fr/adsl/pages/accueil/carte-de-debits-adsl.html

Le fond de carte est manifestement issu d'OSM.

Qui se charge de contacter Free pour que la mention d'origine OSM figure ?

Librement

Christophe

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

Re: [OSM-talk-fr] Import adresses Grand Lyon

[isnogoud]

Le 01/06/2013 16:37, Sylvain Maillard a écrit :

Salut,

est-ce qu'il serait possible d'avoir accès à un extrait du fichier utilisé
pour l'import nantais ? je suis volontaire pour travailler les données et
générer  le fichier pour le fichier pour l'import, mais avec un exemple ça
sera encore plus facile ;)

Le fichier zip est parti à l'instant...


Par ailleurs le but de ce genre d'intégration est bien de conserver (et
éventuellement compléter) les données existantes. D'autant plus quand il
s'agit d'un bon boulot, et qui couvre une grande zone homogène => ça sera
rapide à vérifier, et comme ça on aura plus de temps pour le reste ... et
puis on aura tout l'été pour ça :D

Sylvain




Le 1 juin 2013 12:01, Eric  a écrit :


Pour ce qui du "merge" des adresses importées par rapport à l'existant
saisi à la mano par des contributeurs, si la source de données est fiable
et riche, je pense qu'il vaut mieux zapper l'existant et tout importer à
partir de la source fournie que de se lancer dans un travail de dentelliere
à trier l'existant du nouveau. Ca me semble lourd.


A Nantes, nous avons systématiquement contacté les contributeurs actifs 
qui avaient déjà mis des adresses pour obtenir leur assentiment à un 
remplacement par les adresses de l'import.
Le travail rue par rue est indispensable pour compléter si besoin la 
relation avec les membres "street" pointant vers les ways constituant la 
rue.


Générer la totalité des relations AssociatedStreet en une seule 
opération me parait contraire aux recommandations de la communauté.
En effet, cela va engendrer des relations sans membre "street" et 
d'autres anomalies qui seront imputées au projet d'import sur Lyon.


L'import rue par rue avec est peut être plus long mais la vérification 
par un contributeur a l'avantage de ne pas laisser d'anomalies pendantes.



Enfin, moi j'ai mis pas mal d'adresses sur la presqu'ile mais je n'ai
aucun soucis à ce que ce soit écrasé par un import semi auto si on gagne en
homogénéité / précision /complétude. Je ne sais pas si c'est partagé...
Apparemment c'est le cas : pour Nantes, nous n'avons eu aucune objection 
de la part des contributeurs contactés.



Eric (Blueberry)



Librement

Christophe





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

Re: [OSM-talk-fr] Import adresses Grand Lyon

[isnogoud]

Bonjour,

Le projet réalisé à Nantes est présenté dans le wiki d'OSM :

http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole

Le site du Bruno - http://arboulig.free.fr/OSM/ImportNM/ - associe un fichier
xml par rue qui comporte les ordres de création des points adresse, de la
relation AssociatedStreet et de ses membres.
Pour concevoir ces fichiers, il suffit d'effectuer les opérations à la main dans
JOSM, d'enregistrer le fichier en .xml ou .osm et de voir comment il est
structuré.

Pour produire les fichiers xml de Nantes, j'ai également déterminé pour chaque
rue, la ou les "highway" existants dans JOSM qui portent le même nom. Quand
c'était le cas, ces highway sont ajoutés en membre "street" de la relation
AssociateStreet.

Pour faciliter le travail du contributeur, le fichier XML positionne JOSM au
centre des points adresses et des highways associés.

Pour Nantes, Toulouse et Bordeaux (?), les relations AssociatedStreet comportent
le tag ref:FR:FANTOIR avec le numéro Fantoir (ex-rivoli) quand il figure dans
les données. Il facilite la tâche pour les futures opérations de mise à jour.
voir
http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

La source des données doit également figurer. Pour Nantes, elle est sur chaque
adresse avec le mois et l'année de publication.

Pour terminer, ce type de projet prend du temps. A Nantes, l'intégration s'est
déroulée de décembre 2011 à fin août 2012. Nous avons rencontré les personnes de
Nantes Métropole pour échanger des informations. Nous avons notamment fourni une
liste des anomalies relevées par les contributeurs. La dernière publication sur
le site en opendata en janvier 2013 ne comportait aucune correction.

Le projet sur Lyon représente une taille plus importante que Nantes. A titre de
comparaison, les 24 communes de Nantes Métropole représentent 155000 adresses et
9000 rues.

A mon sens, le projet sur Lyon doit se monter avec des contributeurs locaux en
veillant à son animation via une page sur le wiki et des échanges sur une liste
de diffusion locale.

Librement

Christophe


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

Re: [OSM-talk-fr] Ecotaxe poids lourds

[isnogoud]

Le 26/04/2013 17:44, Pierre-Olivier GREGOIRE a écrit :

Les camions devront contenir un module qui enregistrera leur parcours et le
transmettra par GSM. Les portiques sont là pour verifier a certains points
que les camions qui passent sous le portique ont bien un module, qu'il
correspond bien au  vehicule declaré pour ce module, et que le module
déclare bien par GSM un passage sous le portique.
A noter que certains points de controle seront sans doute mobiles.

En dehors des portiques fixes couvrant toute la largeur de la chaussée, 
il y aura des bornes de contrôles mobiles.

Ces bornes ne contrôlent qu'un seul sens de circulation.
Les emplacements seront pourvus d'une base bétonnée.
D'autres bornes seront placées dans des stations services pour l'achat 
et le retrait des modules par les conducteurs

des véhicules.

Librement

Christophe


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

Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/

[isnogoud]

Le 16/04/2013 10:05, cybercen...@espacebaugeois.org a écrit :

salut,

l'acces au site http://cadastre.openstreetmap.fr/ est impossible 
depuis plusieurs jours.

quelqu'un a un plan B ? un site miroir ?
je voudrai avancer sur la commune de fougeré(49), j'ai rendez vous 
avec un adjoint au maire la semaine prochaine ;)


merci


+1 pour traiter quelques communes en Vendée...

Christophe

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

Re: [OSM-talk-fr] [OSM-Nantes] Re: Contributeur indélicat ?

[isnogoud]

Bonjour,

>> Pas d'accord :) en pratique il y a eu des nombreux échanges entre Géovélo et
>> OSM depuis presque 3 ans sur cette liste de diffusion.
D'accord :) la publicité autour du projet Géovélo sur la liste est conséquente
et la page du wiki sur les pistes cyclables est à présent plus claire par
rapport aux premières versions grâce aux diverses contributions.

> Le lien entre les données OSM et les données du mashup semble poser
> quelques difficultés. En effet, les interventions des contributeurs sur
> OSM ont pu perturber le calcul d'itinéraire, notamment via la
> classification des voies.
Ce problème avait initié des échanges intéressants avec Metacity et les
pratiques de Géovélo sur OSM. Heureux d'apprendre qu'il est réglé.

Désolé pour le SOTM-FR du WE prochain

Librement

Christophe


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

Re: [OSM-talk-fr] [OSM-Nantes] Re: Contributeur indélicat ?

[isnogoud]

Selon Christian Quest :

> Le 14 février 2013 22:57, isnogoud  a écrit :
> > Il ne m'est pas possible d'être à Lyon fin mars pour le SOTM-FR.
>
> Ca tombe bien alors, parce que c'est fin février ;)
>

Bonjour,

Un lapsus de ma part : je voulais écrire "fin février".

Librement

Christophe

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

Re: [OSM-talk-fr] [OSM-Nantes] Re: Contributeur indélicat ?

[isnogoud]

Bonsoir à tous,

Si j'ai bien compris, il y a au moins deux contributeurs qui ont, à des 
périodes différentes, utilisé le pseudo Géovelo.


Le premier, actuellement avec le pseudo Metacity, était employé par la 
Compagnie des Mobilités, notamment pour l'expérimentation à Nantes pour 
le compte de Nantes Métropole.

Le second a probablement pris sa suite.

En pratique, le premier n'a pas changé son adresse mail déclarée dans 
OSM mais a changé son pseudo.


Sauf exception, les choix concernant les tags pour les objets 
constituant un réseau cycliste ont été décidés par l'équipe Géovélo et 
imposés à OSM partout où l'équipe Géovélo intervient.


A ma connaissance, la pertinence de ces choix n'a fait l'objet d'aucune 
discussion.
Ces choix explicités dans une page du wiki d'OSM lèveraient les doutes 
et les ambiguïtés, ouvriraient la discussion et pourraient conduire à 
adopter un ensemble de règles communes en France et ailleurs.


De mes derniers échanges avec Metacity, je retiens qu'il a été très 
impliqué dans le projet Géovélo, apparemment très enthousiaste et 
compétent. Même s'il n'a pas répondu à mon dernier message lui signalant 
une pratique dommageable au projet des adresses postales sur Nantes, il 
a apparemment tenu compte de mes suggestions : je n'ai pas relevé de 
nouvelles anomalies générées par ses interventions.


Dans sa démarche, le projet Géovélo a choisi de gérer une partie des 
tags en dehors d'OSM selon le principe du Mashup. Cette partie 
spécifique sert au calcul d'itinéraire selon des critères définis par 
Géovélo et relevés sur le terrain..
Récemment, les données relatives à la cyclabilité ont été libérées sur 
le site Opendata de Nantes Métropole.


Le lien entre les données OSM et les données du mashup semble poser 
quelques difficultés. En effet, les interventions des contributeurs sur 
OSM ont pu perturber le calcul d'itinéraire, notamment via la 
classification des voies.



Afin de se faire une idée de la classification des voies sur Nantes, 
j'ai demandé à connaitre les documents appliqués pour la classification 
des voies, Metacity m'a indiqué qu'il s'agissait d'un document 
volumineux qu'il n'est pas autorisé à communiquer. A mon avis, cette 
information n'est pas libre et certainement pas en Odbl. Dès lors 
pouvons-nous accepter ces contributions ?


Au cours des deux réunions avec Nantes Métropole, j'ai évoqué les 
contributions qui nous posaient problème.
Manifestement, nous n'avions pas les bons interlocuteurs : la division 
"déplacements" n'était pas représentée.


Il ne m'est pas possible d'être à Lyon fin mars pour le SOTM-FR.
Néanmoins, je suggère que Géovélo mandate un interlocuteur unique pour 
répondre à nos questions.
Le forum de l'association française OpenstreetMap me parait le lieu 
possible pour ces échanges.


Librement

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

Re: [OSM-talk-fr] Article Open Street Map sur Science et Vie Junior

[isnogoud]

Le 10/11/2012 14:13, Eric Pommereau a écrit :

Bonjour,

Suite à une prise de contact de la rédaction de SVJ avec l'association 
(en septembre je crois), un article sur OSM est paru dans le dernier 
numéro de (SVJ n°279), 3 pages à la fin du numéro.


Après avoir introduit le sujet à partir des mappings en Haïti et à 
Fukushima l'article explique le a génèse du projet et le 
fonctionnement de la communauté.


Un encart explique "vos premiers pas sur OSM" avec potlatch.

La fin se termine par une invitation à la contribution et la 
présentation de la communauté française, également une petite mention 
sur live.openstreetmap.fr...


Voilà... ce type d'article toujours trop court mais c'est assez bien 
fait et  constitue une bonne intro pour les ados (et les parents...) 
qui ne connaissent pas le projet.


Bonne journée.




Bonsoir,

Cet article est une excellente initiative pour faire connaitre OSM 
auprès du jeune public. Il me parait restituer assez fidèlement l'esprit 
du projet OSM.
Le choix de démarrer par l'action sur Haïti est judicieux et la partie 
"Vos premiers pas sur Open Street Map" indique l'essentiel tout en 
restant ludique.


Quelques remarques :

 * "[...] ce projet participatif, sans publicité et en Open source,
   permet aux internautes volontaires de dessiner et de mettre à jour
   une carte du monde extrêmement détaillées" : certes, la majorité des
   logiciels à disposition sont en open source mais le coeur du projet
   est la base de données en licence ODbl.
 * une citation de Steeve Coast  : "J'ai donc mis au point un mon
   propre outil de cartographie participatif afin que tous les
   internautes puissent y intégrer librement leurs informations" : on
   peut en dire autant de Google Mapmaker. L'enjeu est ailleurs : dans
   la possibilité de réutiliser ces données cartographiques librement
   par tout en chacun.
 * "Il suffit d'aller sur les sites opendata.paris.fr ou data.gouv.fr
   pour recueillir plusieurs mégaoctets d'infos et les reporter sur la
   carte." : le principe est simple mais la pratique un peu moins...
 * "La carte numérique vierge d'OSM s'est bien remplie et s'avère même
   plus précise que celle de Google" : sauf que ce n'est pas le cas des
   nombreuses zones qui restent à mapper. De plus, la précision est
   très variable le tracé est fondé sur des enregistrement de GPS
   ("géonavigateur" en français officiel).
 * "[...] [cette nouvelle méthode de travail [...] permet d'apporter
   aux internautes des informations que les autres services gratuits de
   cartographie ne fournissent pas : [...], emplacements de radars
   [...] : les radars ont fait l'objet de discussions sur cette liste
   de diffusion. La mention pourrait faire sourciller quelques lecteurs
   avertis.

En tous cas, l'article est un bon support pour intéresser un public 
jeune à l'occasion de nos actions de communication ou d'initiation.


Librement

Christophe

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

Re: [OSM-talk-fr] Imports du cadastre et compte dédié - import adresses Nantes aussi !

[isnogoud]

Bonsoir à tous,

L'usage préconisé d'un compte dédié pour un import peut se comprendre 
par les facilités que cela apporte à la supervision ou la surveillance.
C'est typiquement le cas pour un contributeur qui lance des scripts avec 
des opérations sur un ensemble volumineux de données. C'est le type 
"bot" rencontré sur les corrections de la source cadastre.
Les opérations effectuées sont dédiées à un projet et menées par une 
équipe identifiée, compétente et reconnue.


A mon sens, un compte OSM est habituellement dédié aux actions d'un seul 
contributeur. Il est alors possible de s'adresser à lui via la 
messagerie OSM pour le conseiller ou régler d'éventuels litiges. Les 
outils tels que JOSM sont conçus dans ce sens. Implicitement, chacun est 
responsable de ses actions. Le mot de passe est là pour s'authentifier 
et éviter toute usurpation d'identité.


Pour le cas des adresses à Nantes, il m'a paru important de permettre à 
tout un chacun de participer, chacun restant responsable de ses 
opérations. Celles-ci sont aisément identifiées grâce par la complète 
traçabilité des actions implémentée dans OSM.


Pendant toute la durée de l'import, les statistiques sur la page du wiki 
ont permis  à chacun de suivre la progression régulièrement et de 
mesurer sa participation.


S'il avait fallu dédier un compte à l'import, les actions de chacun 
n'auraient pas pu être identifiées sauf à forcer chacun à mettre une 
information en commentaire sur le changeset pour s'identifier.
Compte tenu de la durée du projet sur Nantes, chacun aurait du penser à 
changer de compte à chaque fois qu'il passe d'une contribution 
individuelle à une contribution au titre de l'import et inversement.
En pratique, cela supposait également de divulguer le mot de passe du 
compte dédié à chaque nouveau contributeur qui souhaitait participer à 
l'import.
Ou alors à créer un compte dédié au projet pour chaque nouveau 
participant...


Pour résumer, le compte dédié me parait actuellement peu adapté à un 
projet collaboratif d'intégration alors qu'il l'est assurément pour des 
opérations d'import ou de correction de type massif.


En attendant un consensus sur des directives communes, je pense faire 
figurer le projet d'intégration des adresses de Nantes sur la liste des 
imports.

Si cela peut faire plaisir à pnorman...

Librement

Christophe

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

Re: [OSM-talk-fr] Imports du cadastre et compte dédié - import adresses Nantes aussi !

[isnogoud]

Bonsoir à tous,

Le cadastre n'est pas le seul projet concerné par le sujet.

Je viens de recevoir le message suivant de pnorman :

==

I was looking at some data in Nantes and saw that you had imported a 
bunch of addresses there. Although there's not much to be done at this 
point, I wanted to remind you if you had any future imports planned that 
imports need to be done from a dedicated account and after consultation 
with the community, which includes the imports@ mailing list.


I checked my imports@ archive and didn't find any proposed Nantes imports.

This is just a reminder for if you plan anything in the future.

==

Le projet d'import d'adresses à Nantes est décrit dans le détail dans le 
wiki d'OSM : 
http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole. 



Il a été signalé sur cette liste de diffusion fin 2011 et début 2012 à 
plusieurs occasions.
Le 7 mars dernier, plusieurs membres du bureau d'OSM France ont 
participé à la réunion avec Nantes Métropole à propos de ce projet.


Jusqu'à ce jour, personne n'a émis d'objection ou de remarque quant à la 
démarche adoptée ni évoqué le recours à un compte OSM dédié.


Le message de pnorman est à verser au débat actuel sur cette liste. 
pnorman n'attend pas de réponse de ma part.


Je relève simplement que le projet n'est pas un import brut et massif 
mais qu'il s'agit d'une intégration rue par rue avec vérification et 
souvent correction manuelle par le contributeur.
La logique est la même que pour les corrections d'osmose. Y a-t-il un 
compte dédié pour la correction des erreurs signalées par osmose ?


Nantes Métropole procède régulièrement à des mises à jour de ses données 
adresses.

Un nouveau projet est à monter pour traiter leur intégration à OSM.

Il serait bon que la communauté OSM aboutisse à un accord sur la manière 
de procéder. Cela concerne potentiellement de nombreux projets Opendata.


Librement

Christophe

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

Re: [OSM-talk-fr] Semaine Internationale de l'OpenData à Nantes #odwnantes

[isnogoud]

Selon Christian Rogel :

> Hier, j'ai participé à une table ronde sur l'OD et à un atelier participatif.
> C'était très bien, les intervenants étaient de bonne qualité.
>
> J'ai cité OpenStreetMap, mais le public, très divers (fonctionnaire,
> journalistes, entrepreneurs, "touristes"), n'en avait, évidemment, pas
> entendu parler.
> Ce qui m'amuse, c'est que l'on dise que dans les collectivités qui ont ouvert
> leurs données, le taux d'utilisation est très faible.
>
> Il est pourtant facile de voir :
> 1 que c'est très récent
> 2 que le juge de paix d'une politique locale, ce sont les élections. C'est
> donc en 2013,
> à mesure que la campagne pour les municipales (et les cantonales) approchera
> que l'on verra des gens s'emparer des données. Il faudra essayer alors de
> montrer les potentialités d'OSM pour les matérialiser.
>

A titre d'exemple, n'hésite pas à montrer l'import des adresses sur la carte OSM
pour Nantes : c'est tout frais issu de l'opendata de Nantes Métropole.

http://www.openstreetmap.org/?lat=47.213574&lon=-1.558525&zoom=18&layers=M

L'intégration des données se poursuit actuellement pour les 24 communes de
Nantes Métropole.

http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole

Librement

Christophe

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

Re: [OSM-talk-fr] Notice à suivre pour les imports

[isnogoud]

Bonjour à tous,

Les guideslines sur les imports 
(http://wiki.openstreetmap.org/wiki/Import/Guidelines
) vont plus loin en préconisant de ne pas utiliser le tag source pour 
mentionner l'origine des données.

-


   Use a dedicated user account

Create a new user for the import. You must not use your standard OSM 
user account. The user page for the account should be used to collate 
data relating to the source and contact details for the import. 
Furthermore, it means that attribution can often be carried in the 
account's display name, or in the account's user page, which is better 
than putting it as a tag, as the user's editing history is a permanent 
record of the source and doesn't interfere with tags or increase the 
size of the database as much. For these reasons, creating a dedicated 
user account is preferable to using a source 
=* tag.


-

Ce choix est motivé par :
- l'usage du compte OSM créé pour l'import afin de donner des informations sur 
la source, les outils, le lien vers une page du wiki. Le nom même du compte 
peut indiquer la source.
- la permanence de l'enregistrement des modifications effectuées à l'aide du 
compte d'import.
- le souci de ne pas charger la base de données de la carte OSM sachant que 
l'historique des modifications est à part

Pour connaitre la source d'un objet, il faut consulter l'historique des 
modifications et repérer le compte qui a créé l'objet.

Cela me laisse perplexe sur la visibilité qu'OSM veut donner à ses sources.
Autant citer la liste de tous les organismes ayant fourni des données dans les 
conditions générales d'utilisation d'OSM ou dans une page Remerciements du wiki.

En tant que contributeur, le tag source me parait une indication utile sur la 
qualité d'un objet.
Si je constate une anomalie, je peux contacter la source (cf les monuments 
historiques mal localisés) ou l'auteur de l'import.

Le mouvement Opendata amorcé en France va générer des imports de données.
Il me parait important que la communauté OSM s'accorde sur des règles et 
pratiques pour ces projets d'import.

Librement

Christophe

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

Re: [OSM-talk-fr] Apple, iOS, Google Maps... et OSM ?

[isnogoud]

A Nantes, un clic sur le bouton 'Apple Only' et c'est le caractère visionnaire
d'Apple qui interpelle :

http://ivan.sanchezortega.es/leaflet-apple.php?lat=47.21245559611419&lon=-1.5528488159179688&z=13

Librement

Christophe



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

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

[isnogoud]

Le 10/02/2012 11:40, rldhont a écrit :
Désolé, mais c'est naturel chez moi... ça va tellement plus vite... 
c'est comme la ligne de commande, ssh, etc.


Le 10/02/2012 10:54, Ab_fab a écrit :
Personne n'avait pris PostGIS LV2 au lycée, mais c'était une solution 
de repli identifiée en cas de blocage.


Les essais d'Isnogoud ont ** rapidement ** donné de bons résultats, 
donc la mise en place d'une BDD spatiale n'a pas été nécessaire pour 
aboutir à des fichiers exploitables.


Le 10 février 2012 08:38, rldhont > a écrit :






Tu es tout excusé : pour traiter les données opendata, je suis plus à 
l'aise avec une base de données relationnelle classique qu'avec les 
outils géomatiques.
Mais ta réflexion m'incite à aller approfondir le sujet PostGIS à l'aide 
du wiki d'OSM.


Par ailleurs, je confirme qu'il reste des rues non mappées par OSM à 
Montpellier et des noms de rue qui diffèrent de ceux de l'opendata.

L'import semi-automatique est probablement la démarche la mieux adaptée.

Bruno est disposé à communiquer les éléments techniques de son site web.
Les fichiers xml associés peuvent être fournis rapidement.

Il nous faut simplement un ou plusieurs interlocuteurs pour organiser et 
animer l'import sur Montpellier.


Qui est partant ?

Librement

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

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

[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

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

[isnogoud]

Bonsoir à tous,

Le test est concluant : les fichiers xml générés à partir du script 
paraissent conformes pour un import d'adresses à Montpellier.


Il reste quelques détails à régler :

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


Quelques différences avec les données de Nantes Métropole nécessitent 
des adaptations :

- le code postal pour chaque adresse n'est pas fourni à Montpellier
- l'identifiant utilisé pour les rues est-il le code RIVOLI comme 
pour Nantes ?

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

Comme pour Nantes, une petite expérimentation parait nécessaire.
Les bonnes volontés sont les bienvenues.

Librement

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

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

[isnogoud]

Bonsoir à tous,

Toutes les infos sur l'import de Nantes sont visibles sur la page 
http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole 

et les discussions sur la liste de diffusion 
http://www.linux-nantes.org/wws/info/openstreetmap-nantes


Le script utilisé pour Nantes devrait fonctionner avec les données de 
Montpellier.

Un petit essai devrait me permettre d'y voir plus clair ce soir.

Si Bruno est partant pour le site web, je fournis les fichiers xml.

A mon sens, l'essentiel de l'import semi-automatique concerne les 
contributeurs (ou "fourmis"), de préférence connaissant bien Montpellier 
et capables d'aller vérifier sur le terrain.


Qui est partant pour l'import à Montpellier ?

Librement

Christophe

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

Re: [OSM-talk-fr] Adresses postales de Nantes Métropole

[isnogoud]

> A propos des adresses postales, une nouvelle analyse est disponible sur
> osmose:
>
> http://osmose.openstreetmap.fr/map/?item=2060
>

D'abord bravo et merci : c'est exactement ce qu'il nous faut pour vérifier les
travaux d'import sur Nantes.

> Elle fait ressortir les incohérences de tag addr:housenumber et de la
> relation "associatedStreet":
> - addr:housenumber sans addr:street et ne faisant pas partie d'une relation
> associatedStreet
> - relation associatedStreet sans membre "street"
> - rôle "street" sur un way qui n'est pas highway=*
> - membres sans rôle
> - membres sans addr:housenumber
> - numéro en double
> - plusieurs noms de rue différents dans une même relation
> - plusieurs relations avec la même rue
>
> Résultat des courses, plus de 6 nouvelles erreurs détectées, la
> principale étant la première de la liste ci-dessus.

Cela n'est pas étonnant : l'utilisation de la relation de type associatedStreet
n'est présentée dans le schéma de Karlsruhe que comme une possibilité
optionnelle mais recommandée. L'usage basique est de porter toutes les
informations sur le point d'adresse.

> Je plaide coupable d'avoir eu une telle idée d'analyse, Frédéric Rodrigo
> est quant à lui coupable de l'avoir codée.

D'autres motifs de culpabilité en vue ?

>
> Le géocodage étant quelque chose de très demandé et utile, j'espère qu'on
> va pouvoir mettre tout ça un peu plus au propre.
>

Une suggestion : à Nantes, nous proposons de mettre le nom de la rue issue de
Nantes Métropole sur la relation. Il s'agit là aussi d'une recommandation du
schéma de Karlsruhe. C'est aussi un moyen de faciliter le travail du mappeur
pour faire le lien avec les ways existant avec notre import. Est-il possible de
mettre une erreur qui compare ce tag name avec les noms de ways figurant en
membre "street" de la relation ?

Il est vrai que le but est de ne pas dupliquer l'information inutilement.
L'idéal serait que le nom de rue ne figure qu'une seule fois dans OSM.


Librement

Christophe

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

[OSM-talk-fr] Adresses postales de Nantes Métropole

[isnogoud]

Bonjour,

Lundi dernier, Nantes métropole a libéré les données d'adresses postales 
recensées dans les 24 communes de son territoire.
Ces données sont en ligne sur le site data.nantes.fr sous licence Odbl 
avec une fréquence de mise à jour trimestrielle.
Un petit groupe de contributeurs se forme actuellement pour préparer 
l'import semi-automatique de ces données sur OSM.


Chaque adresse fournie comporte :
- l'adresse (numéro dans la rue et nom de rue)
- la commune
- le mot directeur (un mot clé du nom de rue)
- le numéro dans la rue
- le code rivoli : un code utilisé par nos administrations
- le code postal
- la longitude en WGS84
- la latitude en WGS84

En pratique, il s'agit apparemment de la localisation de la boite aux 
lettres sur le cadastre, généralement en limite de parcelle cadastrale


Pour importer ces données, nous souhaitons appliquer le schéma de 
Karlsruhe 
(http://wiki.openstreetmap.org/wiki/Proposed_features/Fr:Num%C3%A9rotation_des_rues) 
de la manière suivante pour chaque rue :

- les points d'adresse avec les tags :
- addr:housenumber = [le numéro dans la rue]
- source = "Nantes Métropole 11/2011"
- la relation avec :
- type = "associatedStreet"
- name = [nom de la rue]
- les points d'adresses en membre avec rôle = "house"

Les questions portent sur :
- la mention de la source : a priori sur le point d'adresse avec source 
= Nantes Métropole 11/2011
- la mention du code postal : a priori sur chaque point d'adresse avec 
addr:postcode = [code postal français]
Sauf erreur, chaque rue identifiée par un code rivoli peut comporter 
plusieurs codes postaux.
- la mention du code rivoli : a priori sur chaque relation avec un tag à 
définir

rivoli=[code rivoli] : sous réserve d'acceptation par la communauté OSM
rivoli:fr=[code rivoli] : pour marquer la spécificité français
street:rivoli=[code rivoli] : pour suivre la logique des tags addr:*

Nous proposons de fournir aux contributeurs un fichier xml par rue à 
charger dans JOSM.
Il comprend : les points d'adresse, la relation associatedStreet avec 
les points d'adresse en membre "house"


Le travail du contributeur est de
- charger l'extrait de carte OSM et vérifier qu'il n'y a pas de conflit 
avec l'existant
- compléter la relation associatedStreet avec le ou les ways constituant 
la rue en tant que membre avec le rôle "street"

- envoyer les modifications à la carte OSM

Les premiers essais sont concluants mais il convient d'arrêter nos 
règles d'import,
à la fois pour le projet sur Nantes mais également dans la perspective 
d'ouverture de données par d'autres collectivités territoriales.



Dernier point mais pas le moindre : autorisation de la CNIL

D'après une discussion du 2 mars dernier, la mention des adresses ne 
serait pas autorisée dans OSM : 
http://lists.openstreetmap.org/pipermail/talk-fr/2011-March/030901.html


L'IGN dispose d'outils et de fichiers de géocodage à l'adresse qui 
mentionne en conditions d'utilisation :


"Avertissement :
Conformément à la délibération CNIL n° 2006-091 du 6 avril 2006, POINT
ADRESSE® et BD ADRESSE® ne peuvent être diffusés par l’IGN qu’à l’Etat
et à ses établissements publics,
aux collectivités territoriales et à leurs établissements publics et aux
organismes publics ou
privés statutairement chargés ou délégataires d’une mission de service
public, aux seules fins de l’exécution de cette mission et à l’exclusion
de toute réutilisation commerciale.
Tout traitement de ces fichiers ou toute interconnexion ou rapprochement
avec des fichiers contenant des données à caractère personnel doit faire
l’objet des formalités requises
auprès de la Commission Nationale de l’Informatique et des Libertés.
ROUTE ADRESSE®, qui n'est pas assujetti aux termes de la délibération de
la CNIL n° 2006-091 du 6 avril 2006, est disponible pour tous les
utilisateurs."

Qu'en est-il pour OSM ?

Librement

Christophe

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

Re: [OSM-talk-fr] Re : Site pour placer des lieux sur fond carto OSM

[isnogoud]

Le 18/11/2011 01:35, THEVENON Julien a écrit :

Salut,

Peut etre que la solution "Show your place" pourrait convenir : 
http://syp.renevier.net/


Julien


    *De :* isnogoud 
*À :* talk-fr@openstreetmap.org
*Envoyé le :* Jeudi 17 Novembre 2011 23h46
*Objet :* [OSM-talk-fr] Site pour placer des lieux sur fond carto OSM

Bonjour,

Une question qui vient de m'être posée via un blog :


Une question de candide.
Je fais partie d'un groupe Ville en transition et on a comme
projet de recenser
tous lieux en lien avec la transition dans notre ville. Se pose
bien évidement
ensuite la question de la présentation visuelle de ces lieux. La
facilité serait
d'utiliser Google Maps mais étant un adepte de l'open-source ça me
ferait mal où
je pense.

J'en viens à ma question : est-il possible à partir d'OSM d'avoir
une carte via
API et de positionner des pointeurs avec popup dessus ? Où un truc
dans le
genre.


La documentation du wiki d'OSM ne signale pas de site qui offre ce
genre de
service avec OSM à l'instar de Google.

Mettre ces "lieux de transition" sur OSM avec un tag spécifique et
générer une
carte avec un rendu adapté me parait peu adapté.

Sauf erreur, une solution est peut être de monter un site
spécifique en mashup.

Librement

Christophe

___
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



Bonsoir,

L'internaute qui a posé la question vient de réagir dans les 
commentaires du blog :


==

   Merci beaucoup,

   C'est exactement ce que je cherchais 

==

Tout est là : 
http://www.cyrille-borne.com/index.php?post/2011/11/16/Pourquoi-OpenStreetMap%C2%A0


Librement

Christophe

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

[OSM-talk-fr] Site pour placer des lieux sur fond carto OSM

[isnogoud]

Bonjour,

Une question qui vient de m'être posée via un blog :


Une question de candide.
Je fais partie d'un groupe Ville en transition et on a comme projet de recenser
tous lieux en lien avec la transition dans notre ville. Se pose bien évidement
ensuite la question de la présentation visuelle de ces lieux. La facilité serait
d'utiliser Google Maps mais étant un adepte de l'open-source ça me ferait mal où
je pense.

J'en viens à ma question : est-il possible à partir d'OSM d'avoir une carte via
API et de positionner des pointeurs avec popup dessus ? Où un truc dans le
genre.


La documentation du wiki d'OSM ne signale pas de site qui offre ce genre de
service avec OSM à l'instar de Google.

Mettre ces "lieux de transition" sur OSM avec un tag spécifique et générer une
carte avec un rendu adapté me parait peu adapté.

Sauf erreur, une solution est peut être de monter un site spécifique en mashup.

Librement

Christophe

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

Re: [OSM-talk-fr] Comment nettoyer ça

[isnogoud]

Le 10/11/2011 22:07, Claude a écrit :

Bonjour

ici,
http://osm.org/go/0AxdTedE--

tous les point des routes on un attribut name=pointxx

y a il moyen de nettoyer ça facilement?

merci
cordialement
Claude


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




Bonsoir,

Sous JOSM, après avoir chargé toute la zone à partir du serveur, tu 
crées deux  filtres :


1) pour sélectionner les objets comportant une balise "name" :

name=*

2) pour sélectionner les objets comportant une clé "point", mets 
simplement dans la zone définissant le filtre :


point

3) active les deux filtres en cochant les cases

Tu ne devrais voir que les points qui posent problème.

4) Sélectionner tous les points

5) Supprimer le tag name

6) Envoyer les modifications vers le serveur

Avec un peu d'astuce, cela doit pouvoir être fait avec un seul filtre.

Librement

Christophe




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

Re: [OSM-talk-fr] Nantes va ouvrir ses données publiques

[isnogoud]

Bonsoir,

Ce soir, au cours d'une conférence sur l'Opendata, Nantes Métropole a 
annoncé la mise en ligne prochaine d'une version 1 de son portail Opendata.


Les données sont mises à disposition sous licence Odbl. (Merci Claire !).

L'annonce d'ouverture officielle dépend de la Comm de Nantes Métropole.

Le site aura pour adresse : www.data.nantes.fr

Sur les pages présentées du site, j'ai repéré le fichier des adresses au 
numéro dans chaque rue des 24 communes géolocalisées avec une précision 
de 0,5 à 5 mètres.


Que pouvons-nous en faire dans OSM ?
La CNIL semble sourcilleuse avec un géocodage à l'adresse lorsqu'il est 
trop précis. Les réticences de certains sur cette liste de diffusion 
est-elle fondée ?


Faut-il attendre qu'OSM passe aussi en Odbl ?

Librement

Christophe


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

[OSM-talk-fr] Cleo-carto - Anomalie et contact

[isnogoud]

Bonjour,

Depuis quelques jours, je tente de générer le fichier du bâti pour la 
commune d'Offwiller (Bas-Rhin) sur le site http://cadastre.cleo-carto.org/


Le message "import en cours" s'affiche systématiquement et aucun fichier 
n'apparait sur la page des données.


Ce cas n'est peut être pas isolé.

L'adresse de contact indiquée sur le site est cadastre.osm at 
cleo-carto.com - (remplacer at par @) mais elle ne semble pas 
fonctionner : le domaine n'est pas trouvé par le serveur de courrier.


Y a-t-il un moyen de joindre le pilote dans le cloud ?

Librement

Christophe


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

Re: [OSM-talk-fr] Mauvais imports du bâti cadastral, que faire ? / cas des canaux - chenaux

[isnogoud]

Le 24/08/2011 12:15, Bruno Cortial a écrit :



Le 24 août 2011 08:40, Brice > a écrit :


Bonjour,

Je profite de ce message pour vous demander votre avis sur le
traitement du Marais Breton
(http://fr.wikipedia.org/wiki/Marais_breton).
Exemple :
http://www.openstreetmap.org/?lat=46.99908&lon=-1.95528&zoom=17&layers=M


Les fossés drainants ont été importés depuis le cadastre donc en
surface d'eau et non en linéaire.



Le script d'import du cadastre met le tag "riverbank" pour indiquer les 
rives et non en surface d'eau ("river" ou "water").

Selon le wiki, ce tag devrait être réservé aux fleuves et larges rivières.


Cette configuration inclut notamment des multipolygones avec
relations inner.

Quelle est votre position sur le traitement à adopter pour une
telle zone ?
Des changements sont-ils à prévoir ?


Je suppose que le traitement suivi dans le cas du marais de
Couëron est préférable, qu'en pensez-vous ?
http://www.openstreetmap.org/?lat=47.21828&lon=-1.77005&zoom=15&layers=M



Brice



C'est bien sûr le modèle de Couëron qu'il faut suivre.



A mon sens, en terme de rendu, cela ne diffère pas de manière significative.
Le modèle de Couëron est beaucoup plus simple à mettre en oeuvre en 
représentant l'essentiel des fossés par du filaire.


Les imports water du cadastre se révèlent très lourds à corriger (cf le 
dernier paragraphe en 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents 
).

Cela devrait être réservé à des contributeurs expérimentés.

On voit mieux le pb sur geofabrik:
http://tools.geofabrik.de/osmi/?view=water&lon=-1.95232&lat=46.99195&zoom=14&opacity=0.54&overlays=bodies_of_water,bodies_of_water,broken_bow,vmap0_rivers,long_rivers,waterways_river,waterways_stream,waterways_drain,waterways_canal,waterways_riverbank,waterways_other,waterways_width,waterways_in_tunnels,waterways_on_bridges,waterways_without_names,waterway_nodes,coastline,coastline,simple_islands,coastline_nodes,rivermouths,coastline_not_simple,coastline_unconnected 



=> En l'état on ne peut tirer aucune information sur le réseau hydro. 
L'import "water" c'est le mal ! Même pas de validateur pour forcer le 
contributeur à améliorer ses données comme c'est le cas pour le bâti.




Les informations qu'on peut en tirer sont celles fournies par le 
cadastre. Elles intéressent probablement les agriculteurs et exploitants 
agricoles, peut être les services fiscaux...
En principe, OSM reçoit des données libres sans préjuger de leur usage 
et de leur utilité.


En l'absence d'autres informations sur l'hydrographie, il y a celles-ci. 
Rien n'empêche de les corriger s'il y a mieux ou de les conformer au 
modèle de Couëron (un script pour le faire ?).
Pour mettre les waterway=river, il faut connaitre le sens d'écoulement 
des eaux, ce qui n'est pas fourni avec le cadastre et devrait être 
déterminer par un autre moyen (un fond topographique peut aider ?).


Enfin, il est à noter que le cadastre de type canaux :
- ne se compare pas aux imports water en zone non marécageuse
- n'existe que pour certains départements ou zones côtières (dont la Vendée)
- n'est pas homogène (comparer le traitement de Bouin et de 
Bourneuf-en-Retz 
http://www.openstreetmap.org/?lat=47.00108&lon=-1.9484&zoom=15&layers=M 
 )


Enfin, le validateur de JOSM ne contraint pas le contributeur à corriger 
le bâti importé. On l'a vu récemment pour Quimper et d'autres villes.
En outre, ce validateur se révèle insuffisant : il faut compléter par la 
correction des erreurs détectées par osmose 
(http://osmose.openstreetmap.fr/map/cgi-bin/index.py).


Les erreurs sur l'import water du cadastre sont visibles sous JOSM et, 
pour une part, détectées par le validateur de JOSM.




Pas mal aussi, les riverbank en mer :
http://tools.geofabrik.de/osmi/?view=water&lon=-2.47983&lat=47.49060&zoom=13&opacity=0.54&overlays=bodies_of_water,bodies_of_water,broken_bow,vmap0_rivers,long_rivers,waterways_river,waterways_stream,waterways_drain,waterways_canal,waterways_riverbank,waterways_other,waterways_width,waterways_in_tunnels,waterways_on_bridges,waterways_without_names,waterway_nodes,coastline,coastline,simple_islands,coastline_nodes,river

Re: [OSM-talk-fr] Imports sauvages de bâti du cadastre

[isnogoud]

Le contributeur en question vient de réagir à mon dernier message.

Il est débutant et n'avait pas réalisé qu'il y avait des corrections 
manuelles à faire sur le fichier généré à partir du cadastre.

Il a commencé à corriger ses imports passés.

Pour éviter à un autre débutant de prendre le même chemin, il serait bon 
de disposer d'un outil pour détecter les imports récents
de manière à pouvoir en vérifier la qualité et alerter éventuellement 
l'auteur.


Existe-t-il actuellement un outil pouvant répondre à ce besoin ?
Est-ce que cela intéresse quelqu'un de développer un tel outil ?

Librement

Christophe

___
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] Imports sauvages de bâti du cadastre

[isnogoud]

Depuis plus d'un mois, un nouveau(?) contributeur se livre à de nombreux 
imports de bâti du cadastre sans effectuer aucune correction.


Je lui ai amicalement signalé la page du wiki décrivant les traitements 
à effectuer avant import et je lui ai proposé de me contacter s'il avait 
besoin d'aide.


Il n'a pas daigné me répondre et poursuit actuellement comme si de rien 
n'était.


Quelqu'un peut-il intervenir pour contenir sa frénésie et limiter les 
dégâts ?


Ses œuvres sont visibles sur Concarneau, Paimpol, Plouha, Condrieu.

Librement

Christophe

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

Re: [OSM-talk-fr] Statistiques des km de voiries par communes dans osm comparé au cadastre

[isnogoud]

Le 07/03/2011 20:22, sylvain letuffe a écrit :

Le lundi 7 mars 2011 19:22:05, isnogoud a écrit :

Une petite anomalie à signaler : la commune de Notre Dame de Riez
affiche un taux de 0/72 alors qu'une partie de la voirie figure bien sur
la carte
(http://beta.letuffe.org/?zoom=14&lat=46.74544&lon=-1.8705&layers=B
FFFTF
<http://beta.letuffe.org/?zoom=14&lat=46.74544&lon=-1.8705&layers=BFFF
TF>).

Lors de la construction j'ai eu pas mal de commune avec des erreurs, et celle
là fait partie du lot, j'ai ce message d'erreur :

NOTICE:  TopologyException: found non-noded intersection between LINESTRING
(-214665 5.9031e+06, -213189 5.90304e+06) and LINESTRING (-213626 5.90251e+06,
-215466 5.90369e+06) at -214540 5.9031e+06
ERREUR:  GEOS Intersection() threw an error!

Si je comprends bien, il gueule parce qu'il a trouvé, dans les limites de la
commune, une "non noded intersection", bref, un truc qui ressemblerait à un
auto-croissement

--
sly


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




Apparemment, ta correction du script a résolu le problème de 
Notre-Dame-de-Riez : le taux est de 26/72 ce qui me semble coller à la 
réalité.


Encore merci pour cet outil tant pour la localisation du "reste à faire" 
que pour voir en couleur la progression des fourmis OSM !


Librement

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

Re: [OSM-talk-fr] Statistiques des km de voiries par communes dans osm comparé au cadastre

[isnogoud]

Le 07/03/2011 18:22, Jean-Francois Nifenecker a écrit :


Bonjour,

Le 07/03/2011 16:23, sly (sylvain letuffe) a écrit :


A la suite de l'annonce par Frédéric de son outil de la mort qui tue qui
détermine, gràce au cadastre vecteur, le nombre de km de voirie en 
france par

commune.

Voici un complément visuel, sur une jolie carte du nombre de km de 
voirie,

présent dans osm, comparés à ceux calculés par son outil :



Un seul mot : bra-vo !

En effet, c'est vrai que la mesure du taux de couverture est 
importante... euh... non, TRES importante car elle permet de cibler 
les lieux où intervenir. Or, si le charme même du projet OSM c'est 
"chacun cartographie où il veut, (presque) comme il veut et ce qu'il 
veut", nous sommes arrivés aujourd'hui à un stade où il la 
coordination devient essentielle. Ceci pour nous permettre de combler 
les trous (à la campagne) qui font que OSM fait encore quelquefois 
sourire alors que le travail en zones urbaines montre notre sérieux et 
atteste de la qualité du résultat.


Bref, pour rebondir : il faut des tableaux de suivi de l'avancement et 
les outils conçus par Fred et Sly vont grandement aider.



Amicalement,


+1

A titre d'exemple, nous avons été deux contributeurs à traiter l'ouest 
de la Vendée de manière coordonnée.
Volontairement, nous n'avons pas traité la ville de Challans en gageant 
qu'un autre contributeur s'y intéresserait. Cela a été le cas récemment.


A mon sens, il y a intérêt à lutter contre la "fracture géomatique" en 
traitant a minima les zones rurales.
Cela concerne notamment le réseau routier pour que les outils de routage 
(GPS ou autres) fournissent des itinéraires crédibles.
Récemment: un contributeur allemand signalait que le nord-est de la 
France était insuffisamment couvert pour assurer la continuité avec la 
carte OSM en Allemagne.


Pour les zones très urbanisées, la probabilité est grande qu'un 
contributeur y habitant se mette à mapper.
De plus, cela permet à des novices de ces zones de faire leurs premiers 
pas sur OSM près de chez eux.


La carte sera très utile pour savoir où intervenir pour assurer une 
couverture homogène.


Une petite anomalie à signaler : la commune de Notre Dame de Riez 
affiche un taux de 0/72 alors qu'une partie de la voirie figure bien sur 
la carte 
(http://beta.letuffe.org/?zoom=14&lat=46.74544&lon=-1.8705&layers=BFFFTF 
).


Librement


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

Re: [OSM-talk-fr] [Import 4C] Projet de la Semaine : Cartographie de la CC de Concarneau

[isnogoud]

Le 30/01/2011 07:51, Marc Sibert a écrit :

Bonjour,

Je suis en train de revoir la requête qui fournit les dalles afin 
qu'elle donne tous les ways passant la surface, avec leurs 
prolongement en dehors. En attendant, j'ai toujours le filaire 
complet, mais pas complet en tags qui permet d'avoir une vue 
inter-dalle. Vous pouvez le trouver à http://freeroute.fr/4c/4c.osm (> 
5Mo quand même !)




Je confirme que le fichier proposé plante JOSM.
En comparant avec les fichiers qui passent sans problème, il apparait 
qu'il suffit de remplacer "key=" par "k=" et "value=" par "v=" pour être 
conforme au XML d'OSM.

Le fichier corrigé s'ouvre sans problème dans JOSM.

Encore merci pour le fichier complet : cela permettra de rectifier les 
éventuelles jonctions incorrectes.


J'ai bien noté que les fichiers OSM par dalle comportent à présent les 
tronçons qui débordent. La fourmilière de la C4 applaudira.


Christophe


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

Re: [OSM-talk-fr] [Import 4C] Projet de la Semaine : Cartographie de la CC de Concarneau

[isnogoud]

Le 30/01/2011 07:51, Marc Sibert a écrit :

Bonjour,

Je suis en train de revoir la requête qui fournit les dalles afin 
qu'elle donne tous les ways passant la surface, avec leurs 
prolongement en dehors. En attendant, j'ai toujours le filaire 
complet, mais pas complet en tags qui permet d'avoir une vue 
inter-dalle. Vous pouvez le trouver à http://freeroute.fr/4c/4c.osm (> 
5Mo quand même !)


Désolé, mais JOSM (version 3751) plante en ligne 35 812, colonne 115. Il 
s'agit de la première des lignes décrivant les ways.

La syntaxe a pourtant l'air correcte.

Pour la N 165, je l'ai simplement reprise et corrigé "à la main" pour 
la passer en trunk. De manière générale, il faudra toujours se méfier 
des caractérisations automatique des voies car il est toujours très 
difficile de trouver une "bijection" entre les deux jeux de types. 
Après tout, il faut bien que le cerveau des petites fourmis serve, 
sinon un import massif substitué à tout l'existant aurait suffit.


Dans le rôle de fourmi, j'imaginais que la mention de la source 
engageait à respecter scrupuleusement les objets importés. Il est 
souvent question de "non altération" des données.
Serait-il préférable de mentionner "d'après [...]" comme pour les films 
s'inspirant d'un livre paru ?



Merci de votre aide !
Et ce n'est pas fini, avis aux fourmis désœuvrées : quittez un peu 
votre village et venez nous filer un coup de main !


A+




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

Re: [OSM-talk-fr] [Import 4C] Projet de la Semaine : Cartographie de la CC de Concarneau

[isnogoud]

Le 27/01/2011 01:27, Marc Sibert a écrit :

Le 23/01/2011 21:19, Marc Sibert a écrit :

Bonjour,

Demain une nouvelle semaine commence et je vous propose rien de 
vraiment révolutionnaire. Voilà, l'import et le traitement des 
données de la 4C sont terminés et les données ont été mises en ligne 
sous la forme de pavés "z15" sur http://freeroute.fr/4c.


Je vous propose de terminer l'import dans OSM cette semaine. J'ai 
commencé certaines zones comme vous pouvez le voir sur 
http://www.qualitystreetmap.org/osmqa/?map_x=-431343.72396921&map_y=6079906.5622936&map_zoom=13&lang=fr 



Autochtones ou pas, je vous invite à me rejoindre pour finir 
l'import. Notez bien que de nouvelles remarques sur la 
caractérisation des voies n'empêcheront pas l'import car toute les 
voies portent une référence spécifique à l'import 4C et qu'il sera 
donc possible de passer un robot dessus (et sur celles-là seulement 
;-) en cas de besoin détecté postérieurement à l'import.


A vos souris, partez, mais n'oubliez pas de "réserver" vos tuiles 
dans QSM.


A+


Bonjour,

Après une soirée de maintenance impromptue, l'import de la 4C vient de 
prendre une couche de vernis de plus et intègre maintenant des 
éléments du référentiel de la 4C (pour la maintenance ultérieure) 
incluant un identifiant de voie (composée de plusieurs tronçons) et un 
identifiant de tronçon.


Merci de poursuivre votre effort et de mettre à jour les dalles QSM
http://www.qualitystreetmap.org/osmqa/?map_x=-432213.11994696&map_y=6091418.9292369&map_zoom=11&lang=fr 



A+



Bonjour,

D'abord bravo pour avoir obtenu la libération des données de voirie de 
cette communauté de communes. La réussite de l'opération incitera 
d'autres collectivités à s'engager dans la même voie.
Ensuite, l'outillage mis à disposition est facile à mettre en œuvre pour 
qui maîtrise JOSM.


Après avoir traité Tourch puis Pont-Aven, quelques observations en 
complément aux remarques de Thomas Petillon :


- il est dommage que certains tronçons situés à l'intersection de deux 
dalles ne figurent pas dans l'import.
En règle générale, sa position d'un tronçon peut être déduite de la 
couche cadastre ou de Bing. Ses attributs (tags) sont hérités d'un 
tronçon adjacent en partant du principe qu'un tronçon lie deux 
intersections.
Ce n'est pas le cas pour certains tronçons dont nous n'avons que deux 
noeuds : sur Pont Aven, deux rues (au sud du tronçon 4351 et au nord du 
tronçon 4295) ne peuvent être déterminées pour leurs tags.
Enfin, le tronçon 4505 vraisemblablement situé entre le 4504 et le 4506 
sur le même axe de circulation ne peut être déterminé. J'ai prolongé le 
4504 mais sans certitude.
Comme Thomas, je suggère que les tronçons d'une dalle doivent comporter 
également les tronçons débordant sur une autre dalle. Les contributeurs 
sont capables de traiter les superpositions sous JOSM.


- deux démarches semblent adoptées par les contributeurs :
1) travailler dalle par dalle : la taille de la zone à traiter est 
petite. On progresse lentement mais on peut s'arrêter après chaque dalle.
2) travailler à l'intérieur des limites d'une commune : la fusion 
des couches sous JOSM permet de repérer rapidement les jonctions à 
faire. C'est plus efficace et il vaut mieux réserver les dalles de la 
commune sur QSM.
Les jonctions sur les limites intercommunales peuvent être 
délicates mais il semble que chaque tronçon se situe entièrement dans 
une commune.
Dans les deux cas, il faut veiller à supprimer les voies en doublon 
avec celles de la CC4 et à conserver les autres objets déjà présents.


- les conflits potentiels avec les tags des voies déjà présentes sur OSM :
 Le cas de la RN 165 qui traverse le territoire de Pont Aven est à 
traiter: Pour la CC4, il s'agit de highway=motoway alors que sur 
l'ensemble de l'itinéraire, la voie est tagée en highway=trunk.
Le problème se pose également pour la voirie départementale qui 
traverse une commune. Sur Pont Aven, une voie "unclassified" passe en 
"tertiary" sur la commune limitrophe.


Concernant QSM, je suggère d'améliorer l'ergonomie en offrant la 
possibilité d'appliquer un changement de tag à une sélection de dalles.
De même pour le site d'import, pouvoir importer un seul fichier OSM pour 
un rectangle de dalles déterminé par deux dalles de coin diamétralement 
opposées.


Encore bravo pour cette initiative réussie de libération de données 
géographiques !


Librement

Christophe










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