from:"Benoît ROUSSEAU"

Jean-Francois Nifenecker a écrit :
> Guillaume Allegre a écrit :
>   
>> Perso je reste opposé à l'intégration dans la BD OSM d'itinéraires non 
>> pérennes, 
>> qui ne correspondront plus à rien dans un an.
>> Et il me semble qu'on était majoritaires sur cette position dans les avis 
>> émis
>> sur cette liste.
>>
>> Pour moi, c'est typiquement le champ d'application d'une BD tierce, qui 
>> pourrait
>> piocher les coordonnées des traces dans OSM, si la licence est compatible.
>>
>> 
>
> +1000
>
>   
Je le redis encore pour appuyer que ce type d'intégration dans la base 
me semble inopportun alors que les calques "openLayers, ..." ont 
vocation à cela.
Mais je ne suis pas opposé au projet en lui même, bien au contraire ce 
serait effectivement une occasion d'ajouter des éléments dans OSM et 
d'avoir un fond OSM visible (communication).

Benoît R.

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

Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010

Emilie Laffray a écrit :
>
>
> 2010/4/21 THEVENON Julien  >
>
> *De :* Emilie Laffray  >
> **
> 2010/4/21 THEVENON Julien  >
>
> Tout pareil
>
> Un calque open layer tour de france par dessus le fond
> OSM :-)
>
>
>
> Calque ou pas, ça ne change pas le problème de base qu'il faut
> l'accord de Amaury, et qu'il faut mapper ce qui doit être mappe
> pour les villes qui vont être traversées :)
>
> Oui bien sur pour l accord, je parlais seulement de stocker le
> parcours a l extérieur la base
>
>
> A l'intérieur ou a l'extérieur de la base, au final, ça ne change pas 
> grand chose puisqu'il faudra toujours créer un système qui associe les 
> id des routes que tour de France va utiliser.
A l'intérieur ou a l'extérieur de la base, au final, ça change beaucoup 
de choses !
A ce moment là on y colle les tours cyclistes locaux, les marathon, les 
prix des stations services, les températures moyenne, les trajets boulot 
maison, le trajet pour aller au mariage de Geneviève et Michel, la 
sortie du dimanche en quad, ...
Il y a déjà pas mal de boulot pour intégrer les tags existants et 
réfléchir à de nouveaux tags utiles (particularité françaises, ...) puis 
faire du lobying pour les faire accepter.


Benoît R.

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

Re: [OSM-talk-fr] Re : rendu cyclable : choix d'un nom

Je crois que Julien m'avait parlé de "Cloud" de calcul de tuiles avec 
des serveurs répartis chez les utilisateurs. Cela permettrai de délester 
le serveur Kimsufi de pas mal de calculs de tuiles si nous sommes 
plusieurs à fournir des machines connectées.

Pierre Mauduit a écrit :
> Salut,
>
>   
>> Okay. Un "kimsufi" sera certainement un "kinsufipa" comme serveur de tuile, 
>> ou
>> alors sur une zone et mises à jour très limitées.
>> 
>
> A titre de comparaison / Pour information, MapOSMatic tourne sur un kimsufi,
> certes le deuxième d'entrée de gamme, et l'application n'est pas destinée à
> générer des tuiles à la demande (si ce n'est dans le cadre de la file 
> d'attente
> prévue lors de la demande de rendu des plans de ville), mais la bestiole 
> semble
> être en mesure de manger quotidiennement les modifications à l'échelle 
> mondiale.
>
>
>   
>> Ca fait longtemps que je milite pour la mise en place d'un vrai serveur de
>> tuiles localisé comme l'ont fait les allemands mais c'est exigeant niveau
>> matériel, les serveurs free sont trop limités par exemple.
>> 
>
> +1 ;
>
> a+,
>
>   
> 
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.814 / Base de données virale: 271.1.1/2826 - Date: 04/21/10 
> 13:09:00
>
>   


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

Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010

Emilie Laffray a écrit :
> On 21/04/2010 17:06, Benoît ROUSSEAU wrote:
>   
>> A l'intérieur ou a l'extérieur de la base, au final, ça change beaucoup 
>> de choses !
>> A ce moment là on y colle les tours cyclistes locaux, les marathon, les 
>> prix des stations services, les températures moyenne, les trajets boulot 
>> maison, le trajet pour aller au mariage de Geneviève et Michel, la 
>> sortie du dimanche en quad, ...
>> Il y a déjà pas mal de boulot pour intégrer les tags existants et 
>> réfléchir à de nouveaux tags utiles (particularité françaises, ...) puis 
>> faire du lobying pour les faire accepter.
>>   
>> 
>
> Dans le cas présent, je réitère mon propos. A l'intérieur ou a
> l'extérieur, la problématique reste exactement la même. Ce dont tu
> parles n'a rien a voir avec le point que j'essayais de faire passer, qui
> est notamment que techniquement parlant, a l'intérieur ou a l'extérieur,
> la gestion de la route est la même i.e. on va devoir créer une relation
> de bouts de OSM que ça soit dans OSM ou pas. J'ai exprimé initialement
> il y a quelques jours une préférence pour une relation par étape,
> clairement, ce n'est pas ce que les gens veulent donc je vais avec la
> majorité, mais ca ne change aucunement le problème de comment tu stockes
> le tracé dans une base de donnée externe.
> De plus, a partir du moment que tu vas utiliser un extrait de la base de
> donnée OSM, tu devras mettre a disposition les données sous un format
> OSM dues a la viralité de la licence. Donc, je réitère mon propos, a
> l'intérieur ou a l'extérieur, la problématique reste la même.
> Dans le cas présent, la logique n'est pas de stocker tout et n'importe
> quoi clairement. Quoique la sortie de dimanche en quad, ca doit faire
> une bonne source de fichier gpx a uploader dans OSM et ca doit donc être
> assez utile.
>   
Comme tu veux. Je maintient aussi. Sur le "techniquement parlant ça ne 
change rien" je suis d'accord avec toi. Sur le intérieur/extérieur 
absolument pas. Mais on n'a pas besoin d'être d'accord.
> Particularités françaises, bah oui mais non, je ne vois pas grand chose
> qui soit particulierement français en soi et qui soit suffisemment
> unique au final. De plus, tu parles de lobbying pour les faire accepter,
> j'avoue que l'idée est interessante, mais les faire accepter où? A la
> base, le wiki est quelque chose d'assez optionnel puisque n'importe qui
> peut creer son propre tag et que ce qui fait qu'un tag soit repris en
> masse ou pas, c'est le fait qu'il soit utilisé. Maintenant si tu veux
> que le tag soit mis dans le rendu officiel Mapnik, ca sera plus dur, et
> je ne suis pas sure que l'on veuille surcharger la carte de base du site
> de OSM.
>   
En ce qui concerne "les faire accepter lors des votes", je me suis 
inscrit à des listes internationales où il ne se passe rien (j'en ai 
même oublié les noms) ; si tu as des adresses je suis preneur. Il me 
semblait avoir comprit que les tags était soumis au vote... où, je 
pensais sur les maillings lists auxquelles je me suis inscrit. Une autre 
solution que le lobbying c'est de les rendre standards en les utilisant 
à défaut de norme acceptée. Quant aux particularité françaises c'était 
"un global" mais par exemple il n'y a pas le tag pour les ways qui 
débouchent sur berge avec possibilité de mettre un bateau à l'eau (La 
route s'enfonce dans l'eau) ce qui est pourtant lié à un panneau 
(voiture qui tombe à l'eau) et parfois pratique pour mettre une 
embarcation à l'eau. Y a pas mort d'homme si ça n'existe pas...
> Clairement, si tu veux un site avec un rendu avec toutes les
> "particularités françaises", il va falloir faire comme les allemands et
> avoir notre propre site de rendu. C'est d'ailleurs que quelque chose qui
> tient a cœur a certains d'entre nous, notamment Pieren qui en parle
> depuis très longtemps et qui a fait déjà un bon boulot pour créer des
> dumps avec des polygones français. C'est d'ailleurs aussi la démarche
> qui est en train d'être faite avec toutes les discussions sur le site de
> vélo avec un rendu qui correspond plus aux attentes du public "français"
> dans un premier temps. Il est d'ailleurs clair qu'en lisant le thread,
> il y a deux besoins très différents en terme de route cyclable, entre
> l'urbain et le rural par exemple.
>   
Si certains veulent le faire sur un serveur indépendant où est le pb ! 
Personne ne te demande de suivre et personne ne pollue OSM.
> Maintenant, pour faire du lobbying peut être faudrait il participer un

Re: [OSM-talk-fr] Re : rendu cyclable : choix d'un nom

Damien Hardy a écrit :
> Bonsoir,
>
> Je pense qu'il a du faire référence à :
> http://wiki.openstreetmap.org/wiki/FR:ti...@home
>
> Cdt,
>
>   
Ah oui ! Si ce n'est pas ça, cela y ressemble !


Benoît R.

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

Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010

Ah bah Troll dur c'est clair :p.
Je ne savais pas pour le circuit cycliste... Si ça existe et que c'est 
finalisé avant juillet (pour pas qui des morceaux perdus partout), alors 
ch'ui pour en interne. Ca me fait plaisir pour Émilie.

Benoît R.

Marc SIBERT a écrit :
>
> A l'intérieur ou a l'extérieur de la base, au final, ça change
> beaucoup
>
> de choses !
> A ce moment là on y colle les tours cyclistes locaux, les
> marathon, les
> prix des stations services, les températures moyenne, les trajets
> boulot
> maison, le trajet pour aller au mariage de Geneviève et Michel, la
> sortie du dimanche en quad, ...
> Il y a déjà pas mal de boulot pour intégrer les tags existants et
> réfléchir à de nouveaux tags utiles (particularité françaises,
> ...) puis
> faire du lobying pour les faire accepter.
>
>
> Benoît R.
>
>
> Pour troller un peu...
>
> Les tags existent déjà pour un circuit cycliste... pas pour localiser 
> le lieu d'un mariage, mais bien pour localiser la salle des fêtes.
>
> C'est quand Geneviève et Michel ?
>
> -- 
> Marc Sibert
> m...@sibert.fr 
> 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>   
> 
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.814 / Base de données virale: 271.1.1/2826 - Date: 04/21/10 
> 13:09:00
>
>   


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

Re: [OSM-talk-fr] Re : rendu cyclable : choix d'un nom

Emilie Laffray a écrit :
> On 21/04/2010 17:12, Benoît ROUSSEAU wrote:
>   
>> Je crois que Julien m'avait parlé de "Cloud" de calcul de tuiles avec 
>> des serveurs répartis chez les utilisateurs. Cela permettrai de délester 
>> le serveur Kimsufi de pas mal de calculs de tuiles si nous sommes 
>> plusieurs à fournir des machines connectées.
>>   
>> 
>
> Le cloud c'est tres pratique pour stocker des tuiles rapidement sur le
> net et les servir. Si tu veux toutefois les generer a volee a partir de
> la base de donnée, je ne suis pas sure que ca soit intéressant. Beaucoup
> de gens ont abandonné leurs projets de cloud car c'est bien trop. L'IO
> flanche très rapidement. La seule solution c'est un bon gros serveur.
> Pour servir les tuiles, oui le cloud c'est parfait mais c'est tout.
>
> Emilie Laffray
>
>   
D'après les dires de Julien, l'objet du "Cloud" est de générer les 
tuiles en asynchrone. Le serveur qui les sert les distribues seul mais 
répartie la charge de rendu sur des postes distants. Donc ce n'est pas à 
la volée et un seul serveur sert les tuiles.

Benoît R.

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

Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010


> Pour le 1., Marc a fait ce qu'il fallait. On peut l'en remercier.
De toutes manières, personne ne m'a semblé contre cette initiative.
> Pour le 2., il y a une majorité d'opinions rejetant l'idée de mettre 
> tous les itinéraires mais personne ne râle sur les itinéraires de bus 
> par exemple. Moi je râle sur les itinéraires de bus qui coupent ma rue 
> en quatre morceaux. Finalement, pour moi, c'est la représentation des 
> itinéraires en général qui pose problème. Si ceux-ci étaient moins 
> invasifs, il y aurait moins de rejet.
C'est pas faux.
> Pour le 3., je comprends le point de vue d'Emilie. Que ce soit à 
> l'intérieur de la base ou à l'extérieur (si on utilise les osm-id), 
> rien ne garantie la pérennité des données OSM.
J'ai dû lire trop vite, je n'ai pas lu ça. Mais la remarque est tout à 
fait pertinente.
> Si les étapes du tour sont dans OSM et qu'il y a une grosse pub 
> autour, il y aura certainement du vandalisme tôt ou tard. Ou le simple 
> cycle de vie des éléments OSM fera que les itinéraires perdront leur 
> intégrité à moyen terme. Mais c'est là encore un problème général. Et 
> il y a plein d'autres moyens de tracer un itinéraire sans OSM (suite 
> de points lat/lon par exemple).
Oui. Sur un calque par exemple.
> Pour le 4., demandez à Benoît.
Vous regarderez sur OSM... :p
>
> Pieren
Benoît R.

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

Re: [OSM-talk-fr] Re : rendu cyclable

Cool :p dis moi merci :p
Comment pourrait on t'aider ?

julien balas a écrit :
> Benoît ROUSSEAU wrote:
>   
>>> D'ailleurs, au sujet du rendu de la carte, je pense que ça peut être 
>>> intéressant de prendre contact avec des associations cyclistes afin d'avoir 
>>> un 
>>> regard extérieur à openstreetmap.
>>>   
>>>   
>> Julien Balas pourrait faire l'affaire :p.
>> 
>
> C'est pas beau de dénoncer ;)
> En plus je peut pas avoir un regard extérieur, na!
>
> Pour un besoin précis (recenser les sens interdit en zone 30 dans 
> lesquels les municipalités n'ont pas encore mis de double sens 
> cyclables) j'ai fait une petite feuille de style osmarender.
> http://img32.imageshack.us/img32/7594/mapz30.png
>
> Dans le but d'offrir cette fonctionnalité sur toute la france je suis en 
> train d'installer mapnik sur un serveur.
> Mais j'imagine qu'un kimsufi ne suffira pas pour un vrai rendu opencycle 
> réellement utilisable.
>
>   
> 
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.801 / Base de données virale: 271.1.1/2820 - Date: 04/19/10 
> 08:31:00
>
>   


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

Re: [OSM-talk-fr] Re : rendu cyclable : choix d'un nom

Emilie Laffray a écrit :
> On 21/04/2010 18:26, Benoît ROUSSEAU wrote:
>   
>> D'après les dires de Julien, l'objet du "Cloud" est de générer les 
>> tuiles en asynchrone. Le serveur qui les sert les distribues seul mais 
>> répartie la charge de rendu sur des postes distants. Donc ce n'est pas à 
>> la volée et un seul serveur sert les tuiles.
>>   
>> 
>
> Initialement ti...@home était plus rapide que Mapnik mais maintenant
> c'est clairement l'inverse. Je ne suis pas convaincue par une
> architecture distribuée au final. Dans le même, il y a encore le projet
> turtle Eggs qui utilise une approche distribuée avec un système
> mélangeant Tiles @ home et Bit torrent.
> Le problème après, c'est de savoir quel temps de latence est acceptable
> au final pour le rendu de la carte et aussi la qualité du rendu car
> Tiles @ home a un rendu que je trouve assez moche au final.
>
> Émilie Laffray
>
>   
Ok. Je vais regarder plus en détail ces deux projets que je ne connais 
pas. Tu as eu l'occasion de les tester ?

Benoît R.

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

Re: [OSM-talk-fr] Bâtiments en 3D dans GMap

2010-04-22 Par sujet Benoît ROUSSEAU

f.rodr...@free.fr a écrit :

Selon Benoît ROUSSEAU :

Peut être pour bientôt, j'y travaille :

En arrivant sur la liste je vous disais bosser sur un bidule lié à OSM
sans  osé imaginé que j'avancerai... et bien j'avance... L'idée est de
mapper des points en correspondance  3D cadastre et  photos.  L'image
audessus ne le démontre pas mais ça fonctionne pas mal d'ors et déjà. Là
je ne vous montre que l'aspect vu de haut en réponse au fil mais  on
peut en déplaçant la caméra faire corespondre photos et bati 3D à peu
près correctement. Je pense suffisamment correctment pour placer un
passage piéton ou une boite à lettre. Les données sont directement
issues de la base OSM et habiller les façades avec des photos de
celles-ci n'est pas sorcier, mais juste long.

Tu peux explicité ce que tu mets derrière 3D cadastre ?
Les bâtiments que tu extrudes sont des données OMS ou des données du cadastre ?
Le but est d'utiliser des photos pour, d'une part obtenir hauteur des bâtiments
et placer différents PIO (passages piétons...), et d'autre part pouvoir plaquer
des textures sur les bâtiment extrudées ?

***
Ce sont les données étiquetées "building=yes" dans OSM que j'extraie.
Les photos ne sont présentées que pour placer les PIO, mais régler la 
hauteur des bâtiments est une fichtre bonne idée. Pour le texturage des 
façades, je l'ai en tête, bien évidement :p, mais ce sera pour plus tard.

***

Conclusion ajouter un rendu 3D des "building=yes" dans OSM est à la
portée de n'importe quel programmeur. Pour ma part je dois convertir les
coordonnées dans celles du cadastre afin que les bâtiments "orthogonaux"
soient rendu correctement pour calage avec les images. Mais dans le cas
de google même pas la peine. On peut rêver à avec tags
"UrlImgFacadeN1=htttp...", "UrlImgFacadeTop=htttp...", ... ça ne suffit
pas mais cela serait déjà un début.

On en revient toujours à la même discution, mais pour moi ça n'a pas ça place
dans OSM.

***
Je suis moi même plus pour du complémentaire comme cela à pu se 
comprendre dans un autre fil de discussion :p.

***

Benoît R.

eMerzh a écrit :

La vrai question est à,quand une gestion plus fine de la 3D dans OSM?
(pas juste un height :p)

2010/4/19 Gilles Bassière mailto:gbassi...@gmail.com>>

jul...@krilin.org <mailto:jul...@krilin.org> wrote:
>> Je viens de découvrir que les bâtiments sont représentés dans
GoogleMap.
>> Et en 3D en plus. (j'espère que ça n'as pas déjà été posté :))
>>
>>

http://maps.google.fr/maps?f=q&source=s_q&hl=fr&geocode=&q=montb%C3%A9liard&sll=46.75984,1.738281&sspn=7.210429,13.820801&ie=UTF8&hq=&hnear=Montb%C3%A9liard,+Doubs,+Franche-Comt%C3%A9&ll=47.511061,6.804271&spn=0.000868,0.002709&z=19

<http://maps.google.fr/maps?f=q&source=s_q&hl=fr&geocode=&q=montb%C3%A9liard&sll=46.75984,1.738281&sspn=7.210429,13.820801&ie=UTF8&hq=&hnear=Montb%C3%A9liard,+Doubs,+Franche-Comt%C3%A9&ll=47.511061,6.804271&spn=0.000868,0.002709&z=19>

