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

[Vincent de Chateau-Thierry]

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 :-)

vincent

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

Re: [OSM-talk-fr] nettoyage des imports bâti amont et aval

[Philippe Verdy]

Le 8 février 2012 18:38, Bruno Cortial  a écrit :
>
> Le 8 février 2012 17:44, sly (sylvain letuffe)  a écrit :
>
>> On mardi 7 février 2012, Bruno Cortial wrote:
>> > Salut,
>> > Il y a quelques temps, j'avais proposé 2 scripts python pour améliorer
>> > les
>> > fichiers Cléo.
>> > http://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035156.html
>>
>> Je te propose de passer sur la liste dev-fr histoire de ne pas remplir
>> plus ce
>> sujet avant d'y revenir si on a réussi à avancer.
>>
>> > Ca n'avait pas eu un grand succès à l'époque je retente ce soir: si des
>> > testeurs pouvaient faire un retour sur la qualité des fiabilisations.
>>
>> Hé bé c'est pas facile à lancer ton truc ! les modules python nécessaires
>> ne
>> semblent pas présents dans les debian stables, bon, j'ai réussi à m'en
>> dépêtrer quand même.
>>
>
> Merci d'y avoir passer du temps ! Je crois que le plus dur est de lire mon
> code :-)
> En plus il faut que je m'y remette, j'y ai pas touché depuis des mois...
>
>>
>> Quelques remarques à prendre avec pincettes, j'ai pas tout testé :
>> - En effet, comme s'inquiète julien, si deux bâtiments ou deux murs du
>> même
>> bâtiment sont séparés par moins que la tolérance ils sont fusionnés. Si ça
>> pouvait être réservé aux bâtiments qui se chevauches (erreur claire) ça
>> limiterais les fausses corrections
>
>
> Je crois que la valeur de tolérence est de l'ordre de 5 centimètres. doit
> doit pouvoir tuner çà. Sinon la condition d'overlap doit être facilement
> réalisable avec shaply. D'ailleur il y a eu des release de cette lib depuis,
> et il y sans doute des choses intéressantes pour ce code.
>
>
>>
>> - Concernant les noeuds dupliqués, a priori rien à dire, cette correction
>> là
>> me semble tranquille, mais il faudrait peut-être encore abaissé le seuil.
>> J'ai eu le cas d'une entrée d'immeuble qui formait un truc genre :
>>
>> _||__||_
>>
>> Transformée en :
>> _/\__/\__
>>
> C'est juste sur les script des noeuds dupliqués ? Ca m'intéresse. Tu as la
> commune et l'adresse ? Ca serait ptet' 50 cm finalement :-)

50 cm c'est encore trop, car c'est exactement la moitié de la
résolution métrique qu'on utilise, mais aussi parce que certaines
sources n'ont pas de données au mètre avec une résolution de 50 cm,
mais des données à la résolution de 30 cm. Je penche plutôt sur 30 cm,
sinon les sources à 30 cm vont se mettre à faire des zigzags si on les
"simplifie" en résolution métrique.

Noter que JOSM permet de placer les points et les différencier encore
de plusieurs pixels à l'écran, alors que les données enregistrées
seront identiques avec la précision des coordonnées WGS84 envoyées au
serveur. Ce cas est détecté par le validateur JOSM lorsqu'il prégénère
le code XML. Cette précision (où il n'y a plus moyen de distinguer les
coordonnées WGS84 en XML) est voisine de 3 cm en France
métropolitaine, et au zoom maximal correspond à la taille des petits
carrés jaunes à ce niveau maximum de zoom, soit moins de 8 pixels...
Dans ce cas JOSM indique que les nœuds bien  qu'apparemment distincts
au zoom maximum, sont en fait superposés dans le XML généré.

A cette échelle, il n'y a guère que le bati à nécessiter une
distinction aussi précise pour conserver leur "forme".

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Philippe Verdy]

Les FIXME c'est justement pour ce que le validateur ne détecte pas ou
ne peut pas détecter, par exemple des données à affiner ou vérifier
sur le terrain.

En revanche, mettre "FIXME" dans une valeur de tag (par exemple
name=FIXME) est inutile. Mais FIXME est tout à fait utilisable en tant
que clé, et prend alors une valeur textuelle expliquant ce qui devrait
être réglé (mais pas la peine de mentionner non plus un FIXME s'il
manque soit un nom soit une référence pour une route).

Exemples de FIXME :

* mentionner qu'il y a désaccord entre plusieurs sources, ou une
ambiguité sur les dates de ces sources, ce qui ne permet pas de
prendre une décision.

* mentionner que des données d'un import n'ont pas pu être traitées de
façon automatique, et qu'un tag (par exemple description) contient des
données à interpréter depuis la description, données qu'on peut alors
reclasser dans d'autres tag.

* mentionner un doûte sur une valeur

* mentionner un tracé douteux, même si le validateur ne signale rien,
par exemple des numéros de voies différents dans la même commune et
pour le même nom alors que ces voies sont connectées, ou bien deux
voies éloignées (non connectées), qui utilisent le même nom et la même
référence au sein de la même zone de numérotation (par exemple dans la
commune pour les voies communales, dans le département pour une route
départementale ou un chemin départemental, le pays entier pour une
route nationale ou une autoroute)

Noter cependant ces disjonctions arrivent dans certains cas sur un
tronçon où la route change temporairement de classification car le
tronçon de raccordement n'est pas encore construit ou aménagé (un
exemple en est l'A84 qui est disjointe à Avranche, car le tronçon de
raccordement se fait encore par la N 175 qui traverse la ville (et se
prolonge ensuite : il manque encore le tronçon autoroutier en rocade
d'Avranche, qui ne figure même pas encore sur les chantiers; en
attendant c'est la nationale, qui a été réaménagée, mais pas
suffisamment pour avoir la classification autoroutière).

Ces disjonctions ne sont donc pas toujours des erreurs, raison pour
laquelle le validateur ne signale rien. Un FIXME en revanche peut être
utilisé temporairement pour des erreurs à vérifier et corriger plus
tard. Si la vérification a eu lieu, et qu'il n'y a pas d'erreur, ce
FIXME sera à remplacer par une note mentionnant que la disjonction est
normale en l'état actuel des lieux.

Osmose n'affiche pas réellement les fixme mis en valeurs d'une clé
(hormi si cela est contraire à d'autres règles de toponymie ou de
typographie et capitalisation), mais détecte bien les noms de clés
"fixme" ou "FIXME". La présence d'un tel FIXME ne permet aucune
correction automatique. Il faut un contrmole humain qui ne se
contentera pas de le supprimer car ils ont une raison d'être.


Le 8 février 2012 18:00, Vincent de Chateau-Thierry  a écrit :
>
>> De : "HELFER Denis"
>>
>> Je lance une idée en l'air (pour voir où elle peut retomber) :
>> - injecter le fichier osm brut de fonderie (ou générer directement à partir 
>> du pdf)
> une base locale PostGIS
>> - utiliser les outils de PostGIS pour signaler les éléments problématiques
>> * points trop rapprochés (seuil de tolérance à définir)
>> * superposition d'objets
>> * détection de surfaces inférieures à un autre seuil
>> * etc
>> - le signalement est rabattu sur un élément FIXME ; des corrections simples 
>> peuvent
> peut-être déjà intervenir au sein de la base
>> - export de PostGIS vers osm
>>
>> Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger 
>> plus
> facilement, non ?
>> Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y 
>> réfléchisse
>>
>
> +1 pour le pré-traitement des fichiers "-houses" avant leur mise à 
> disposition,
> pour leur appliquer des corrections, que ce soit via PostGIs ou les scripts 
> de Bruno par
> ex.
> En revanche je ne crois pas à l'intérêt d'ajouter des FIXME dans le fichier. 
> Pour moi
> la fonction d'avertissement est déjà (bien) assurée par le Validator, je 
> crains que ces
> FIXME ne se retrouvent directement en base. Ignorer un warning du Validator 
> ou ignorer un
> FIXME, je vois peu de différence (vu de ma lorgnette).
>
> 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

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

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

[Philippe Verdy]

Le 8 février 2012 23:57, Pieren  a écrit :
> - ne pas surestimer le temps de mise à jour des tuiles de la carte en ligne

Je ne sais pas trop ce que cela veut dire. Parce que Mapnik (ou
MapQuest si on le préfère) ont un "lag" très variable. Et il suffit
qu'une tuile vient d'être raffraichie par le moteur de tuile pour que
cela repousse à bien plus tard toute nouvelle mise à jour. Hors une
tuile peut avoir été rendue par le moteur alors même que les modifs
n'étaient pas terminées : il suffit de faire un zoom avant ou arrière
pour que ce niveau soit mis à jour tout de suite et mis en cache local
pour JOSM.