>
> c'est peut-être les premiers résultats de sketchup
> "dessine ta maison et met la sur google earth".
> Si un montbél^w habitant de Montbéliard s'est un peut pris au
jeux, il a
> peut etre fait toute la ville.
> On connais bien des gens qui décalquent le cadastre :)
>
> ps : ou alors kkun a fait un plugin cadastre-fr pour sketchup.

http://google-latlong.blogspot.com/2009/10/introducing-google-building-maker.html

A la fin de la vidéo: "It's fun, easy and all you need is to be
online"
! Merci Google de nous fournir autant de joyeuses distractions :p Ils
prennent vraiment les gens pour des imbéciles...

Du point de vue strictement technique, je dois quand même reconnaître
que l'interface utilisateur a l'air pratique. Ils s'abstiennent quand
même de montrer comment ils gèrent les formes moins régulières (je
pense
aux flêches d'une église, aux toits non-plats, etc).

--
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/

___
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

Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr
Version: 9.0.801 / Base

Re: [OSM-talk-fr] [dev] OsmWatch : outil pour voir les modifications/ajouts/suprression d'un ensemble d'objets

2010-04-22 Par sujet Benoît ROUSSEAU

kimaidou a écrit :
> Bonjour,
>
> Je suis en train de développer un petit outil en python qui permette 
> sans installation complexe de faire du suivi rapide de l'évolution des 
> objets dans la bdd OSM sur une ou plusieurs zones. Je l'ai appelé 
> "OsmWatch"
>
> Pour l'instant, c'est encore un embryon, mais les fonctionnalités 
> basiques sont à peu près en place, et donc j'en parle ici pour qu'on 
> ne soit pas plusieurs à faire un outil équivalent dans notre coin, 
> mais pour rassembler les bonnes volontés. Je souhaitais attendre un 
> peu, mais Germaine de Marseille a accéléré les choses...
>
> Objectif:
> *
> Cet outil va permettre de suivre l'évolution d'objets OSM via le :
>
> * Choix d'une ou plusieurs zones (bbox)
> La taille de chaque bbox doit rester pas trop grande (limites de l'api 
> et de la xapi, cf description technique + loin)
>
> * Choix du suivi des objets. L'outil doit permettre de suivre des 
> groupes d'objets caractérisés par :
> - une liste d'osm_id fixe
> - une valeur pour un tag, par exemple toutes les boulangeries shop=bakery.
> - un utilisateur : soit tous les objets dernièrement édité par 
> l'utilisateur X, soit (plus lourd) tous les objets qui ont une fois 
> été édités par X
>
> On peut avoir plusieurs listes, donc suivre par exemple tous les 
> objets "boulangerie" et tous les supermarchés, tous les objets édités 
> par Bob et par Germaine sur la ou les zones.
>
> Fonctionnement
> ***
> L'objet de cet outil n'est pas de stocker tout l'historique de chaque 
> objet à chaque passage, ni de proposer des outils statistiques de 
> folie, ni d'éditeur carto, etc.
> J'ai décidé plutôt de faire un outil simple, qui fonctionne par passe.
> Lorsqu'on le lance,
> * il va chercher via l'api et la xapi les objets par rapports aux 
> critères rentrés (utilisateur, tags, etc.)
> * il compare cette liste d'objet à celle obtenue lors de la dernière passe
> * Il fait un rapport html avec les différences : objets modifiés, 
> supprimés, ajoutés depuis la dernière fois.
> * il écrase les données stockées par les nouvelles (qui seront 
> comparées lors de la prochaine passe).
>
> Technologie
> **
> Pour l'instant, ce n'est qu'un petit et moche fichier python, qu'il 
> faudra que j'organise mieux.
> Il est basé sur la pythonOsmApi ( 
> http://wiki.openstreetmap.org/wiki/PythonOsmApi , merci à l'auteur !) 
> , mais utilise aussi la XAPI pour ses capacités de recherche avancée.
> Les données de chaque passe sont enregistrées dans une base sqlite, 
> pour que l'outil soit portable.
> Je cherche ici à faire un outil léger et portable, qu'on puisse lancer 
> d'une simple clé USB.
> Pour l'instant, l'outil fait juste un "rapport" au format HTML avec 
> des codes couleurs pour dire "supprimé", "modifié", ajouté et avec des 
> liens vers la dscription de l'objet dans OSM.
> Pour l'instant, l'outil suit seulement les nodes, mais bien sûr je 
> vais étendre à tous les objets (je teste d'abord)
>
> Idées d'utilisation
> *
> * Je suis une commune, j'ai "donné" 550 poins de bancs publics à OSM, 
> je veux pouvoir les suivre, mais aussi voir si d'autres sont ajoutés 
> par des utilisateurs
> * Je veux voir les modifications faites sur les objets que j'ai édités 
> précédemment
> * Je savoir quand quelqu'un ajoute des écoles dans ma zone
> * etc.
>
> Je ne cherche pas ici à faire un outil qui permette d'éditer 
> directement la bdd OSM (par exemple : "Tiens, Germaine a supprimé mon 
> arrêt de bus, hop, je clique et il est recréé !" ). Je préfère que la 
> personne soit prévenue, et ensuite qu'elle utilise les outils d'OSM 
> manuellement.
>
>
> Idées futures
> *
> * lancé l'outil périodiquement sur un serveur
> * faire une interface graphique
> * envoyer un email
> etc.
>
> Voilà pour la description générale.
>
> Les étapes :
> * j'améliore un peu le code, je le nettoie et l'organise
> * je crréé un projet OpenSource sur une forge quelconque
> * tout le monde peut l'améliorer, le faire avancer, etc.
>
> Kimaidou
>
Je bosse entre autre sur des fonctionnalités similaires avec pour 
objectif final une bibliothèque d'accès C# aux api OSM qui . L'idée pour 
moi est avant tout de suivre les coins que je cartographie et de 
visualiser graphiquement les zones éditées depuis mes derniers ajouts.
Je suis prêt à mutualiser idées, extraits de sources (sont caca pour 
l'instant), speudo code, algorithmes, ...

Benoît R.

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

Re: [OSM-talk-fr] [dev] OsmWatch : outil pour voir les modifications/ajouts/suprression d'un ensemble d'objets

2010-04-23 Par sujet Benoît ROUSSEAU

Emilie Laffray a écrit :
>
>
> 2010/4/22 Benoît ROUSSEAU  <mailto:adressepossi...@free.fr>>
>
> Je bosse entre autre sur des fonctionnalités similaires avec pour
> objectif final une bibliothèque d'accès C# aux api OSM qui .
> L'idée pour
> moi est avant tout de suivre les coins que je cartographie et de
> visualiser graphiquement les zones éditées depuis mes derniers ajouts.
> Je suis prêt à mutualiser idées, extraits de sources (sont caca pour
> l'instant), speudo code, algorithmes, ...
>
>
>
> Amusant. J'ai bientôt fini la première version d'une librairie qui 
> parle avec l'API OSM en C#. Il me reste quelques jours de hacking 
> dessus pour la première version pour obtenir l'équivalent de osmpy. La 
> librairie s'appelle osmsharp, et gère les éléments suivants 
> actuellement en attendant d'atteindre la parité avec osmpy:
> - Manipulation changeset
> - Obtention, création, mise a jour et effacement de nodes, ways, et 
> Relations
> - Historique nodes, ways, relations
> - Capabilities
>
> Reste a coder pour la version actuelle
>
> - NodeWays, NodeRelations, et NodesGet
> - WayRelations, WayFull, WaysGet
> - RelationRelations, RelationFullRecur, RelationFull, RelationsGet
> - Changeset automatique, ChangesetUpload, changesetDownload, changesetsGet
> - Map
>
> Cela devrait ne plus prendre trop de temps pour finir puisque tous les 
> parseurs et convertisseurs sont écrits. Je pense la finir avant de 
> venir en France lors de SIG Les Lettres.
>
>
> La prochaine version du code 0.2 supportera les fonctionnalités suivantes:
> - Revert
> - Gestion des erreurs complètes
> - Full Mono Support
> - Interface completement oriente objet a la place de l'approche 
> existante dans osmpy (actuellement il faut creer un objet osmapi, et 
> ensuite faire osmapi.NodeCreate pour creer un node, la prochaine 
> version fera node.Get() etc...)
> - Support XAPI (voire écriture d'un composant LINQ, si je n'ai 
> vraiment rien a faire).
> - Support Nominatim
>
> La librairie sera mise a disposition en format LGPL.
>
> Emilie Laffray
> 

Excellent ! D'autant plus aprsè nos prises de positions... :p

Bon, t'es super plus avancée que moi. Je continue en // tant que t'as 
pas une release pour me familiariser avec les différents éléments. 
Ensuite je pense te rejoindre si un cadre de dev est défini. Tient 
moi/nous au courant et quand tu lâcheras une version de code je verrai 
comment participer si tu veux bien.


Benoît R.

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

Re: [OSM-talk-fr] [dev] OsmWatch : outil pour voir les modifications/ajouts/suprression d'un ensemble d'objets

2010-04-24 Par sujet Benoît ROUSSEAU


Emilie Laffray a écrit :

On 23/04/2010 22:16, Benoît ROUSSEAU wrote:
  

Excellent ! D'autant plus aprsè nos prises de positions... :p
Bon, t'es super plus avancée que moi. Je continue en // tant que t'as 
pas une release pour me familiariser avec les différents éléments. 
Ensuite je pense te rejoindre si un cadre de dev est défini. Tient 
moi/nous au courant et quand tu lâcheras une version de code je verrai 
comment participer si tu veux bien.


  



Bah heureusement que tout le monde n'est pas d'accord au final, sinon ca
serait monotone, et on n'avancerait pas. Et puis si ne pas être d'accord
implique la guerre, il y aurait longtemps que Pieren et Sylvain ne se
parlerait plus ;)
  

Oui. No problemo.

Je pense que je créerai a terme une page sur le wiki concernant la
librairie.
  

Ok, t'auras mon aide.
Moi je pensais à une page de "bienvenue" sur la liste. Avec les trolls à 
aborder avec précaution, les liens vers pages de synthèses de 
discussions, éventuellement les "profils OSM" de ceux qui acceptent, ... 
Quand on débarque on ne connait ni le profil ni les trolls, ... et les 
informations éparses ne permettent pas rapidement d'intégrer la liste 
sans balancer des troll avec l'historique, aborder certains sujets en 
connaisse de de causes, utiliser les votes doodle, Où sont localisez les 
participant de la liste pour se voir (avec le respect de la vie privée, 
pour ceux qui le souhaitent, ...), la liste des projets français,  ... 
Je vous ferai une proposition, brouillon dans un premier temps, qui 
pourrait être envoyée en lien aux nouveaux venus. Ca pourrait amener à 
une intégration "sociale" plus rapide dans la liste.


ÇA EXISTE PEUT-ÊTRE DÉJÀ TOUT OU PARTIELLEMENT. SI OUI, FAITES LE MOI 
SAVOIR.

D'ailleurs concernant cette librairie, je tiens a remercier Étienne pour
avoir créer la version Python qui donne une bonne idée de certaines
choses de base :)

Emilie Laffray

  

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

Re: [OSM-talk-fr] Analyseur de mega relation

Etienne Chové a écrit :
> Coucou,
>
> Voila un analyseur :
>   - compatible relation récursive
>   - rapide (3 secondes pour la France)
>   - très moche, même très très moche
>   - mis à jour avec les minute-replicate
>   - analyse que l'ouverture des relation pour le moment
>   - en version beta, car il bouffe 60Go de disque, et je sais
> pas si un jour j'en aurai pas besoin
>   - très léger en ressources (il faut 1h15 pour analyser toutes les
> relations administratives du monde... vous voyez où je veux en
> venir ?!?)
>   - l'import du planet prend 12 heures
>   - mange 4 minute diff par seconde
>   - n'utilise pas de bdd (enfin si : un format maison pour plus de perf)
>
> Voila un exemple : http://osm3.crans.org/osmbin/analyse-relation?11980
>
>   
Bravo pour ce travail.

Benoît ROUSSEAU.

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

Re: [OSM-talk-fr] Carte des rond-points qui n'en sont pas

>
> - Mail Original -
> De: "Thomas Walraet" 
> À: talk-fr@openstreetmap.org
> Envoyé: Mardi 18 Mai 2010 18h19:43 GMT +01:00 Amsterdam / Berlin / Berne / 
> Rome / Stockholm / Vienne
> Objet: Re: [OSM-talk-fr] Carte des rond-points qui n'en sont pas
>   
> [...]
>
> L'idée de pouvoir surveiller une zone est sympa, mais ça serait vraiment 
> génial si une solution de surveillance prenait en compte les différents 
> outils de validation plutôt que chacun fasse sa sauce dans son coin.
>   
C'est amusant on discutais de tout ça par ailleurs avec Julien B. :p.

Je proposerai bien quelque chose mais n'ayant pas encore attaqué le 
sujet (ça ne devrait pas tarder), j'attends d'estimer le pour et le 
contre avant de rentrer dans la bataille.

Que chacun fasse dans son coin peut paraître être du temps perdu, mais 
pas tout à fait. Nous ne sommes pas tous aussi aguerris à l'approche 
programmée d'OSM qu'Émilie, Étienne et bien d'autres et nous ne sommes 
pas suffisamment structurés pour coordonner les projets. De plus, moi le 
premier, nous programmons préférentiellement dans un langage qui n'est 
pas celui de tous, ... Mais à chaque projet abouti même non mutualisé de 
prime abord, l'expérience du concepteur, puis, par réflexion des autres 
est enrichie de nouvelles méthodes, manières de concevoir, ... Donc au 
final c'est un bien pour un ça pourrait être merveilleux.

Benoît ROUSSEAU

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

[OSM-talk-fr] Contrôle d'affichage des dalles OSM en C#

re bonjour,

J'ai presque terminé une version d'un contrôle utilisateur en C# pour 
afficher les cartes de dalles type OSM.

Mis à part Émilie il y a t'il d'autres programmeurs C# ? C'est pour 
tester l'utilisation et avoir un autre regard sur le code avant de le 
"publier".

Et au passage : Émilie aurais-tu du temps pour et la volonté d'y regarder ?

Benoît ROUSSEAU.

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

Re: [OSM-talk-fr] Contrôle d'affichage des dalles OSM en C#


Etienne Chové a écrit :

Benoît ROUSSEAU a écrit :
  

re bonjour,

J'ai presque terminé une version d'un contrôle utilisateur en C# pour 
afficher les cartes de dalles type OSM.


Mis à part Émilie il y a t'il d'autres programmeurs C# ? C'est pour 
tester l'utilisation et avoir un autre regard sur le code avant de le 
"publier".



Pas vraiment du C#, mais c'est cousin du vb.net que j'utilise 
intensément au boulo. Donc je veux bien tester.


  


Je te prépare ça et j'envoie sur ton adresse perso.

Merci +

Benoît.

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

Re: [OSM-talk-fr] Contrôle d'affichage des dalles OSM en C#

Emilie Laffray a écrit :
> On 18/05/2010 20:14, Benoît ROUSSEAU wrote:
>   
>> re bonjour,
>>
>> J'ai presque terminé une version d'un contrôle utilisateur en C# pour 
>> afficher les cartes de dalles type OSM.
>>
>> Mis à part Émilie il y a t'il d'autres programmeurs C# ? C'est pour 
>> tester l'utilisation et avoir un autre regard sur le code avant de le 
>> "publier".
>>
>> Et au passage : Émilie aurais-tu du temps pour et la volonté d'y regarder ?
>>   
>> 
>
> Vi je vais avoir plus de temps. Donc tu peux m'envoyer cela. J'ai pu
> recommence ce soir a programmer.
>
> Emilie Laffray
>
>   
Merci,

Je vous prépare un paquet pour deux. Je documente au moins les méthodes 
avant de vous envoyer ça... Le code est brut de pisse de lignes, vous 
êtes prévenus.

Benoît R.

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

Re: [OSM-talk-fr] Première version d'un contrôle OSM pour les Windows.Form

2010-05-24 Par sujet Benoît ROUSSEAU

Pieren a écrit :
> 2010/5/22 Benoît ROUSSEAU  <mailto:adressepossi...@free.fr>>
>
> Bonjour,
>
> Vous trouverez la première édition de mon contrôle OSM pour
> l'affichage de cartes dallées destiné à être incorporé dans un
> Windows.Form ici :
> 
> http://arduinodezero.hautetfort.com/archive/2010/05/22/osm-tiles-control-version-0-1.html.
>
> Vos remarques et commentaires sont les bienvenus.
>
>
> Pour mieux faire partager ton développement, il serait sans doute 
> possible de le mettre à disposition dans le dépôt SVN 
> d'openstreetmap.org <http://openstreetmap.org> (suivant la license que 
> tu choisiras) et une page dédiée sur le wiki. Voir même un message sur 
> la liste osm-dev qui est audience plus large de développeurs.
>  
> Pieren
>   
Ok je vais essayer dès la doc totalement terminée. Merci pour l'info.

> 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>   
> 
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.819 / Base de données virale: 271.1.1/2889 - Date: 05/22/10 
> 08:26:00
>
>   


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

[OSM-talk-fr] ... La mairie X lance une application officielle pour iX

2010-05-25 Par sujet Benoît ROUSSEAU

Pieren a écrit :
> 2010/5/23 Nicolas Dumoulin  <http://nicolas_openstreetmap.org>@dumoulin63.net <http://dumoulin63.net>>
>
>
> Je n'ai pas l'impression que cela s'appuie sur OSM, ni que ça
> aille dans le
> sens de la libération des données publiques …
>
>
> C'est une carte GMaps qui apparait dans le reportage BFM. Ce qui 
> manque pour une application libre, c'est uniquement l'API qui donne la 
> capacité actuelle des stations. Mais est-ce que l'Iphone est la 
> plateforme idéale pour du libre...
>
> Pieren
>

Je vais être grossier...

Il est vrai que je suis sidéré de voir que tous nos monuments, villes, 
... proposent des applis de visite pour Apple I- uniquement. Si ton 
matos n'est pas marqué du sceaux de la pomme, il est considéré comme un 
godemiché qu'on peux se mettre... C'est assez affligeant de la part du 
Publique.

Benoît ROUSSEAU.

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

Re: [OSM-talk-fr] ... La mairie X lance une application officielle pour iX

2010-05-25 Par sujet Benoît ROUSSEAU

Steven Le Roux a écrit :
>
>
> 2010/5/25 Benoît ROUSSEAU  <mailto:adressepossi...@free.fr>>
>
> Pieren a écrit :
> > 2010/5/23 Nicolas Dumoulin  <http://nicolas_openstreetmap.org>
> > <http://nicolas_openstreetmap.org>@dumoulin63.net
> <http://dumoulin63.net> <http://dumoulin63.net>>
> >
> >
> > Je n'ai pas l'impression que cela s'appuie sur OSM, ni que ça
> > aille dans le
> > sens de la libération des données publiques …
> >
> >
> > C'est une carte GMaps qui apparait dans le reportage BFM. Ce qui
> > manque pour une application libre, c'est uniquement l'API qui
> donne la
> > capacité actuelle des stations. Mais est-ce que l'Iphone est la
> > plateforme idéale pour du libre...
> >
> > Pieren
> >
>
> Je vais être grossier...
>
> Il est vrai que je suis sidéré de voir que tous nos monuments, villes,
> ... proposent des applis de visite pour Apple I- uniquement.
> Si ton
> matos n'est pas marqué du sceaux de la pomme, il est considéré
> comme un
> godemiché qu'on peux se mettre... C'est assez affligeant de la part du
> Publique.
>
> Benoît ROUSSEAU.
>
>
> Continuons. Si osm n'est pas utilisé, c'est surtout :
>
> - par méconnaissance
> - par manque de simplicité
>
> Donc continuons à travailler, ça paiera... Communiquer sert à faire 
> prendre conscience des choses. Les contributions feront le reste. Et 
> le jour où la carte sera indiscutablement la meilleure, google 
> l'intègrera, et toutes les applis développées avec l'api google en 
> bénéficieront. L'ennemi n'est pas GMaps ! (Je pense que dans un 
> premier temps ils fourniront même un layer osm comme il y a un layer 
> sat/map/relief...)
Oui, pour ce qui concerne OSM, nous sommes loin d'un service équivalent pro.
L'APÏ apple pour les I-x est paraît il super bien faite, les machines 
sont hypes côté Culture, ...
Mais une appli java, en plus de l'appli I-X, compatible avec la majorité 
des smartphones serait plus service public selon moi.


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

[OSM-talk-fr] Pour info : nouvelle version du Tiles Control C#/COM

2010-05-30 Par sujet Benoît ROUSSEAU

Pour ceux que ça intéresse, la dernière version : 
http://arduinodezero.hautetfort.com/archive/2010/05/30/osm-tiles-control-version-0-1-0-2.html
Il y a eu un 40aine de téléchargement, il va falloir que je passe 
bientôt au SVN. Les spécialistes, faudra peut être m'aider ce jour là :).
Benoît R.

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

Re: [OSM-talk-fr] Variantes de chemins de St Jacques de Compostelle

2010-05-30 Par sujet Benoît ROUSSEAU

Mon avis qui ne cherche pas à convaincre et qui ne fais pas 
nécessairement avancer le schmilblick.


Je m'étais posé la question de faire la route, et ça me trotte toujours 
en tête...


Les chemins de GR sont des chemins de GR, les chemins de St Jacques sont 
bien plus anciens et effectivement parfois perdus. Donc tout dépends 
l'objectif, soit référencer les voies actuellement empruntables, les 
plus directes (peut être parfois des GR) où référencer les tracés d'origine.


Mais de quelle époque ? Il n'y a pas un chemin mais des chemins et ils 
ont bougés au cours du temps.


Pour ce qui pourrait être appelé voies principales, je regarderai s'il y 
a de "véritables" relais d'étape sur leur tracé. Comme tu le fais 
remarquer "(la toponymie locale et les monuments semble l'attester)", 
c'est à mon sens un chemin typique et ancien.


Tout dépends donc de ton objectif et du sens que tu veux donner à tes 
tracés. Tu pourrais très bien tous les indiquer en les étiquetant 
différemment selon divers critères.


Benoît R.

Gérard a écrit :

Bonjour,

Voulant cartographier les chemins de St Jacques de Compostelle dans les
alentours de Toulouse, je constate qu'il y a plusieurs variantes locales.

Celles balisées avec des flèches à l'emblème de la coquille, en jaune 
sur fond bleu.
Celles balisées à la peinture rouge et blanche (GR) et avec de temps à 
autres sur

les panneaux indicateurs, une coquille en prime (noir sur fond jaune).
Il y a même une commune qui se targue d'encore un autre tracé (la 
toponymie locale et
les monuments semble l'attester), passant par son territoire bien sur, 
et ayant son

propre fléchage sur ce tronçon.

Quels chemins considérer comme la voie principale de la Via Tolosane, 
alias le chemin d'Arles (relation 389715) et

lesquels considérer comme des variantes (nouvelles relations à créer)?

Sur quel critère se baser? Prendre l'itinéraire le plus direct comme voie
principale (à Toulouse ça serait celui que conseille l'association de
coopération interrégionale "les chemins de St Jacques de Compostelle")?
Prendre le GR car c'est ce que Monsieur-tout-le-monde connait le plus?



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




Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.819 / Base de données virale: 271.1.1/2906 - Date: 05/30/10 11:21:00


  


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

Re: [OSM-talk-fr] Liste des gares ferroviaires

2010-05-31 Par sujet Benoît ROUSSEAU


Bonsoir,

L'idée est comme dit dans un autre mail  est que les trains, les gares, 
... vont être gérées en France, comme ailleurs, sur le même principe que 
pour le trafic aérien.


L'opérateur pour les voies (entre autre) est bien RFF c'est dit "par 
défaut" dans des textes de lois. Pour les gares ça change de main petit 
à petit. La SNCF est un transporteur. On aura bientôt d'autres 
transporteurs sur les voies comme (peut être) la DB, Air France, Virgin, ...


Nous sommes en période de transition, mais mieux vaudrait commencer à 
s'aligner sur le futur avec l'étiquette "operator". Mais ça c'est libre 
à celui qui le fait e le faire ou non. Si déjà on arrive à trouver les 
gares et qu'on sait qu'il y a une et peut être des voies qui suivent un 
tracé c'est déjà du travail.


Benoît R.

Marc Sibert a écrit :

Le 31/05/2010 16:53, Eric Sibert a écrit :
  

Le tag operator n'est à mettre que quand il y a plusieurs opérateurs
ou quand il y a des exceptions aux cas majoritaire :

If the vast majority of a certain object is operated by a certain
company and only very few by others, only the "exceptions" should be
tagged.

   

Ça doit être spécifique à opérator alors car je trouve souvent des 
"oneway=no" qui relèvent de la même exception, non ?
  

http://wiki.openstreetmap.org/wiki/Operator

Donc, pas de operator=sncf. Par contre, operator=RATP ou autre sur
certaines voies privées comme le train des Pignes ou pas mal de
chemins de fer touristiques.
   

En plus, je pense que l'opérateur des voies est RFF en fait, même si 
c'est la SNCF qui en fait l'entretient... moi, je dis ça... j'aime aussi 
les trolls ;-)
Et qui fait rouler les trains ; ça veut dire que la voie physique est 
operator=RFF (par défaut, mais c'est écrit où le défaut de la France ?) 
mais que le trajet (relation route, etc.) est operator SNCF ?


  

Eric
   


--

Marc Sibert
m...@sibert.fr


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




Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.819 / Base de données virale: 271.1.1/2908 - Date: 05/31/10 08:25:00


  


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

Re: [OSM-talk-fr] Hameau et lieu-dit

2010-06-02 Par sujet Benoît ROUSSEAU

Pierre-Alain Dorange a écrit :
>
> Le 2 juin 10 à 13:32, Nicolas Dumoulin a écrit :
>
>>> En France, un bourg rural serait une commune avec une certaine
>>> concentration de commerces : coiffeur, pharmacie, poste, présence d'un
>>> marché hebdomadaire, indépendamment de sa population qui peut être 
>>> faible.
>>
>> Je plussoie (d'un ton pédant).
>> Le terme de bourg « tout-court» s'emploie également dans ce sens par 
>> chez moi.
>
> En effet, à priori le bourg (par chez moi) désigne aussi la zone d'une 
> commune ou la densité est plus importante et qui comporte soit la 
> mairie et/ou des commerces, le reste de la commune étant composé de 
> hameaux plus ou moins disséminé.
> Moi je le comprend comme plus petit qu'un village mais surtout 
> beaucoup moins centralisé ; quand le bourg a une taille proche des 
> hameaux en gros...
>
> -- 
> Pierre-Alain Dorange, 
> Blog Citoyen de Cognac : 
> Twitter :  - Facebook : 
> 
>
Bonjour,
Nous sommes du même coin, je confirme. Et généralement quand on te parle 
de bourg dans la région c'est pas pédant mais parfois patois :).
Benoît R.

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

Re: [OSM-talk-fr] [stats] Le fichier Planet mainte nant à 10 GB

2010-06-03 Par sujet Benoît ROUSSEAU


Etienne Chové a écrit :

Le 03/06/2010 16:23, Christophe Merlet a écrit :
  

Le XML n'est il pas trop verbeux ?



D'où le taux de compression de 93%, grace la répétition de beaucoup de 
motifs. Je ne suis pas sûr que changer de format gagne vraiment quelque 
chose par rapport à un fichier compressé.


  

Bonjour,

Un poil en retard...

+1 Etienne et Émilie (et les autres). Les fichiers compressés sont en 
quelque sorte les version binaires pour les fichiers XML et l'intérêt de 
rester en XML pour la source est que c'est verbeux, compatible toute 
plateforme et directement interprétable par l'homme avec le filtrage 
possible en sus. Au vu de la puissance des machines grand publique 
actuelles, de la volonté de partage du projet, des connections Internet 
dispo pour les particuliers, le xml à beaucoup d'avantages au vu des 
temps de réponse nécessaires pour ce projet.


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

[OSM-talk-fr] Militantisme ?

2010-06-03 Par sujet Benoît ROUSSEAU

Bonjour,

Je pose ces questions parce quelles me trottent en tête depuis le début...

- Le vandalisme/militantisme est-il fréquent sur OSM ?

Rien ne m'empêche un "Je t'aime Germaine" sur le monde pour l'anniv de 
ma compagne, d'afficher mon militantisme en ajoutant "Non au NUCLAIRE !" 
sur la France, ajouter une grosse bite à la France pour enculer 
l'Angleterre lors de la coupe du Monde de football, ou effacer trois ou 
quatre villes pour me marrer parce que je m'ennuie... Les exemples sont 
volontairement idiots, mais j'y repensai suite aux pb au moyen orient.

D'autant plus que même pour du texte ou un sigle, nombre de petits 
segments peuvent être créés par autant d'utilisateurs fantômes, ... pas 
nécessairement super simple à éliminer en bloc.

La bêtise et les possibilités offertes peuvent laisser rêveur nombre 
d'abrutis et de militants de toutes causes. Qui plus est, tout cela 
pourrait faire du buzz dans les médias.

- Dans pareils cas que se passerai t'il du côté d'OSM, de la communauté 
? C'est prévu, réversible (oui la 10Go/semaine)? Il y a t'il une vigilance ?

Benoît R.



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

Re: [OSM-talk-fr] Militantisme ?


Bonjour,

   Merci pour toutes vos réponses de qualité. Pour tout dire, j'ai eu 
peur après envoi de déchainer un troll.


   PS :
   1 - j'aurai dû trouver la page 
http://wiki.openstreetmap.org/wiki/Vandalism tout seul.
   2 - je ne connaissais pas OWL mais Ito grâce à Julien B. J'ai fait 
aussi un outil de "surveillance" basique mais juste pour suivre 
l'évolution autour des zones que je complète et surtout tester ma 
librairie sur de vrais projets pour l'améliorer. Devrait pas tarder à 
ressembler à OWL en local. Je vous ferai suivre un de ces quatre.


Benoît R.

Emilie Laffray a écrit :



2010/6/4 Lord Awikatchikaen >


Sur Wikipedia il y a plusieurs grade avec différents droit tels
que les modérateur.
Et tous les contributeurs ne sont pas au même niveau, un
utilisateur non enregistré sera plus surveillé.

Peut être faudrait il instruire un système identique, les modif
d'un nouvel utilisateur seront peut être plus a surveiller que
celles de Pieren, Sylvain ou Émilie ? Sans aller jusqu'au
vandalisme les erreurs de débutant étant nombreuses


Ou pas. Récemment, on m'a montre des modifications que j'avais faite 
ne respectant pas la toponymie telle qu'elle était définie sur la page 
Française. Nul n'est a l'abri d'erreurs au final ou de vandalisme au 
final. C'est le principe Ebay ou certains vendeurs restent la pour 
monter leur réputation et pour finalement mieux arnaquer une fois leur 
réputation faite. Rien ne m'empêche maintenant de vandaliser sans 
vergogne sous prétexte que je ne suis pas d'accord avec untel.
Je pense que les différents systèmes que les gens essaient de mettre 
en place ne tiennent pas compte des utilisateurs, et je pense que 
c'est une bonne chose car ça enlève tout jugement sur une personne. A 
la différence de Wikipedia, nous sommes dans le domaine des faits 
observables et non pas dans l'explication de connaissance, avec tout 
ce que ça implique de parti pris du fait de l'outil linguistique ou de 
motivations personnelles diverses et variées. Il y a bien sur des 
partis pris dans OSM notamment d'un point de vue technique, mais ça 
reste bien moindre au final car je pense que de toute façon tout va 
converger a terme. Il ne faut pas oublier qu'OSM est encore quelque 
chose de très jeune avec la transition de 0.5 a 0.6 étant très récente 
par exemple.
Nous sommes plusieurs a travailler sur des outils de détection de 
changements; le plus abouti actuellement est celui de Matt Amos OWL: 
http://matt.dev.openstreetmap.org/owl_viewer/


Emilie Laffray


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




Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.829 / Base de données virale: 271.1.1/2917 - Date: 06/04/10 08:25:00


  


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

Re: [OSM-talk-fr] Concours geoportail

René-Luc D'Hont a écrit :

Le 04/06/2010 11:52, sly (sylvain letuffe) a écrit :

http://ign.cab02.net/geoportail2010-soiree-lancement-concours.cfm?WL=1007&WS=160583_3591716&WA=450

Mon dieu...
Ils sont tombés bien bas pour en arriver à se prendre pour des américains.

Qu'est-ce qu'il se passe, il n'est pas utilisé par les développeurs leur
truc ?

C comme pour Mappy, ils ont besoin que l'on parle de leur API et que les
devs se tournent vers eux plutôt que Google..
Pour ma part, j'avais regardé et ça m'avait paru super lourdingue à tous
niveaux, engagements, contrat, obligations, limitations, ... Après
lecture, je m'étais dit que je ne voyais pas ce que je pouvais
développer d'intéressant avec de telles limitations et comment je
n'allais pas finir en conflit sur tel ou tel point de règlement. Pour au
final ne même pas pouvoir bénéficier de mon travail ou le faire
partager. C'est juste du ressenti, une interprétation de la réalité,
mais pfff...

En gros ça m'a impliquer encore plus sur OSM :p. L'idée était de tracer
les zones à moins de 150 d'un point d'eau pour déterminer grossièrement
les zones d'implantation évidentes du Frelon asiatique. En gros parce
qu'un bidon de récupération d'eau de pluie doit leur suffire. Depuis j'y
bosse, mais à partir des données d'OSM. Bravo Geoportail !

Moi je dirais : on ouvre ou on n'ouvre pas, mais la voie médiane
indéterminée est sans issue.

Benoît R.

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

Re: [OSM-talk-fr] Re : Militantisme ? - outil de s urveillance des données osm - ressources serveur ?


sly (sylvain letuffe) a écrit :

On vendredi 4 juin 2010, Pieren wrote:
  

Ce qu'il faudrait donc, c'est un outil capable de surveiller (monitorer) une
zone grande comme la France mais en ne montrant que les changements dignes
d'intéret et en regroupant les autres pour info. 



Ce type de projet m'intéresserait bien, ce serait un super complément des 
outils de surveillance déjà existant.


Je pense écrire une page wiki avec des idées d'abord puis tenter de faire un 
premier prototype d'outil de ce type que je commencerais à faire tourner sur 
la france.


Yaka, fauqueje.

Y'aurait un bout de serveur dispo dans un coin qui puisse ensuite servir à 
ça ?

(le mien est déjà pas mal "busy" )

  
Juste un aperçu de mon appli. qui surveille des tuiles, avec une 
interface tout en franglish :p


Un apercu ici 

Ma config compare environ 300 dalles/s : AMD Athlon 64 X2 Dual Core 
5000+ 2,6 GHz - 4 Go RAM


L'idée était de faire simple, à la manière d'un satellite de 
surveillance (dans le spectre du visible), pour regarder ce qui se passe 
autour des zones que je complète. Puis, de ne charger que les éléments 
des zones modifiées si besoin. Actuellement, j'en suis au chargement des 
éléments des zones modifiées (J'ai attaqué la partie API). Ca ne fait 
pas le café, c'est avant tout pour améliorer ma librairie en constituant 
de "vrais" projets qui l'utilisent.


Pour l'essai, je suis en zoom 16 et j'ai recalé un noeud en le 
déplacement d'1 mètre. La différence de rendu est signifiée en rouge sur 
la tuile de droite.


La France "étendue" selon http://www.geotribu.net/node/262 au niveau de 
zoom 16 c'est :


Sauf erreur très possible :
lat   10,38 - 7560 tiles
long  16,8 - 6120 tiles
46.267.200 tiles au total
soit 154.224 s ou 2.570 h ou 107 jours de comparaisons :p. On peux 
négliger le temps de chargement car la comparaison peut se faire durant 
le chargement sans le ralentir de manière significative.


Bon... ce n'est pas LA solution et c'est du local. Charger sur un 
serveur, pour tous, et bosser sur le xml semble plus cohérent pour un 
vrai projet.


Benoît R.

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

Re: [OSM-talk-fr] Re : Militantisme ?

Vincent Pottier a écrit :
> Le 04/06/2010 13:12, Emilie Laffray a écrit :
>   
>> - Règles heuristiques sur l'ajout de tags, et leur disparition. Ça 
>> implique de créer des tables de relations entre les différents tags ou 
>> les combinaisons sont logiques. Je pense qu'une étude statistique sur 
>> des chaînes de Markov pourrait donner ce genre de résultat
>> 
> Je ne connais pas ce monsieur. Dommage pour lui. Mais je vais me renseigner.
>   
>> - Règles heuristiques sur la modification d'un tag
>> 
> Genre filtre bayésien pour associations de tags, de type de primitive ?
> C'est peut-être quelque chose qui peut s'implémenter sur osmose... Au 
> début, ça va être pourri ! mais ça s'éduque...
>
> PS : Je suis allé lire "Chaîne de Markov" sur wikipédia. Qui a de 
> l'aspirine ?
> --
> FrViPof
La détection automatique, est un plus indéniable. Mais quant à détecter 
une attaque en règle pas sûr que ça fonctionne. Une incursion préparée 
se baserai sur l'ajout de données cohérentes. Il n'y à pas que des 
idiots qui passent en force.
La question s'est déjà posée, OSM y travaille et est prêt à réagir. 
C'est à mon avis le plus important.
Benoît R.

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

Re: [OSM-talk-fr] Re : Militantisme ? - outil de s urveillance des données osm - ressources serveur ?


Pieren a écrit :
2010/6/4 Benoît ROUSSEAU <mailto:adressepossi...@free.fr>>


Je vois deux  inconvénients à cette approche:
- tu ne compares que ce qui est rendu par Mapnik
- tu compares deux jeux de données complets


Absolument !

Alors que ce dont je parlais ne concernerais que la surveillance des 
fichiers planet intermédaires (les daily-diff ou minutely-diff) qui 
sont bien plus petits (quelques dizaines de Mo par jour, voir 
http://planet.openstreetmap.org/daily/) et donc qui ne nécessitent pas 
une grosse machine pour le traitement.
Les rapports pourraient être sauvegardés pour pouvoir revenir en 
arrière si besoin.

Tout a fait !


Pieren
D'ailleurs je n'ai rien publié :p. C'est la prochaine étape, là c'était 
pour tester ma librairie (des choses à changer d'ailleurs suite à cet 
essai). C'était ça ou un jeu de "pousse pousse" avec des dalles (une 
case vide, reformer le puzzle en permutant les dalles- jeu qui serait 
d'ailleurs un bon outil de promo pour OSM).


Benoît R.

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

[OSM-talk-fr] Et paf !

Suite à mon message :
 > [bla bla]
 > Sauf erreur très possible :
 > lat   10,38 - 7560 tiles
 > long  16,8 - 6120 tiles
 > 46.267.200 tiles au total
 > soit 154.224 s ou 2.570 h ou 107 jours de comparaisons :p. On peux 
négliger le temps de chargement car la comparaison peut
 > se faire durant le chargement sans le ralentir de manière significative.
 > Bon... ce n'est pas LA solution et c'est du local. Charger sur un 
serveur, pour tous, et bosser sur le xml semble plus cohérent pour un 
vrai projet.

Bingo ! les résultats annoncés étaient faux !

46.267.200 / 300 = 154.224 secondes
... / 60 = 2.570,4 minutes
... / 60 = 42,84 heures
... / 24 = 1,785 jours
Ca ne change rien aux conclusions apportées malgré tout. Mais c'est 
rectifié.
Inutile de charger la liste en commentant cette lamentable erreur. Je 
m'en veux déjà de vous envoyer le correctif.

Benoît R.

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

Re: [OSM-talk-fr] Géovélo & Travaux temporaires


Guilhem Bonnefille a écrit :

Le 8 juin 2010 10:00, Vincent Pottier  a écrit :
  

15 mn pour les bouchons ? L'autre jour, j'ai mis 1 h 30 entre Créteil et
Porte d'Orléans. Vive la capitale ! (À Besançon, on peste quant on est
bloqué 5 ')



J'habite Toulouse. Et même si certains peuvent mettre de long moment,
les petits bouchons se forment et disparaissent en moins de 15 minutes
il me semble. En fait, quand je suis soucieux de l'état de la
circulation, je consulte un site dédié qui intègre des informations de
trafic. Or j'ai remarqué à plusieurs reprises que celui-ci est
passablement pessimiste : il indique des tronçons chargés alors que
lorsque j'arrive sur les lieux tout est fluide.

  

Il y a des discussions sur la ML anglaise pour un identifiant d'objet
unique. Peut-être une solution.
Mais dans le cas des travaux et bouchons, la durée de vie de
l'information étant relativement courte, l'id osm de l'objet devrait
fonctionner sans trop de risque.



Il y a peut-être une autre solution, moins précise mais plus simple.
J'ai remarqué que le service de routage intègre la possibilité de
définir des zones que le logiciel ne doit pas franchir. Peut-être
peut-on imaginer une première version simpliste qui :
- géolocalise les évènements uniquement avec des coordonnées (sans
lien avec les données OSM)
- génère, à l'intention des logiciels de routage, un périmètre à ne
pas emprunter

A mon avis, c'est une piste à suivre car, comme le montre le projet
OSM, il peut être intéressant de creuser des pistes qui ne suivent pas
du tout les solutions conventionnelles (je pense au fait que le
système de stockage de l'information d'OSM n'est pas du tout l'état de
l'art des solutions classiques). C'est à mon avis un des intérêts des
projets libres : leur liberté, voire naïveté, dans la résolution des
problèmes.

  

Bonjour,
J'ai vu parfois des tags TMC qui si j'ai bien comprit sont en rapport 
avec l'info traffic (ptet Traffic Mangement Control).
Je le redis mais c'est un vieux débat... Pour ma par ces données n'ont 
rien à faire dans la base OSM. Les travaux en l'état actuel des choses 
(sauf si c'est vraiment long à la rigeur (6 mois +) mais faut surveiller 
après), les ralentissement jamais. Par contre monter une BDD extérieurs 
d'info traffic en utilisant OSM en sous couche pour un rendu avec 
OpenLayers OUI. Ce serait même super bien. Mais je ne vois qui va passer 
sa vie à la fenêtre ou scruter les infos pour saisir des embouteillages 
possibles toutes les 15 min.

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

Re: [OSM-talk-fr] key:construction

Rodolphe Quiedeville a écrit :
> Christophe Merlet a écrit :
>   
>> Le mardi 08 juin 2010 à 16:29 +, jos sinet a écrit :
>> 
>>> Bonjour,
>>>   
>> Bonjour,
>>
>> 
>>> Je suis Jocelyn de l'équipe Géovélo, fraichement inscrit à la
>>> mailing-list, et collègue de Gaël qui vous a soumis ce matin la
>>> question des travaux temporaires.
>>> Je voudrais apporter quelques précisions sur cette affaire, ou plutôt
>>> reformuler les termes du débat.
>>>   
>> ...
>> 
>>> Qu'en pensez-vous ?
>>>   
>> J'en pense que ce n'est pas à OSM de supporter ce genre d'applications.
>>
>> Par contre j'ai récemment vu passer le lien vers le Chimère d'une
>> commune qui affichait les travaux en cours. C'est parfait.
>>
>> OSM fournit des données cartographique et un fond de carte. Les
>> applications dérivées sont à développer en dehors de la base.
>> 
>
> Je suis aussi de cet avis, OSM est un outil formidable mais il faut
> aussi accepter qu'il ne fasse pas le café
Sur couche...

Tout à fait d'accord. D'autant que je ne comprends absolument pas ce 
genre débats alors que toutes les solutions existent. Même si je dois 
dire qu'indiquer l'A6b en travaux ne me choque pas :). Ca bouleverse les 
solutions d'accès à la capitale et la quantité de personnes que ça 
impacte. Mais ensuite faudra trancher à chaque fois et déjà qu'il n'est 
pas simple de déterminer des critères comme ville/commune/bourg/hameaux, 
je n'ose pas imaginer les discussions sur l'opportunité d'indiquer tels 
ou tels travaux...

*Question : pourquoi ne voulez-vous pas créer et maintenir des données 
affichées sur un calque ?
Cela ne serait-il pas plus simple ?*

Quelque chose m'échappe, pourquoi ne pas "monter" un calque avec 
OpenLayer ? Pourquoi vouloir absolument tout entrer dans OSM ? Et je 
parle en connaissance de cause, j'y ai collé des n° de cabines 
téléphoniques alors que ma ville n'est pas complète (je me fouette). 
Est-ce rendu correctement pour votre usage ? Est-ce réellement plus 
simple à créer et maintenir ces informations sur OSM ? Pas sûr.

Benoît R.



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

Re: [OSM-talk-fr] key:construction

Re bonne nuit,

Sans vouloir clore la discussion...

Globalement, personne n'est contre et tout le monde aimerai bien inclure 
les travaux. Mais, il est trop tôt, nous n'avons pas les outils adéquats 
aujourd'hui pour les inclure puis les gérer dans de bonnes conditions. 
D'où nos réactions qui peuvent ingrates face à la proposition faite de 
faire avancer les choses dans cette direction.

Benoît R.




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

Re: [OSM-talk-fr] key:construction

Christian Quest a écrit :
> Une question peut être bête et un peu annexe... comment fait-on pour 
> maintenir des données externes liées à OSM ?
>
Ce n'est pas du tout une question bête ! Il faut par exemple surveiller 
puis digérer les changeset. Ca peut très vite devenir lourd à gérer. J'y 
traille avec Julien B. C'est  ardu mais passionnant. D'autant que la 
quantité de données n'est pas si triviale à gérer, ne serait-ce que pour 
la France.

Pour localiser des travaux une copie de tronçon où une paire de 
coordonnées avec un descriptif pourrait suffire.
> Par là je veux dire que vu que le contenu d'OSM peut changer à tout 
> moment, que les ID des nodes et ways peuvent aussi changer 
> (effacement, remplacement, etc), comment conserver de façon pérenne le 
> lien entre OSM et d'autres data, qu'elles soient volatiles ou pas ?
Effectivement.
>
> Les coordonnées GPS permettent éventuellement de localiser des travaux 
> (ou autre), mais ça ne permet pas de lier sur le bon way qui peut être 
> déplacé.
Exactement.

D'où la conclusion que je proposait, c'est peut être trop tôt mais pas 
nécessairement à mettre aux oubliettes. Je pense que la plus grosse 
crainte c'est que ce projet démarre fort puis s'écrase faute de plein de 
choses, en laissant derrière lui nombre de fragments obsolètes. Après 
les pours et les contres ce ne sont que des avis.
>
> Bonne nuit
> Christian
>


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

Re: [OSM-talk-fr] key:construction

Christophe Merlet a écrit :
> Le mercredi 09 juin 2010 à 00:56 +0200, Christian Quest a écrit :
>   
>> Une question peut être bête et un peu annexe... comment fait-on pour
>> maintenir des données externes liées à OSM ?
>>
>> Par là je veux dire que vu que le contenu d'OSM peut changer à tout
>> moment, que les ID des nodes et ways peuvent aussi changer
>> (effacement, remplacement, etc), comment conserver de façon pérenne le
>> lien entre OSM et d'autres data, qu'elles soient volatiles ou pas ?
>>
>> Les coordonnées GPS permettent éventuellement de localiser des travaux
>> (ou autre), mais ça ne permet pas de lier sur le bon way qui peut être
>> déplacé.
>> 
>
>
> De quelle distance un way existant peut éventuellement être déplacé dans
> OSM ?
>
> Cette distance peut-elle être si importante qu'on ne puisse plus
> associer automatiquement des travaux a une voie en particulier ?
>
> Pourquoi le lien entre travaux et voie serait il défini par l'id du node
> ou du way et pas par son nom ?
>
>
>   Librement,
>   
Après je me tais...

Je réponds à : "Pourquoi le lien entre travaux et voie serait il défini 
par l'id du node ou du way et pas par son nom ?".

Parce que bien que possible ça n'apporte rien (quelle chance de changer 
l'ID d'un way alors qu'il existe, pas de différence vis à vis d'une 
suppression et que le nom peut aussi changer (mauvaise orthog. de 
départ, ...)) que c'est dramatiquement inefficace en terme de 
traitements et que tu perds les liens (pb les travaux dans une rue qui 
s'étale sur plusieurs ways).

Benoît R.



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

[OSM-talk-fr] Noeuds orphelin en France

Bonjour

Avec Julien B. on cherche actuellement les nœuds vides et orphelins (pas 
de tag significatif et n'appartenant ni à un ways ni à une relation). Je 
travaille sur l'extraction France de geofabrik datant du 2 juin pour 
tester. Il semble qu'un nettoyage est été fait depuis le 7 juin : 
"Nettoyage post-import Romans" comme sur 
http://www.openstreetmap.org/browse/node/763277871 qqun pourrait il 
éventuellement nous donner en gros le nombre de nœuds supprimés ?

Pierre-Alain nous parlait de la Charente : il y a ce nœud orphelin par 
exemple : http://www.openstreetmap.org/browse/node/765653312. Je ne 
jette pas la pierre Pierre c'est juste que je me souvenais de tes 
messages cause je suis à Poitiers. L'exemple est d'ailleurs parlant, les 
noeuds orphelins sont difficiles à voir.

Je vous joint la première liste extraite, si vous y trouvez des faux 
positifs, ... et toute critique est la bienvenue sachant que c'est la 
toute première édition non vérifiée et mal présentée mais que tout cela 
est prévu. Sous Windows c'est Chrome qui s'en tire le mieux pour 
afficher la liste alors que IE pédale dans la semoule et que FireFox 
3.xx prends son temps.

La pièce jointe du précédent mail attends l'approbation donc vous 
recevrez peut-être le précédent courrier par la suite. En attendant la 
liste est téléchargeable ici : 
http://arduinodezero.hautetfort.com/files/results-final.zip.

Rousseau B.


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

Re: [OSM-talk-fr] Noeuds orphelin en France

Etienne Chové a écrit :
> Le 09/06/2010 05:58, Benoît ROUSSEAU a écrit :
>> Bonjour
>>
>> Avec Julien B. on cherche actuellement les nœuds vides et orphelins (pas
>> de tag significatif et n'appartenant ni à un ways ni à une relation). Je
>> travaille sur l'extraction France de geofabrik datant du 2 juin pour
>> tester. Il semble qu'un nettoyage est été fait depuis le 7 juin :
>> "Nettoyage post-import Romans" comme sur
>> http://www.openstreetmap.org/browse/node/763277871 qqun pourrait il
>> éventuellement nous donner en gros le nombre de nœuds supprimés ?
>
> C'est une très bonne idée.
> - Est ce qu'on peut voir le code ou c'est secret ? Ce serait sans 
> doute plus simple que de regarder les 4 nodes.
No problemo mais c'est du C# en cours de réa pour justement caler ma 
librairie sur des fonctions utiles. Si tu lis le C#, redemande moi perso 
et je t'envoi ça perso dans un premier temps. En attendant de diffuser 
le tout avec la prochaine version de la lib.

Ce qui peut t'intéresser c'est l'ago :
1 - je sépare le fichier d'origine en 3 fichiers pour les 
nodes/ways/relations
2 - dans ces fichiers j'y copie les éléments respectifs mais filtrés
- je vire les attributs version/timestamp/uid/user/changeset/
- je n'y copie pas les tag ayant un k = à created_by/source/source_ref 
/note/wikipedia ce qui fait qu'un node n'ayant que des tags de cette 
liste devient un noeud xml sans enfants.
3 - Je charge la liste des uid des noeuds sans enfants => ListeN
4 - Je charge les uid des nodes référencés dans les ways => ListeComp
5 - Je dégage de la ListeN les uid présents dans le ListeComp
6 - J'initialise la ListeComp
7 - Je charge les uid des nodes référencés dans les relations => ListeComp
8 - Je dégage de la ListeN les uid présents dans le ListeComp
=> j'obtiens UNE liste de noeuds orphelins.

> - Est ce que vous regardez la date de création pour éviter des 
> suppression intempestives.
Non ! Faudrait-il éviter de supprimer les noeuds les moins âgés car il 
pourraient être en cours de raccord à un way ou une relation c'est ça ?
> - Si vous voulez l'afficher sur une slippy map, je dois pouvoir vous 
> aider...
>
Euh oui :) merci.

Benoit R.


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

Re: [OSM-talk-fr] Noeuds orphelin en France





Vincent Pottier a écrit :

  Le 09/06/2010 08:27, Etienne Chové a écrit :
  
  
Le 09/06/2010 05:58, Benoît ROUSSEAU a écrit :
   


  Bonjour

Avec Julien B. on cherche actuellement les nœuds vides et orphelins (pas
de tag significatif et n'appartenant ni à un ways ni à une relation). Je
travaille sur l'extraction France de geofabrik datant du 2 juin pour
tester. Il semble qu'un nettoyage est été fait depuis le 7 juin :
"Nettoyage post-import Romans" comme sur
http://www.openstreetmap.org/browse/node/763277871 qqun pourrait il
éventuellement nous donner en gros le nombre de nœuds supprimés ?
 
  

C'est une très bonne idée.
- Est ce qu'on peut voir le code ou c'est secret ? Ce serait sans doute
plus simple que de regarder les 4 nodes.
- Est ce que vous regardez la date de création pour éviter des
suppression intempestives.
- Si vous voulez l'afficher sur une slippy map, je dois pouvoir vous
aider...
   

  
  En gros : 40 000.
  

Ok, donc nos prochaines extractions iront beaucoup plus vite :p


  J'ai utilisé le validator de JOSM, carré par carré (mais avec deux 
machines en parallèle), et l'item "nœud sans tag n'appartenant à aucun 
way", plutôt que "nœud dupliqué", donc bien la même recherche que Benoît.
  

C'est une branche de notre recherche me semble t'il mais je ne connais
pas la technique que tu exposes avec JOSM. Ca t'a pris combien de temps
sur quelle zone totale ?

  
J'espère qu'il n'y a pas de dégâts collatéraux...
  

Aucun, on ne travaille qu'en local ! Je voudrais pouvoir valider
l'extract avant d'attaquer la base réelle via l'API.

  --
FrViPofm

  

Benoît R.



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

Re: [OSM-talk-fr] Noeuds orphelin en France





Pierre-Alain Dorange a écrit :

  
  Le 9 juin 10 à 05:58, Benoît ROUSSEAU a écrit :
  
  Pierre-Alain
nous parlait de la Charente : il y a ce nœud orphelin par 
exemple : http://www.openstreetmap.org/browse/node/765653312.
Je ne 
jette pas la pierre Pierre c'est juste que je me souvenais de tes 
messages cause je suis à Poitiers. L'exemple est d'ailleurs parlant, les 
noeuds orphelins sont difficiles à voir.
  
  
  
Je suis en train de travailler sur ce coin et ce point est bien un
orphelin suite à la reconstruction de voie de chemin de fer (au
préalable il y avait un tunnel géant qui passait sous le village, ce
qui ne correspond pas à la réalité).
  Je vais corriger.

Pour celui-ci... ok, mais l'idée est d'arriver bientôt à une
surveillance globale avec suppression automatique.
Je n'ose pas chercher ceux à mon nom... 

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Pierre-Alain
Dorange, 
  Blog Citoyen de Cognac : <http://cognac-citoyen.blogspot.com/>
  
  
  
  
  
  
  
  Twitter : <https://twitter.com/padorange>
- Facebook : <http://www.facebook.com/pa.dorange>
  
  
  
  
  
  
  
   
  

Benoît R.



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

Re: [OSM-talk-fr] Noeuds orphelin en France





Etienne Chové a écrit :

  Le 09/06/2010 09:27, jul...@krilin.org a écrit :
  
  
un truc ala http://matt.dev.openstreetmap.org/dupe_nodes/ ?

  
  
Il faudrait un mapnik performant pour ça et écrire une feuille de 
style... et dans ces deux points je ne suis pas vraiment bon. Peut être 
que quelqu'un dans l'auditoire...

  
  
ca pourrait etre cool oui
une liste d'ID de point avec lat/long suffirais ?

  
  
Oui, si tu me donne un fichier csv avec ces 3 info, je dois pouvoir m'en 
sortir pour fournir une carte avec des marqueurs là ou il y a des noeuds 
manquants.
  

C'est partit pour coder une sortie CSV... on va essayer.

Benoît R. 



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

Re: [OSM-talk-fr] key:construction

GaelADT a écrit :
> Pour apporter quelques précisions par rapport à la question : "Pourquoi ne
> pas mettre simplement un calque pour les travaux ?"
>
> Heu encore une fois il faut faire la différence entre les données, et le
> résultat (l'affichage). En mettant les travaux dans OSM, on pourrait très
> bien arriver à avoir un calque séparé avec les travaux. Et inversement.
>   
Oui.
> Alors pourquoi vouloir mettre les travaux dans OSM ? Par soucis de
> simplicité de mise à jour des données. Comme plusieurs l'ont précisé dans
> les messages précédents il est extrêmement compliqué de gérer une base de
> données en lien avec OSM.
>   
Oui.
> De plus, il faut vraiment arrêter avec cette histoire oui mais les travaux
> déjà passés vont se voir sur la carte s'ils n'ont pas été retiré ! OSM ce
> n'est pas une carte mais une base de données ! On peu très bien imaginé des
> tags qui ne seront jamais visibles sur une carte. Il y a bien des tags
> d'informations liés à la création des ways par exemple. Tout est possible,
> il suffit de bien s'organiser.
>   

- la base de données à 1 objectif principal -> la cartographie.
- c'est une base de données accessible mais ce n'est pas une raison pour 
faire d'une qualité un défaut. Il faut la conserver en état 
d'utilisation et des tags. Je me disais par exemple (lié au mail 
vandalisme) qu'on pouvait y stocker n'importe quoi très discrètement 
(photos, textes, ...), et s'en servir pour diverses raisons plus ou 
moins légales.
- et comme tu le souligne c'est l'organisation le point clé. Je pense 
que c'est ce qui en a fait trembler plus d'un à la lecture de ton 
premier mail. Alors sache que la constitution d'un groupe au sein d'une 
asso (j'ai pas suivi corrigez si nécessaire) est en cours, et que des 
projets formidables abandonnés il y en a plein donc on avertit (même 
maladroitement). Que toujours question organisation plusieurs on fait 
remarqué que nous n'avions pas les outils pour gérer correctement ce 
genre de données et qu'il faut commencer par le début, se donner les 
moyens de pouvoir gérer ces éléments en attendant les outils capables de.
- donc je pense qu'il te faut être patient et préparer l'intégration de 
ces données en fournissant des propositions de tags si nécessaire et 
surtout comment elles doivent être gérées. Ensuite tu verras, des outils 
apparaîtront, tout le monde se fera à l'idée et surtout sera rassuré sur 
la pérénité du projet.
- beaucoup d'entre nous pensent aussi qu'il y a plus prioritaire et 
moins localisé. Difficile de leur reprocher.

> Autre chose que je tenais à préciser. Dans mes premiers posts j'ai
> l'impression que beaucoup ont pensé : "ah il est pénible lui, il veut tout
> bouleverser OSM pour ses propres besoins !". Oui, c'est vrai j'ai besoin de
> ces informations sur Paris. Mais d'un autre côté :
>   
Oui mais ça c'est l'effet liste et courriel. L'écriture est un exercice 
difficile. J'ai donné des cours là dessus (avec pour fond de commerce le 
fait que je sais pourquoi moi non plus je n'y arrive pas).
> - nous allons nous occupé de collecter ces informations (des gens seront
> payés pour ça quand même, ça nous coûte de l'argent, et nous voulons
> partager ces informations).
>   
> - nous avons déjà notre propre base de données perso en lien avec OSM (plus
> ou moins... c'est compliqué à gérer, mais on y arrive), donc nous pourrions
> nous contenter de mettre ces informations de travaux dans notre base privée.
>
> Bref, à la base ça part d'un bon sentiment. Car contrairement à nos infos
> privés j'estime que ces infos là devraient être libérées et qu'elles ont
> leur place dans OSM. Maintenant si ça ne plait pas à la plupart des
> contributeurs ici, tant pis, nous acceptons votre choix, on ne va pas se
> fâcher pour ça quand même ;)
>   
Ce n'est pas la plupart, ce sont les plus investis et les plus grandes 
gueules. A mon premier mail je me suis fait flinguer à raison. J'ai pu 
m'accrocher sans nous fâcher. Il y a des partisans de ci ou de ça comme 
ailleurs mais des gens biens.
Prends tout ça comme des conseils pour mener à bien ton projet dans 
l'ordre. Je n'ai rien vu de non argumenté dans ce qui t'a été opposé. A 
toi de convaincre pour passer au dessus des courants partisants historiques.
> Gaël.
>   
Benoît R.

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

Re: [OSM-talk-fr] Noeuds orphelin en France

Pieren a écrit :
> 2010/6/9 Benoît ROUSSEAU  <mailto:adressepossi...@free.fr>>
>
> Non ! Faudrait-il éviter de supprimer les noeuds les moins âgés car il
> pourraient être en cours de raccord à un way ou une relation c'est
> ça ?
>
>
>
> Oui. Il y a aussi les imports qui ont encore un espace encore plus 
> grand entre la création des nodes et des ways. Et on est pas toujours 
> au courant des imports en cours, surtout si vous utilisez des extracts 
> du planet qui débordent largement de l'hexagone. Un délai d'une 
> semaine serait un minimum, voire un mois pour être sûr ou alors il 
> faudrait limiter le travail à l'hexagone.
>
> Pieren
Ok je comprends mieux.
Pour l'instant on se limite à la France même si je teste sur le planet 
pour comprendre ce que c'est de traiter 150 Go d'Xml et essayer de 
trouver des solutions viables. De toutes manières 1 semaine, ... 1 mois, 
qu'importe, rien presse et tout sera finalement traité si on va au bout.
Benoît R.


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

Re: [OSM-talk-fr] Noeuds orphelin en France

Etienne Chové a écrit :
> Le 09/06/2010 14:02, Benoît ROUSSEAU a écrit :
>> Ce qui peut t'intéresser c'est l'ago :
>> [...]
>
> Je parle un peu C#, mais l'algo suffit s'il correspond à ce qui est 
> codé. Ça semble clair et bon.
C'est celui de Julien B.
>
> Il faut aussi réfléchir aux effets de bord : si l'extrait déborde à 
> l'étranger certains pourraient ne pas être content.
Moi je seari content qu'on vienne faire le ménage chez moi 
:p.
> Pour controler qu'un point est en France, soit il faut un extrait qui 
> ne déborde pas (pour ça il faut voir avec Pieren s'il peu te fournir 
> ça), soit il faut un polygone de la France et tester l'appartenance 
> (je peux essayer d'en faire un). Je pense que NetTopologySuite doit 
> pouvoir t'aider à faire ça en C#. Demande à yoann qui l'utilise 
> courament.
Ok, avant de demander je vais réinventer la roue pour voir que c'est une 
bonne idée et que d'autre le font mieux que moi. Pas la peine de réagir, 
c'est ma manière de faire et de m'approprier les pourquoi et comment, de 
savoir pourquoi ce n'est pas si simple que ça en a l'air, ... Donc je 
reviendrai vers les personnes citées dans peu de temps :p. Mais je 
saurai pourquoi.
>
>> Euh oui :) merci.
>
> Si tu génères un fichier xml bien formaté, c'est immédiat. Il faut que 
> le format corresponde à ça :
>
> 
> 
>   
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
>   [...]
> 
>
> Ensuite tu le met sur un site (non compressé, ou compressé en bz2 ou 
> gz) et tu me donnes l'url, je te donnerai la procédure pour l'afficher 
> sur une carte.
Ok j'abandonne le CSV pour te sortir le format xml qui va bien.

Benoît R.

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

Re: [OSM-talk-fr] Conseils d'enfants et de jeunes

Vincent Pottier a écrit :

Le 09/06/2010 10:46, Ab_fab a écrit :

Je viens de découvrir l'existence de l'ANACEJ, Association Nationale
des Conseils d'Enfants et de Jeunes.
http://fr.wikipedia.org/wiki/Association_nationale_des_conseils_d%E2%80%99enfants_et_de_jeunes
A mon avis, cela peut être un relais intéressant vers les jeunes tout
d'abord, mais aussi les élus locaux et l'éducation nationale pour
organiser des mapping parties de communes.

Dans le même ordre d'idée, samedi soir, j'ai parlé d'OSM devant quelques
personnes. Une instit (pardon, professeur des écoles) m'a demandé si
elle pouvait organiser une mapping party avec ses élèves.
J'ai évoqué quelques outils : walking-paper, osmecum... et la difficulté
que doit être la saisie de l'information récoltée. Mais sans avoir
expérimenté la faisabilité.
Ce serait intéressant de parler d'expériences de cartographie avec les
enfants, dans un cadre scolaire ou péri-scolaire.
Quelqu'un a de l'expérience ?

Que pensez vous du principe d'une tentative de prise de contact avec
cet organisme ?
Pour la façon de faire, on pourra discuter par la suite
C'était l'idée en l'air du jour ^^

Bien belle idée...

Bonne journée

De même.
--
FrViPofm

A un moment où nous parlions de photographies aériennes qqun avait
envoyé un lien avec des ballons à hélium fait en sacs poubelle. Le
projet qui fait ça bosse avec des enfants et ils en parlent sur leur
site (de tête il map des bidonvilles, ...), il font des maquettes de
leur maison avec les enfants, les positionnent sur une carte papier,
Je n'ai plus le lien en tête à rechercher ya ptet des idées
d'approche du sujet...

Benoît R.

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

Re: [OSM-talk-fr] /!\ URGENT /!\ Reportage sur OSM pour France Télévision Aix en Provence Jeudi

Bravo !
Benoît R.

RatZilla$ a écrit :
> Bonjour à Tou[te]s
>
> Voilà c'est fait le reportage est en ligne, j'ai fait au mieux :
>
> * Micro mapping party
> * Un peu de cadastre
> * Un peu de CrisisCamp
> * Vulgarisation, pas de termes trop techos'
>
> Le tournage a duré la journée, c'est un exercice un peu
> différent,prise et reprise de séquence.
> C'est facile de parler d'OSM, bcp moins de parler de soi.
> Mais les deux ravissantes journalistes m'ont vite fait oublier les difficultés
> ;-)
> ;-D
>   
>>> ;-)
>>>   
>
> Gros Bisous à elles ;-)
>
> Début du reportage à 8:50
>
> http://info.francetelevisions.fr/video-info/player_html/index-fr.php?id-video=tvradio_guadeloupe_20100607_350k_150k_07062010072804_RFO&chaine=&id-categorie=&ids=&timecode=false&sequence=false#navVdoPlayer
>
> A Bientôt ... Sur Canal  ... ;-)
> Mr Denisot si vous lisez cette ML n'hésitez pas à nous contacter ;-)
>
> Gaël
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>   
> 
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.829 / Base de données virale: 271.1.1/2927 - Date: 06/09/10 
> 08:35:00
>
>   


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

[OSM-talk-fr] Retours d'infos sur l'extraction des noeuds orphelins





Pour ceux que ça intéresse...

Le fichier pour Étienne : http://arduinodezero.hautetfort.com/files/results.zip

Pour information... Ca peux vous donner des ordres d'idées sur les
données et vous aider à préparer des programmes, ...

Donc j'ai relancé une extraction depuis le fichier France disponible
aujourd'hui sur Geofabrik ici : http://download.geofabrik.de/osm/europe/
. Dézippé le fichier France.osm fait 8 095 744 000 octets (les Go
varient selon les systèmes).

Sur ma machine d'hypermarché à 180€ (Athlon 64 x2 5000+ 2,6 GHz), en
temps de traitements ça donne :

* PREFILTER and SPLIT - computed
in 0:6:33 *
> 6m33 pour filtrer et séparer les
nodes/ways/relations
en trois fichiers à partir du fichier source France de 8 Go.
> L'application dans son ensemble utilise 7Mo de mémoire.

* EXTRACT NOT TAGGED NODES - start at 02:16:32 *
17339081 not tagged nodes collected.
* EXTRACT NOT TAGGED NODES - computed in 0:1:37 *
> 1m37 pour extraire du fichier nodes filtrés (2
Go) les noeuds sans tags.
> Utilise 7Mo de mémoire.
> j'obtiens 17 339 081 nodes sans tags dans un fichier qui pèse
moins d'1 Go

* LOAD UID NODES'S LIST IN MEMORY - start at 02:18:09 *
17339081 uid loaded.
* LOAD UID NODES'S LIST IN MEMORY - computed in 0:0:34 *
> 34 secondes pour charger cette liste en
mémoire triée et indexées sur les n° de ligne
> Il y a 17 339 081 de noeuds sans tags
significatifs en France
> Utilise maintenant environ 150 Mo de mémoire

* LOAD UID WAYS'S NODES LIST IN MEMORY - computed in 0:2:20 *
> 2m20 pour charger en mémoire la liste triée
des UID des nodes référencés dans le fichier ways qui pèse environ 1,3
Go 
> on monte à 1,12 Go de mémoire utilisée c'est le max ensuite ça
descend trop vite pour que je note

* SUPRESS NODES REFERENCED BY WAYS - computed in
0:1:48 *
> 1m48 pour supprimer de la liste des noeuds
vierges ceux référencés par des ways
> à la fin il ne reste que 6 936 noeuds
vierges en liste

* LOAD UID RELATIONS'S NODES LIST IN MEMORY -
computed in 0:0:1 *
> 1 seconde pour charger en mémoire la liste des
noeuds référencés par des relations
> il ne doit pas il y en avoir beaucoup... et le fichier ne pèse
"que" 54 Mo
> ou j'ai une erreur dans le code :)

* SUPRESS NODES REFERENCED BY RELATIONS - start
at 02:22:54 *
6865 now in nodes list.
* SUPRESS NODES REFERENCED BY RELATIONS - computed in 0:0:0 *
> moins d'une seconde pour enlever de la liste
des noeuds vierges ceux référencés par des relations
> à l'issue du traitement il reste 6 865 noeuds "orphelins"
> la suppression de l'import Roman à bien enlevé environ 35 000
noeuds orphelins.

* XML RESULTS EXPORT - computed in 0:0:10 *
> 10 secondes pour à partir des 6 865 uid des
nodes constituer le fichier d'export au format pratique pour Etienne.
C'est à dire aller retrouver les informations lat et lon des noeuds, à
partir de leur UIDs, dans le fichier xml des 17 millions de noeuds
vierges.
> je l'ai mis pour vous donner une idée des pbs... Au départ j'avais
traité le pb comme je fais d'habitude en 1/4 d'heure. Mais au bout de 2
heures, l'export n'en était qu'au tiers pour 7 000 noeuds ! Une astuce
et ça passe à 10 secondes.

Il faut, au total, à l'application : 13m03s pour obtenir la liste dans
les conditions évoquées. Sachant que la partie filtrage et partage qui
consomme à elle seule la moitiée du temps n'est pas nécessairement à
répéter pour chaque traitement.

Pour ma part je pense qu'il est souvent inutile de se trainer
l'ensemble des tags pour tous les éléments, je réduis les noeuds à
uid/lat/lon considérant que je peux retrouver l'info complète par la
suite. A ce propos j'émets l'hypothèse que ce filtrage et séparation en
fichier des éléments permet de travailler mieux et plus vite (même en
restant ou surtout en restant en XML) et que même pour l'import en base
on y gagne au final. Mais voilà ni Julien ni moi même n'avons fait
l'essai avec une base. Ca reste donc théorique ! Si quelqu'un à des
élément à ce sujet... nous sommes preneurs. Ensuite, je verrai à
convertir le fichier noeuds en binaire pour attaquer ce genre de
traitement sur un planet mais déjà ça fonctionne aux dimensions de la
France.

Benoît R.







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

[OSM-talk-fr] Nettoyage post-import Romans / Noeuds orphelins

Bonjour,

J'échantillonnais les résultats de détection des noeuds orphelins 
pour voir s'il n'y à pas d'erreurs... et je tombe sur 
http://www.openstreetmap.org/browse/node/763365142 donc le travail de 
nettoyage post-import Romans n'est pas terminé...

Benoît R.

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

[OSM-talk-fr] Noeuds orphelins j'y suis :)

2010-06-10 Par sujet Benoît ROUSSEAU

Allez ! Pour la bonne humeur : je suis dans la liste des noeuds 
orphelins à 2 reprises comme ici  
http://www.openstreetmap.org/browse/node/687500834 .

Benoît R.

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

Re: [OSM-talk-fr] Géovélo & Travaux temporaires

2010-06-10 Par sujet Benoît ROUSSEAU


Eric Marsden a écrit :

"br" == Benoît ROUSSEAU  writes:



  br> traffic en utilisant OSM en sous couche pour un rendu avec
  br> OpenLayers OUI. Ce serait même super bien. Mais je ne vois qui va
  br> passer sa vie à la fenêtre ou scruter les infos pour saisir des
  br> embouteillages possibles toutes les 15 min.

  Il est possible de générer automatiquement des données sur les temps
  moyen de trajet et les bouchons, comme le font par exemple Google Maps
  et Waze sur les mobiles.

  Il existe des projets en cours pour collecter ce type de données et
  les intégrer à des outils de routage pour OSM, par exemple
  
   http://wiki.openstreetmap.org/wiki/Routing/Travel_Time_Analysis

   http://wiki.openstreetmap.org/wiki/Average_speed_per_way
  
  



+1

Je connaissais "ASPW", et je n'y avait vu que la détermination des 
vitesses autorisées. Mais il vrai qu'a force de données on peut 
déterminer en chaque point, la vitesse moyenne à chaque heure de chaque 
jour de l'année. Cequi fluctue en fonction des ralentisseurs, des jours 
fériés, des zones de vacances scolaires, ...


Et je me disais aussi que, finalement, les travaux sur la voirie sont 
déclarés en mairie puisque qu'un arrêté municipal est produit. 
M'étonnerai qu'ils travaillent sur fiches bristol. Ainsi ils pourraient 
ouvrir ces données au même titre que d'autres.


Quant au dates de fin prévues mais rarement respectées et bien il 
suffirait de les tagguer "prévues" comme c'est le cas sur les panneaux 
réels et ne mettre à jour qu'en fonctions des observations et des 
données mairies qui signaleraient la fin effective des travaux et 
signerai l'arrêt de mort des tags en question.


Du même coup le côté local serait intéressant pour créer un précédent et 
engager les autres institutions jumelles ou autre à emboiter le pas. Le 
local prendrait ainsi un intérêt national.


Avec de telles solutions en place cela devient envisageable. Où en sont 
les projets cités ? Participation des mairies ?


Alors les porteurs du projet c'est pas beau ? Un pessimiste retourné en 
2 jours (sous réserve que ce soit travaillé dans l'ordre pour ma part). 
Mais c'est du boulot et la manière d'aborder les choses changerait 
radicalement.


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

Re: [OSM-talk-fr] Rencontre & Négociation Fédé ration Française de Randonnée Pédestre -- GR etc . ..

2010-06-11 Par sujet Benoît ROUSSEAU

Rodolphe Quiedeville a écrit :
> Pieren a écrit :
>   
>> 2010/6/11 RatZilla$ mailto:ratzil...@gmail.com>>
>>
>> Il n'était pas au courant de nos
>> sollicitations précédentes.
>>
>>
>> Ouais bon. C'est toujours pareil. Si le courrier/courriel n'est pas
>> adressé directement à la bonne personne, ça se perd rapidement dans les
>> méandres administratives pour finir en classement vertical.
>> Je t'enverrais une copie de ma demande de l'année dernière avec la
>> réponse "on vous répond d'ici 15 jours"  si tu le souhaites.
>> Sinon c'est une bonne nouvelle si un partenariat peut se mettre en
>> place. J'ai aussi dit sur cette liste que nous avions nos chances sur ce
>> coup-là. Après tout, la FFRP compte aussi beaucoup sur ses topoguides
>> qui sont un vrai travail d'auteur, d'avantage que de simples tracés
>> d'itinéraire archi-connus dont l'originalité (condition nécessaire pour
>> être protégé par le droit d'auteur) est parfois difficile à défendre.
>> 
>
> A propos de ces courriers, quand les destinatires sont joignables
> publiquement (ie coordonnées et nom publiés sur des sites web) pourquoi
> ne pas faire des lettres ouvertes ? Avec l'effervescence au sujet de
> l'OpenData cela pourrait faire un effet de levier interessant, non ?
> Nous pourrions publier l'ensemble de ces courriers sur un site dédié
> genre lettres-ouvertes.openstreetmap.fr histoire de communiquer autour
> de cette initiative.
>
> A++
>
>   
+1

Benoît R.


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

Re: [OSM-talk-fr] Des licences libres pour concilier i nnovation sociale et économique

2010-06-14 Par sujet Benoît ROUSSEAU

Thomas Gratier a écrit :
> Bonjour,
>
> Des réflexions intéressantes sur les licences
> L'illustration est pas mal en ce contexte d'interrogation sur la 
> libération de données
>
> *Des licences libres pour concilier innovation sociale et économique*
> http://owni.fr/2010/06/14/des-licences-libres-pour-concilier-innovation-sociale-et-economique/?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+Owni+(Owni)&utm_content=Twitter
>  
> 
>
> ThomasG
> 
Bonsoir,
C'est article est très intéressant et synthétique. Merci de l'avoir 
porté à notre connaissance.
Benoît R.

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

[OSM-talk-fr] Plus d'OSM :(

2010-06-14 Par sujet Benoît ROUSSEAU





Bonjour,

Il 4h46 et pas d'autre réponse sur http://www.openstreetmap.org/ et
l'API que :


Application error

The OpenStreetMap server encountered an unexpected condition that
prevented it from fulfilling the request (HTTP 500)
Feel free to contact the
OpenStreetMap community if your problem persists. Make a note of the
exact URL / post data of your request.
This may be a problem in our Ruby On Rails code. 500 occurs with
exceptions thrown outside of an action (like in Dispatcher setups or
broken Ruby code)



Espérons qu'il n'y a rien de grave...

Benoît R.










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

Re: [OSM-talk-fr] rendu bizarre

2010-06-18 Par sujet Benoît ROUSSEAU

Vincent Pottier a écrit :
> Le 18/06/2010 11:23, Cedric Dumez-Viou a écrit :
>   
>> Bonjour,
>>
>> Je crois qu'il faut surtout laisser du temps à ceux qui sont en train
>> d'importer le polygone géant ;)
>> Il est découpé en carrés de 0.3° et la bande que l'on voit est la
>> frontière importé/non-importé.
>>
>> Cedric
>>
>> 
> Gagné !
> Il reste 80 morceaux à importer sur plus de 450.
>
> On ne peut pas passer inaperçu ;-)
>
> Patience.
>
> Des candidats pour les autres polygones ?
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Op%C3%A9rations_post-import#Liste_des_polygones_.C3.A9normes
> --
> FrViPofm
>   

Oui moi M'sieur !

Mais j'ai regardé du côté des


  Préalables

* Avant d'importer un polygone CLC dans OSM, il faut savoir pourquoi
  celui-ci n'a pas été importé.
* Il ne suffit pas qu'une zone soit vide pour la remplir ! Une
  connaissance du terrain est souvent indispensable !
* Des données OSM peuvent être de meilleur qualité (précision ou
  information) qu'un polygone CLC.

Et j'avoue que contrôler tout ça sur de telles surfaces me rebute. Car 
ai je bien compris ? Il faut regarder pour chaque sous polygone s'il est 
opportun de l'importer. Si ce n'ai pas le cas, cela vaudrait le coup de 
scripter l'import, on gagnerai du temps.

Benoît R.


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

[OSM-talk-fr] Noeuds orphelins la suite...

2010-06-18 Par sujet Benoît ROUSSEAU

Bonjour,

Je viens de terminer la suppression automatique des 2010 plus anciens 
noeuds orphelins répertoriés le 9 juin dernier. On à au moins gagné deux 
cathédrales équivalent points :p.

Dites moi si les changements ont posés des problèmes, j'ai gardé des 
traces au cas ou...

 Pour infos 

L'utilisateur utilisé pour la suppression est nommé SeaSharkBot.

Suite à une erreur dans mon code, le programme à tenté de supprimer plus 
de 1000 fois les 50 premiers nœuds. Ne vous étonnez pas de trouver un 
paquet de changeset vides, s'il ne sont pas automatiquement supprimés, 
mais c'est sans conséquence.

Ca dépends de la charge des serveurs, de ma connexion, ... Mais, en 
gros, pour synchroniser les 2000 nœuds avec l'API il faut compter 4 
minutes soit environ 12 dixièmes de seconde par nœud. Puis il faut 
environ 8 minutes et 30 secondes pour créer ouvrir les 40 changeset de 
50 actions d'effacement et les fermés. Aucune erreur ou tentative de 
supprimer un point finalement rattaché ou déjà effacé.

Ce qui veux dire, pour bientôt, une deuxième API C# (avec celle 
d'Émilie). C'est robuste et ça fonctionne, mais j'attends d'avoir 
implémenté l'essentielle des fonctions avant de publier.

 

Benoît R.

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

Re: [OSM-talk-fr] Noeuds orphelins la suite...

2010-06-18 Par sujet Benoît ROUSSEAU

Bonjour,

Intéressant comme retour, ça donne une idée, c'est noté. Pour mon 
premier essai un fractionnement en tranches de 50 me permettait de 
suivre au plus prêt le déroulement (par exemple les pbs de suppression 
de x000 fois les même points).

Questions supp. :
   
Le serveur de dev. semble se comporter de manière différente du 
serveur de prod à plusieurs niveaux :
- les tuilles ne semblent jamais mise à jour même avec un /dirty,
- seuls les ajouts semblent retournés, comme si le serveur était 
vide.
Ce qui est déroutant au premier abord.

Je me disais donc, que sur le serveur de dev, le rendu était fixe 
(peut-être celui de la base prod) et la base vide (ne reprend pas la 
base prod).
Est-ce la bonne interprétation ?
   
Existe t'il des serveurs de dev "Sandbox" avec rendu (même si c'est 
du luxe) ?

Benoît R.

Pieren a écrit :
> 2010/6/19 Benoît ROUSSEAU  <mailto:adressepossi...@free.fr>>
>
> Tu devrais augmenter la taille de tes changeset. 50 edits, c'est pas 
> beaucoup. J'ai constaté qu'autour de 1000 à 2000, ça tournait encore 
> assez bien.
>
> Pieren
>
> 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>   
> 
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.829 / Base de données virale: 271.1.1/2946 - Date: 06/18/10 
> 08:35:00
>
>   


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

Re: [OSM-talk-fr] Import semi-automatique du bâti

2010-06-19 Par sujet Benoît ROUSSEAU





Frédéric Rodrigo a écrit :

  Le 19/06/2010 02:39, sylvain letuffe a écrit :
  
  
Le samedi 19 juin 2010 01:18:34, V a écrit :
Et au fait, j'entends cadastre et vectoriel, et j'en salive, l'indisponibilité
du site du cadastre m'empêche de vérifier dans quel menu biscornu est pû se
trouver cet export PDF que j'enrage n'avoir pas découvert plus tôt.

Je suis particulièrement intéressé de voir ce qu'on y trouve en vectoriel...

cours d'eau ?
limites de commune ?

J'ai comme la vague impression qu'un temps énorme a été "perdu" à faire de la
reconnaissance d'image, du clic clic frénétique sur du bitmap alors que tout
ça est peut-être disponible en vecto dans ce fichu pdf.

Pitié, répond non pour la santé mentale d'un certain P et d'un autre
F... R et de moi même ;-)

  
  Je te remercie de te soucier de ma santé ;)

Je connaissais déjà l'existence de l'export en PDF. J'en avait fait 
mention sur le wiki en janvier 2009... Par contre j'en mettrai presque 
ma main à couper d'avoir vérifié ce qu'il contenait (càd une image). Le 
paramétrage du serveur a-t-il changé ? (le SVG est peut être de retour ;) )
Quoi qu'il en soit. Suite à la vectorisation des rasters des limites 
administratives j'avais pu constater que la version SVG était de 
présiction moindre. Je ne serrais pas dire si c'était dû au zoom.

Quoi qu'il en soit cette générosité des PDF pourrait ne pas durer.

Fred

Bonsoir,

    Fred je confirme...

    Je n'osais pas en parler, de peur d'avoir rêvé. Mais j'avais moi
aussi tenté de passer par le Pdf en mars 2010  lors de mes début sur
OSM. Sur Poitiers le Pdf contenait une image. Est-ce une évolution ?
Est-ce lié à certaines zones qui sont présentées selon en images ou en
vectoriel ?

Benoît R.



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

[OSM-talk-fr] Import bâti...

2010-06-22 Par sujet Benoît ROUSSEAU

Bonjour,

Merci à V. J'adore ce côté "je fais le Graal avec des briques lego" en 
50 lignes. Simple, efficace et pas hors de portée d'utilisation (ça 
tourne sous Vista dans une MV). Il y a quelque chose de magique :).