De plus les tuiles des niveaux faibles de zoom mettent énormément plus
de temps à être mises à jour (elles demandent beaucoup plus de données
à charger, le moteur de rendu va donc leur donner une priorité plus
basse s'il faut les remettre à jour, en mettant un délai plus
important après qu'une modification y a eu lieu. Le moteur travaille
avec des files d'attentes contenant les numéros de tuiles modifiées,
il fixe alors semble-t-il des priorités en fonction du nombre de mises
à jour qui y ont eu lieu : plus il y a eu de modifs, plus la mise à
jour devient urgente et raccourcit le délai pour la gestion de la file
de priorité.

Le délai ne sert qu'à ça: déterminer les priorités, mais si la file
d'attente est vide, il est ignoré, et la tuile sera alors recalculée
immédiatement. Ce délai peut être réduit par de nouvelles mises à jour
dans la tuile (il semble bien qu'elles sont comptées, chaque tuile
ayant son propre compteur, mais n'enregistrant pas les données qui ont
été mises à jour puisqu'elles seront chargées seulement au moment du
rendu quand la tuile sort première de la file d'attente des tuiles),
mais jamais rallongé.

Enfin il y a plusieurs bases de tuiles, dont celles justement pour la
détection des erreurs (base de données Osmose, tuiles de la couche de
contrôle de surfaces administratives, etc.)

Mais comment expliquer ça simplement à des CM1/CM2 ?

Dommage que le moteur de rendu ne retourne pas une date estimée où une
tuile marquée comme étant modifiée sera remise à jour (en fonction de
sa file d'attente justement) ou de la place de la tuile dans cette
file d'attente et la longueur de cette file. Cela permettrait de
savoir si la tuile a tenu compte ou non d'une modif récente, en
activant une option d'affichage sur le client permettant d'ajouter
cela dans une couche transparente non intégrée dans la tuile mais
affichée par le client lui-même.

___
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

[Philippe Verdy]

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", qui montrent les plaques de rues.
Ce ne sont pas des "approximations", au moins concernant
l'orthographe, sauf si cepuis la prise de vue un nom de rue (ou de
route) a changé. La date de prise de vue peut renseigner, par rapport
à ce qui a été cartographié depuis le cadastre. Il arrive que les
photos soient plus récentes que le plan cadastral disponible.

Regarder une photo pour lire une plaque, ce n'est pas la copier, il
n'y a pas de violation du copyright sur la photo, Google n'est pas
propriétaire des noms affichés sur les plaques de rue et la
signalisation publique, mais seulement de sa base de données dérivée
de ces photos et des clichés eux-même à l'exclusion de *tout* ce
qu'ils représentent (que les objets présentés soient eux-mêmes publics
ou privés, les éléments privés étant aussi sujets à retrait par leurs
propriétaires légitimes qui peuvent demander à flouter une façade,
l'état d'une porte ou fenêtre, un intérieur visible par une fenêtre,
un visage reconnaissable oublié, une plaque d'immatriculation, un
mobilier ou équipement extérieur hors de la voie publique; il arrive
même que Google floute les numéros de routes sur la signalisation,
quand celle-ci ne correspond plus et la plaque de signalisation n'a
pas encore été changée par l'équipement départemental ou la commune).

Et je note que ***bien souvent*** les photos de Google Street View
(prises de plein pied) sont plus récentes que celles fournies par le
CNES/Spot Image pour Bing ou Google en mode aérien, et que les données
présentes dans la base OSM sont issues d'une vectorisation depuis
l'imagerie Bing (plus ancienne) et utilisée par les "Chair mappers".

Je ne dis pas qu'il faut reprendre les données de Google Street View.
En fait on n'en reprends aucune: on regarde les photos, qui souvent
aussi renseignent même sur des erreurs dans la base cartographique de
Google Maps, et qu'on peut aussi lui signaler en cliquant le lien
"signaler une erreur" (pour cela il faut sortir du zoom en mode
"street view" pour se repositionner sur la carte ou la vue satellite)
; par exemple des fautes d'orthographe, des accents manquants, des
noms obsolètes, etc... (Google demande qu'on lui fournisse une
référence fiable et datée pour qu'il accepte la correction, ou une
brève explication concernant un toponyme mal orthographié ou un accent
manquant, et permettant de localiser un autre nom auquel le toponyme
ou le nom de rue est normalement lié).

C'est aussi bien pour cela que Google Street View mentionne ses dates
de prises de vue, afin ensuite de pouvoir comparer avec d'autres
sources plus récentes qui lui seraient fournies, au cas où une photo
de plein pied ne serait elle aussi plus à jour (Google réponds à ces
signalements par Email et informe que la mise à jour de sa base peut
prendre plusieurs semaines pour apparaître sur son plan corrigé.

En attendant, on peut mettre à jour rapidement sur OSM. Et il est bon
dans ce cas-là d'ajouter une note mentionnant la source d'un éventuel
changement de nom ou de situation en contradiction avec les sources
utilisées ici (notamment l'imagerie Bing, et certaines autres sources
ouvertes non cadastrales) : par exemple un lien vers l'arrêté au
journal officiel mentionnant un changement de nom, la désaffection
d'une voie, le reclassement d'une route nationale en départementale,
une démolition de route récente... Sinon un cartographe amateur serait
tenté de remettre des données anciennes pourtant déjà corrigées et à
jour..

___
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] Openstreetmap chez les cm1 cm2

[Pieren]

Je profite de ce message pour ressortir un ancien blog en anglais sur
une expérience similaire (mais le public était un peu plus vieux :
15/16 ans):

http://geoxchange.esriuk.com/journal/2011/11/17/the-next-geographers.html

Je traduis ce que l'auteur a retenu (entre autres) de cette expérience
et qui intéressera ceux qui s'engagent dans des actions similaires :
- ralentir la démo - l'auteur a été un peu trop rapide et aurait pu
laisser les élèves suivrent la démo en les laissant faire leurs
propres essais en parallèle
- s'assurer qu'ils n'utilisent pas potlatch 1 en mode "edit live"
- s'assurer qu'on montre comment effacer et annuler les erreurs.
- ne pas surestimer le temps de mise à jour des tuiles de la carte en ligne
- les presets de l'éditeur (écoles, magasins, arrêts de bus)
permettent aux élèves d'aller seuls au-delà des quelques exemples qui
peuvent être montrés lors de la présentation (bâti, adresses).

Pieren

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

Re: [OSM-talk-fr] forum: générer carte JPEG

[Henri Gabolde (lp)]

Plus facile à utiliser que Qgis, Viking (Linux ou Windows).

Tu ne pourras pas modifier la carte OSM, mais tu pourra rajouter dans 
des couches supplémentaires tes points ou tes traces


http://sourceforge.net/apps/mediawiki/viking/index.php?title=Main_Page
http://doc.ubuntu-fr.org/viking

Cordialement, Henri

Le 30/01/2012 17:16, partir-en-vtt a écrit :

Bonjour,

Regardez le logiciel gratuit et libre Qgis. En effet, avec cet outil, vous
pourrez composer votre carte avec les données OSM et ajouter vos données.



--
View this message in context: 
http://gis.19327.n5.nabble.com/forum-generer-carte-JPEG-tp5441808p5441855.html
Sent from the France mailing list archive at Nabble.com.

___
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] Contact avec un service SIG dans l'Aisne

[Brice]

Bonsoir,

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 ?


Brice Mallet / Britz




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

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

[Romain MEHUT]

Le 8 février 2012 18:41, monsieur a  a écrit :

> Le 8 févr. 2012 08:57, "Romain MEHUT"  a écrit :
> >
> > Bonjour,
> >
> > Excusez moi pour la facilité, Simon va pouvoir faire un stage
> orthographe chez les CM1/CM2 ;)
> >
>
> Si c'est une offre, je l'accepte volontiers, je regrette de n'avoir pas
> bien suivi les cours a cette époque.
>
Il n'est jamais trop tard...

> > Bon plus sérieusement, j'ai déjà transmis à mon enseignante préférée...
> >
> > Romain
> >
> > Le 7 février 2012 22:26, simon  a écrit :
> >>
> >> Bonjour
> >>
> >>
> >> Je viens de faire un atelier OpenStreetMap dans le cadre d'une activité
> de
> >> soutien scolaire pour des classes de cm1 et cm2.
> >> Le but étais de faire une sensibilisation au carte et de leurs faire
> découvrir
> >> le quartier.
> >>
> >> Pour le matériel je disposait d'un vidéo projecteur sur un tableau
> blanc pour
> >> pouvoir annoter la carte.
> >>
> >> Après avoir fait une très courte et simplifié présentation d'OSM, je
> leur est
> >> fait recherché ou on se situais sur la carte. Tous le monde n'étant pas
> >> d'accord sur les niveau de zoom élevés nous avons tenté de les faire
> travaillé
> >> de façon communautaire en les faisant venir placé une croix sur
> l'endroit
> >> supposé avec leur commentaire. au fur et a mesure des participation et
> de la
> >> découverte de nouveau point de repère le travail de groupe nous fi
> zoomer sur
> >> notre quartier.
> >>
> >> Ensuite vain l'étape de la complétion de la carte par groupe de deux
> avec
> >> chaqu'un une carte du quartier au format papier il ont repéré tous ce
> qu'ils
> >> connaissaient et qui n'étais pas sur la carte.
> >>
> >> Ces données ont été ensuite reportées par moi même dans OSM sous le
> changeset
> >> http://www.openstreetmap.org/browse/changeset/10616362
> >>
> >> Une deuxième session avec se groupe est prévu pour leur montrer
> Openstreetbug,
> >> entre temps il devraient faire un peut de terrain avec leur formateur.
> >>
> >> Ces nouveaux contributeurs ce sont révélés fort intéressé et au dire de
> leur
> >> formateur "très calme par rapport à l'habitude"
> >>
> >> 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.
> >>
> >> Librement
> >>
> >> Simon
> >>
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Romain MEHUT]

Le 8 février 2012 14:57, Etienne Trimaille  a
écrit :

>
>
> Le 8 février 2012 14:54, Romain MEHUT  a écrit :
>
> Le 8 février 2012 14:52, Pieren  a écrit :
>>
>> 2012/2/8 Romain MEHUT :
>>> > J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
>>> > plusieurs morceaux (par les limites de parcelles) qui prennent
>>> nettement
>>> > plus de temps à corriger.
>>>
>>> Non. Si les polygones sont correctement attachés, la fusion des deux
>>> se fait en une touche avec JOSM.
>>>
>>
>> Laquelle?
>>
>
>
> Maj + J ;-)
>
> Faut regarder dans les menus ce que propose JOSM ;-)
>

Merci. Voici un peu de temps de gagné!

 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
>>
>>
>
> ___
> 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] 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] Vérification Osmose: nettoyage des imports routiers, champs redondants