Par contre, le côté frustrant c'est qu'il faut tout retoucher autour des 
bâtiments (les tracés des pionniers au GPS, ...) :p, mais, c'est une 
très bonne chose au final car une fois la bâti en place on est tenté 
d'aménager les alentours. Et puis on visite des zones qui auraient 
attendues plusieurs années notre passage.

Rousseau B.

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

Re: [OSM-talk-fr] Import semi-automatique du bâti

jul...@krilin.org a écrit :
>
> oui, bravo a tous, j'enrage juste que mon modem ai choisi ce moment pour
> griller...
>
>   
:p. la haine !

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

Re: [OSM-talk-fr] [bâti] Explosion


> C'est sûr que l'import du bâti va avoir un gros impact. Une rue c'est 
> quelques points, mais avec une dizaine de bâtiments de chaque côté 
> ayant au moins 4 points, ça fait facilement une centaine de 
> points/ways en plus donc un facteur qui peut tourner autour de 100 
> fois plus d'infos !
>
> Faudra se plaindre au papa du tag building=yes !
Et son frère du tag wall=no !
C'est un troll ne pas répondre.

Benoît R.

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

[OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !

Bonjour,

Pour ceux qui bossent sur la Vienne ! TI_DIC STP !

Les imports sont décalés et non nettoyés ! Y a un protocole ! Le 
respecter autant que possible ! OUI c'est 110 maison à passer à la main 
pour ,ettoyer et ça prends du temps. Oui il faut recaler les bâtis 
Buxerolles tout est importé décalé sans être nettoyé ! Oui il faut 3 
heures pour en nettoyer un tiers mais zut ! On ne va pas faire et 
refaire tout le temps ! Je m'apprêtais à envoyer 1/3 correct et c'est 
mort ! J'espère ne pas avoir à décaler 50 communes !

Benoît R.



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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !





Steven Le Roux a écrit :
Et ajouter chaque import dans le "import catalog" sur le
wiki ;)