[Vincent de Chateau-Thierry]

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é.


 non corrigées malgré la présence

de photos dans son mode "Street View", et souvent Google Maps (Bing
aussi...) inscrit le nom d'un lieu-dit comme nom d'une voie à défaut
d'autre chose. Dans ces cas là, seul le numéro de référence est
réellement pertinent.

Pour de nombreuses routes sans numéro de référence, ce n'est pas Bing
ou Google Maps qui donne ces numéros, mais presque toujours le
cadastre (car il n'y a souvent aucun panneau, cette numérotation est
gérée directement au niveau de chaque commune, et même pas toujours
affiché sur les plans municipaux diffusés par la commune ou affichés
sur des panneaux).
(...)


vincent

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

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

[Bruno Cortial]

Le 8 février 2012 15:32, Jean Couteau  a écrit :

> A Nantes, l'humain fait presque tout à la main :
>
>
> http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole
>
> - --
> Jean Couteau - Code Lutin
>


J'ai pas les chiffres sous le coude mais sur les rues importées "à la main"
de Nantes Métropole on n'est pas loin de 7% sur lesquelles il y a un
signalement "à revoir". Donc l'import à la main, mais prémaché et outillé,
semble justifié. Il faudra faire un retour sur la liste des petites anos
rencontrées (quand j'arriverai à faire marcher ces fichus commentaires).
Alors bien sûr c'est peut-être du aux données de Nantes Métropole...

Pour les interressés : http://arboulig.free.fr/OSM/ImportNM/   (tout aussi
fiable que mes scripts sur le bati ;-)  )

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

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

[monsieur a]

Le 8 févr. 2012 08:57, "Romain MEHUT"  a écrit :
>
> Bonjour,
>
> Excusez moi pour la facilité, Simon va pouvoir faire un stage orthographe
chez les CM1/CM2 ;)
>

Si c'est une offre, je l'accepte volontiers, je regrette de n'avoir pas
bien suivi les cours a cette époque.

> Bon plus sérieusement, j'ai déjà transmis à mon enseignante préférée...
>
> Romain
>
> Le 7 février 2012 22:26, simon  a écrit :
>>
>> Bonjour
>>
>>
>> Je viens de faire un atelier OpenStreetMap dans le cadre d'une activité
de
>> soutien scolaire pour des classes de cm1 et cm2.
>> Le but étais de faire une sensibilisation au carte et de leurs faire
découvrir
>> le quartier.
>>
>> Pour le matériel je disposait d'un vidéo projecteur sur un tableau blanc
pour
>> pouvoir annoter la carte.
>>
>> Après avoir fait une très courte et simplifié présentation d'OSM, je
leur est
>> fait recherché ou on se situais sur la carte. Tous le monde n'étant pas
>> d'accord sur les niveau de zoom élevés nous avons tenté de les faire
travaillé
>> de façon communautaire en les faisant venir placé une croix sur l'endroit
>> supposé avec leur commentaire. au fur et a mesure des participation et
de la
>> découverte de nouveau point de repère le travail de groupe nous fi
zoomer sur
>> notre quartier.
>>
>> Ensuite vain l'étape de la complétion de la carte par groupe de deux avec
>> chaqu'un une carte du quartier au format papier il ont repéré tous ce
qu'ils
>> connaissaient et qui n'étais pas sur la carte.
>>
>> Ces données ont été ensuite reportées par moi même dans OSM sous le
changeset
>> http://www.openstreetmap.org/browse/changeset/10616362
>>
>> Une deuxième session avec se groupe est prévu pour leur montrer
Openstreetbug,
>> entre temps il devraient faire un peut de terrain avec leur formateur.
>>
>> Ces nouveaux contributeurs ce sont révélés fort intéressé et au dire de
leur
>> formateur "très calme par rapport à l'habitude"
>>
>> 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.
>>
>> Librement
>>
>> Simon
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] nettoyage des imports bâti amont et aval

[Bruno Cortial]

Le 8 février 2012 17:44, sly (sylvain letuffe)  a écrit :

> On mardi 7 février 2012, Bruno Cortial wrote:
> > Salut,
> > Il y a quelques temps, j'avais proposé 2 scripts python pour améliorer
> les
> > fichiers Cléo.
> > http://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035156.html
>
> Je te propose de passer sur la liste dev-fr histoire de ne pas remplir
> plus ce
> sujet avant d'y revenir si on a réussi à avancer.
>
> > Ca n'avait pas eu un grand succès à l'époque je retente ce soir: si des
> > testeurs pouvaient faire un retour sur la qualité des fiabilisations.
>
> Hé bé c'est pas facile à lancer ton truc ! les modules python nécessaires
> ne
> semblent pas présents dans les debian stables, bon, j'ai réussi à m'en
> dépêtrer quand même.
>
>
Merci d'y avoir passer du temps ! Je crois que le plus dur est de lire mon
code :-)
En plus il faut que je m'y remette, j'y ai pas touché depuis des mois...


> Quelques remarques à prendre avec pincettes, j'ai pas tout testé :
> - En effet, comme s'inquiète julien, si deux bâtiments ou deux murs du même
> bâtiment sont séparés par moins que la tolérance ils sont fusionnés. Si ça
> pouvait être réservé aux bâtiments qui se chevauches (erreur claire) ça
> limiterais les fausses corrections
>

Je crois que la valeur de tolérence est de l'ordre de 5 centimètres. doit
doit pouvoir tuner çà. Sinon la condition d'overlap doit être facilement
réalisable avec shaply. D'ailleur il y a eu des release de cette lib
depuis, et il y sans doute des choses intéressantes pour ce code.



> - Concernant les noeuds dupliqués, a priori rien à dire, cette correction
> là
> me semble tranquille, mais il faudrait peut-être encore abaissé le seuil.
> J'ai eu le cas d'une entrée d'immeuble qui formait un truc genre :
>
> _||__||_
>
> Transformée en :
> _/\__/\__
>
> C'est juste sur les script des noeuds dupliqués ? Ca m'intéresse. Tu as la
commune et l'adresse ? Ca serait ptet' 50 cm finalement :-)



> Si d'autres veulent se faire une idée de ce que fait le soft de bruno sur
> un
> fichier osm réél, on peut s'en faire une idée ici :
> http://download.letuffe.org/correction-auto-bati/
>
> En bref, ça passe de 320 erreurs de bâtiments se chevauchant, à 60 (selon
> le
> validateur)
> 260 usure de la touche J en moins
>
> == concernant le "déjà dans la base osm" ==
>
> - J'ai fais une correction pour que le soft conserve les attributs
> "version"
> des relations/ways/noeuds, ce qui permet de travailler sur des données déjà
> dans osm alors que ta version est prévue pour des fichiers osm neufs (id
> négatifs) et donc, sans n° de version.
> Ce qui est logique, pour être lancé juste après l'export par cleocarto
>
>
C'est le but final, mais déjà qu'on limite le flux de nouveaux cas.

Sinon il y a deux autres axe d'amélioration des fichiers Cleo, pour les
courageux :
* la simplification des géométries, des centaines de points en moins à
chaque import. C'est faisable par JOSM, mais il ne simplifie pas les
segments partagés par 2 polygones (à contrôler parce ca fait un moment que
j'ai pas utiliser cette fonction). J'avais creusé les fonctions shaply,
mais sans aboutir, car il y a un risque de perdre la topologie.

* Faire le boulot de validator avant en mettant des fixme sur les objets se
chevauchant: on gagne du temps, et comme mon script créé des cas qui passe
sous le radar de validator... exemple :

  +-+
  | |
  | |
+-+--+  |
| |  |  |
| +--+--+
++

Après les scripts:
  +-+
  | |
  | |
  +--+  |
  |  |  |
  +--+--+

Cette situation de chevauchement n'est pas détectée par validator

Bruno
___
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

[Philippe Verdy]

Cela ne concerne pas que la "4C", je trouve des cas semblables partout
en France, où le champ "name" est mal choisi...

Encore une fois, en cas de doute sur la clé à utiliser pour les
"tags", avec des données pourtant utiles au repérage, mieux vaut
importer le texte sous la clé "description". L'absence de nom et/où de
référence sera ensuite rapportée par Osmose, mais on évitera de mettre
des infos qui ne sont pas des noms, et qui entreront ensuite en
conflit avec des noms de rues par exemple, afin ensuite de les relier
aux adresses.
Et sur un import massif, il n'est pas inutile de mettre un tag de
suivi pour la vérification manuelle (sur la base de diverses sources
utilisables, sur le terrain ou sur des photos lisibles sur un moteur
comme Google Maps, pour voir les plaques de rues et de lieux-dits ou
la signalisation).

 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, non corrigées malgré la présence
de photos dans son mode "Street View", et souvent Google Maps (Bing
aussi...) inscrit le nom d'un lieu-dit comme nom d'une voie à défaut
d'autre chose. Dans ces cas là, seul le numéro de référence est
réellement pertinent.

Pour de nombreuses routes sans numéro de référence, ce n'est pas Bing
ou Google Maps qui donne ces numéros, mais presque toujours le
cadastre (car il n'y a souvent aucun panneau, cette numérotation est
gérée directement au niveau de chaque commune, et même pas toujours
affiché sur les plans municipaux diffusés par la commune ou affichés
sur des panneaux).

Ces voies non numérotées dans Bing et Google Maps sont essentiellement
les chemins ou voies communales (format "C nnn"), chemins vicinaux
(format "CV nnn"), chemins ruraux (format "CR nnn"), chemins
d'exploitation (format "CE nnn"), et chemins départementaux (format
"CD nnn", trouvés uniquement en limite de département pour les petits
chemins qui en marquent la frontière), car justement on ne les voit
partiquement jamais dehors sur un panneau.

Parfois il faut se pencher (on ne verra rien sur les photos de Google
Street View) et regarder les inscriptions sur certaines bornes
cadastrales, mais bon nombre de bornes n'affichent que des numéros de
parcelle, parfois un code interne difficile à interpréter ; mais on y
voit souvent l'identité du service cadastral qui les plantées (avec un
avertissement "Ne pas déplacer", afin justement de les reconnaître).

Ces bornes cadastrales n'ont pas toujours une grande durée de vie, et
sont posées par des géomètres avant le début de travaux sur des
terrains faisant l'objet de demande de permis de construire. Après
quoi le chantier est contrôlé et la commune peut autoriser leur
retrait éventuel (quand ces bornes ne font pas partie du réseau
géodésique réglementaire), le plan cadastral prenant en compte les
bâtiments ou voies construits et recettés, conformes aux permis de
construire.

Elles peuvent aussi être déplacées (pas par les propriétaires
eux-mêmes ! il faut faire une demande d'autorisation), voire
supprimées, notamment dans le cadre de remembrements de parcelles pour
une exploitation agricole, ou de construction de murs de séparation de
propriétés (hors voirie publique, car les collectivités imposent des
distances réglementaires sur les terrains privés, dans lesquelles où
rien ne peut être construit en dur, parfois même pas un arbre, mais où
des plantations "légères" restent possibles comme des pelouses; il
arrive aussi que des morceaux de parcelles fassent l'objet d'une
préemption par les communes, où rien ne peut être aménagé par les
propriétaires, en vue d'un élargissement futur d'une petite voirie ;
mais cette préemption peut mettre du temps à se transformer en rachat
de terrain, le temps de trouver les accords avec les propriétaires et
les budgets nécessaires pour le rachat des terrains expropriés, le
plan d'aménagement n'étant pas complètement défini).

Le 8 février 2012 16:19, Marc SIBERT  a écrit :
> Bonjour,
>
> Pour faire court (si si c'est aussi possible), je plaide coupable, car j'ai
> activement participé à l'import de la 4C probablement à l'origine de tes
> remarques (cf. http://freeroute.fr/4c/ & http://freeroute.fr/?page_id=307).
>
> Je suis donc à ta dispo pour un petit marathon correctif dans ce sens.
>
> A+
>
> --
> Marc Sibert
> m...@sibert.fr
>
> Le 8 février 2012 15:51, Philippe Verdy  a écrit :
>>
>> Je tombe souvent sur des zones où Osmose annonce (avec raison) une
>>
>> grande redondance de données parmi celles qui ont été importées.
>> Notamment car les champs sont en fait mal choisis pour les mettre.
>>
>> Exemple:
>>
>>  
>>  
>>
>> Ici, le champ "name" ne contient pas le nom de la voie, c'est en fait
>> une description (un nom de voie pourrait s'y ajouter si la voie
>> traverse par exemple un village et prend le nom d'une rue).
>> La partie de cette description "Voie communales n°7" correspond à ce
>> qui a été mis dans le "ref". Le reste es

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Vincent de Chateau-Thierry]

> De : "HELFER Denis" 
> 
> Je lance une idée en l'air (pour voir où elle peut retomber) :
> - injecter le fichier osm brut de fonderie (ou générer directement à partir 
> du pdf) 
une base locale PostGIS
> - utiliser les outils de PostGIS pour signaler les éléments problématiques
> * points trop rapprochés (seuil de tolérance à définir)
> * superposition d'objets
> * détection de surfaces inférieures à un autre seuil
> * etc
> - le signalement est rabattu sur un élément FIXME ; des corrections simples 
> peuvent 
peut-être déjà intervenir au sein de la base
> - export de PostGIS vers osm
> 
> Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger 
> plus 
facilement, non ?
> Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y 
> réfléchisse 
> 

+1 pour le pré-traitement des fichiers "-houses" avant leur mise à disposition,
pour leur appliquer des corrections, que ce soit via PostGIs ou les scripts de 
Bruno par 
ex.
En revanche je ne crois pas à l'intérêt d'ajouter des FIXME dans le fichier. 
Pour moi
la fonction d'avertissement est déjà (bien) assurée par le Validator, je crains 
que ces
FIXME ne se retrouvent directement en base. Ignorer un warning du Validator ou 
ignorer un
FIXME, je vois peu de différence (vu de ma lorgnette). 

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] nettoyage des imports bâti amont et aval

[sly (sylvain letuffe)]

On mardi 7 février 2012, Bruno Cortial wrote:
> Salut,
> Il y a quelques temps, j'avais proposé 2 scripts python pour améliorer les
> fichiers Cléo.
> http://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035156.html

Je te propose de passer sur la liste dev-fr histoire de ne pas remplir plus ce 
sujet avant d'y revenir si on a réussi à avancer.

> Ca n'avait pas eu un grand succès à l'époque je retente ce soir: si des
> testeurs pouvaient faire un retour sur la qualité des fiabilisations. 

Hé bé c'est pas facile à lancer ton truc ! les modules python nécessaires ne 
semblent pas présents dans les debian stables, bon, j'ai réussi à m'en 
dépêtrer quand même.

Quelques remarques à prendre avec pincettes, j'ai pas tout testé :
- En effet, comme s'inquiète julien, si deux bâtiments ou deux murs du même 
bâtiment sont séparés par moins que la tolérance ils sont fusionnés. Si ça 
pouvait être réservé aux bâtiments qui se chevauches (erreur claire) ça 
limiterais les fausses corrections
- Concernant les noeuds dupliqués, a priori rien à dire, cette correction là 
me semble tranquille, mais il faudrait peut-être encore abaissé le seuil.
J'ai eu le cas d'une entrée d'immeuble qui formait un truc genre :
 
_||__||_

Transformée en :
_/\__/\__

Si d'autres veulent se faire une idée de ce que fait le soft de bruno sur un 
fichier osm réél, on peut s'en faire une idée ici :
http://download.letuffe.org/correction-auto-bati/

En bref, ça passe de 320 erreurs de bâtiments se chevauchant, à 60 (selon le 
validateur)
260 usure de la touche J en moins

== concernant le "déjà dans la base osm" ==

- J'ai fais une correction pour que le soft conserve les attributs "version" 
des relations/ways/noeuds, ce qui permet de travailler sur des données déjà 
dans osm alors que ta version est prévue pour des fichiers osm neufs (id 
négatifs) et donc, sans n° de version.
Ce qui est logique, pour être lancé juste après l'export par cleocarto


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[HELFER Denis]

> -Message d'origine-
> De : sly (sylvain letuffe) [mailto:li...@letuffe.org]
> Envoyé : mercredi 8 février 2012 14:32
> À : Discussions sur OSM en français
> Objet : Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo
> carto
> 
> > > Frédéric Rodrigo :
> > > - Il y a peut être une solution pas trop compliqué à mettre en
> œuvre
> > > pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction
> > > http://postgis.org/documentation/manual-svn/ST_Snap.html
> 
> Je pense que c'est une solution valable pour nettoyer sa propre copie
> de la
> base, pas une méthode pour corriger en amont celle de OSM.

Je lance une idée en l'air (pour voir où elle peut retomber) :
- injecter le fichier osm  brut de fonderie (ou générer directement à partir du 
pdf) une base locale PostGIS
- utiliser les outils de PostGIS pour signaler les éléments problématiques
* points trop rapprochés (seuil de tolérance à définir)
* superposition d'objets
* détection de surfaces inférieures à un autre seuil
* etc
- le signalement est rabattu sur un élément FIXME ; des corrections simples 
peuvent peut-être déjà intervenir au sein de la base
- export de PostGIS vers osm

Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger 
plus facilement, non ?
Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y 
réfléchisse 

Mes 0,02€
Denis

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

Re: [OSM-talk-fr] Import Ballades Vertes du 71 dans le cadre de Night of the live mapping, le 7 Février

[Marc SIBERT]

Mon "peut-être" n'était pas anodin, je pensais à cette possibilité.

Le 8 février 2012 16:24, Vincent de Chateau-Thierry  a
écrit :

>
> > De : "Marc SIBERT"
>
> (...) Je
> > soupçonne d'ailleurs que les traces sont tirées d'un décalque sur des
> > cartes IGN réalisé par le CG : si cela est confirmé, cela mettrait
> > *peut-être *en cause la responsabilité du CG vis à vis de la
> réutilisation de
> > ces données à des fins commerciales. OSM ne peut être inquiété car :
> >
> > 1. les données viennent du site du CG71 et ont une licence compatible
> > CC-BY-SA & ODbL (http://www.opendata71.fr/licence/)
> > 2. les information de géolocalisation des nodes sont systématiquement
> > modifiées (du fait de leur faible qualité) avant d'être intégrées dans
> OSM.
>
> L'utilisation de fonds IGN par certains de ses clients disposant d'une
> licence
> professionnelle doit permettre la création de données sans inquiétude
> quant à leur
> réutilisation, cf. les éléments fournis par Denis :
>
> http://lists.openstreetmap.org/pipermail/talk-fr/2011-December/038369.html
>
> vincent
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous
> tente ?
> Je crée ma boîte mail www.laposte.net
>
>
A+

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

Re: [OSM-talk-fr] Import Ballades Vertes du 71 dans le cadre de Night of the live mapping, le 7 Février

[Vincent de Chateau-Thierry]

> De : "Marc SIBERT" 

(...) Je
> soupçonne d'ailleurs que les traces sont tirées d'un décalque sur des
> cartes IGN réalisé par le CG : si cela est confirmé, cela mettrait
> peut-être en cause la responsabilité du CG vis à vis de la réutilisation de
> ces données à des fins commerciales. OSM ne peut être inquiété car :
> 
> 1. les données viennent du site du CG71 et ont une licence compatible
> CC-BY-SA & ODbL (http://www.opendata71.fr/licence/)
> 2. les information de géolocalisation des nodes sont systématiquement
> modifiées (du fait de leur faible qualité) avant d'être intégrées dans OSM.

L'utilisation de fonds IGN par certains de ses clients disposant d'une licence
professionnelle doit permettre la création de données sans inquiétude quant à 
leur
réutilisation, cf. les éléments fournis par Denis :

http://lists.openstreetmap.org/pipermail/talk-fr/2011-December/038369.html

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] Import bâti => nettoyage des données cleo carto

[Eric Sibert]

J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
plusieurs morceaux (par les limites de parcelles) qui prennent nettement
plus de temps à corriger.


Comme ça vient d'être signalé, il y a des bâtiments mitoyens  
construits indépendamment sur des parcelles voisines (typiquement dans  
les centres anciens) qui n'ont pas lieu d'être fusionnés. Et  
inversement, des bâtiments uniques construits sur plusieurs parcelles  
qui eux doivent être fusionnés. Les données du cadastre seul ne  
permettent pas de choisir. Donc, pas de fusion/correction automatique,  
uniquement du manuel après contrôle sur le terrain.


Sinon, j'ai aussi rencontré des cas de bâtiments récents sur parcelle  
unique mais découpés en plusieurs morceaux. Dans ce cas, je serais  
plus favorable à un traitement automatisé.


Il semble qu'à un moment donné (durant automne 2011), cleo carto  
faisait la fusion en automatique. Vous confirmez?


Eric


___
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

[Marc SIBERT]

Bonjour,

Pour faire court (si si c'est aussi possible), je plaide coupable, car j'ai
activement participé à l'import de la 4C probablement à l'origine de tes
remarques (cf. http://freeroute.fr/4c/ & http://freeroute.fr/?page_id=307).

Je suis donc à ta dispo pour un petit marathon correctif dans ce sens.

A+

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

Le 8 février 2012 15:51, Philippe Verdy  a écrit :

> Je tombe souvent sur des zones où Osmose annonce (avec raison) une
> grande redondance de données parmi celles qui ont été importées.
> Notamment car les champs sont en fait mal choisis pour les mettre.
>
> Exemple:
>
>  
>  
>
> Ici, le champ "name" ne contient pas le nom de la voie, c'est en fait
> une description (un nom de voie pourrait s'y ajouter si la voie
> traverse par exemple un village et prend le nom d'une rue).
> La partie de cette description "Voie communales n°7" correspond à ce
> qui a été mis dans le "ref". Le reste est seulement descriptif.
>
> Je suggère que les imports routiers fassent attention aux données
> qu'ils importent, quitte à utiliser un champ "description" pour les
> données qui ne sont pas converties correctement, afin de faciliter les
> mises à jour manuelles, où à titre documentaire ou de suivi. Par
> exemple la plupart des imports ajoutent des tags de suivi, propres à
> la source utilisée, notamment des identifiants divers, comme ici la
> source de la Communauté de communes de Concarneau - Cornouailles
> (), avec des tags dont le nom commence par "4C:". Cela doit
> suffire pour assurer une synchronisation ou un suivi de ce qui a été
> importé (attention toutefois à utiliser des tags appropriés qui ne
> risquent pas de rentrer en conflit avec des tags génériques
> documentés: l'utilisation des préfixes est donc fortement recommandé,
> surtout si la source est très locale et pas nationale, comme ici une
> communauté de communes).
>
> Si on en tient compte, l'exemple ci-dessus (détecté par le
> vérificateur Osmose) devrait être après nettoyage:
>
>  
>  
>
> Reste à savoir ensuite si on garde ou non les champs "description" qui
> restent (à mon avis ils peuvent rester, et seront utiles même pour le
> suivi ou lors de l'utilisation d'une carte interactive, surtout ici où
> il n'y a pas de nom clair, ou alors parce que ces noms révèlent des
> lieux dits proches, qui facilitent aussi la localisation, à condition
> d'avoir demandé à afficher les infos détaillées d'une voie)...
>
> De même, des champs fréquents comme:
>
>  
>  
>
> sont clairement redondants, car le nom donné n'apporte strictement
> rien de plus que la référence. Dans ce cas on supprime directement le
> champ "name", et on ne garde que le champ "ref".
>
> Ces nettoyages peuvent se faire directement depuis l'interface en
> ligne d'Osmose, avec rawedit et non JOSM, parce que c'est nettement
> plus léger et rapide à faire.
>
> Mais pour des zones étendues où il y a une grande répétition de ces
> redondances, la fonction de recherche intégrée à JOSM permet de faire
> des sélections multiples d'objets sur la valeur d'un champ spécifique,
> pour corriger cette valeur dans tous les objets chargés qui utilisent
> cette valeur redondante.
>
> A mon avis, il vaudrait mieux faire ces nettoyages dans JOSM avant
> l'importation vers la base de données, mais il peut s'agit aussi d'un
> oubli. A vous de voir quel éditeur utiliser selon l'étendue des
> nettoyages à faire avant vos imports de données. ou après pour
> corriger les erreurs introduites après l'importation des données
>
> ___
> 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] Import Ballades Vertes du 71 dans le cadre de Night of the live mapping, le 7 Février

[Marc SIBERT]

Le 8 février 2012 09:57, partir-en-vtt  a écrit :

> Alors les chemins ont été intégré ?
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/ANNONCE-Night-of-the-live-mapping-le-7-Fevrier-a-Paris-et-ailleurs-tp5441144p5465964.html
> Sent from the France mailing list archive at Nabble.com.
>
> Bonjour,

En fait, comme à Grenoble, à Paris nous avons beaucoup parlé (c'est un
euphémisme même...) et pas trop agi pour ma personne en tout cas. J'ai fait
une présentation informelle du processus d'import de "Balades Vertes" dans
OpenLayers et la manière de les récupérer dans JOSM.

En pratique, l'import se passe bien, mais le travail de reprise
(réutilisation des chemins déjà existant) et de nettoyage des traces
(plusieurs mètres de dérive ou d’imprécision constaté avec les imports du
bâti par exemple) est très long. Hier soir j'en avais fait 3. Peut-être
qu'un autre contributeur en a fait une de son côté. J'en ai fait une autre
ce matin. Je poursuivrais cela dans le temps.

L'étape suivante consiste à trouver un moyen de mettre en valeur ces
balades dans un site web. Incidemment, j'ai découvert un site touristique
du CG du 71 qui affiche déjà ces traces au dessus du GéoPortail. Je
soupçonne d'ailleurs que les traces sont tirées d'un décalque sur des
cartes IGN réalisé par le CG : si cela est confirmé, cela mettrait
peut-être en cause la responsabilité du CG vis à vis de la réutilisation de
ces données à des fins commerciales. OSM ne peut être inquiété car :

   1. les données viennent du site du CG71 et ont une licence compatible
   CC-BY-SA & ODbL (http://www.opendata71.fr/licence/)
   2. les information de géolocalisation des nodes sont systématiquement
   modifiées (du fait de leur faible qualité) avant d'être intégrées dans OSM.

Note : il y a un concours de bonnes idées d'utilisation sur le site de CG,
pour ceux qui voudraient exploiter ces balades dans OSM et les mettre en
valeur.
A+

-- 
Marc Sibert
m...@sibert.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

[Frédéric Rodrigo]

Bonjour,

Tes remarques sont légitimes. Malheureusement ces données ne
proviennent pas d'imports mais de contributions manuelle en recopiant
"bêtement" le cadastre.

Frédéric.

Le 8 février 2012 15:51, Philippe Verdy  a écrit :
> Je tombe souvent sur des zones où Osmose annonce (avec raison) une
> grande redondance de données parmi celles qui ont été importées.
> Notamment car les champs sont en fait mal choisis pour les mettre.
>
> Exemple:
>
>  
>  
>
> Ici, le champ "name" ne contient pas le nom de la voie, c'est en fait
> une description (un nom de voie pourrait s'y ajouter si la voie
> traverse par exemple un village et prend le nom d'une rue).
> La partie de cette description "Voie communales n°7" correspond à ce
> qui a été mis dans le "ref". Le reste est seulement descriptif.
>
> Je suggère que les imports routiers fassent attention aux données
> qu'ils importent, quitte à utiliser un champ "description" pour les
> données qui ne sont pas converties correctement, afin de faciliter les
> mises à jour manuelles, où à titre documentaire ou de suivi. Par
> exemple la plupart des imports ajoutent des tags de suivi, propres à
> la source utilisée, notamment des identifiants divers, comme ici la
> source de la Communauté de communes de Concarneau - Cornouailles
> (), avec des tags dont le nom commence par "4C:". Cela doit
> suffire pour assurer une synchronisation ou un suivi de ce qui a été
> importé (attention toutefois à utiliser des tags appropriés qui ne
> risquent pas de rentrer en conflit avec des tags génériques
> documentés: l'utilisation des préfixes est donc fortement recommandé,
> surtout si la source est très locale et pas nationale, comme ici une
> communauté de communes).
>
> Si on en tient compte, l'exemple ci-dessus (détecté par le
> vérificateur Osmose) devrait être après nettoyage:
>
>  
>  
>
> Reste à savoir ensuite si on garde ou non les champs "description" qui
> restent (à mon avis ils peuvent rester, et seront utiles même pour le
> suivi ou lors de l'utilisation d'une carte interactive, surtout ici où
> il n'y a pas de nom clair, ou alors parce que ces noms révèlent des
> lieux dits proches, qui facilitent aussi la localisation, à condition
> d'avoir demandé à afficher les infos détaillées d'une voie)...
>
> De même, des champs fréquents comme:
>
>  
>  
>
> sont clairement redondants, car le nom donné n'apporte strictement
> rien de plus que la référence. Dans ce cas on supprime directement le
> champ "name", et on ne garde que le champ "ref".
>
> Ces nettoyages peuvent se faire directement depuis l'interface en
> ligne d'Osmose, avec rawedit et non JOSM, parce que c'est nettement
> plus léger et rapide à faire.
>
> Mais pour des zones étendues où il y a une grande répétition de ces
> redondances, la fonction de recherche intégrée à JOSM permet de faire
> des sélections multiples d'objets sur la valeur d'un champ spécifique,
> pour corriger cette valeur dans tous les objets chargés qui utilisent
> cette valeur redondante.
>
> A mon avis, il vaudrait mieux faire ces nettoyages dans JOSM avant
> l'importation vers la base de données, mais il peut s'agit aussi d'un
> oubli. A vous de voir quel éditeur utiliser selon l'étendue des
> nettoyages à faire avant vos imports de données. ou après pour
> corriger les erreurs introduites après l'importation des données
>
> ___
> 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] bonjour + utilisation de data.gouv.fr

[arsyl]

Bonjour,j'arrive fraichement sur le talk-fr bien que contribuant déjà depuis quelques temps à OSM (notamment dans les forêts sarthoises, grâce à mon précieux GPS, Garmin Oregon de son petit nom). J'ai un peu fouillé dans data.gouv.fr, et ai déniché des données qui me semblent intéressantes : les périmètres des forêts publiques, produites par l'ONF. Je me suis permis de mettre à jour le wiki en ce sens. Par ailleurs, j'ai intégré le périmètre de la forêt domaniale de Sillé-le-Guillaume à OSM avec landuse=forest et name="forêt domaniale de Sillé-le-Guillaume". Je suis en train de faire les vérifications mais le tracé me semble très précis (sans commune mesure avec Corine Landcover). Il faudra simplement retirer du polygone les maisons forestières, les étangs et les quelques prairies permanentes, et retirer la couche issue de Corine Landcover, ou plutôt n'y laisser que les forêts privées attenantes à la forêt domaniale. Qu'en pensez-vous ? Par ailleurs, j'ai importé quelques cours d'eau issus de data.gouv.fr (agence de l'eau Loire-Bretagne), toujours dans les forêts publiques sarthoises. Leur précision semble relativement bonne (de l'ordre de 10m a priori), après vérification de terrain. Votre avis sur la faisabilité à plus grande échelle ?Bien cordialement,Sylvain H.



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

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

[Philippe Verdy]

Je tombe souvent sur des zones où Osmose annonce (avec raison) une
grande redondance de données parmi celles qui ont été importées.
Notamment car les champs sont en fait mal choisis pour les mettre.

Exemple:

  
  

Ici, le champ "name" ne contient pas le nom de la voie, c'est en fait
une description (un nom de voie pourrait s'y ajouter si la voie
traverse par exemple un village et prend le nom d'une rue).
La partie de cette description "Voie communales n°7" correspond à ce
qui a été mis dans le "ref". Le reste est seulement descriptif.

Je suggère que les imports routiers fassent attention aux données
qu'ils importent, quitte à utiliser un champ "description" pour les
données qui ne sont pas converties correctement, afin de faciliter les
mises à jour manuelles, où à titre documentaire ou de suivi. Par
exemple la plupart des imports ajoutent des tags de suivi, propres à
la source utilisée, notamment des identifiants divers, comme ici la
source de la Communauté de communes de Concarneau - Cornouailles
(), avec des tags dont le nom commence par "4C:". Cela doit
suffire pour assurer une synchronisation ou un suivi de ce qui a été
importé (attention toutefois à utiliser des tags appropriés qui ne
risquent pas de rentrer en conflit avec des tags génériques
documentés: l'utilisation des préfixes est donc fortement recommandé,
surtout si la source est très locale et pas nationale, comme ici une
communauté de communes).

Si on en tient compte, l'exemple ci-dessus (détecté par le
vérificateur Osmose) devrait être après nettoyage:

  
  

Reste à savoir ensuite si on garde ou non les champs "description" qui
restent (à mon avis ils peuvent rester, et seront utiles même pour le
suivi ou lors de l'utilisation d'une carte interactive, surtout ici où
il n'y a pas de nom clair, ou alors parce que ces noms révèlent des
lieux dits proches, qui facilitent aussi la localisation, à condition
d'avoir demandé à afficher les infos détaillées d'une voie)...

De même, des champs fréquents comme:

  
  

sont clairement redondants, car le nom donné n'apporte strictement
rien de plus que la référence. Dans ce cas on supprime directement le
champ "name", et on ne garde que le champ "ref".

Ces nettoyages peuvent se faire directement depuis l'interface en
ligne d'Osmose, avec rawedit et non JOSM, parce que c'est nettement
plus léger et rapide à faire.

Mais pour des zones étendues où il y a une grande répétition de ces
redondances, la fonction de recherche intégrée à JOSM permet de faire
des sélections multiples d'objets sur la valeur d'un champ spécifique,
pour corriger cette valeur dans tous les objets chargés qui utilisent
cette valeur redondante.

A mon avis, il vaudrait mieux faire ces nettoyages dans JOSM avant
l'importation vers la base de données, mais il peut s'agit aussi d'un
oubli. A vous de voir quel éditeur utiliser selon l'étendue des
nettoyages à faire avant vos imports de données. ou après pour
corriger les erreurs introduites après l'importation des données

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Vincent de Chateau-Thierry]

Bonjour,

> De : "Etienne Trimaille" 
> Le 8 février 2012 14:54, Romain MEHUT  a écrit :
> > 2012/2/8 Romain MEHUT :
> >> > J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
> >> > plusieurs morceaux (par les limites de parcelles) qui prennent nettement
> >> > plus de temps à corriger.
> >>

N'empêche que ce temps, aussi long soit il, reste d'un volume ridicule en 
comparaison de 
tracer tout le bâti à la main, comme ça se faisait, sans autre choix, jusqu'à 
juin 2010. 
Ce temps (Denis parlait de transpiration, on parle de la même chose) figure une 
forme de 
valeur ajoutée, qui distingue de l'import brut, associé au recalage ou au tracé 
du
filaire de voies.
Ne pas oublier qu'il n'y a aucune obligation à importer du bâti, tout comme il 
n'y a
aucune obligation de faire du chiffre / du volume d'upload.
De mon côté je garde une logique assez simple : je n'importe que là où je peux 
ajouter
autre chose que ce que donne le cadastre : ne serait-ce qu'un POI, mais ce sera 
forcément
un endroit où j'ai déjà mis les pieds. Oui, ça limite le nombre de patelins, 
mais ça
limite aussi les imports "à l'aveugle". Je pense qu'on met forcément un peu plus
d'énergie à bien faire en s'occupant de coins qu'on connaît et qu'on pratique.

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] Point adresse à Montpellier

[Jean Couteau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 08/02/2012 15:25, jul...@krilin.org a écrit :
> On Wed, 8 Feb 2012 09:34:14 +0100, Romain MEHUT wrote:
>> Bonjour à tous,
>> 
>> Le portail Open Data de Montpellier a mis en ligne les "points 
>> adresse" de toute la ville de Montpellier: 
>> http://opendata.montpelliernumerique.fr/Point-adresse [1]
>> 
>> Est-ce que des contributeurs montpelliérains sont sur le coup
>> pour l'import dans OSM comme à Nantes où c'est en cours?
> 
> si quelqu'un a déjà fait ca, ca m'interesse les données sont aussi
> dispo a Rennes
> 
> je pensait faire un truc en java en utilisant les lib de JOSM pour 
> tester si un point est dans un batiment. - si il est le seul, on
> peut y mettre l'addresse - si il y en a plusieurs, on ne fait rien
> et on laisse l'humain travailler.
> 

A Nantes, l'humain fait presque tout à la main :

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

- -- 
Jean Couteau - Code Lutin
Tel : 02.40.50.29.28
Port : 06.68.07.29.29
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPModhAAoJEFOQdnjKiPj3o+wH/0oZtA8oW4qk4KHMnqM/v2OH
5wCdBuYdLaSqZqn33YR1KCgcfrX7eUPqvj99z64FUHoUNIpRy38THyqjVDaZTnID
eV3E0xPoJThUedmNdAiSoM5y8NYIIKfI1dw4LIRdQh6IxgeBQ8wEp/nww2/1WXOi
gsErickjuQUa+vara/hw/MrY68Kr8avdGdLJCW205XZHEwPDGCEdwv3OMpWZIHVY
gLGXCx14gbFER1sOUYZiXb0CgmDNkRw6pvrhHkxgvKurkeLxZscDU1x73JHRJ6SC
m4L67gElp0gmg3HAjofY1UYrxAj7rmJB4i4pNCKCdCecY3rxFFvgimU3/Xjp+Rw=
=qAz/
-END PGP SIGNATURE-

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

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

[partir-en-vtt]

bonne idée ;-)

--
View this message in context: 
http://gis.19327.n5.nabble.com/Point-adresse-a-Montpellier-tp5465918p5466635.html
Sent from the France mailing list archive at Nabble.com.

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

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

[julien]

On Wed, 8 Feb 2012 09:34:14 +0100, Romain MEHUT wrote:

Bonjour à tous,

Le portail Open Data de Montpellier a mis en ligne les "points
adresse" de toute la ville de Montpellier:
http://opendata.montpelliernumerique.fr/Point-adresse [1]

Est-ce que des contributeurs montpelliérains sont sur le coup pour
l'import dans OSM comme à Nantes où c'est en cours?


si quelqu'un a déjà fait ca, ca m'interesse
les données sont aussi dispo a Rennes

je pensait faire un truc en java en utilisant les lib de JOSM pour 
tester si un point est dans un batiment.

- si il est le seul, on peut y mettre l'addresse
- si il y en a plusieurs, on ne fait rien et on laisse l'humain 
travailler.


--
JB

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[julien]

On Wed, 8 Feb 2012 14:32:25 +0100, sly (sylvain letuffe) wrote:

> Frédéric Rodrigo :
> - Il y a peut être une solution pas trop compliqué à mettre en 
œuvre
> pour corriger les deux cas d'erreur avec postgis 2.0 et la 
fonction

> http://postgis.org/documentation/manual-svn/ST_Snap.html


Je pense que c'est une solution valable pour nettoyer sa propre copie 
de la

base, pas une méthode pour corriger en amont celle de OSM.



Bruno :
Un des 2 scripts précédemment postés fait un "J" JOSM ("Join Node to
Way")sur tous les noeuds, et donc recolle les bâtiments.
Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-)


Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je
suis sûr
que la majorité serait pour un nettoyage automatique, si suffisamment 
bien

fait, de la base OSM (justement pour éviter de se le taper à la main)


C'est peut etre mes expériences désastreuse d’écriture de robot (ou 
plutot leurs executions), mais je me mefie toujours un peut des 
correction automatique.

Il y aura toujours des cas de la vrai vie auquel on n'aura pas pensé

Un exemple tout bete :
les batiments
http://www.openstreetmap.org/browse/way/81188412
et
http://www.openstreetmap.org/browse/way/81188234
sont bien séparés de 20cm, il ne faut pas les recoller.

--
JB



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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Etienne Trimaille]