C'est le "Suivi des imports" ? Si c'est ça je
le fais... no problemo, je n'avais pas vu le changement en bas de page.


  
  2010/6/23 Benoît ROUSSEAU <adressepossi...@free.fr>
  Bonjour,

Pour ceux qui bossent sur la Vienne ! TI_DIC STP !

Les imports sont décalés et non nettoyés ! Y a un protocole ! Le
respecter autant que possible ! OUI c'est 110 maison à passer à la main
pour ,ettoyer et ça prends du temps. Oui il faut recaler les bâtis
Buxerolles tout est importé décalé sans être nettoyé ! Oui il faut 3
heures pour en nettoyer un tiers mais zut ! On ne va pas faire et
refaire tout le temps ! Je m'apprêtais à envoyer 1/3 correct et c'est
mort ! J'espère ne pas avoir à décaler 50 communes !

Benoît R.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
  
  
  
  
  
-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB <ste...@le-roux.info>
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
  

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


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.829 / Base de données virale: 271.1.1/2956 - Date: 06/22/10 20:36:00

  





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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !





Tenshu a écrit :
Je croit qu'un message aux uploaders sera nettement plus
efficace.

J'suis pas certain qu'il consulte plus sa boite osm que la page
d'import semi auto" ou la liste. J'm'en va essayer après dèj. Ca va
être galère... :p.
Bon, en tout cas, TI_DIC j'vais pas te bouffer il faut juste qu'on se
coordonne donc t'as mon adresse, contacte moi.