Le 8 février 2012 14:54, Romain MEHUT  a écrit :

> Le 8 février 2012 14:52, Pieren  a écrit :
>
> 2012/2/8 Romain MEHUT :
>> > J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
>> > plusieurs morceaux (par les limites de parcelles) qui prennent nettement
>> > plus de temps à corriger.
>>
>> Non. Si les polygones sont correctement attachés, la fusion des deux
>> se fait en une touche avec JOSM.
>>
>
> Laquelle?
>


Maj + J ;-)

Faut regarder dans les menus ce que propose JOSM ;-)


>
>
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : [Annonce]Nuit des cartes vivantes le 7 Fevrier a Grenoble

[THEVENON Julien]

Bref compte rendu de la soiree:
10 personnes presentes ! un resultat inespere vu les delais d organisation 
ultra-courts.
Parmi ces 10 personnes 4 habitues du LOG, 5 autres etant des mappeurs OSM 
contactes pour l occasion et un autre 
etant un visiteur venu pour en savoir plus sur le projet

Parmi ces 10 personnes il y avait au moins 4 mappeurs "experimentes" ( dont 
Eric S ) qui ont au final passe pas mal de temps a expliquer le projet, ses 
avantages etc et aider a la prise en main des outils ( JOSM, 
plugin cadastre).
Resultat la soiree n a pas ete forcement tres productive du point de vue 
enrichissement de 
la base OSM mais a permis de beaucoup echanger autour du projet, notamment 
les manieres de mapper et cela a aussi permis de se rencontrer entre 
mappeurs de la region.
La mailing liste ouverte par Guillaume permettra de se coordonner plus 
facilement dans le futur

A noter que d autres contributeurs contactes etaient interessees mais non pas 
pu venir car n ayant pu se liberer pour le creneau d hier soir


Le LOG ayant une session tous les jeudis soir au CCSTI il est toujours possible 
d en profiter pour se rencontrer entre mappeurs locaux


Merci a tous les participants qui ont brave le froid pour venir notamment
Seul regret, la soiree est passee tellement vite qu a priori personne n a pense 
a prendre une photo pour immortaliser ca...


Julien



>
> De : THEVENON Julien 
>À : "talk-fr@openstreetmap.org"  
>Envoyé le : Samedi 4 février 2012 14h04
>Objet : [Annonce]Nuit des cartes vivantes le 7 Fevrier a Grenoble
> 
>
>Bonjour,
>
>
>Le Laboratoire Ouvert Grenoblois ( http://www.logre.org ) participera a NOTLM 
>le 7 Fevrier a partir de 19h en partenariat avec le CCSTI ( 
>http://www.ccsti-grenoble.org/ ) qui nous accueillera dans ses locaux 2 place 
>Saint Laurent ( http://tinyurl.com/4br99rl  )
>Nous essaierons aussi d organiser une presentation/initiation si certains 
>veulent decouvrir le projet
>
>
>
>Pour des raisons d organisation et d assurance les personnes qui souhaitent 
>participer sont priees de se faire connaitre afin d evaluer le nombre de 
>participant.
>
>
>Julien
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Romain MEHUT]

Le 8 février 2012 14:52, Pieren  a écrit :

> 2012/2/8 Romain MEHUT :
> > J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
> > plusieurs morceaux (par les limites de parcelles) qui prennent nettement
> > plus de temps à corriger.
>
> Non. Si les polygones sont correctement attachés, la fusion des deux
> se fait en une touche avec JOSM.
>

Laquelle?


> 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] Import bâti => nettoyage des données cleo carto

[Pieren]

2012/2/8 Romain MEHUT :
> J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
> plusieurs morceaux (par les limites de parcelles) qui prennent nettement
> plus de temps à corriger.

Non. Si les polygones sont correctement attachés, la fusion des deux
se fait en une touche avec JOSM.

Pieren

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Romain MEHUT]