Benoît R.

  2010/6/23 Benoît ROUSSEAU <adressepossi...@free.fr>
  Bonjour,

Pour ceux qui bossent sur la Vienne ! TI_DIC STP !

Les imports sont décalés et non nettoyés ! Y a un protocole ! Le
respecter autant que possible ! OUI c'est 110 maison à passer à la main
pour ,ettoyer et ça prends du temps. Oui il faut recaler les bâtis
Buxerolles tout est importé décalé sans être nettoyé ! Oui il faut 3
heures pour en nettoyer un tiers mais zut ! On ne va pas faire et
refaire tout le temps ! Je m'apprêtais à envoyer 1/3 correct et c'est
mort ! J'espère ne pas avoir à décaler 50 communes !

Benoît R.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
  
  
  
  
  
-- 
Mon weblog - http://www.tenshu.fr/
Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
  
  
  

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


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.829 / Base de données virale: 271.1.1/2956 - Date: 06/22/10 20:36:00

  





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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !

Vincent de Chateau-Thierry a écrit :

De : "Emilie Laffray"

Peut être contacter les personnes par OSM Mail serait plus efficace :)

Bien sûr, mais le publier ici est aussi, je pense, salutaire pour rappeler quelques bonnes
pratiques vue la frénésie du moment.

Et en avertir d'autres au passage car il pas certain que ce ne soit pas
décalé par ailleurs aussi. Je me suis rendu compte du décalage que
parce que j'ai vérifié avec le plugin Cadastre.
Bon ce n'est pas la mort, c'est environ 50 cm (ça ressemble au décalage
de l'ancienne version du plugin Cadastre) mais c'est le bazar ensuite
pour les autres tracés, ... C'est surtout les bâtiments chevauchant qui
me gênent, car c'est long et pénible (des heures) à corriger. Ca me
ferai vraiment CH de repasser derrière dans 50 communes.

Benoît R.

Je continue de plaider pour un import par +/- pâtés de maisons. C'est l'unité que j'ai
adopté pour mes ajouts depuis hier, et j'aurais du mal à faire plus gros en gardant
une vision de ce que je fais. Alors ça ira beaucoup moins vite, bien sûr, mais on ne fait
pas la course, ou alors je ne sais pas contre qui (et je ne veux pas le savoir :-)). Et au
final dans qq jours/semaines/mois on aura quoi qu'il arrive donné un coup de boost
aux buildings sur la France, en comparaison du rythme qui se serait poursuivi sinon.

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

Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr
Version: 9.0.829 / Base de données virale: 271.1.1/2956 - Date: 06/22/10 20:36:00

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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !

Christian Quest a écrit :
> Le 23 juin 2010 12:00, Vincent de Chateau-Thierry  > a écrit :
>
>
>
> > De : "Emilie Laffray"
> >
> > Peut être contacter les personnes par OSM Mail serait plus
> efficace :)
>
> Bien sûr, mais le publier ici est aussi, je pense, salutaire pour
> rappeler quelques bonnes
> pratiques vue la frénésie du moment.
>
> Je continue de plaider pour un import par +/- pâtés de maisons.
> C'est l'unité que j'ai
> adopté pour mes ajouts depuis hier, et j'aurais du mal à faire
> plus gros en gardant
> une vision de ce que je fais. Alors ça ira beaucoup moins vite,
> bien sûr, mais on ne fait
> pas la course, ou alors je ne sais pas contre qui (et je ne veux
> pas le savoir :-)). Et au
> final dans qq jours/semaines/mois on aura quoi qu'il arrive donné
> un coup de boost
> aux buildings sur la France, en comparaison du rythme qui se
> serait poursuivi sinon.
>
> vincent
>
>
>
>  OSM mail envoi un "vrai" email au mappeur... donc il devrait être 
> prévenu de façon plus ou moins certaine.
> 
Je ne savais pas. C'est noté merci Christian.
Benoît R.

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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !





Pieren a écrit :
Même si 50cm, c'est pas la mort, il serait intéressant de
comprendre la raison de ce décalage.

Ca donne ça pour la commune de Buxerolles (86) et toutes les autres que
j'ai vu aussi d'ailleurs :


Pour l'instant, je n'ai regardé que sur Paris et il n'y
pas de décalage notable.
Le script doit utiliser la grille de conversion ntf sinon on aurait
beaucoup plus que 50cm. Ca reste donc probablement un problème
d'arrondi, soit à l'export PDF (et on ne peut rien faire), soit dans le
script et il pourrait/devrait être amélioré pour éviter de futurs
problèmes dans le suivi du cadastre.

Il faudrait que je regarde si c'est uniforme pour déjà traité les
fichiers actuels en batch et pas via un décalage souris très très long
par approximations successives sous Josm

Benoît R.


Pieren
 
  

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


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.829 / Base de données virale: 271.1.1/2956 - Date: 06/22/10 20:36:00

  




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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !





simon a écrit :

  Je retrouve l'erreur uniquement en lambert 4 zones (sur la vienne zone
2)

  

Bah on fera avec :p c'est toujours plus rapide qu'a la main. Merci.
Benoît R.


  Le mercredi 23 juin 2010 à 14:30 +0200, Pieren a écrit :
  
  
Même si 50cm, c'est pas la mort, il serait intéressant de comprendre
la raison de ce décalage.
Pour l'instant, je n'ai regardé que sur Paris et il n'y pas de
décalage notable.
Le script doit utiliser la grille de conversion ntf sinon on aurait
beaucoup plus que 50cm. Ca reste donc probablement un problème
d'arrondi, soit à l'export PDF (et on ne peut rien faire), soit dans
le script et il pourrait/devrait être amélioré pour éviter de futurs
problèmes dans le suivi du cadastre.

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
  
  


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.829 / Base de données virale: 271.1.1/2956 - Date: 06/22/10 20:36:00

  





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

Re: [OSM-talk-fr] Import du bati du cadastre - upload arrêté au milieu du gué

Pieren a écrit :
> Relance l'upload tout simplement. Le nombre d'edits restant devrait 
> avoir considérablement diminuer (les ways arrivent à la fin). Me 
> traine pas trop, certaines personnes pourraient effacer tes nodes 
> isolés et ça pourrait empêcher JOSM de créer des ways. Et surtout, ne 
> ferme pas JOSM entre temps.
>
> Pieren
Bonjour,
En plus de quand on supprime à la main...
Concernant les noeuds orphelins :
- j'ai des pb pour uploader mon fichier (pb de blog) de résultats pour 
ensuite mettre à jour la carte sur Osmose (sans publication préalable 
pas de suppression)
- je ne ferai aucune suppression de points réçents durant l'import 
massif du bâti étant donné les pbs rencontrés,
- ca va nettoyer pas mal de choses ensuite par contre :p.
Benoît R.

>
> 2010/6/23 OSM Léon mailto:osm.l...@gmail.com>>
>
> J'ai essayé d'envoyer le gros fichier du 19e que j'ai en stock via
> JOSM en scindant en envois de 500 objets. Las! il s'est arrêté
> vers les 90% (erreur Bad Gateway). OSM est peuplé dans le 19e de
> points isolés dont quelques uns sont reliés par des chemins qui
> figurent des batiments. Que puis-je faire pour reprendre un upload
> propre ?
>
> Pour info, le changeset en cause est le 5059771 qui devait se
> faire en 80 envois
>
> Thomas
>
> ___
> 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
>   
> 
>
>
> Ce message entrant est certifié sans virus connu.
> Analyse effectuée par AVG - www.avg.fr 
> Version: 9.0.829 / Base de données virale: 271.1.1/2958 - Date: 06/23/10 
> 13:11:00
>
>   


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

[OSM-talk-fr] Il est possible de tester avant de faire...

Bonsoir,

Pour tous les essais Bulk_upload, ... outils de JOSM, ... n'oubliez pas 
qu'il existe un serveur de dev où il est vraiment rassurant de pouvoir 
essayer des méthodes et des outils en bac à sable. Après tout c'est fait 
pour ça.
Vérifier sous JOSM car il n'y a pas de carte tuillé de dev.

Benoît R.


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

Re: [OSM-talk-fr] /!\ Import bâti et noeuds dupliqu és /!\





julien balas a écrit :

  Sébastien Dinot wrote:
  
  
Christophe Merlet a écrit :


  Je constate que l'import du bâti multiplie les explosion de nœuds
dupliqués à travers la France.
  

Je me trompe où ça commence à devenir du grand n'importe quoi cet import !

  
  
On est dans un processus itératif d'ajout de données intéressante puis 
de nettoyage de données en trop, ca ne me choque pas.

C'est sur que si on fait bien du 1er coup c'est mieux, mais bon...

  

Hum... bah pour la corrections itératives à la main sur 10.000 ways
décalés, dupliqués, ..  t'es le bien venu :p.

Je suis partisan d'ajouter un tag comme
ISMBversion="X" à tous les nœuds générés par le script selon sa version.

Ainsi nous pourrions intervenir sur de larges zones pour appliquer des
corrections automatiques plus simplement. Une fois une zone validée, on
vire les tags. Nous pourrions plus facilement traiter les travers de
cet import plus facilement, ne chercher les noeuds dupliqués que sur
les import bâti semi auto, ... sans gêner les autres imports (CLC,
...), ... et ainsi être plus réactifs.

Geofabrik offre pour la France des découpages par région que nous
pourrions utiliser comme base pour nettoyer et valider de temps à
autres. Actuellement il est difficile d'isoler les éléments importés
automatiquement sinon en regardant les imports par unités de temps.

Benoît R.




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

[OSM-talk-fr] Les adresses...

Bonjour,

Le bâti sera importé coûte que coûte et cela aura pour avantage que 
le tracé des voies urbaines et l'adressage va avancé. Mais je suis 
bloqué quant à l'adressage alors que c'est à mon avis un enjeu majeur 
(routage, ...).

J'ai consciencieusement regardé les pages 
http://wiki.openstreetmap.org/wiki/FR:Key:addr et 
http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema.
 
J'ai testé le méthodes... regardé en Allemagne ce qui se faisait, ... 
j'ai testé le greffon d'adressage et au final je ne sais que faire !

Je suis tenter par deux solutions :
- "Associating a building-polygon with a street" pour les maisons 
individuelles,
- et "Associating a node with a street" pour le bâtiments ayant 
plusieurs entrées.

Je suis preneur de vos remarques et de vos habitudes. Je pense qu'il 
serait bon de nous déterminer sur un "A minima" afin d'offrir une vision 
claire et exploitable de l'adressage au nouveaux venus et faire 
progresser l'adressage.

Je mettrai ensuite les pages FR, qui concernent les adresses, à jour 
avec les recommandations qui dégagent un consensus.

Benoît R.
   

   

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

[OSM-talk-fr] Import bâti : un ordre d'idé e pour ceux qui voudrait se lancer...





Pour l'import d'une petite commune où il n'y avait aucun bâti
existant mais une rivière. Le tout représentant environ 32.000
objets.

Hors exécution du script d'import semi-auto, sans nécessairement faire
tout parfaitement (la rivière peut être un pb.); ça donne tout de même :
- nettoyage des données brutes : 3 h. 34 min.
(chevauchements, croisées, ...) ;
- chargement vers le serveur (upload) des données avec JOSM : 36
min. ;
- nettoyage après la fusion : 40 min..