J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
plusieurs morceaux (par les limites de parcelles) qui prennent nettement
plus de temps à corriger.

Romain

Le 8 février 2012 14:18, sly (sylvain letuffe)  a écrit :

> On mardi 7 février 2012, DH wrote:
> > Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit :
> > > Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait
> l'avis
> de
> > > christian.
> >
> > Ni moi le tien. C'est ce qui fait le charme (?) de cette liste.
>
> C'est même un de ces buts ! confronter des idées et des choix pour tenter
> d'obtenir une meilleure cohérance.
>
> A lire les débats, je crois que moi et christian perdons sur un score sans
> appel de 7-2
>
> J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce
> débat
> démocratique.
> C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je
> fasse à
> la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête
> de mettre mes cochonneries dans la base.
>
> > Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur
>
> Je me qualifierais de fourmi raisonnée ou de cigale assumée.
>
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> 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] Import bâti => nettoyage des données cleo carto

[sly (sylvain letuffe)]

> > Frédéric Rodrigo :
> > - Il y a peut être une solution pas trop compliqué à mettre en œuvre
> > pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction
> > http://postgis.org/documentation/manual-svn/ST_Snap.html

Je pense que c'est une solution valable pour nettoyer sa propre copie de la 
base, pas une méthode pour corriger en amont celle de OSM.


> Bruno :
> Un des 2 scripts précédemment postés fait un "J" JOSM ("Join Node to 
> Way")sur tous les noeuds, et donc recolle les bâtiments.
> Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-)

Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je suis sûr 
que la majorité serait pour un nettoyage automatique, si suffisamment bien 
fait, de la base OSM (justement pour éviter de se le taper à la main)

Le problème a mon avis, il est là :
- 10 personnes sur cette liste savent lancer ton programme en python
- 6 ont les compétences de l'analyser le tester et l'améliorer
- et 0.5 ont le temps de le faire !

En clair, tu as accompli une très bonne première étape : fournir un soft pour 
nettoyer.
Frédéric et/ou jocelyn ont fourni l'outil pour repérer les erreurs (osmose)
et Philippe a fourni un export basé sur le soft qadastre de je sais plus qui, 
qui malheureusement ne fourni pas un export cadastre assez "propre" (ce n'est 
pas un reproche)

Maintenant, on passe au "yaka", c'est à dire trouver celui qui va proposer non 
pas une brique, mais un résultat final, qui soit facile (ou plutôt très très 
facile) à contrôler par d'autres. Puis proposer un plan d'action, obtenir 
l'accord d'une majorité d'exprimés, et le faire.

Comme toujours, facile à dire. Donc non, c'est pas qu'on en veut pas, c'est 
qu'on voudrait bien que tu fasses tout ;-)))

Dans la limite de mes compétences+temps, je veux bien filer un coup de main, 
je vais regarder ce qu'il fait ton bidule et voir comment je peux l'utiliser 
et voir comment je pourrais par exemple présenter un échantillon avant/après 
d'un fichier -houses.osm d'une commune.


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[sly (sylvain letuffe)]

On mardi 7 février 2012, DH wrote:
> Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit :
> > Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis 
de
> > christian.
> 
> Ni moi le tien. C'est ce qui fait le charme (?) de cette liste.

C'est même un de ces buts ! confronter des idées et des choix pour tenter 
d'obtenir une meilleure cohérance.

A lire les débats, je crois que moi et christian perdons sur un score sans 
appel de 7-2

J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce débat 
démocratique.
C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je fasse à 
la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête 
de mettre mes cochonneries dans la base.

> Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur

Je me qualifierais de fourmi raisonnée ou de cigale assumée.


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

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

[partir-en-vtt]

dispo en osm sur

http://www.partir-en-vtt.com/stockage/hebergement/montpel.zip 
telechargement 

--
View this message in context: 
http://gis.19327.n5.nabble.com/Point-adresse-a-Montpellier-tp5465918p5466433.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Cadastre-camp ? (was Re: Import bâti => nettoyage des données cleo carto)

[Philippe Pary]

Le 08/02/2012 11:58, jul...@krilin.org a écrit :
> On Wed, 08 Feb 2012 10:16:03 +0100, Philippe Pary wrote:
>> - rédaction de procédures d'imports
> ca existe déjà
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents

C'est une section sur une page technique. Sa rédaction est aride
(non-illustrée, sans mise en page etc.)

Je maintiens l'utilité d'un tel point :-)

Philippe

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

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

[partir-en-vtt]

sympa ces données !

Reste plus qu'à intégrer ;-)

--
View this message in context: 
http://gis.19327.n5.nabble.com/Point-adresse-a-Montpellier-tp5465918p5466259.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Cadastre-camp ? (was Re: Import bâti => nettoyage des données cleo carto)

[julien]

On Wed, 08 Feb 2012 10:16:03 +0100, Philippe Pary wrote:

Salut,

Je lis pas mal de choses dans ces échanges qui me font dire que si on 
se

posait tous autour d'une table et qu'on y bossait, on ferait sauter
beaucoup de soucis :



- rédaction de procédures d'imports

ca existe déjà
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents

--
JB

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[julien]

par contre, j'ai justement corrigé pas mal de truc de ce genre dont
l'auteur etait le pieren_bot... ;)


je tiens a faire ici publiquement mes excuses au bot,
il n'est que le dernier modificateur de bâtiments qui était déjà en 
erreurs.


--
JB


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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Bruno Cortial]

Le 8 février 2012 10:05, Frédéric Rodrigo  a écrit :

> Bonjour,
>
> J'ai deux points que j'aimerais ajouter à ce débat.
> - Il y a deux fois plus d'erreurs que ce que relève osmose. En plus
> des chevauchements il y a les vides incorrects entre les bâtiments.
> - Il y a peut être une solution pas trop compliqué à mettre en œuvre
> pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction
> http://postgis.org/documentation/manual-svn/ST_Snap.html
>
> Frédéric
>
>
Un des 2 scripts précédemment postés fait un "J" JOSM ("Join Node to
Way")sur tous les noeuds, et donc recolle les bâtiments.
Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-)

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

[OSM-talk-fr] Cadastre-camp ? (was Re: Import bâti => nettoyage des données cleo carto)

[Philippe Pary]

Salut,

Je lis pas mal de choses dans ces échanges qui me font dire que si on se
posait tous autour d'une table et qu'on y bossait, on ferait sauter
beaucoup de soucis :

- amélioration des fichiers sur le dépôt
- rédaction de procédures d'imports
- organisation pour « nettoyer » l'existant
…

Que pensez-vous de l'idée d'un « cadastre-camp » qui se grefferait à un
événement quelconque (Solutions Gnu/Linux, RMLL ou autre) ?

Philippe, homme de compromis ;-)

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Frédéric Rodrigo]

Bonjour,

J'ai deux points que j'aimerais ajouter à ce débat.
- Il y a deux fois plus d'erreurs que ce que relève osmose. En plus
des chevauchements il y a les vides incorrects entre les bâtiments.
- Il y a peut être une solution pas trop compliqué à mettre en œuvre
pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction
http://postgis.org/documentation/manual-svn/ST_Snap.html

Frédéric

Le 7 février 2012 21:08, DH  a écrit :
> Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit :
>
>> Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis
>> de
>> christian.
>
>
> Ni moi le tien. C'est ce qui fait le charme (?) de cette liste.
>
>> Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me
>> semble
>> pas "pas tant" que ça.
>
>
> un cadastre importé, c'est un cadastre importé. C'est sûr si c'est un
> patelin de 300 habitants, c'est moins de boulot qu'une banlieue de plusieurs
> milliers d'âmes (genre Kingersheim au hasard).
> L'enjeu et le travail reste le même :
> 1. on laisse faire les outils en attendant qu'ils s'améliorent (sur quels
> critères d'abord ?) et on a ce que l'on mérite
> 2. on connaît les limites de 1, mais le sang de la fourmi ne fait qu'un seul
> tour quand elle découvre que des miettes de qualité peuvent être grapillées
> (la fourmi est écolo dans l'âme). La fourmi est besogneuse, sinon c'est une
> cigale déguisée en fourmi.
>
>>> L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
>>> si en plus, on ne corrige pas les erreurs géométriques, ça va être
>>> encore pire pour notre (déjà mauvaise) réputation.
>>
>> Je suis bien d'accord.
>>
>>> Une critique que
>>> j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres
>>> polygones landuse (sans doute suite à une intervention manuelle, soit
>>> dans l'import, soit dans la création du doublon) et qui perdure dans
>>> la base pendant des années.
>>
>> Je suis aussi d'accord
>
>
> A l'analyse, il semble que les outils (et autre méthodes d'import de masse)
> soient tolérés dans la mesure où la "colonie" ne s'assied pas sur le tas de
> données produit d'un air satisfait : "ça c'est fait", mais prend pelle et
> pioche pour remuer le tout et l'intéger au reste de la base.
>
>>> Certains regrettent d'avantage les imports sans voirie, ou sans
>>> correction sur les voiries qui se croisent alors avec le bâti. Mais
>>> c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
>>> s'en chargeront plus-tard.
>>
>> Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de
>> réparer de manière automatique ce que des humains devraient faire sinon.
>> Dans celui que tu cites, je n'arrive pas à imaginer un processus
>> automatique
>> pour placer des rues entre les bâtiments ou pour savoir où passerait
>> vraiment
>> la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec
>> chevauchement car aucun robot ne pourra le corriger plus tard.
>>
> Repense à HAL9000
>
> Chacun est responsable de ses apports (tiens cela ressemble encore trop à
> imports) à la base. Chaque contributeur est, de fait, responsable du niveau
> de qualité qu'il injecte dans la base. Noboby is perfect (as a ro(b)ot ?),
> mais on moins on aura mis de la transpiration dans cette base ; c'est ce qui
> devrait faire son odeur si particulière, appréciée par certains.
>
> Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur
>
>
> ___
> 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] Import Ballades Vertes du 71 dans le cadre de Night of the live mapping, le 7 Février

[partir-en-vtt]

Alors les chemins ont été intégré ?

--
View this message in context: 
http://gis.19327.n5.nabble.com/ANNONCE-Night-of-the-live-mapping-le-7-Fevrier-a-Paris-et-ailleurs-tp5441144p5465964.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] liste local-grenoble [HS ou presque]

[Eric Sibert]

Si le Nord-Isère en a marre d'être à cheval,
ils pourront toujours créer local-bourgoin,


Nan, local-terres-froides!!!

Eric


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

Re: [OSM-talk-fr] liste local-grenoble [HS ou presque]

[Guillaume Allegre]

Le mar. 07 f�vr. 2012 à 16:26 +0100, sly (sylvain letuffe) a ecrit :

> > Modestes suggestions : 
> > 1 rebaptiser la ML Dauphiné-Savoie, c'est moins grand que la Bretagne et
> > donc plus efficace  
> > que Rhône-Alpes qui est un monstre disparate (plus grande région de France).
> > Une ML Lyon-St-Etienne peut avoir du sens, mais je suis mauvais juge.
> 
> Je valide l'idée, et même quelque chose du style : Dauphiné-SavoieS ou 
> alpes-nord

bof-bof
A mon avis "local-grenoble" est plus pérenne / "scalable" ; on ne sait pas à 
l'avance
en combien de parts la zone sera découpée à terme, en fonction de l'affluence 
ou pas,
mais ce dont on peut être sûr c'est que les villes-centres seront stables.
On a local-lyon et local-grenoble. Si le Nord-Isère en a marre d'être à cheval, 
ils pourront toujours créer local-bourgoin, on n'aura pas à renommer les listes.


> Ce qui me semble unir potentiellement ces contributeurs/utilisateurs (mais 
> vise-t-on bien des contributeurs/utilisateurs ?) c'est surtout la montagne 

Bah c'est un thème d'intérêt bien sûr, mais c'est pas le seul.
On peut très bien dire que local-grenoble s'étend jusqu'à la frontière 
tant que personne ne demande une autre liste.
A mon avis, fixer les limites a priori est une mauvaise idée.



-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.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

[Emmanuel Dewaele]

Bonjour,

C'est super, merci pour ce compte-rendu. Au moins, la MJC est 
correctement marquée, à ne pas confondre avec un centre Léo Lagrange.


Concernant des améliorations à appliquer sur OpenStreetBugs, j'avoue je 
n'ai pas vraiment le temps en ce moment, mais des choses sont prévues.


Le 07/02/2012 22:26, simon a écrit :

Bonjour

Je viens de faire un atelier OpenStreetMap dans le cadre d'une activité de
soutien scolaire pour des classes de cm1 et cm2.
Le but étais de faire une sensibilisation au carte et de leurs faire découvrir
le quartier.

Pour le matériel je disposait d'un vidéo projecteur sur un tableau blanc pour
pouvoir annoter la carte.

Après avoir fait une très courte et simplifié présentation d'OSM, je leur est
fait recherché ou on se situais sur la carte. Tous le monde n'étant pas
d'accord sur les niveau de zoom élevés nous avons tenté de les faire travaillé
de façon communautaire en les faisant venir placé une croix sur l'endroit
supposé avec leur commentaire. au fur et a mesure des participation et de la
découverte de nouveau point de repère le travail de groupe nous fi zoomer sur
notre quartier.

Ensuite vain l'étape de la complétion de la carte par groupe de deux avec
chaqu'un une carte du quartier au format papier il ont repéré tous ce qu'ils
connaissaient et qui n'étais pas sur la carte.

Ces données ont été ensuite reportées par moi même dans OSM sous le changeset
http://www.openstreetmap.org/browse/changeset/10616362

Une deuxième session avec se groupe est prévu pour leur montrer Openstreetbug,
entre temps il devraient faire un peut de terrain avec leur formateur.

Ces nouveaux contributeurs ce sont révélés fort intéressé et au dire de leur
formateur "très calme par rapport à l'habitude"

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.

Librement

Simon


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



--

Emmanuel Dewaele,
Ingénieur études et recherche
La Compagnie des mobilités

64, avenue Portalis
bureau 202
37200 TOURS

☏ 06 26 94 94 71


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

[OSM-talk-fr] Point adresse à Montpellier

[Romain MEHUT]

Bonjour à tous,

Le portail Open Data de Montpellier a mis en ligne les "points adresse" de
toute la ville de Montpellier:
http://opendata.montpelliernumerique.fr/Point-adresse

Est-ce que des contributeurs montpelliérains sont sur le coup pour l'import
dans OSM comme à Nantes où c'est en cours?

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