Donc 4 h. 50 min. au total pour : (zone dense de l'import)
http://www.openstreetmap.org/?lat=46.63781&lon=0.17321&zoom=16&layers=B000FTF

Je n'ose pas attaquer la préfecture de front sachant qu'il y a déjà de
l'existant ! On va voir ça par pâté de maisons. Mais il va falloir que
je code un programme pour l'éclatement des données brutes avant ; parce
que sous JOSM c'est galère. 

Benoît R.






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

Re: [OSM-talk-fr] Re : Re : Import bâti : att ention, décalage !

Je confirme aussi que cela fonctionne ! Merci.
Benoît R.

THEVENON Julien a écrit :
> *De :* Pieren 
> **
> 2010/6/23 THEVENON Julien  >
>
> Je confirme ! chez moi en lambert 4 zones Zone 2 tout est
> parfaitement aligne apres avoir modifie le script !
>
> Julien
>
>
>
> Serait-il possible de mettre à jour les fichiers pointés par le wiki :
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents#Installation
>
> (pour éviter que le problème perdure) ?


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

Re: [OSM-talk-fr] Import bâti : un ordre d'idé e pour ceux qui voudrait se lancer...





Pieren a écrit :

  2010/6/24 Benoît ROUSSEAU <adressepossi...@free.fr>
  
Donc 4 h. 50 min. au total
pour : (zone dense de l'import)
http://www.openstreetmap.org/?lat=46.63781&lon=0.17321&zoom=16&layers=B000FTF



  
  
Je trouve ça un peu long. Est-ce que tu utilises le plugin validator et
la possibilité de "corriger" automatiquement les doublons ?
  
  
  

Moi aussi je trouve ça long :). Et je trouve que vous allez très vite.

Oui j'utilise validator et je n'ai que très peu de doublons. Pour le
reste c'est l'horreur, la bâtiments chevauchants en particulier et les
traîts de parcelles qui flinguent le bâti. Ce doit être lié aux
différentes qualités de numérisation selon les lieux et les opérateurs.
J'ai préparé des captures d'écrans avec les pb rencontrés, je vais
faire une page liée à celle de l'import semi auto.

J'ai bouclé Quincay qui est à côté en moins d'une heure. Du coup j'ai
commencé la rivière :p. Ce n'est pas prioritaire alors qu'il manque les
voies principales, mais j'avais envie d'apprendre.

Toujours est-il que si l'on souhaite prendre des précautions, dans
certains cas, cela peux prendre énormément de temps ! Mieux vaut être
prévenu. Les 35 min d'export JOSM ça change des habitudes par exemple.

Benoit R.




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

Re: [OSM-talk-fr] Les adresses...





Dominique Rousseau a écrit :

  Le Thu, Jun 24, 2010 at 03:01:46AM +0200, Benoît ROUSSEAU [adressepossi...@free.fr] a écrit:
  
  
Bonjour,

Le bâti sera importé coûte que coûte et cela aura pour avantage que 

  
  
Euh non, pas « coute que coute ».
Tu as même été le premier à dire halte au feu, parceque certains
morceaux sont fait "n'importe comment".
  

Nous sommes d'accord ; sauf que je reste sur le "coûte que coûte". :p
Ca va faire exploser les compteurs d'erreurs cette histoire.

  
Personellement, je ne vois toujours pas beaucoup d'interet à voir
dans la base OSM tous les batiments représentés individuellement (pour
l'habitat), en dehors des points d'adresse, ce qui est un débat et une
oeuvre en soi.
  

Oui et non pour les bâtis individuels, je ne relance pas le débat. Oui
pour les adresses.

  
Mais que celà « éclate » s'en donne à coeur joie, hein. Mais pas « coute
que coute ».
  

L'avenir nous le dira :p et les compteurs d'erreurs aussi.

  (par contre, si vous pouviez ne pas tout éparpiller dans 10 fils de
discussion différents :-)


  

Ah bah là aussi y a deux écoles :p. Pour ma part dès que ça s'éloigne
trop du sujet initial -> Séparation et nouvel objet. Là je ne veux
parler que des adresses parce que je trouve que c'est un sujet crucial
qui va devenir rapidement un nouveau problème avec l'import massif du
bâti. Si on repart sur 50 manières de coder les adresses dans les jours
qui viennent moi je pleure. Donc là justement j'aimerai séparer la
discussion de l'import bâti en lui même pour qu'on reste sur une idée
plus de 5 courriels d'affilé (challenge).




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

Re: [OSM-talk-fr] Les adresses...

Mathieu Arnold a écrit :
> +--On 24 juin 2010 03:01:46 +0200 Benoît ROUSSEAU
>  wrote:
> | Je suis tenter par deux solutions :
> | - "Associating a building-polygon with a street" pour les maisons 
> | individuelles,
> | - et "Associating a node with a street" pour le bâtiments ayant 
> | plusieurs entrées.
> | 
> | Je suis preneur de vos remarques et de vos habitudes. Je pense qu'il 
> | serait bon de nous déterminer sur un "A minima" afin d'offrir une vision 
> | claire et exploitable de l'adressage au nouveaux venus et faire 
> | progresser l'adressage.
>
> J'ai fait le XVème arrondissement[1] de Paris avec le plugin et son option
> d'interpolation, ou on trace un chemin, on selectionne le chemin et la
> route, on lui dit qu'au début du chemin, c'est tel n° et à la fin tel
> n° et il crée tous les nodes entre les deux et il ne reste plus qu'à les
> placer exactement au bon endroit, et ça va assez vite une fois qu'on a
> pris le coup.
> J'ai utilisés les noeuds associés à la rue partout parce que je trouvais
> ça plus logique d'avoir la même chose partout. (C'était aussi plus
> rapide.)
>
> 1: <http://osm.org/go/0BOdQs_xD-->
>   
OK c'est noté. +1 pour cette méthode. On va voir pour les autres.

Cette méthode (c'est sûrement l'arrondissement d'a côté) fait déjà des 
bizarreries par endroits :
http://www.openstreetmap.org/?lat=48.846374&lon=2.290802&zoom=18&layers=B000FTF 
<http://www.openstreetmap.org/?lat=48.846374&lon=2.290802&zoom=18&layers=B000FTF>
Les 98, 100, 102, (même le 104), 106, 110, 112 à 122 Avenue Émile Zola 
par exemple.

C'est là où je dis qu'il faut se mettre d'accord rapidement. :p. Existe 
t'il dans cette méthode une manière de spécifier X n° pour une entrée ?

Benoît R.

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

Re: [OSM-talk-fr] Import bâti : un ordre d'idé e pour ceux qui voudrait se lancer...





Tenshu a écrit :
Comme tu dis tout dépend de la numérisation sur 6
communes, que j'ai traitée, 2 possédaient des bâtiments de chevauchant.
  

Houla, moi c'est à chaque fois et au moins 65 au plus 130. C'est super
long de chopper le bon point (sélectionner, zoomer sur zone, zoomer à
la main, déterminer si c'est un point pour du "J" ou deux points pour
du "M", ... faire la manip, ...) et les limites de parcelles, faut
zieuter, joindre les chemins, couper, virer le(s) segment, joindre de
nouveau, virer les points en trop, ... pff je ne map pas au bon endroit
on dirait... Entre le cadastre numérisé avec les pieds et les décalages
récurrents, nous somme maudits dirait on ! Z'avez de la chance vous :p.

Benoît R.


  2010/6/24 Benoît ROUSSEAU <adressepossi...@free.fr>
  
    
Pieren a écrit :



  2010/6/24 Benoît ROUSSEAU <adressepossi...@free.fr>
  
Donc 4 h. 50 min. au
total
pour : (zone dense de l'import)
http://www.openstreetmap.org/?lat=46.63781&lon=0.17321&zoom=16&layers=B000FTF



  
  
Je trouve ça un peu long. Est-ce que tu utilises le plugin validator et
la possibilité de "corriger" automatiquement les doublons ?
  
  
  



Moi aussi je trouve ça long :). Et je trouve que vous allez très vite.

Oui j'utilise validator et je n'ai que très peu de doublons. Pour le
reste c'est l'horreur, la bâtiments chevauchants en particulier et les
traîts de parcelles qui flinguent le bâti. Ce doit être lié aux
différentes qualités de numérisation selon les lieux et les opérateurs.
J'ai préparé des captures d'écrans avec les pb rencontrés, je vais
faire une page liée à celle de l'import semi auto.

J'ai bouclé Quincay qui est à côté en moins d'une heure. Du coup j'ai
commencé la rivière :p. Ce n'est pas prioritaire alors qu'il manque les
voies principales, mais j'avais envie d'apprendre.

Toujours est-il que si l'on souhaite prendre des précautions, dans
certains cas, cela peux prendre énormément de temps ! Mieux vaut être
prévenu. Les 35 min d'export JOSM ça change des habitudes par exemple.

Benoit R.



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

  
  
  
  
  
-- 
Mon weblog - http://www.tenshu.fr/
Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
  
  
  

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


Ce message entrant est certifié sans virus connu.
Analyse effectuée par AVG - www.avg.fr 
Version: 9.0.829 / Base de données virale: 271.1.1/2959 - Date: 06/23/10 20:35:00

  





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

Re: [OSM-talk-fr] cadastre et ligne de cote

jul...@krilin.org a écrit :
>> 2010/6/24 
>>
>> 
>>> Est ce que le cadastre est une bonne référence pour modifier la ligne de
>>> cote ?
>>> Est ce qu'il faut prendre des précautions particulière quand on modifie
>>> la
>>> ligne de cote ?
>>> Est ce qu'une ile apporte des contraintes particulière ?
>>>
>>>
>>>   
>> Non le cadastre n'est pas idéal pour les lignes d'eau en général.
>>
>> Pour la ligne de côte, je pense que la meilleure source est l'orthophoto
>> du
>> geolittoral qui est maintenant une source exploitable par OSM (c'est une
>> grande nouvelle qui est pourtant passée inaperçue il y a quelques
>> semaines).
>> Regarde le wiki:
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/G%C3%A9oLittoral
>> 
>
> génial !
>
> et sur http://wiki.openstreetmap.org/wiki/FR:Port il y a pas mal de
> réponses a mes questions.
>
> Il me reste juste une question.
> Faut-il "ecraser" la source si il y en a une ?
>
>
> Merci
>   
Oui si la source change :). Ou je n'ai pas compris la question.

Benoît.

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

Re: [OSM-talk-fr] Les adresses...

Frédéric Rodrigo a écrit :

- "Pieren" a écrit :

2010/6/24 Tenshu
Je suis d'accord sur l'enjeu majeur des adresses. Et que les solutions
actuelles ne sont pas satisfaisantes car trop lentes.
L'idéal et le plus rapide serait de pouvoir automatiser, au moins dans
les parties les plus faciles, l'identification des numéros sur le cadastre
et les associer à la rue la plus proche.
Mais comme cette solution n'est pour l'instant pas possible...

Cela me semble techniquement faisable, en zoomant assez sur le cadastre on peut récupérer les numéros de rues comme chemin dans le SVG. Partant de la il faut les reconvertir en texte, ce qui est tout à fait faisable.

Oui. Je pense pouvoir arriver au résultat escompté si les textes sont
en chemins dans les SVG ou les fichiers OSM de manière distinctif (un
attribut chiffre par exemple). reste que le problème est peut être de
les distinguer.

Si quelqu'un met au point cette solution, il faudra encore repasser sur toutes les zones ou les bâtiments viennent d'être importé...

Perso, je trouve que ça va trop vite et que tout le monde c'est lancé la dedans sans trop vite sans trop réfléchir et peaufiner le truc. Il y plein d'amélioration et d'automatisation possibles : reconnaissance des adresses, import réfléchit à la CLC, transfère d'attributs plus ou moins automatiques entre bâtis existant et nouvellement importés...

Fred (qui n'a encore importé aucun bâtiment)

D'accord sur le "ça va trop vite". Mais on n'arrête pas le progrès. Et
je ne suis pas de ceux qui disent que "C'éatait mieux avant". C'est une
réel avancée ce script de V.

Le plus nuisible dans l'histoire, c'est cette exaltante idée que le
boulot est déjà fait et on oublie un peu vite "SEMI" qui précède
automatique. Le gain de temps est pourtant déjà appréciable en essayant
de bien faire.

Fred, tente une importation sur une petite commune pour voir. Ca donne
une idée des pbs rencontrés et de ce qui pourrait être fait pour
améliorer les choses.

Benoît R.

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

Re: [OSM-talk-fr] Import bâti : un ordre d'idé e pour ceux qui voudrait se lancer...





Vincent Pottier a écrit :

  
Le 24/06/2010 10:13, Benoît ROUSSEAU a écrit :
  

Tenshu a écrit :
Comme tu dis tout dépend de la numérisation sur 6
communes, que j'ai traitée, 2 possédaient des bâtiments de chevauchant.
  

Houla, moi c'est à chaque fois et au moins 65 au plus 130. C'est super
long de chopper le bon point (sélectionner, zoomer sur zone, zoomer à
la main, déterminer si c'est un point pour du "J" ou deux points pour
du "M", ... faire la manip, ...) et les limites de parcelles, faut
zieuter, joindre les chemins, couper, virer le(s) segment, joindre de
nouveau, virer les points en trop, ... pff je ne map pas au bon endroit
on dirait... Entre le cadastre numérisé avec les pieds et les décalages
récurrents, nous somme maudits dirait on ! Z'avez de la chance vous :p.

Benoît R.
  
  
Pour zoomer sur le problème :
clic-droit sur l'item dans la liste du validator
zoom par le curseur de JOSM plutôt qu'à la molette (à la molette, on a
des chances de zoomer à côté)
  
Pour sélectionner deux polygones jointifs :
clic sur le trait mitoyen (le premier polygone est sélectionné) puis
sans déplacer la souris, maj+alt gr + clic (le second polygone est
sélectionné aussi)
  
Pour fusionner deux polygones jointifs ou se chevauchant :
sélection des deux polygones puis maj+J
  
Je garde l'index de la main gauche au dessus de la touche maj, c'est le
petit doigt qui navigue de 'alt gr' à 'J'. C'est assez rapide.
  

--
FrViPofm


Ah ! maj+J me sera utile :p
Le maj+alt gr+clic je connaissais mais je n'y arrive pas :).

Merci.
Benoît R.




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

Re: [OSM-talk-fr] Les adresses...





Pieren a écrit :

  2010/6/24 Benoît ROUSSEAU <adressepossi...@free.fr>
  
D'accord sur le "ça va trop
vite".


  
  
Je ne crois pas que ce soit un problème. Il faudra de toute manière un
jour ou l'autre être capable de gérer les mises à jour, c.a.d intégrer
des données du cadastre avec ce qui est déjà présent dans OSM. C'est
plus compliqué que de partir d'une page blanche mais il faudra de toute
façon s'y atteler tôt ou tard.
  
Pieren
  
  


Bonjour Pieren,

Je ne refuse pas le progrès et tu sais que les automatismes me
passionnent. Seulement, il n'y a qu'une semaine, nous rêvions du bâti
vectoriel directement importable (pas tous) et nous espérions avoir
saisi le bâti à la main pour 2050.

Je pense simplement que nous ne sommes ni à un jour ni à une semaine
près. Prendre le temps réfléchir après cette première vague pourrait
nous faire gagner du temps par la suite. Être contraints le couteau
sous la gorge de trouver une solution à un pb répété à 50 millions
d'exemplaires avec des cas particuliers dans une France de 500 Go ne
m'enthousiasme pas. Je préférerai nous voir œuvrer à des choses plus
intéressantes ou à chercher des solutions à des pbs qui se posent déjà.

Au passage, pour je ne sais plus qui, la France à 500 Go, ou jouer à
qui à la plus grosse avec l'Angleterre et l'Allemagne, ne devrait pas
être une motivation.

Benoît R.



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

Re: [OSM-talk-fr] Les adresses...

Mathieu Arnold a écrit :
> +--On 24 juin 2010 10:06:51 +0200 Benoît ROUSSEAU
>  wrote:
> | Cette méthode (c'est sûrement l'arrondissement d'a côté) fait déjà
> | des  bizarreries par endroits :
> | http://www.openstreetmap.org/?lat=48.846374&lon=2.290802&zoom=18&layers=B
> | 000FTF 
> | <http://www.openstreetmap.org/?lat=48.846374&lon=2.290802&zoom=18&layers=
> | B000FTF> Les 98, 100, 102, (même le 104), 106, 110, 112 à 122 Avenue
> | Émile Zola  par exemple.
>
> C'est le même arrondissement, et les numéros sont bien placés, mais les
> batiments ne sont pas là, en général, c'est parce que le batiment n'est
> pas au cadastre (comme un batiment public par exemple.)
>
>   
Nom de Dieu ! J'en apprend tous les jours.
C'est dû à quoi que certains bât publiques ne soient pas au cadastre ? 
J'aurai bêtement pensé le contraire.

Benoît R.

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

Re: [OSM-talk-fr] Les adresses...


Christian Quest a écrit :
Le 24 juin 2010 12:26, Benoît ROUSSEAU <mailto:adressepossi...@free.fr>> a écrit :


Mathieu Arnold a écrit :
> +--On 24 juin 2010 10:06:51 +0200 Benoît ROUSSEAU
> mailto:adressepossi...@free.fr>> wrote:
> | Cette méthode (c'est sûrement l'arrondissement d'a côté) fait déjà
> | des  bizarreries par endroits :
> |
http://www.openstreetmap.org/?lat=48.846374&lon=2.290802&zoom=18&layers=B
<http://www.openstreetmap.org/?lat=48.846374&lon=2.290802&zoom=18&layers=B>
> | 000FTF
> |
<http://www.openstreetmap.org/?lat=48.846374&lon=2.290802&zoom=18&layers=
<http://www.openstreetmap.org/?lat=48.846374&lon=2.290802&zoom=18&layers=>
> | B000FTF> Les 98, 100, 102, (même le 104), 106, 110, 112 à 122
Avenue
> | Émile Zola  par exemple.
>
> C'est le même arrondissement, et les numéros sont bien placés,
mais les
> batiments ne sont pas là, en général, c'est parce que le
batiment n'est
> pas au cadastre (comme un batiment public par exemple.)
>
>
Nom de Dieu ! J'en apprend tous les jours.
C'est dû à quoi que certains bât publiques ne soient pas au cadastre ?
J'aurai bêtement pensé le contraire.

Benoît R.



Peut-être que ces bâtiments ne sont pas soumis à l'impôt foncier... il 
ne faut pas oublier que le cadastre sert quand même avant tout à ça 
pour ce qui est des bâtiments, non ?

C'est plausible.
Tu voudrais dire qu'ils ne bossent pas pour le rendu :P ?
Benoît R.


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

Re: [OSM-talk-fr] Import bâti cadastral - Bâtiment s mitoyens et plugin validator


Mathieu Arnold a écrit :

+--On 24 juin 2010 12:58:07 +0200 Christian Quest
 wrote:
| Il y a un truc que je ne comprends pas avec validator.
| 
| Il me sort des avertissements pour des bâtiments chevauchants alors

| qu'ils sont mitoyens et que j'ai vérifier que les noeuds de contact
| étaient bien communs.
| 
| Les chemins en question sont un mix entre du building=yes et du

| building=yes+wall=no

Alors, en fait, le validator donne deux choses :

1) un avertissement de chevauchement
2) une info de zone superposée

Le deuxième, il le donne parce que les deux batiments ont un segment
commun. (Ça pourrait petre pas mal de lui apprendre que c'est pas grave.)

Le premier par contre, en général, il a toujours raison, et il t'affiche
quels segments se chevauchent, avec ça, tu peux en général résoudre le
problème, et le surlignage jaune devient bleu.

  

J'ai pris des copies d'écran de pb rencontrés sur l'import du cadastre 
ja vais faire une page, à l'arrachée dans un premier temps. Je/nous 
complèterons. Il est vrai qu'au d'épart le nombre d'erreur, 
d'avertissements et d'infos m'effrayait. On va essayer de dégrossir ça 
en français d'autant que certains ont des trucs et astuces à nous faire 
partager pour aller plus vite et mieux.


Benoît R;

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

Re: [OSM-talk-fr] Les adresses...


Re...

   Je viens de regarder les SVG extraits par le script de V. Il est 
possible d'en extraire les numéros d'adresse.
   Ce n'est, A PRIORI, pas vraiment compliqué, mais il me faudra du 
temps pour mettre au point (5 jours, 2 semaines, + ?).


   On peux même imaginer faire les relations d'adressage directement en 
base, façon points le long des rues, si les voies existent.

   Le faire après l'import bâti est possible.

   Donc... je confirme ou j'infirme bientôt. Voilà pour les nouvelles.

Benoît R.

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

[OSM-talk-fr] Un aperçu des erreurs à corrig ées lié à l'import semi auto


Bonsoir,

   J'ai initié une page incomplète et non exhaustive des "erreurs" que 
je cherche à résoudre avant un import bâti semi auto.
   Elle n'est pour l'instant liée à aucune autre page. Si vous avez des 
éléments pour la compléter, n'hésitez pas et remaniez comme vous le 
souhaitez.


Benoît R.
  


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

Re: [OSM-talk-fr] Re : Un aperçu des erreurs à corrigées lié à l'import semi auto





THEVENON Julien a écrit :

  
  >>>> De : Benoît ROUSSEAU

  
  
  >>>> Bonsoir,
  
  >>>>   J'ai
initié une page incomplète et non exhaustive des "erreurs" que je
cherche à résoudre avant un import bâti semi auto.
  >>>>   Elle
n'est pour l'instant liée à aucune autre page. Si vous avez des
éléments pour la compléter, n'hésitez pas et remaniez comme vous le
souhaitez.
  
Tu peux donner le lien stp ?
  
  
  

Zut ! Un grand classique. :p
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents/Aper%C3%A7u_des_erreurs_rencontr%C3%A9es


  
  
  
Julien
  
  
  
  





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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti





sylvain letuffe a écrit :

  Le vendredi 25 juin 2010 00:21:49, Etienne Chové a écrit :
  
  
Guillaume Allegre a écrit :


  Le Thu 24 Jun 2010 à 10:53 +0200, Frédéric Rodrigo a ecrit :
  
  
Perso, je trouve que ça va trop vite et que tout le monde c'est lancé la
dedans sans trop vite sans trop réfléchir et peaufiner le truc.

  
  +1
  

+1, c'est du grand n'importe quoi. On pourrait faire un truc propre à la
clc, et là chacun est parti pour faire la course à l'upload massif. Ca
donne des gens qui importent de la quantité à la place de la qualité, et
qui disent "quelqu'un repassera après moi pour corriger".

  
  
C'est ici la discussion des râleurs ?

Alors je publie mon mail que j'ai envoyé en privé

**
On mercredi 23 juin 2010, Machin truc bidule dont je ne me permet pas de 
dévoiler l'identité wrote:
  
  
- question du suivi de cet import (l'idée d'utiliser des relations pour en
garder une trace me semble à creuser)
- question du suivi dans le futur
- question du choix entre import massif puis corrections ou corrections
avant import massif

  
  
C'est en effet de très bonnes remarques, la disponibilité d'un coup de cet 
outil et le "rush" qui a suivi la réouverture du cadastre donne un peu 
l'impression vu de loin d'un "bordel anarchique"

Chacun y allant de son export (bon ça, à la limite, c'est juste tant pis pour 
la charge sur le serveur du cadastre) mais chacun y allant surtout de son 
intégration rapide et sauvage dans osm.

Y'a qu'a lire le topic nomé "ARg ! Doucement ! STOOP !" pour se dire que 
forcément, à un moment, ou en tout cas pour la suite, ça va être le bazar.

L'outil n'ajoute aucun autre tag repérable que :
$tag_source = "cadastre-dgi-fr source : Direction Générale des Impôts - 
Cadastre. Mise à jour : " . ($year + 1900);

Ce qui, grosso modo, correspond également à tout ce qui a été fait également à 
la main.

En bref, il va être dur d'identifier l'automatique, le semi-automatique, du 
manuel. Alors forcément, pour d'éventuel mise à jour ultérieur, c'est plus 
compliqué.

Mais voilà, l'effervescence actuelle est difficile à endiguer ;-) et un peu 
d'anarchie représente bien la philosophie osm finalement.
**

Loin, très loin de moi, de dire que cet outil n'est pas extraordinaire, par 
contre l'utilisation anarchique me dérange un peu. Certes, la critique est 
facile, et peut-être semble-t-il préférable d'importe "un peu mal" que de 
laisser en suspend (cf import des parcs/réserves), mais quand même.

Je rejoins complètement l'avis d'un développeur anonyme de plugin pour JOSM 
( ;-) ) qui, après avoir développé un très bon outil de récupération des SVG 
du cadastre a vu son boulot devenir caduc parce que "pouf" l'export a été 
coupé et j'abonde en son sens sur le oui à une récupération de la source de 
donnée vecto (les pdf), à garder non public dans un but de re-traitement, par 
contre, je ne trouve pas ça terrible d'importer chacun dans son coin, à la 
sauvage, avec tout ce que ça implique.

Car cette méthode va sans doute "oublier" les zones fortement démunies de 
mappeurs osm, là où, un import réfléchi, coordonné, global, avec détection de 
collisions, avec meta-données de repérage, ( devrais-je dire "a la CLC" ?) 
aurait sans doute pû réaliser 99% de l'import des bâtiments de france et 
fournir ce qui avait été appelé les rebus de CLC pour les 1% restant.

D'accord il y a les socles de fontaine, les bâtiments écroulés, les erreurs du 
cadastre, mais n'est il pas judicieux de :
- récupérer au plus vite la source pour éviter de se trouver le bec dans l'eau
- réfléchir tranquillement à tout ça
- et proposer un plan d'action ?

Tout ce qui est fait en ce moment rend plus difficile un éventuel import total, 
génère du temps perdu.

On fait une pause et on y réfléchi ?

--
sly

  

+1. J'avais  rédigé un courriel du même type et je ne l'ai pas envoyé
pour ne pas en ajouter.

Il y a une semaine on rêvais de pouvoir importer massivement depuis le
cadastre. Et alors que nous espérions terminer à la main peu après
2050, M. V trouve et implémente l'astuce magique "Alléluia". Maintenant
il ne faudrait pas que le rêve devienne cauchemar.

On a testé et on peux continuer le plus proprement possible en
nettoyant et en ajoutant en tag supp qui identifie ce type d'import (A
DÉTERMINER). Ce n'est pas idiot de continuer tranquillement pour
préparer la méthodologie, détecter les cas particuliers, ca prépare et
détermine l'organisation et permet à tous de comprendre le pourquoi et
le comment. Cela fera plus de contributeurs pour aider ensuite en
connaissance de causes et d'effets.

Mais franchement nous ne sommes pas à qques jours/semaines prês (vs
2050) et plus important est effectivement d'organiser le rapatriement
des sources.

Pour le reste effectivement, j'aimerai aussi que cet import permette
d'ajouter plus de sens aux éléments. Je vais essayer pour les adresses,
mais

Re: [OSM-talk-fr] Les adresses...


Benoît ROUSSEAU a écrit :

Re...

   Je viens de regarder les SVG extraits par le script de V. Il est 
possible d'en extraire les numéros d'adresse.
   Ce n'est, A PRIORI, pas vraiment compliqué, mais il me faudra du 
temps pour mettre au point (5 jours, 2 semaines, + ?).


   On peux même imaginer faire les relations d'adressage directement 
en base, façon points le long des rues, si les voies existent.

   Le faire après l'import bâti est possible.

   Donc... je confirme ou j'infirme bientôt. Voilà pour les nouvelles.

Benoît R.

Youpi !

C'est du bricolage, mais j'arrive à reconnaitre les chiffres que j'ai 
sur mon extrait d'essai.

La faisabilité tend vers "oui c'est possible".

Sans garantie aucune, car il tard ou tôt, il est peut être possible 
d'extraire d'autres éléments comme les cimetières... mais je n'ai pas 
vérifié, ne m'en veuillez pas si j'infirme pas la suite.


Benoît R.

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

[OSM-talk-fr] Bâtiments jointifs


helene a écrit :

esperanza a écrit , Le 25/06/2010 09:11:

Comment fusionner deux bâtiments jointifs dans JOSM rapidement ?
Merci d'avance.
E.


+1 !
moi aussi je me pose la question !

helene


Je vous renvoi un courriel de FrViPofm

--

Pour zoomer sur le problème :
clic-droit sur l'item dans la liste du validator
zoom par le curseur de JOSM plutôt qu'à la molette (à la molette, on a 
des chances de zoomer à côté)


Pour sélectionner deux polygones jointifs :
clic sur le trait mitoyen (le premier polygone est sélectionné) puis 
sans déplacer la souris, maj+alt gr + clic (le second polygone est 
sélectionné aussi)


Pour fusionner deux polygones jointifs ou se chevauchant :
sélection des deux polygones puis maj+J

Je garde l'index de la main gauche au dessus de la touche maj, c'est le 
petit doigt qui navigue de 'alt gr' à 'J'. C'est assez rapide.


--
FrViPofm



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

Re: [OSM-talk-fr] Organisation du wiki


helene a écrit :
C'est plutôt compliqué de naviguer dans le wiki du projet France, il 
me semble que ce n'est pas une arborescence (au sens mathématique du 
terme) ; dites moi si je me trompe.


J'ai aussi un problème pour me retrouver dans les 
.openstreetmap.org, je n'ai pas trouvé l'endroit où se trouve la 
liste.


merci de votre aide,
helene
Tu ne te trompe pas (et j'ai ajouté à la confusion en ne sachant pas 
trop ou rattacher une page et en lui donnant un nom non signifiant).
"Faudrait yaka" reprendre l'ensemble pour lui redonner de la cohérence 
et corriger les obsolètes. J'en suis parfaitement incapable pour ma part.


Benoît R.



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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !


helene a écrit :

Steven Le Roux a écrit , Le 23/06/2010 11:44:

Et ajouter chaque import dans le "import catalog" sur le wiki ;)


le lien, s'il te plait ?
helene

Ca correspond au bas de la page "Import semi auto du bâti", section 
"Suivi des imports".

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents#Suivi_des_imports

Benoît R.

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

Re: [OSM-talk-fr] Les adresses...





Pieren a écrit :

  2010/6/25 Benoît ROUSSEAU <adressepossi...@free.fr>
  Sans
garantie aucune, car il tard ou tôt, il est peut être possible
d'extraire d'autres éléments comme les cimetières... mais je n'ai pas
vérifié, ne m'en veuillez pas si j'infirme pas la suite.




  
  
  
Reconnaître le numéro est une chose mais le script ne pourra pas
associer numéro et rue puisqu'il ne connait pas les highway... est-ce
que l'idée est de créer les nodes avec addr:housenumber et de faire une
fusion avec les données osm ou est-ce qu'on le fait dans JOSM
automatiquement ou manuellement ? 
L'association automatique peut se résoudre si l'identification de la
rue la plus proche est bien claire (genre la deuxième rue est 10x plus
loin que la première). Mais ça l'est moins près des carrefours. Et
encore moins si le highway est manquant dans OSM...
  
Pieren

Bonjour Pieren,

    C'est bien ce que je disais quand je me suis lancer sur l'affaire.
Peut être un peu trop en raccourci.

 Une connexion via l'api est un mieux, chercher la voie la plus
proche si elle existe et faire l'import de ce qui semble correcte.
Sinon pour moi perso, un bricolage intermédiaire me facilitera la vie.

    Je vous donnerai tout pour ceux qui veulent, transposer sur
d'autres langages, d'autres éléments, allez plus loin, ...

    Pour tous, ce n'est pas fait ! Mais je reconnais quasi tous les
premiers chiffres et leurs emplacements (je suis en cours de
séquencage). Une fois les nombres reconnus et placés on prendra le
temps...

Benoît R.



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

Re: [OSM-talk-fr] Import des données INPN (was: ODbL et compatibilité avec sources actuelles)