Re: [OSM-talk-fr] [MS BOT] proposition oneway=true - oneway=yes
Autant que je sache rev n'existe pas Et c'est bien un tort à mon avis ! reverse ou opposite aurait été mon choix donc yes/no/-1 c'est pas très logique. Tout à fait d'accord, et comme -1 me semble hautement explicite, c'est bien -1 qui est le problème. Ca revient à choisir entre vert, jaune et poële à frire. Lorsqu'un cas de ce type se présente, je me demande : que veut-on décrire ? si c'est une couleur, alors je vire poële à frire, si c'est un ustensile de cuisine, je remplace alors vert par caquelon savoyard et jaune par appareil à raclette -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Openhikingmap, OSM et la rando
Sujet zombie ressortie de sa tombe : En googlant un peu, je suis tombé là dessus : http://www.mail-archive.com/mapnik-us...@lists.berlios.de/msg00208.html Yahoo You find the wolf man ! Le mot clef documenté nul part était donc transparent à la place de la couleur de fond. Wep. Dans le cadre d'une génération dynamique comme celle sur laquelle tu travailles c'est plutôt très bienvenu. Bon, je redoute quand même que le résultat ne soit pas forcément très exploitable sous IE 7 (qui reste malheureusement assez employé...) vu sa gestion pas terrible de la transparence PNG. Et on ne parlera pas des versions inférieure à 7 (au bout d'un moment si les gens sont assez masochistes pour continuer à utiliser de si mauvais logiciels...). Et ben voilà, I did it, les données OSM générées en temps réél et mise à jour quasi en temps réél par dessus les données de terrain qui elles sont gardées en cache indéfiniment ( je les régénérerais après la prochaine période glaciaire ) Me reste plus qu'a trouver comment dynamiquement indiquer la durée de cache au navigateur pour éviter durant une session de promenade de recharger trop souvent (quelqu'un sait comment je fais remonter en python un header http ? ) Quelqu'un pourrait me faire un screen shot IE7 pour voir la catastrophe ? http://beta.letuffe.org/index2?zoom=9lat=46.74025lon=7.11201layers=TB PS: un grand merci à françois et pierre pour le coup de main avec openlayers -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Openhikingmap, OSM et la rando
Tu tourne en mode cgi avec un apache ou tu utilise un serveur http python ? désolé, j'ai pas été assez précis, j'utilise mod_python Mon code est en copie ici : http://wiki.openstreetmap.org/wiki/Howto_real_time_rendering_with_mapnik_and_mod_python#How_to_set_up_the_real_time_rendering si je résume cette partie là de mon code sa donne : def handle(req): from mod_python import apache, util req.status = 200 req.content_type = 'image/png' req.write(renderers[style].genTile(x, y, z, ext, cache)) return apache.OK c'est dans le que j'aimerais faire un truc du genre : req.additionnal_header = 'Expires: ', new datetime.add(new timedelta(minutes=1)).isoformat() j'imagine qu'il doit y avoir une doc quelque part sur la classe apache de mod_python Dans le premier cas un bête print Expires: , new datetime.add(new timedelta(minutes=10)).isoformat() devrait suffire au début du script. Yann ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Openhikingmap, OSM et la rando
Tu peux utiliser mod_expire pour mettre les durées de cache dans la conf d'Apache plutôt que dans ton code. La syntaxe est simple, et ça te génère les entêtes qui vont bien. C'est ce que je faisais jusqu'a présent, mais je voudrais manipuler le expire plus finement selon le type de données que je vais envoyer. Comme tu l'avais suggéré il y a peu (et que j'ai bien lu ! ) Thomas à dit : Avec Apache : Location /tiles/fond ExpiresDefault access plus 2 weeks /Location Location /tiles/ski ExpiresDefault access plus 2 hours /Location le problème c'est que ma gestion de cache est assez délicate : sur les zoom faible, je veux un cache quasi infini, sur les zoom élevés, un cache de quelques minutes max, sur certaines tuiles de relief un cache infini à tout zoom Bref, ça me semble plus judicieux de déporter ça coté applicatif. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Openhikingmap, OSM et la rando
Re-salut, Ainsi cela devrait être bon : d = (datetime.datetime.now() + datetime.timedelta(minutes=1)) req.headers_out['Expires'] = d.isoformat() Tout simplement nikel ! req.headers_out['Mercis'] = 'beaucoup' Mais vous êtes tous fan de python ma parole, va falloir que je m'y mette ;-) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [MS BOT] Exécution de la vers ion 1.2
Salut, Dommage qu'il ne soit pas allé au bout La taille du log qui contient toutes les modifications appliquées laisse penser que le robot avait dépassé les 91% de progression. Je tente de voir postg...@binael ~ $ echo select count(name) from planet_osm_line where name like 'avenue%' | psql gis count --- 96 (1 row) postg...@binael ~ $ echo select count(name) from planet_osm_line where name like 'avenue%' | psql gis_france count --- 675 (1 row) Ha oui, pas mal du tout, joli nettoyage, je ne sais pas, parmi les 96 restants si ce sont des effets de bordure ou si c'est la non fin du traitement mais ça en fait déjà 1-96/675 = 86% de nettoyé -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [MS BOT V1.3] Début des tes ts de la V1.3
On Friday 30 January 2009 12:10, Marc SIBERT wrote: Bonjour, Je viens de finir d'intégrer la lib PCRE dans mon robot. Cela veut dire que je vais reformater les séquences de détection (on transforme...) en expressions rationnelle et donc intégrer l'existant et les suggestions de la v1.3. Pour m'éviter de courir après les corrections, merci de mettre vos prochaines propositions dans la V1.4. Je vais aussi déplacer la page MS BOT sous son nom (http://wiki.openstreetmap.org/wiki/User:MS_BOT) Génial ! Ce sera sans doute bien plus simple avec les expressions régulières/rationnelles En attente du pré-log pour voir si tout semble bien se passer PS: un relancement de l'ancienne version est-elle prévue pour corriger les oubliés de la dernière fois ? -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [MS BOT V1.3] Début des test s de la V1.3
On Friday 30 January 2009 12:46, Pieren wrote: J'ai trouvé des expressions à améliorer: name=* Georges Sand* - name=* George Sand* pourrait aussi s'appliquer à Georges Sanders. name=*Ecolier* corrigera mal Ecoliere Très bonne remarque. Essayes d'être un peu plus conservateur et vérifier un espace ou fin de chaine ou début de chaine. Par exemple, je ne sais pas si ça existe mais : name=*Ecole* - name=*École* va par exemple corriger la Rue Franck Ecolet dont on ne sait pas si c'est un oubli du É ou vraiment Ecolet valable pour les autres aussi -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [MS BOT V1.3] Début des test s de la V1.3
Pour les gens sous Windows et qui n'utilisent pas le clavier Bépo, il faut quand même retenir les combinaisons alt-0201 et alt-0199 (et alt-174 et alt-175 temps qu'on y est). Pour certains, ça reste une bonne excuse (même si elle est mauvaise). Je sens que je vais passer pour un con, mais verrouillage majuscule + éàçè c'est pas plus simple ? ÉÀÈÇ ? -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
On Tuesday 03 February 2009 16:53, Pieren wrote: 2009/2/3 g.d g...@wanadoo.fr: Le 3 févr. 09 à 12:08, sly (sylvain letuffe) a écrit : Et si on remplaçait tous les highway=footway par highway=path Je pense que Sletuffe a voulu lancer un troll... héhé, c'est marc qui l'avait demandé ;-) mais ça n'a pas trop pris, y'a trop de gens sages sur cette liste ... et si on remplaçait tous les tags smoothness par surface ? ;-) Rhooo ! le mien était bien plus crédible, tu oublies de proposer une équivalence claire : On pourrait donc remplacer smoothness=bad par surface=gravel puisque de toute façon c'est équivalent... -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
On Tuesday 03 February 2009 16:39, g.d wrote: Le 3 févr. 09 à 12:08, sly (sylvain letuffe) a écrit : Et si on remplaçait tous les highway=footway par highway=path Oups, ptèt' pas remplacer ça, Pas de panique, c'était bien juste qu'une blague ;-) Un footway semble être une liaison piétonne, à plat, plutôt dans des zones bâties, et faisable pour une poussette, une personne âgée, ou à vélo, Heu, soit c'est un troll et je me fais avoir, tant pis, je le tente ;-) si tu peux passer à vélo, il ne me semble alors pas judicieux de mettre footway, puisque la définition de footway est : For designated footpaths, i.e. mainly/exclusively for pedestrians. Pour moi, le footway c'est là où les vélos ne devraient ou ne doivent pas aller, donc ton cas, je mettrais plutôt path justement là où path semble être plutôt général, un passage dans la nature, peu importe sa viabilité : ça peut être un chemin de débardage, un sentier, ou une via ferata. M, c'est pas comme ça que je vois path moi : Provide a value for a nonspecific or multi-use path. ( encore que cette phrase a été enlevée de la page key ) En gros, path pour moi, c'est quand il n'est pas spécifiquement précisé que c'est que pour les vélo (cycleway) ou que pour les chevaux (bridleway) ou que pour les piétons (footway) et m'étais dit à quoi bon de tracer, si ça reste invisible ?!. On tente souvent de dire ne pas tagguer pour les rendus, mais on sait bien que c'est très étrange à faire car on ne voit pas son travail -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Robot MS BOT V1.3
http://wiki.openstreetmap.org/wiki/User:MS_BOT
Je suis contre :
// {^(improve_me|no_?name)$, FIXME}, // Erreur : signification différente.
tenons nous pour l'instant à des fautes évidentes, là tu commences à toucher à
la manière dont les gens ont choisi de mapper. Je préfère reporter ça à la
v2.x de ton robot qui, si elle voit le jour, tentera de modifier non plus des
erreurs mais des manières.
N'hésitez pas à troller un peu, c'est bien calme ces jours. On s'ennuie
presque.
Et si on remplaçait tous les highway=footway par highway=path
c'est plus logique en france non ? footway étant très mal défini, ça ferait un
peu le ménage pour laisser la place à path qui est bien plus logique et bien
mieux fait. (En france, les chemins uniquement piéton sont très rares en
proportion)
--
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires pou r relation:type=route_instruction
Rappel de l'URL : http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Droute_instruction Nom de bleu que c'est compliqué Me voilà en train de faire des schémas sur des papiers pour voir quel est le cas que l'on ne peut résoudre avec le système de lane et qui nécessiterait ce type de relation. Si tu en as sous la main, ce serait bien de les indiquer, car, sauf erreur, les 3 exemples que tu cites en début me semble solublent topologiquement. isn't it ? -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires p our relation:type=route_instruction
C'est la conclusion (hâtive à mon avis) à laquelle en était arrivé un mec dans la partie talk avant de réaliser qu'avec les changement de nombre de lanes du deuxième exemple ça n'était pas possible. là, je n'en suis pas convaincu 1) lane=2 tout le long la sortie Le logiciel de navigation doit dire : tenez votre droite puis sortez à la prochaine 2) lane=3 avant lane=2 juste après la sortie Le logiciel de navigation doit dire : garder la file de droite ( il ne dit pas sortez car il a remarqué qu'après il n'y avait plus que 2 voies donc il sait que fatalement, c'est celle de droite qui sort ) 3) lane=3 avant a) une sortie + lane=2 b) une sortie + lane=1 Il sait de a) que la file de droite va à la première à droite Il sait de b) que la file du centre va à la deuxième à droite ça me semble jouable par soustraction Sans parler du fait qu'il faudrait renseigner le nombre de lanes de tous les segments Certes, mais il faudrait de toute façon placer la relation, donc l'un dans l'autre et aussi du fait que dans le deuxième exemple, les panneaux de directions sont sur la partie à 4 voies et nécessite donc de donner des instructions depuis une partie qui ne se scinde que plus tard si tu suis la mortorway. Tout à fait, le moteur de routage peut très bien prendre la décision, 400m avant l'embranchement d'indiquer placer vous sur la file centrale/droite/gauche Les motorway_junction ne suffisent donc pas non plus. Il me semble que peut importe le tag sur le highway, le nombre de files suffissent. (mais je peux me tromper) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires po ur relation:type=route_instruction
Scinder c en 2 pour ajouter l'information du changement de nombre de voies. Voilà comment il me semble que je ferais : http://slyserv.dyndns.org/osm/sorties.png 3 cas quand le conducteur vient du segment A : 1) Le conducteur veut aller en B le logiciel de navigation calcul qu'entre A et B il y a 2 files de moins. Il en déduit qu'il faut se trouver sur la 1ère ou 2ème à gauche (car en france on roule à droite) et que les deux autres vont partir 2) le conducteur veut aller en D Entre A et B 2 files continues, il propose alors de les éviter et propose de se retrouver soit sur la 1ère ou 2ème à droite avant la jonction J1 Il calcul un peu à l'avance et détermine que de C à D une seule file continue sur D, il proposera donc : Avant J1 restez sur la file de droite, après J1 mais avant J2 passer sur la fil de gauche. ( avec un peu de calcul à l'avance, il doit pouvoir déterminer qu'il fallait, dès le départ, rester sur la 2ème file de droite ) 3) le conducteur veut aller en E même raisonnement, mais après J1 et avant J2 il proposera de rester sur la file de droite Après, pour l'histoire des panneaux, ma foi, c'est un élément de terrain qu'on peut tagguer, on peu imaginer donc définir un POI que l'on place sur le way, qui aurait comme attribu ce qu'on veut (une couleur, un texte,...) le logiciel de navigation pourrait en ternir compte pour donner une directive 100m avant le panneau qui conforte alors le conducteur dans le choix de son GPS. On peut raffiner en donnant : highway=sign // c'est un panneau way_direction=yes // il est lisible dans le sens du chemin text:3=Chambéry 20 km \n Grenoble 80 km \n Valence 150 km // voici son texte sur la file n°3 bgcolor:3=blue textcolor:3=white text:2=Sortie n°18 Crolles 2000m // sur la 2 bgcolor:2=white textcolor:2=black text:1=Aire du grésivaudan 500m // sur la 1 bgcolor:1=blue textcolor:1=white Y'a moyen de faire une jolie usine, mais on va l'avoir notre mappy ;-) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel: appel à commentaires pou r relation:type=route_instruction
http://www.coupin.net/vrac/sorties.png Un petit dessin vaut mieux qu'un long discours ;-) j'y cogite Mais je me suis basé sur ton lien ici : http://slyserv.dyndns.org/osm/aerienne.jpg et c'est ce que j'ai tracé, mais bon, ok supposons ce nouveau cas. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le Rhone déborde vers Avig non ?
Cette dernière n'apparait pas encore avec le rendu mapnik. On voit le problème ici : http://beta.letuffe.org/?zoom=13lat=43.98075lon=4.8466layers=B000 -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le Rhone déborde vers Avig non ?
On Thursday 05 February 2009 13:15, Yann Coupin wrote: Tiens d'ailleurs je voulais te demander un truc sur ton rendu real- time. Les ways entourées de rouge c'est les noname ? Le blabla que j'ai écris ici : http://wiki.openstreetmap.org/index.php/Yet_another_validation_tool_for_osm_data dit : no name layer This layer is working a bit like the noname one with a red line around : * unclassified/tertiary/residential/minor when there is no name set to the highway or the keyword FIXME To avoid false positive this tool take advantage of the Proposed features/Internal quality validate:no_name=no_sign and validate:no_name=yes key value --- Pour les non-roastbeef compliant : en français --- en rouge : ceux qui n'ont pas de nom, ou qui ont le mot clé FIXME et qui n'ont pas le tag validate:no_name=no_sign ou validate:no_name=yes ( sinon y'a aussi le style mapnik normal c'est un peu plus joli si on veut juste voir ce qu'on vient de tagger sans que les routes ne saignent ) Sinon c'est très très bien ! Thanks you ;-) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvelle version du plugin JOSM cadastre-fr (13546) (0.9)
Prochaine étape: - l'import des building sur la vue en cours (le faire sur toute la commune en une fois ne semble pas possible, la vue d'ensemble présentant les bâtiments de manière incomplète - à étudier) Je ne peux qu'encourager cette prochaine étape ! je suis en train de me taper comme un boulet le tracé des building orange, et quand je vois certains villages, ça me fait déprimer de me dire qu'un robot pourrait sans doute le faire. Mais comme je n'ai pas le courage de me lancer dans le développement, j'ai pas grand chose à dire sinon bravo, continues comme ça ! Si l'idée devait germer d'automatiser ce tracer building à grande échelle, je ne pourrais que vous féliciter. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] fichier et/ou gps ?
tracer building à grande échelle serait-ce un de tes trolls ? Je n'en fais que si on me demande, ou si je me suis emporté, là, ce n'est pas le cas. Importer les bâtis en masse, sans vérification humaine, sans avoir vu soi-même, sur place ? oui, c'est ce que j'ai dis (Es-tu sûr, que tel ou tel bâti cadastré existe encore, depuis les parfois vingt ou trente ans ?) non. Suis-je pour autant plus sûr que la batisse saisie dans OSM est plus juste ? Si on irait par-là, où va la plus-value du terrain, d'osm, du réel, Il n'est pas de plus-value venant de l'inexistance selon moi. La non présence d'une batisse dans osm ne me semble pas avoir plus de valeur que la présence (de probabilité faible) d'une fausse batisse. En outre il est possible de rajouter le tag batisse=oui et peut_etre=oui pour mentionner une incertitude et l'appréciation du subjectif ? heu ? perso, je tente de faire une carte objective, en acceptant tout de même qu'un système puisse contenir des erreurs. Je pense juste qu'une carte OSM avec toutes les batisses du cadastre vectorisées, me sera plus utile comme base à modifier que l'abscence de toutes. En ce moment, tiens toi à ton siège, je recopie à la main, sans réfléchir, toutes les batisses du cadastre dans OSM. De ce que j'en vois, c'est une source de repérage de très bonne qualité, et je doute avoir le courage de faire le tour, de chaque batisse, avec mon GPS en main un jour. Ces données nous sont offertes, ça me semble être une chance, je préfère supprimer les 0.1% de faux que de rajouter les 100% de juste (qui ne viendront selon moi jamais, on est pas géomètres !) Si c'est ça, yapuka faire un plombé du cadast', avec toutes ses erreurs Je serais pas contre, tant que la source et la qualité de la donnée est indiquée, et que jamais elle ne remplace la donnée OSM collectée à la main Tu sais, sillonner le pays juste pour corriger des données erronées ou imprécises, plombées depuis ailleurs, sans créer soi-même, ce ne serait pas très motivant. Là, tu lances à un sacré pavé, que j'avais moi même soumis à pieren lors de l'annonce de ré-utilisabilité du cadastre en finissant mon mail par : et merde, j'ai plus qu'a balancer mon GPS J'avoue te comprendre, et être sur le même sentiment... je regarde mon dur labeur de cette dernière année, et je me dis : Merde, j'aurais pû tout faire en 10 jours avec le cadastre Maintenant, je ne sais plus quoi penser, mais je suis informaticien, j'aurais dû mal, sachant que ça existe, à venir faire chaque village et faire le tour de chaque batisse en rentrant dans le jardin des gens 'Faudrait qu'on en discute, quelle direction prendre... Les questions de robot ou de import massif n'en sont que les pointes du iceberg. totafais, le plugin cadastre encore plus que tout. Combien parmis nous commencent à tracer aveuglément par dessus le cadastre ? combien traces par dessus la yahoo imagery ? combien convoitent des vélib, des stations de bus, des dab, des églises, à rentrer d'un coup comme ça en masse avec un robot ? -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] extraire un contour depuis géofla ?
Quelqu'un veut-il bien m'indiquer la bonne piste pour extraire ce contour (ça me fait une occasion de comprendre comment sont fait les shp) ? La dernière fois que j'ai travaillé sur geofla pour l'incorporer dans osm (frontière de département), j'ai cherché plusieurs solutions pour retravailler le fichier shp En graphique clic clic ou presque, j'avais trouvé qgis et son convertisseur ogr, mais comme ma version devait être un peu vielle, je me suis dirigé vers une solution ligne de commande avec l'outil ogr2ogr Avec cette outil, en une commande (que je n'arrive bien sûr pas à retrouver) mais qui devait s'approcher d'un truc du genre : ogr2ogr -nlt MULTILINESTRING -t_srs EPSG:4326 -f GPX resultat.gpx fichier.shp Tu devrais arriver à t'approcher d'une conversion en gpx, donc que tu peux travailler dans JOSM (un test m'indique que ma précédente commande ne marche pas car gpx ne supporte pas les polygones, mais il doit y avoir un moyen de le forcer à en faire des lignes) http://www.gdal.org/ogr2ogr.html http://www.gdal.org/ogr/drv_gpx.html -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] extraire un contour depuis géofla ?
avec la fonction explode du logiciel libre MapWindow ^ Open Source le jour où l'opensource sera libre les poules auront des dents Oui, mais on dirait bien que ton intervention est tout à fait hors propos dans le cas de MapWindow : http://www.mapwindow.org/pages/opensource.php The Mozilla Public License 1.1 applies to all MapWindow GIS source code raté ;-) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] extraire un contour depuis géofla ?
Une autre piste pourrait être (...) et ce programme : http://www.gdal.org/ogr2ogr.html qui sait lire le shapefile et écrire le GPX. Arrr ! J'ai 10 minutes de retard sur toi ;-) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [HS] extraire un contour depuis géofla ?
Allez, pas grave, tu auras quand même une médaille, mais...en chocolat : http://g.co/maps/aybp7 ;-) ha ha ! J'en profite pour faire de la pub, mon tonton fait de bons chocolats ;-) Chocolaterie vue en place en décembre 2011 comme on dit de certains repères. Rhô, et pas dans osm pour autant ! Voilà qui est corrigé -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Dans quelle catégorie de contributeur êtes-vous ?
On mardi 10 janvier 2012, Pieren wrote: Le site How did you contribute to OpenStreetMap ? Inutile, donc indispensable ! I'm An Addicted Mapper Même pas vrai d'abord... tiens, ça fait 1heure que j'ai pas contribué, il faut que j'y retourne -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une question (farfelue ?) sur le changement de licence
On vendredi 13 janvier 2012, Christian Quest wrote: Des données en CC-by-SA doivent rester sous licence CC-by-SA à cause du SA, non ? Exact. Si on avait le droit d'exporter puis ré-importer pour nettoyer la licence, toutes ses prises de becs depuis 3 ans n'auraient pas eu cette raison d'être. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une question (farfelue ?) sur le changement de licence
On vendredi 13 janvier 2012, Vladimir Vyskocil wrote: Mais je ne parle pas de re-importer les données... Je parle d'utiliser les données comme source, un peu comme ce que l'on fait avec Bing. Pourrais t'on par exemple décalquer les routes manquante dans la nouvelle base en utilisant en fond OSM CC-by-sa ? C'est pareil, ça deviendrait un travail dérivé qui devra être sous cette licence. Quelqu'un a dit licences libres ? cette complexité des licences dites libres n'ait (à mon avis) qu'un moyen maladroit de finalement se contraindre dans la ré-utilisation des données avec des myriades d'incompatibilité qui font que ça fait 3ans que osm est empêtré dedans pour un gain dont je commence vraiment à douter. troll Quelqu'un veut discuter et proposer avec moi que l'on passe toute la base osm dans le domaine public ? /troll -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] a marche pu ? cé bin triste.
Le samedi 21 janvier 2012 11:50:06, Hélène PETIT a écrit : http://beta.letuffe.org/?zoom=11lat=43.13761lon=1.37122layers=BF FFFTFFFT rin de rin ? le N° du layer a changé ? J'ai juste ré-arrangé les layers et j'ai tenté d'en garder le bon nombre pour qu'ils soient toujours dans l'ordre d'avant (quitte à rajouter des styles vides) Mais j'ai mauvaisemanipé, voilà qui est corrigé -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Bonjour, (oui, je sais, ce sujet a déjà été abordé maintes fois, mais toujours en mouvement est l'avenir d'osm) Certains l'ont peut être remarqué, le département de l'ille-et-Vilaine ne ferme plus sur http://suivi.openstreetmap.fr/communes/communes.csv.txt et, pour une fois, ce n'est pas à cause d'une erreur. C'est à cause d'un chantier en cours de la part de Verdy_p consistant à re-modéliser, comme cela avait déjà été suggéré et fait, les frontières de la france par une modélisation pyramidal, en poussant toujours plus vers les niveau administratifs plus élevés : 4 et 6 (régions et départements) http://www.openstreetmap.org/browse/changeset/10451651 Nous avons échangé en privé, et je pense que la proposition est d'ampleur et qu'elle vaut d'être discuter ici. (désolé, c'est peu long et mélangé) sly : Salut, Je vois que tu as commencé pour le département de l'ille-et-vilaine une opération de démultiplication des relations en utilisant un système à base de type=boundary_segment Je suis entièrement pour dans un but à long terme d'utiliser une méthode pareil, ayant toujours été un défenseur des relations. Mais là, je me demande si ça risque pas de poser pas mal de problèmes et si c'est pas encore un peu tôt pour le faire compte tenu des outils très rares qui savent utiliser cette méthode. Verdy_p : Ce n'est pas qu'un besoin à long terme. Car déjà immédiatement les mises à jour de cartes génèrent un travail infini sur des relations trop longues, avec souvent des erreurs du serveur lors du chargement. Je n'ai fait qu'une toute petite partie en attendant de voir comment cela se comporte et comment les serveurs génèrent les cartes. Dans l'état c'est surtout encore un essai. Si cela mache bien pour ce segment je continuerai le reste. Ces frontières par département faciliteraient le travail, notamment sur les côtes qui demandent un travail énorme (il suffit de regarder le zoom maximal (celui des rues, numéros de maisons et immeubles: les côtes sont très grossières, et très éléatoires : travailler dessus sur des frontières très longues est un enfer qui demande un temps infini de plus en plus long). Le niveau de scission régional est aussi trop grand. Le niveau départemental serait plus adéquat, mais ruen ninterdit plus tard encore de descendre au niveau arrondissement, selon le département en question. Ce niveau départemental est plus facile é manipuler pour les départements côtiers (notamment en Bretagne avec ses très nombreuses îles et îlots). Il y a des incohérences encore à corriger: je voudrais aussi utiliser les relations de type subarea entre les niveaux de découpage administratifs, et m'assurer que l'union des frontières forment bien une partition (exhausitve et sans intersection) de l'espace (par exemple la région Bretagne n'a pas les frontières de ses départements, corriger cela va prendre du temps...) Autre chose lié, mais différent, je vois que tu préfères utiliser pour les frontières un caractère qui ressemble à un tiret pour séparer les deux entités administrative. Seulement, je n'arrive pas à faire un tel tiret et donc je fais un truc simple : - Moralité, c'est pas très cohérent et on a tantôt l'un tantôt l'autre. C'est clair que c'est vraiment un détail, mais vu que justement c'est un détail, je propose d'utiliser un caractère tout bête facilement accessible pour tous. C'est surtout pour le rendu et aussi pour éviter les confusion avec les traits d'union. Cela participe au travail général pour obtenir des libellés de frontières une fois qu'on les aura bien structurés pour éviter l'affichage des libellés multiples inadéquats (car on utilise trop de relations par segment là où on ne devrait avoir à mettre un segment que dans une seule relation. Les segments peuvent alors avoir des libellés utiles et lisibles sur la carte. Ce n'est pas un problème de saisie, on peut très bien continuer à entrer des -, et corriger ça plus tard pour afficher un tiret long. C'est une question plus typographique qu'autre chose, amis aussi qui améliore la lisibilité. Le problème de cohérence est très mineur, il y a bien d'autres incohérences plus problématiques et plus graves dans les dénominations que ce seul caractère. Je ne corrige pas systématiquement, juste ce que je vois au fur et à mesure, en fonction des navigations dans la carte. J'ai les tirets demi-cadratins – et cadratins — sur mon clavier (Shift + AltGr + 6 ou 8), ce n'est pas du tout une difficulté à taper, et je les emploie très souvent sly : (...) si c'est pas encore un peu tôt pour le faire compte tenu des outils très rares qui savent utiliser cette méthode. Tu parles de quels outils ? Visiblement, les boundary_segment sont bien supportés et reconnus par tous les outils de modification, rendu de tuiles, et vérification. Il n'y a aucune difficulté que je voie (et d'ailleurs la France elle-même utilise déjà ces segments, même si le découpage n'est pas adéquat, la
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
On lundi 23 janvier 2012, PhQ wrote: Je suis pour à 100% l'utilisation du concept boundary_segment, malheureusement l'outil de validation JOSM le détecte en avertissement comme inconnu. J'ai loupé quelque chose ou il faut faire un ticket ehancement dans JOSM pour faire avancer la chose ? Ce ne sera ni la première ni la dernière fausse erreur/warning que le validateur JOSM aura renvoyé ! Si ce n'est que ça, je ne m'inquiète pas -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Bonne nuit, Stoppez le massacre ! C'était déjà le bordel avant mais là, ça devient le pompon. hé ho, elle est où ta diplomatie légendaire ? Tout doux, on va réfléchir entre humains sans nécessairement sauter à la gorge de ce pauvre verdy_p que j'ai invité à discuter avec nous pour voir comment on peut faire au mieux. Evoluer, sans trop casser Je reviendrais sur les autres points, mais je vais parler brièvement du tag subarea : Très confus, là. Il faut aussi dire que le terme subarea est extrêmement mal choisi. Cette notion représente une somme de surfaces dans son usage alors que l'unique documentation que je trouve (http://wiki.openstreetmap.org/wiki/Relation:boundary) parle de boundaries of sublevels. J'aimerais avoir des statistiques de son usage (marginal, ama) mais il est urgent de ne pas utiliser un tag qui casse tous nos polygones de limites administratives car ce role n'est reconnu par AUCUN logiciel à part le validator de JOSM (peut-être parce que ça vient de la même personne Dirk Stocker) ! Il s'agit en effet de la même personne avec qui je me suis péniblement battu en édit war sur la page que tu cites. L'arrivé de cette proposition de subarea (qui, pour résumer, consiste à inclure dans une relation d'admin_level=n, toutes les relations d'admin_level n+1) N'a été discutée nulle part, a été parachuté sur le wiki sans réélle justification que : vu que certains l'ont fait, indiquons qu'il faut le faire (voir la talk page en anglais pour les combats) Pour la france, je continue donc à défendre la non utilisation de ce modèle bien que je suis à l'écoute de ceux qui m'expliquerons ce qu'elle apporte. Et j'ai sauvé du massacre en traduisant in-extrémis la page que je recommande de suivre : http://wiki.openstreetmap.org/wiki/FR:Relation:boundary -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
On mardi 24 janvier 2012, verdy_p wrote: Pour verdy_p : toutes les utilisations que tu as cités peuvent déjà se faire avec le modèle actuel (modèle frontières) grâce aux bases de données relationnelles. Je me suis trompé, je voulais dire grâce aux bases de données spatiales Pas du tout ! Pour trouver ces relations de subdivision, ce ne sont pas du tout des modélisations de type relationnel, mais de type géométrique (2D uniquement ! avec les limites que cela comporte quand on passe à la 3e dimension sur les plans multicouches, par exemple si on veut modéliser les étages de la gare Montparnasse, avec une incertitude sur les élévations sachant qu'il y a des couloirs en pente aussi !). Je ne comprends pas le rapport avec la gare Montparnasse, on parle ici d'entité administrative. (Et au pire, les bases de données spatiales, comme l'indique le nom, peuvent aussi trouver dans volume appartient un point 3D) Par exemple trouve la relation qui lie le 1er arrondissement de Paris (niveau 9) avec la commune de Paris (niveau 8). Ça se fait, ça tient en une ligne de SQL avec postgresql et la base osm2pgsql, je peux d'ailleurs faire pareil pour trouver que le 1er arrondissement de Paris est en europe, en france, en Ile de france, etc. En revanche, dans le modèle complètement relationnel que tu proposes, pour faire la même chose, tu sera obligé de passer niveau après niveau, puisque l'arrondissement de Paris n'est pas en subarea de l'europe. Je le répète, les deux modèles permettent la même chose, il me semble juste une perte de temps d'utiliser les deux. En plus, comme l'espagne les utilises, attendons 3 ans, et nous leur demanderons si c'est mieux ou moins bien ! C'est un gâchis énorme de requêtes SQL. Et oui cela ne facilite pas du tout le travail sur la carte et ses mises à jour. Et produire des cartes statistiques par exemple est un enfer sans les subareas. Tentons de ne pas tout mélanger : 1- Il y a le boulot pour les ordinateurs 2- Et le boulot pour les humains Je privilégie de loin la réduction de 2), si 1) devient intenable, ce qui n'est pas le cas, nous repenserons 2) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
La encore, ça n'est que relativement récemment que osm2pgsql a été modifié pour ignorer les subarea car ça faisait tout planté justement lié a ce mélange hideux de sémantique et de géographique. Bluff detected. Non, osm2pgsql dernière version dans le svn n'a pas de code pour exclure les subarea. Cependant, si ça marche encore a peu près, c'est parce que osm2pgsql ne support par les relations pyramidales et comme les role subarea concerne des relations, ouf, elles sont ignorées. Seulement, ça créer un problème pour l'avenir : - Si quelqu'un rentre en subarea non plus une relation mais un way fermé ça plante - Si quelqu'un tente de coder dans osm2pgsql le support des relations pyramidales, il va galérer un peu plus à lister tous les rôles selon qu'ils soient relationnels ou géométrique -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
On mardi 24 janvier 2012, Christian Quest wrote: Le sujet semble sensible vu le ton de plusieurs messages... Je le déplore d'ailleurs alors qu'on est là pour discuter, mais bon, l'humain aime la fight, ça doit être ça. Quand on travaille sur la base de données, c'est quand même plus simple de passer par des liens logiques entre relations pour naviguer dans les hiérarchies administratives, non ? Les requêtes spatiales sont coûteuses en calcul et c'est de pire en pire vue le nombre croissant d'objets dans les bases, autant s'en passer quand on peut. Voilà qui est un la première bonne question : - Est-ce que le programme gagne ou perd du temps Je vais tenter d'aider de mes connaissances, mais ça reste pas facile à savoir tant qu'on a pas les deux formats côte à côte pour faire des tests. Prenons un exemple, la région Ille de France, avec le modèle logique ou surfacique ou relationnel on peut répondre facilement est simplement à la question : quels département sont dedans. Par contre, quand je veux répondre à la question : quelles communes sont dedans, je dois d'abord passer par les départements (à moins d'inclure en subarea tous les niveaux administratifs supérieurs mais ça c'est juste la folie) et ça, c'est pas forcément simple car il faut savoir quel est le ou les niveaux entre les deux (admin_level=6) et ça, ça ne se devine que parce qu'on est habitué, ça n'est portable qu'en france, dans d'autres pays, il y aura un admin level=5 ou un autre tag. Si maintenant je veux tous les bâtiments d'ille de france, c'est juste impossible, car il n'y a pas de relation subarea pour lier les entités administratives et les bâtiments. De sorte que je suis obligé d'avoir les deux modèles quand même, je suis donc obligé de réfléchir selon chaque besoin si je dois utiliser le premier ou le deuxième modèle, ça me semble pas jouable et pas homogène comme méthode Je ne vois pas trop quel problème cela pose de mélanger au sein d'une même relation des objets géographiques et logiques (sémantiques). Moi, je vois que ça fait plus de boulot pour le mappeur, et ça, je ne vois pas ce qui le justifie. Si quelqu'un a vraiment besoin d'un modèle logique pour accélérer des traitements ou faire je ne sais quoi, ce qu'il y a de génial, c'est qu'il pourra construire sa base de donnée en partant du modèle surfacique pour accélérer ou pour son traitement. L'inverse n'est pas vrai. Les deux types d'infos sont utiles. On peut considérer que c'est redondant, c'est vrai, mais cette redondance permet aussi de vérifier la cohérence et d'assurer un contrôle de qualité. Ça, c'est encore un autre débat, mais intéressant aussi. Je dirais quand même que l'informatique nous a appris que dans bien des cas, la redondance ne faisait que créer des problèmes, et pas en résoudre. Et puis, d'autres bases existent déjà (le cadastre) qui permet, comme je le fais, de faire un peu de contrôle qualité par la comparaison. Je ne pense pas que ça soit utile d'avoir deux modèles dans osm dans ce seul but. Si ce mélange au sein d'une même relation est vraiment source de problème, devrait-on créer 2 relations, une purement logique (niveau N - niveau N+1 avec les sub_area et autres choses du même ordre) et une géographique pour avoir juste les contours ? Selon moi, ça ne change pas grand chose. Ajouter un if role différent de inner/outer then rien faire est chiant à mettre partout, mais c'est quand même possible et ça coûtera moins cher au mappeur. Mais je pense qu'avant d'en arriver là, il faut déjà se demander subarea : pour quel usage ? En ayant rajouté bon nombre d'EPCI ces derniers jours, je trouve l'approche uniquement frontière trop limitée. Voilà la deuxième bonne question : - Est-ce que le mappeur gagne ou perd du temps Pour les EPCI, je n'en ai pas rentré, mais j'ai bien l'impression que oui, c'est plus galère d'inclure les frontières que d'inclure les communes. Et cela est à mon avis dû à une loi mathématique : Le périmètre d'un cercle est en f(r) celui d'une surface est en f(r²) Plus ça devient gros, et moins on aura de membre sur un modèle frontière, et inversement. Donc pour les départements/commune, je pense que c'est plus simple en modèle frontière, pour les EPCI/communes c'est plus simple en modèle surface Mon avis n'a pas changé, vu qu'on ne sait rien, il faut tester. Et je propose de sacrifier les taggeurs d'EPCI sur l'autel de la recherche et leur proposer d'utiliser le modèle surfacique. L'avenir nous permettra de comparer tout ce que ça implique (logiciel pour exporter, outil de check, facilité à rentrer, etc.) J'accepte toutefois qu'on me réponde c'est pas éthique. Car comment laisser, en pensant que c'est une mauvaise idée, des gens faire quelque chose qui sera changé par la suite et du temps perdu. La science aussi produit ses héros -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Enfin bon j'attends avec impatience le jour ou on aura des objects polygones ce qui permettra d'eviter le melange entre le semantique et le geographique. Aller, aujourd'hui, je m'acharne sur Emilie, demain je m'occuperais d'un autre. Bien évidement, rien contre toi, mais contre ce courant de pensé que je constate sur dev, sur talk, et même ici. Courant de pensé que je qualifierais même de religion. Une religion qui dit : ne vous inquiétez pas, le messie viendra, la nouvelle primitive pour les area va tout changer et nous sauver, et son nom sera API 0.7 C'est une religion, car à chaque fois que nous n'avons pas de solution nous invoquons ce messie, des fois c'est même une secte car certains disent : pourquoi t'embêter à réfléchir, l'API 0.7 va tout changer et réglera nos problèmes Mais hélas, la vérité est la même que pour une religion, tous savent que dieu(x) existe, mais personne ne sait ni ou ni comment ni sous quelle forme. Je pense qu'il faut sortir de ça et analyser ce que l'on sait vraiment du http://wiki.openstreetmap.org/wiki/The_Future_of_Areas J'ai pourtant tout lu et la seule chose qui m'a convaincu car : - on pouvait migrer de l'ancien vers le nouveau système - on pouvait continuer à ne charger qu'une partie pour éviter de foutre en l'air JOSM - on pouvait éviter de superposer à l'infini des chemins - on pouvait éviter des constructions inbitables C'était de remplacer type=multipolygon par area et garder toute la logique des roles inner/outer, des membres. Franchement quelle révolution, ça va juste foutre le merdier pour un moment et gagner trois fois rien (un checker de fermeture, interdire les autres roles pour que les développeurs imposent leur vu au mappeurs, bravo !) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Réflexions sur la modélisation dans osm des niveaux administratifs en france
On mardi 24 janvier 2012, THEVENON Julien wrote: De : sylvain letuffe li...@letuffe.org Mais si au moins osm2pgsql pouvait supporter ça(...) Qui est le Papa de cet outil ? est ce que quelqu un lui a deja demande le support du modele pyramidal ? et si oui quel est le plan de developpement ? Des papas il en en plusieurs (si je puis dire) c'est un logiciel libre auquel n'importe qui est le bienvenu pour participer. Je ne sais d'ailleurs plus qui était l'auteur à l'origine. J'ai tenté discrètement de faire la demande sur la liste dev à plusieurs reprise, mais grosso modo c'est resté sans réponses. Sans doute parce que ça n'est pas si simple et le besoin n'est pas si grand. J'avoue avoir fortement l'envie de m'y mettre, mais mon niveau en C est franchement bas, et mon poil dans la main franchement grand. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osm2pgsql et boundary_segment [was: Re: Re : Réflexions sur la modélisation dans osm des niveaux administratifs en france]
Je me permet de migrer vers dev-fr, je sens que ça va partir en sucette Déjà, si c'est en C, ça m'intéresse bien plus que le java d'osmosis :) Non, pas possible ;-) tu, tu, tu... voudrais mettre ton nez dans osm2pgsql ? malheureux, tu n'en peux déjà plus de mes bugs reports, mais je vais te harceler pour mettre à l'épreuve ton très bon niveau de programmation et ta grandeur qui (bon, aller, j'arrête de faire mon lèche-cul manipulateur à deux balles) Je suis près à filer un coup de main et envoyer tous les bugs reports que tu voudra. Mais on peut aussi se demander si cette m... d'osm2pgsql est une bonne base au final. Oui, je suis contradictoire, mais je m'explique : J'utilise, je patch, je compile du osm2pgsql 4 fois par jours (les nutritionnistes l'ont recommandés) et je suis obligé de l'admettre, son schéma dé-normalisé est merdique, sur-consommateur de ressources CPU et disques. Mais voilà, il est tellement utilisé qu'il est au final quand même très complet en fonctionnalités et au mieux de ce que son schéma lui permet : import de diff, création de géométries multipolygones ultra-rapides, création de géométries multilinestrings et quelques autres babioles. Qui font que je n'ai jamais su quelle voie je devais suivre : apprendre le java ultra normalisé d'osmosis pour ajouter ce qui manque, tenter de faire des requêtes en veux tu en voilà par dessus osmosis, accepter osm2pgsql et avancer en boitant, rêver qu'imposm sera mieux ou... finalement, attendre le messie et faire la flemme. Mais je m'égare aux morilles, reprenons. Avant de modifier osm2pgsql, est-ce qu'il serait envisageable de faire tourner une moulinette SQL qui rajouterait les relations dépendantes aux relations déjà dans la base ? C'est déjà opérationnel, c'est la table _osm_rels imbriqué dans un champs htore qui détient cette information Ce n'est possible que si on garde la liste des membres de relations dans la base: je ne sais pas trop si c'est déjà le cas. osm2pgsql dispose en fait de deux schémas : Un qui est une version bijective de la base osm (_osm_rel, _osm_nodes et _osm_ways), l'autre qui contient les géométries de manière a être utiliser par le rendu. Sinon, je ne pense pas que ce soit compliqué de rajouter une colonne members initialisée par osm2pgsql lors de l'import. Cette colonne contiendrait juste un hstore avec les différentes relations membres de la relation en question. (bon, après relecture, ce n'est pas très clair parce que je n'arrive pas à trouver le bon vocabulaire...) C'est très clair pour moi, et c'est déjà fait. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
J'ai répondu à pas mal de tes remarques dans d'autres mails que j'ai fais aux autres. Je vais juste prendre celle qui n'ont pas encore été adressées (il y a des trous volontaires dans les sous-zones C'est gérable, avec le role inner pour les données et la primitive MULTIPOLYGON dans les bases spatiales , et parfois des sous-zones à cheval sur deux zones de niveau supérieur, et le modèle géomatrique ne permet pas de représenter ça). Sans aucun problème, la fonction standardisé est http://www.postgis.org/docs/ST_Intersects.html -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Le mercredi 25 janvier 2012 11:48:33, Christian Quest a écrit : N'y a-t-il pas un petit problème quand toutes les subarea n'existent pas encore ? C'est un des problèmes soulevé il y a longtemps: temps que nous n'avons pas toutes les communes, le modèle par surface ne fonctionnera que très mal (logique, plein de niveau admin inférieurs seront faux en terme de surface, contenu, etc.). Attention : je ne dis pas pour autant que quand nous les aurons toutes, ce sera bien ;-) Personne n'a réagit à l'idée d'avoir 2 relations, une 100% frontières géographiques et l'autre pour stocker les informations logiques (donc les subareas mais aussi d'autres choses si c'est utile). Je suis contre de le recommander sur le wiki car c'est un double travail qui pourrait être utiliser à autre chose et qui embrouille les mappeurs qui se pose la question de comment bien faire. Je ne suis en revanche pas contre, que ça soit expliqué sur une autre page, disant qu'aucun consensus ne s'est dégagé, que le but est de répondre à ça et ça, que le type de relation utilisé doit être type=boundary_relationnelle (différent) et que certain mappent des relations comme ça. Certes, ça téléchargera encore un peu plus de donnée de l'API à chaque fois qu'on télécharge une commune, mais on est plus à ça près ;-) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
yo, Pour revenir au départ du sujet, on se trouve encore à l'heure qu'il est avec un contour d'Ille-et-Vilaine inutilisable. Sauf levée de boucliers (argumentée), je procéderai demain soir à son rétablissement sous forme d'une relation classique Bien que nous soyons tous d'accord pour dire que nous sommes en désaccord, je vote +1 pour le rétablissement du statu quo qui me semble la bonne manière de casser un minimum de chose. D'ici là, pour les tests en tous genres à base de relations imbriquées ou sommes de surfaces pour des entités Région, Département et au dessous, il est tout à fait possible de créer de toute pièce des relations avec un autre schéma de tags, qui servent de support à la discussion, et sans pour autant casser / squatter un existant qui fonctionne et qui sert aussi à des consommateurs de données OSM. C'est aussi valable pour les contours d'EPCI, sly :-). J'admets avoir jouer la provoc, il faut néanmoins garder à l'esprit que ça n'intéresse que peu un testeur/développeur de faire un outil qui gère des données qui n'existent pas, et ça n'intéresse que peu un contributeur dont les données qu'il rentre ne sont pas valorisées. ça fait un peu cercle vicieux dont OSM se sort généralement par le forcing, forcing qui était plus facilement de mise quand nous n'avions que 2 rendus et un pelé qui utilisait la base, et qui maintenant devient en effet de plus en plus délicat. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
On lundi 23 janvier 2012, PhQ wrote: Je vous demande de m'excuser de recadrer la discussion sur le boundary_segment, mais ... Dans le barouf de ce fil de discussion, j'avais loupé cette question. il y a le fait que la vérification de continuité ne se fait pas dans l'éditeur de relation de JOSM. Bien sur, on peut vérifier la continuité et la cohérence d'un boundary_segment, mais à l'intérieur d'une relation comprenant des segments et un boundary_segment, on ne sait pas si ça ferme ! Tu as tout à fait raison, il manque le support de JOSM pour gérer ça et c'est pénible, mais JOSM ne changera pas si on ne les utilises pas, et si on ne les utilises pas parce que JOSM ne les supportent pas, ben on avance plus. Peut on vivre avec, et comment contourner cette lacune ? On peut vivre avec je pense, mais c'est pénible, on peut mettre en place des outils de contrôle externes, mais ce n'est qu'un palliatif. plusieurs cas : - Dans le cas de l'utilisation de la france entière, JOSM ramerait tellement, l'API ramerait tellement (et planterait), que avec ou sans, ça ne change rien, c'est pas possible. J'en ai fais le constat il y a 2 ans ce qui, déjà à l'époque, m'a obligé à changer le modèle pour le France. Et depuis, c'est encore pire. Donc là, à mon avis, c'est oui, car de toute façon on ne perd rien - Dans le cas des régions, ça devient très limite presque comme le cas du dessus - Dans le cas des départements et plus petits, on peut tout mettre dans JOSM, ça le fait à peu près donc pour ça, je suis pour de retarder tant que faire se peut jusqu'au jour ou JOSM supportera cela mieux Dans tous les cas de toutes façon, il faut prévoir des outils de surveillance de non fermage car tout le monde ne pense pas à vérifier avec JOSM (et tout le monde n'utilise pas JOSM) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france [HS]
Je ne résiste pas, pour ajouter un peu d'humour à nominer cette phrase d'anthologie pour les Fortunes http://wiki.openstreetmap.org/wiki/FR:Fortunes Verdy_p les côtes sont très grossières, et très éléatoires : travailler dessus sur des frontières très longues est un enfer qui demande un temps infini de plus en plus long). -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
On mercredi 25 janvier 2012, Philippe Verdy wrote: Si on a bien défini les relations, il n'est plus nécessaire de modifier dans JOSM les frontières (trop lourdes à charger et vérifier). Un outil automatique peut générer ces frontières de la France de base par celle des régions définies dans la relation Oui, c'est vrai, de même que la liste des départements d'une région peut être construite automatiquement si on dispose des frontières de la région et de celles des départements. Encore une fois, les deux modèles permettent logicielemnet de construire l'autre, d'où à mon sens la non utilité d'avoir les deux. La question est donc bien le choix de l'un ou l'autre modèle. Et comme chacun présente des inconvénients, tant que l'un n'est pas prouvé comme meilleur, le statu quo me semble la règle. Cependant, comme dit dans les autres fils, la construction d'une deuxième relation pour chaque département, chaque région et la france et l'option retenu pour expérimenter avec le nouveau modèle, sans casser l'existant. Y'a plus qu'a -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Comme ce débat revient souvent, je propose d'en faire une page sur le wiki, qui tente de présenter objectivement avantages et inconvénients de manière résumé http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Modèle_somme_de_surface_ou_modèle_frontière Si des motivés se sentent d'ajouter des points de comparaisons, vous êtes les bienvenus. Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
On mercredi 25 janvier 2012, Pieren wrote: Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des modifs semble d'accord pour une séparation des modèles dans des relations différentes à minima ? Je vote bien évidement pour le retour arrière sur ces relations comme la majorité des exprimés et laisse loisir à ceux qui défendent ce modèle de le créer, mais de manière séparé et isolé. Visiblement, la nuit été chargée en modification, je lui envoi un email pour lui demander s'il peut les retirer, ce sera plus simple car il sait quelles modifications il a fait. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Open Data
Le 26 janvier 2012 11:16, partir-en-vtt ad...@partir-en-vtt.com a écrit : Ce serait donc d'après vous plus par abandon (afin d'éviter de se ruiner la santé ou se ruiner tout court à traquer les fraudeurs) que par logique du non commercial que la clause NC n'a pas été mise en place ? Difficile de répondre pourquoi, à l'origine, le choix d'utilisation commercial possible a été choisi, il faudrait demander à steeve Coast. Au mieux, tu pourra avoir les avis des gens présents ici ;-) Il existe des projets libre non réutilisables commercialement donc, tout est possible, la majorité des gros cependant utilise cette autorisation, je suppose donc avant tout un mimétisme plutôt qu'un abandon. Suppositions : Steeve coast, pas avocat, dans son coin, démarre le projet avec 3 copains, 2 mois plus tard on lui demande : c'est quoi la licence ? Ben, heu... j'en sais rien moi, voyons : j'utilise et j'aime les logiciels libre et je veux faire un truc style wikipedia. Regardons : \autorisation commercial : OK\, alors pareil ! Je pense qu'il ne faut pas chercher plus loin. Pour ma part, jamais je n'aurais rejoins osm sans l'autorisation commercial de la licence. Je veux bien être philantrope jusqu'a un certain point, mais à un moment, il faut que je gagne ma croute. Et je compte (et j'utilise un peu) osm de manière commerciale, donc oui je donner à tous, mais après, j'ai bien l'intention de me servir du tout. Pour moi, cette clause est donc rédhibitoire -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Les éditions ont continué cette nuit, pour propager des subarea : http://www.openstreetmap.org/browse/changeset/10499268 Bordel de p de foutage de gueule Ho, on a dit stop ! Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était la teneur de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche de verdy_p. Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces derniers temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la non information. La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war ne soit plus très loin. Et, comme OSM dispose de fonctions d'annulation extrêmement simples à utiliser et extrêmement efficace (j'ironise), on peut parier sur soit des dommage collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes encore. Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, ça ne m'amuse pas du tout, please, stop ! re moi, Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct, discuté correctement et on est tous d'accord sauf toi pour continuer. Il ne te semble pas que ta manière de faire ne peut que dégénérer ? Alors passons à autre chose, c'est triste, mais c'est une menace. Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande de bannir ton compte, et en attendant j'annule tous les changesets que tu fera par un logiciel et tout le monde y perdra du temps et ça ne peut que finir en EDIT war avec des pertes tristes. Comme en plus tu sembles t'y connaître en développement (d'après tes mails), et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde et potentiellement violent. Alors, s'il te plait, arrêtes. -- sly *** -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Pour des raisons de retro-compatibilité, je suppose. C'est vrai qu'on pourrait s'en passer mais le logiciel de rendu - par exemple - devrait scanner l'ensemble des relations avant de pouvoir déterminer l'admin_level le plus haut (et donc le style à appliquer). Sauf erreur, C'est déjà ce qui se passe pour map...@osm.org ;-) d'une manière peu élégante d'ailleurs. Ce rendu réalise un rendu du chemin de frontière pour chaque relation dont il est membre, et en plus pour ces propres tags. Ce qui donne une infame couche très ampilée de tracés et le style a été fait pour que, par exemple, admin_level=2 fasse un rendu plus gros que tout les autres pour cache la misère. Exemples : http://www.openstreetmap.org/?lat=-79.863lon=-160.7434zoom=13layers=M En revanche, comme on le sait déjà, je ne suis pas partisan de mettre TOUS les tags dans les relations, pour des raisons de facilité de lecture pour un humain comme moi. à part pour le tag source=* moi c'est l'inverse, mais le sait aussi déjà ;-) D'autant que les progrès de josm sur la gestion des relations ont été énorme ces 2 dernières années -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france
Le jeudi 26 janvier 2012 23:08:18, Philippe Verdy a écrit : Non, désolé, le stop concernait le seul test du bounary_segment. Alors je m'excuse si je n'ai pas été clair, mais maintenant que tout est clarifié tout va bien, l'incident est clos concernant les role:subarea, on n'en veut pas. Ce qui n'empêche pas, comme on a pu le dire que tu créés, si tu le veux, des relations différentes, avec un autre type=bidule sur le modèle subarea. Pour les type=boundary_segment, pour l'instant, restons avec les contours de la france (contraintes techniques obligent) nous passerons peut-être, ultérieurement à des niveau régions et départements. (...) Sans vouloir te vexer, ni m'abaisser de trop à m'attarder sur la forme de tes emails, tu as souvent des points valident à avancer, des idées pertinentes à défendre, que tu noies dans un terrible flot trop long de paroles qui répète plusieurs fois ce que tu as déjà dis et finissent à mon avis par desservir les idées qui s'y cachent. Ce qui est dommage. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] conversion geofla des X_CENTROID de RGF93 en WGS84
Le samedi 28 janvier 2012 01:57:34, Philippe Verdy a écrit : Le 25 janvier 2012 16:09, Damouns damo...@gmail.com a écrit : j'ai trouvé GeoFLA qui indique le centroïd, qui je pense (j'espère) correspond au centre géométrique. Mais il faut faire la conversion. Apparemment, c'est le chef-lieu et pas un centre géométrique qui est donné dans centroïd. Donc c'est la même chose que dans le RGC. où est le problème ? Le centroïde calculé mathématiquement n'est pas très utile dans la base puisqu'on peut aussi le calculer. En revanche celui donné dans le RGC est bien plus utile à la cartographie, il tient compte de considérations comme les surfaces fortement non convexes (ex: l'Île-Saint-Denis), ou ayant des exclaves complétement hors de l'agglomération principale. Je vois souvent revenir cette question de placer un label sur une surface convexe ou à multiple polygones. Tout va bien, postgis l'a prévu, la fonction s'appelle ST_PointOnSurface — Returns a POINT guaranteed to lie on the surface. http://postgis.refractions.net/documentation/manual-1.5/ST_PointOnSurface.html ps: je n'ai pas dis que c'est mieux qu'un humain qui la placerait, je dis juste que ça peut être une alternative au centroïde -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Des stats détaillées pour OSM
Le samedi 28 janvier 2012 13:44:11, phip...@phiphou.com a écrit : Je me dis alors qu'il suffit d'aller trouver quelque part le nombre total de nodes,ways et relations pour la France pour le comparer aux infos que donne OSM2PGSL sur les données déjà traitées...et je n'ai trouvé ça nulle part. Obligé d'aller demander sur IRCpour qu'une bonne âme (c_quest et Jocelyn, merci les gars) me donne ces infos, depuis sa propre base. Ton fichier france n'est peut-être pas non plus le leur (notre ?) ;-) ça te donnera une idée proche, mais à mon avis, le mieux, c'est encore de compter toi même dans ton fichier le nombre de noeud, way, relations ! Je me dis que ça serait sympa si on pouvait trouver ce genre de stats sur le wiki, non ? Lidéal serait de pouvoir sélectionner une bbox et obtenir des infos sur cette zone. Intégrable au wiki me semble une mauvaise idée, car ça va être bien galère techniquement. L'option de christian, pourquoi pas. Mais je vois arriver gros comme une maison que c'est le truc qu'un tondu et un pelé vont voir par semaine pour des heures de calculs perdues chaque jours. (s'il s'agit bien des stats routiers, cours d'eau, etc.) par départements, régions, communes, pays. Ton option de la bbox, aura au moins l'avantage de ne s'activer qu'a la demande. Mais si la bbox fait la taille de la france, j'ai peur que ça prenne un poil de temps. Bref, à réfléchir. Vous visez quoi comme stats exactement ? -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Des stats détaillées pour OSM
Le samedi 28 janvier 2012 14:39:16, Christian Quest a écrit : C'est en chantier, mais voici un début d'ébauche de commencement de fondation: http://openstreetmap.fr/outils/etat-du-decoupage-administratif L'idée est de sortir des statistiques à chaque niveau ainsi que d'autres informations comme les contributeurs actifs sur la zone afin de pouvoir rentrer plus facilement en contact localement, l'état des erreurs (osmose voire autres) pour mieux les corriger, etc... Joli programme. N'hésites pas à demander de l'aide, des orientations à réfléchir pré- développement et voir comment interconnecter correctement tes softs avec la base (celle de osm7 je suppose ?) Ayant moi même pas mal cogité et coder dans ce domaine, je pourrais peut-être t'éviter les impasses. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Y a t'il des éléments qui doivent rester nécessairement figés dans OSM ?
On lundi 30 janvier 2012, Patrice Hadot wrote: Existe quelque part un recueil de ce qu'il ne faut pas toucher tant qu'on n'est pas ceinture noire de cartographie ? Si tu es ceinture noire, je pense que tu peux même bouger les repères géodésiques ! Cela me parait évident quand il y a des tags tel que note=Ne pas déplacer ce point, cf. - Do not move this node, see - Certains aiment dire : si tu ne comprends pas ce que c'est comme élément ne touche pas Mais je trouve ça un peu restrictif et élitise. Je dirais tant qu'il n'y a pas une note qui insiste sur le fait qu'il faut lire un truc pour comprendre le quoi et le pourquoi, alors il n'y a pas de raison de se priver. Il y a t'il d'autres cas ? Puis je modifier les zones taguées CLC:code source=Union européenne - SOeS, CORINE Land Cover, 2006. sans m'attirer les foudres de toute la communauté ? Si tu modifies ça, tu risques plutôt de t'attirer les bénédictions de la communauté ! Le tag source est un élément très important (car on n'a que ça en gros) pour indiquer d'où provient un élément dans osm, après, c'est le wiki qui va t'en dire plus sur ce que telle ou telle source implique en terme de qualité et de faut il changer Dans le cas de CORINE Land Cover, c'est une qualité de qualité médiocre, si ta source provient de bing, de ton gps, du cadastre, de ta connaissance locale : vas-y -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Y a t'il des éléments qui doivent rester nécessairement figés dans OSM ? [HS]
On lundi 30 janvier 2012, Pieren wrote: 2012/1/30 sly (sylvain letuffe) li...@letuffe.org: Si tu es ceinture noire, je pense que tu peux même bouger les repères géodésiques ! C'est de l'humour bien sur : même un ceinture noire ne peut bouger les repères, sauf indication contraire de l' IGN. Pieren Et un ceinture noire de maniement de la pioche ? J'admets cependant que ça risque d'être mal vu s'il s'agit d'une cathédrale... -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom rivières large
Le mardi 31 janvier 2012 00:27:35, Pieren a écrit : 2012/1/30 Stéphane MARTIN st3ph.mar...@laposte.net: Mais qu'est-ce que je fais du nom ? Je mets le tag name=* - avec les ways fermés waterway=riverbanks ? - avec le way waterway=river ? - répété sur les deux ? Personnellement, je ne le met que sur le waterway=river Moi sur les deux. Ça fait redondance, mais comme je n'ai pas trouvé de solution pour les assembler. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] role=label
Le mardi 31 janvier 2012 10:24:36, Hélène PETIT a écrit : Donc, dans une relation frontière administrative y a-t-il une astuce pour gérer à la fois le rôle label et le rôle admin-centre ? Et le point amenity=townhall ? il fait pas triplette ? Je me pose régulièrement la question en ces termes : Le rôle label est-il utile, son apparente bonne intention est elle louable, est-ce utilisé quelque part et ne pourrait-on faire autrement ? Autant le dire tout de suite, je n'ai pas la réponse ! -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] role=label
Le mardi 31 janvier 2012 11:05:49, Christian Quest a écrit : Si j'ai bien compris, ce label sert (ou pas) au moteur de rendu Pour l'instant, c'est ou pas il me semble, mais peut-être que des rendus non connus l'utilise pour positionner le nom, mais à ma connaissance il n'affiche pas un nom en plus. Il y a: - un nom affiché pour le multipolygone type=boundary - un nom affiché pour le place=* A part faire remonter le place dans la relation (idée bizarre, j'avoue), je ne vois pas comment éviter d'avoir 2 noms... sauf à revoir bien sûr les moteurs de rendu. Il y a la proposition du role admin_centre qui a pour but de faire remonter dans la relation Mais la question du double nom entre la relation administrative et le tag place est pour moi un faux problème. Je continue de dire qu'il s'agit de deux noms pour deux choses différentes, donc normal. Coïncidence, en France, les communes portent souvent le nom de leur chef lieu (mais ce n'est pas tout le temps le cas) Mon questionnement a moi se situe plutôt au niveau du role=label et de son utilité. Option 1) : ça ne mange pas de pain, autant le mettre, s'en serviront ceux qui le veulent Option 2) : ne pas le mettre et laisser ce qui le veulent se creuser la tête pour le déterminer automatiquement -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le site data.gouv.fr inaccessible - Et si Philippe V avait raison ?
Le mardi 31 janvier 2012 22:32:31, Marc Sibert a écrit : A Dieu alors ! En plus, je sais de sources très haut placées que même lui ne voudra même pas de toi. Mais t'inquiètes, avec le diable au moins on ne s'ennuie pas, et y'a de quoi cartographier là bas parcequ'il y a un de ces monde ! Des villes entières et des millions des limites administratives assez fuzzy (par contre, ça n'est que du cadastre image, c'est pas le paradis hein ?) PS sérieux : ya quelqu'un qui sait comment faire oublier un 301 à un navigateur ? A mon avis vincent se gourre, il a juste cliqué, il a vu un site et il s'est dis ça marche, il n'a pas fait gaffe que son navigateur s'est tiré ailleurs. Donc pareil pour moi toujours, j'arrive sur : http://www.gouvernement.fr/premier-ministre/le-secretariat-general-du- gouvernement/etalab ps: sinon, ça n'a rien à voir mais firefox est hyper casse bur... avec les 301, aux dernières nouvelles soit tu connais le code secret shift+ctrl+bouton droit+echap+reload en chantant du joe dassin, soit tu le fermes et tu le relances -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le site data.gouv.fr inaccessible - Et si Philippe V avait raison ?
Le mardi 31 janvier 2012 23:07:56, sly (sylvain letuffe) a écrit : A mon avis vincent se gourre, il a juste cliqué, il a vu un site et il s'est dis ça marche, il n'a pas fait gaffe que son navigateur s'est tiré ailleurs. Bon sang de bois, on dirait que c'est moi qui me gourre ! Toutes mes excuses Vincent pour avoir douté de toi. Elle est pas mal celle là, je tente avec 3 navigateurs, toujours pareil. Je me connecte à distance sur une autre machine, pof ! la page qui va bien. Merde, mon IP a été blacklistée, je vais me retrouver à cartographier l'enfer avec Marc. Arghh, je les entends qui tapent à la porte. Non... je noo -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le site data.gouv.fr inaccessible - Et si Philippe V avait raison ?
Le mardi 31 janvier 2012 23:34:18, Philippe Verdy a écrit : Il est possible aussi que ce soit un changement de DNS pas encore reporté à votre FAI. On dirait que t'a gagné le ponpon Sur bécane 1 : $ host -t a www.data.gouv.fr www.data.gouv.fr has address 89.31.148.145 http 301 Sur bécane 2 : host -t a www.data.gouv.fr www.data.gouv.fr has address 160.92.169.98 http 200 -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le site data.gouv.fr inaccessible - Et si Philippe V avait raison ?
Le mardi 31 janvier 2012 23:24:38, Yves a écrit : Ben oui, si le serveur voulait te faire faire autrement, il te dirait 302 ! C'est, ma foi, une remarque très juste. Mais visiblement, dans notre cas, nous avons encore le cas d'un 301 abused. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le site data.gouv.fr inaccessible - Et si Philippe V avait raison ?
Le mardi 31 janvier 2012 23:54:39, Philippe Verdy a écrit : Mais visiblement, dans notre cas, nous avons encore le cas d'un 301 abused. Non, ce que tu vois c'est un 301 (Moved permanently), ;-) J'aurais pas dû mixer français et anglais dans ma phrase, je semble t'avoir perturbé. Je voulais dire on est dans le cas d'un abus du code HTTP 301 -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Google maps condamné en France pour abus de position dominante
On mercredi 1 février 2012, Pieren wrote: Le tribunal de commerce de Paris estimant que Google Maps fausse la concurrence en fournissant son service gratuitement, a condamné la société Google à 500.000€ de dommages et intérêts au bénéfice de la société plaignante Bottin Cartographes (et 15.000€ d'amende). Un porte-parole de Google s'exprime en réaction pour dire qu' un outil cartographique de haute qualité, libre, et gratuit est bénéfique tant pour les internautes que pour les propriétaires de site web. Le terme libre a été aussitôt corrigé par Camille Gévaudan dans son billet sur ecrans.fr (http://www.ecrans.fr/Google-Maps-condamne-en-France,13992.html) et n'a pas raté - encore une fois - une occasion de citer OpenStreetMap. Bravo et merci Camille. J'ai lu (lemonde.fr), et égallement je n'ai pû m'empêcher de rire un coup que le mot libre est apparu au coté de googlemaps. Il n'empêche que je ne pense pas qu'un tel jugement soit une bonne chose pour OSM (et le libre en général). De manière indirect, cela condamne un service gratuit sous prétexte qu'il en existe un, similaire, payant. Certes, google fait du dumping de prix avec son Gmaps et on peut penser que c'est surtout pour ça qu'il a été condamné, mais ce type de condamnation pourrait rebondir en mal dans la tête des juges (pourquoi pas jurisprudence) sur une base opposition gratuit vs payant. La libre concurrence, on l'accepte en block ou on l'accepte pas, c'est pas des fois oui des fois non. M'enfin, je ne vais pas faire de politique. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sondage sur le travail collaboratif de saisie de données pour un contributeur expérimenté OSM
Ceci me fait penser à une technique utilisée par Google Maps en Inde, pour générer des descriptions d'itinéraire intégrant des points de référence locaux («à droite après le McDonalds» ...). M mais c'est pas complètement con cette idée. Il y a des choses qu'on ne peut en effet pas déterminer uniquement par leur position. Des notions comme visibilité depuis la route, visibilité car haut, visibilité car gros logo. Il y aurait donc peut-être matière à un tag du genre : visibility=McDonalds pour indiquer qu'un texte McDonalds est très visible de ce coté du bâtiment et peut donc être utilisé comme repérage. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sondage sur le travail collaboratif de saisie de données pour un contributeur expérimenté OSM
D'une part, je me heurte toujours à la subjectivité de la chose. Par exemple, j'ai vaguement connaissance qu'il y a des McMachin autour de chez moi mais je suis incapable de dire où ils sont, je n'y prête pas attention, c'est-à-dire qu'ils ne sont pas visibles pour moi. Je ne nie pas l'aspect subjectif d'un tel tag, mais j'aurais tendance alors à parler de subjectivité majoritaire Dans le sens, où, le fait que tu ne remarques pas qu'il y a un MacDo devant chez toi me semble être limité à peu de cas (dont toi) Et d'autre part, je reviens toujours à la notion de POI. Effectivement, qu'est-ce que le visibility=McDonalds apporte de plus que amenity=fast_food+name=McDonalds ? Il apporte l'information qu'une majorité de gens, si on les interrogerait dans la rue, aurait plus tendance à remarquer la présence d'un McDonalds que d'une borne à incendie. Une sorte de description relative de la visibilité d'un élément par rapport à un autre sur le terrain. Ainsi, je rajouterais le tag de visibilité au mac do, à l'enseigne de l'hotel truc bidule, la pharmacie si elle fait l'angle, mais pas, par exemple, le kinésythérapeute si ça n'est pas visible ou un autre hôtel pourtant placé à coté mais disons moins visible quand on passe en voiture. Clairement, ce tag serait un tag pour le routage, et encore, le routage relativiste ! (celui qui dit, en face de la pharmacie, à droite après le phare) En fait, pour faire ce que présente Google en Inde, je ne crois pas que nous ayons besoin de plus que cette notion de POIs. Libre au développeur de choisir ce qu'il considère comme étant des POIs pertinents pour l'audience à laquelle il s'adresse. Moi aussi, je pensais au début que l'on pouvait laisser ça à un algo, mais j'ai changé d'avis. Deux 2 restaurants côte à côte, indiscernables par leur tags usuels, peuvent très bien avoir un attrait visuel une visibilité déséquilibrée. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Une API pour accélérer l'édition avec JOSM (utile pour les grosses géométries style administratives par exemple)
Yo, (et bon week end) Il y a 2 mois, j'ai mis en place (un peu en secret le temps de tester) un service d'API permettant d'accélérer un peu JOSM quand il doit télécharger des données OSM pour les modifier (En fait, c'est pas sa faute, c'est qu'on est beaucoup à éditer en même temps et tant mieux pour les données, mais un peu dommage d'attendre parfois) Pour des petites zones, ça change pas grand chose, mais quand on veut récupérer des gros trucs (surtout des frontières de plusieurs milliers de points... au hasard ;-) ) ça devient un peu relou. Pour l'utiliser, c'est pas très compliqué, dans les préférences de JOSM (F12) - paramètres de connexion On rentre : http://api.openstreetmap.fr/api au lieu de http://api.openstreetmap.org/api Rien d'autre n'est à changer, même pas login/mot de passe et on peut continuer comme d'habitude. Limitations : - Votre mot de passe transit par mon serveur, et bien que je ne garde rien, je ne peux le prouver, a vous de me faire confiance ou ne pas utiliser - Pas de Oauth - ça ne marche que pour l'europe (pas d'édition en DOM-TOM par exemple) Cas d'utilisation où je trouve ça bien : * Pour décharger un peu le serveur API principal * Lorsque vous voulez télécharger une grosse zone * Pour les grosses frontières * Si vous faites la nuit du bidule truc à donf tous depuis le même réseau et ne voulez pas être bannis pour plus=== Pour les plus tech c'est expliqué ici : http://wiki.openstreetmap.org/wiki/FR:Comparatif_des_formats_de_base_de_données#overpass_api_DB A noter que j'ai mis ça en place qui l'utilise : http://beta.letuffe.org/analyse/cgi-bin/index.py ça marche comme http://analyse.openstreetmap.fr mais ça va plus vite ;-) A noter qu'un plugin vient de sortir pour JOSM qui ajoute une fonctionnalité similaire mirrored_download et qui peut aussi être branchée sur l'overpass_api que j'ai installée citée juste avant. C'est un peu beta, ne fait pas tout, mais permet d'éviter de faire les éditions en passant par mon serveur et permet aussi de choisir différents mirroirs Enjoy, and report bugs -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une API pour accélérer l'édition avec JOSM (utile pour les grosses géométries style administratives par exemple)
Le samedi 4 février 2012 16:40:27, Vincent de Chateau-Thierry a écrit : Testé (et enjoyé) à l'instant, pour la rapidité ça saute aux yeux ! Alors fait gaffe a bien mettre des lunettes de protection ! Je savais que ça pourrait plaire aux éditeurs fou de limites admin ;-) Une question néanmoins : la base attaquée ici a quel âge en comparaison de la base de l'api d'osm.org : autrement dit quel est son décalage de mise à jour : minute, heure, jour ? Si tout va bien (et c'est le cas depuis le début), c'est 2 minutes de retard au maximum Ce qui veut dire que ça peut quand même être un défaut. Par exemple : si tu édites une zone, tu envois tes modifs, tu supprimes le calque osm et tu re-télécharge la même zone dans la foulée alors tu va te retrouver dans l'état d'avant tes modifs. Et si là tu modifies ces données anciennes alors tu va rencontrer un conflit lors de l'envoi (comme si un autre avait fait des modifs en même temps que toi, sauf que cet autre... c'est toi ;-) ) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une API pour accélérer l'édition avec JOSM (utile pour les grosses géométries style administratives par exemple)
Le samedi 4 février 2012 17:19:27, Jocelyn Jaubert a écrit : Le 3 février 2012, sly (sylvain letuffe) a écrit : branchée sur l'overpass_api que j'ai installée citée juste avant. Ça utilise vraiment la même URL que celle qui tu as mises plus haut ? (l'email parle d'utiliser l'API Overpass API plutôt que osm) ça dépend de quel plus haut tu parles. http://api.openstreetmap.fr/api c'est une API 0.6 et le plugin JOSM doit se brancher sur une URL de type xapi (si j'ai bien compris) Donc il faut lui indiquer http://api.openstreetmap.fr/xapi Mais j'avoue ne pas avoir essayé. Et comme il est déjà configuré pour d'autres xapi, j'ai pas eu le courage de me recompiler du plugin et comme ce que j'ai fais m'apporte satisfaction à peu de modif j'utilise ça pour l'instant. Bon, je ne sais pas vraiment ce que ça apporte réellement à JOSM ça lui permet de se centrer directement sur la zone téléchargée. Ce que je trouve d'ailleurs étrange car c'est lui qui a fait la demande, à quoi bon ne pas se centrer sur ce qu'il a lui même demandé. Sans doute dans des cas de téléchargement par objet par id on a ceci en plus: bounds minlat=42.4359746 minlon=3.1737089 maxlat=42.4361953 maxlon=3.1739952/ Est-ce que c'est envisageable d'ajouter ce bounds sur ton API ? C'est possible, mais c'est du traitement en plus. Je vais plutôt attendre que l'overpass_api le supporte plutôt que de le re-coder par dessus. Surtout que c'est pas fondamental il me semble (a moins que ?). -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une API pour accélérer l'édition avec JOSM (utile pour les grosses géométries style administratives par exemple)
Le samedi 4 février 2012 18:34:10, sly (sylvain letuffe) a écrit : http://api.openstreetmap.fr/api c'est une API 0.6 et le plugin JOSM doit se brancher sur une URL de type xapi (si j'ai bien compris) Donc il faut lui indiquer http://api.openstreetmap.fr/xapi Mais j'avoue ne pas avoir essayé. En fait non, ça ne marche pas car JOSM a besoin des éléments version, user, etc. qui ne sont pas fourni par défaut sur l'url que j'ai indiqué Si ça marche sur l'overpassapi officielle c'est que des corrections ont été faites mais qui ne sont pas documentées sur le wiki. Bref, en attendant que je mette à jour toute mon API (qui attendra surement les nouveaux serveur osm-fr) on peut quand même sen sortir, sans compilation et sans trucs insurmontable, ce qu'il faut c'est rentrer cette url dans le plugin mirrored_download de JOSM : http://api.openstreetmap.fr/api/xapi?[@meta] -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une API pour accélérer l'édition avec JOSM (utile pour les grosses géométries style administratives par exemple)
Le dimanche 5 février 2012 15:08:32, sly (sylvain letuffe) a écrit : http://api.openstreetmap.fr/api/xapi?[@meta] Ha ben en fait non. Le plugin josm ne peut pas fonctionner avec la xapi que j'ai installée dans l'état actuel puisque j'arrive pas à faire passer le paramètre [@meta] -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Accueil des nouveaux contributeurs
On lundi 6 février 2012, Gilles Bassière wrote: Bonjour salut, Je vais moi aussi apporter mon grain de sel, car je me suis plusieurs fois retrouvé exactement dans ton cas et je manque un peu de truc à dire ou d'une page à montrer. Je détecte aussi les nouveaux (plus artisanalement, via OWL) et, s'il y a des améliorations à proposer, j'envoie un message. Je fais ça encore plus artisanalement mais ça me permet de ne cibler que ceux qui font des erreurs : - Je repère par keepright ou osmose une erreur - Je constate que cette erreur est répétée par le même utilisateur - Je prend contact, j'explique très pragmatiquement le cas d'erreur que j'ai repéré et je tente d'envoyer 2 ou 3 liens qui lui permette d'avoir les bases - faut-il mieux contacter personnellement le nouveau ou lui envoyer un mail standard au nom de l'association ? (peut-être moins effrayant pour les grands timides ou les accros de l'anonymat ?) Je pense qu'un truc perso-perso fait plus humain, surtout si la zone géographique d'intérêt est la même on peut donner des trucs du coin, et même finir par suggérer d'aller boire une mousse ensemble. - faut-il contacter systématiquement les nouveaux ou seulement ceux qui font n'importe quoi ? Moi j'opte pour la 2 dans une logiquement purement : pour pas que ça empire mais le 1 pourrait avoir son sens dans une logique non t'es pas tout seul - peut-on proposer un guide du débutant ? ou vaut-il mieux écrire des conseils personnalisés après analyse des contributions ? Perso, je fais les deux, c'est à dire ne pas juste envoyer un lien l'air de dire : et ho, tu veux bien arréter de faire des conneries ce qui n'est ni l'envie, ni le but, ni, à mon avis, utile. Le problème c'est que je n'ai pas de guide pour débutant qui fait des erreurs ! Il y a bien ça : http://wiki.openstreetmap.org/wiki/FR:Beginners_Guide Mais c'est trop vague et ça s'adresse plus à celui qui n'a encore rien fait. Si quelqu'un connait mieux à proposer, un truc du genre : les petites erreurs courantes et comment les éviter je suis preneurs. A défaut, si je réuni des courageux, je veux bien m'occuper de la rédaction. Idées : - Les erreurs courantes (routes non connectées, point d'intersection quand croisement, rond point à l'envers, surface non fermée, toponymie, etc.) - ne pas sauter dans l'import de bâtiments trop tôt - ne pas sauter dans l'import de waterway... jamais ;-) - Outil de contrôle recommandé (osmose et keepright) pour s'auto-corriger - à qui demander de l'aide (forum/liste) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] liste local-grenoble [HS ou presque]
Je profite lâchement de cette excellente initiative du LOG pour créer la liste local-grenoble. http://listes.openstreetmap.fr/wws/info/local-grenoble J'espère que l'activisme du LOG et la liste vont permettre l'émergence d'un vrai groupe local (enfin, s'il y a suffisamment de motivés). Je serais pas loin d'être tenté, mais pour l'instant, je lis : Liste locale, pour Grenoble et alentours. Les alentours sont larges jusqu'à la création de listes/groupes voisins. je comprends parfaitement qu'il s'agisse d'un lancement et donc le temps de définir un peu plus les objectifs, je vais questionner : - pour qui ? et pour quoi ? Je me souviens de la création sur osm.org de la liste alpes qui se voulait multi-langue et sur toutes les alpes, mais ça n'a jamais décolé (euphémisme) Je pense que l'idée multilangue, bien que bel objectif, était sans doute en partie la cause de la végétation. En se lançant sur un grenoble on règle le problème de la langue, mais je sens que vous visez un peu petit (c'est juste un feeling sans backup) Il faut au minimum, je pense, réunir une communauté qui partage soit des besoins culturels (restaurant qui vent de la fondue ou st marcelin chaud ;-) ) soit des besoins pragmatiques dans le cadre de OSM pour notre région : accords intercommunaux, transport interdépartementaux, tunnels, la rando, le ski, les barrages, la montagne, les lyonnais qui traîne sur la route, etc. Mais je suis peut-être à coté de la plaque de ce pour quoi est souhaitée cette liste ? D'où ma question du pour quoi ? Sinon, en tant que chambérien, une liste avec un nom tel que local-grenoble n'a que peu de chance de me voir inscrit ! Ha ces dauphinois... -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On mardi 7 février 2012, partir-en-vtt wrote: JOSM propose la correction automatique de la superposition de bâtiment ? Je n'ai pas trouvé. Comment procéder ? Pour ma part, j'ai abandonné ce genre de corrections. Oui oui, je sais, c'est pas bien. Explications : - C'est un boulot manuel de fou - Y'a déjà du pourri dans la base - un logiciel pourrait en réparer une grande partie automatiquement - D'autres ne feront de toute façon pas cette effort J'ai donc jugé qu'il n'y avait que peu d'issues valables à cet état de fait : 1) développer un robot qui nettoye le merdier des bâtiments 2) ne rien faire Dans les deux cas, rien ne justifie selon moi de perdre du temps contributeur qui serait mieux employé à autre chose. ps: je n'ai pas dis que réparer le problème en amont (fichier -houses) n'était pas une bonne idée, je dis que ça n'est de toute façon pas suffisant -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] liste local-grenoble [HS ou presque]
On mardi 7 février 2012, Eric Sibert wrote: une liste SavoieS au pluriel pour ne pas froisser les susceptibilités des gars de la Haute (à prononcer Yote). Yôte ou Yaute, pas Yote. Merde devancé pour le s ou Annecy-Chambéry ou Cartes pentues sub-lémaniques et, si le besoin arrive, une liste régionale. Ou Alpes du Nord, tient!!! Flûte ! devancé encore ! -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Je ne suis pas d'accord sur le c'est pas grave, je pense juste que corriger à la main est une perte de temps qui serait mieux employé. Je suis bien évidement pour qu'un courageux nous développe l'outil qui corrigera ce qui peut se corriger de manière automatique. Corriger le bâti ne nécessite pas tant de travail que ça. Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me semble pas pas tant que ça. Pensez à tous les autres pays qui font ça à la mano en traçant sur l'imagerie et vous comprendrez... Tant pis pour eux, justement, on a pas cette non-chance, c'est pas parce que c'est pire ailleurs qu'on doit accepter de se transformer en robots ! L'import de masse est déjà sévèrement critiqué par nos voisins. Alors si en plus, on ne corrige pas les erreurs géométriques, ça va être encore pire pour notre (déjà mauvaise) réputation. Je suis bien d'accord. Une critique que j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres polygones landuse (sans doute suite à une intervention manuelle, soit dans l'import, soit dans la création du doublon) et qui perdure dans la base pendant des années. Je suis aussi d'accord Je ne fais évidemment pas partie du camps des anti-import mais il faut toujours exiger un minimum de qualité. Déclarer un script s'en chargera plus-tard, c'est prendre le risque que les erreurs ne soient jamais corrigées Pas d'accord, quand bien même l'hypothèse qu'aucun script n'existe jamais, cela n'invalide pas que l'on puisse quand même le faire, a posteriori, à la main. Alors entre le faire tout de suite, et le faire peut-être plus tard, je préfère le peut-être plus tard Certains regrettent d'avantage les imports sans voirie, ou sans correction sur les voiries qui se croisent alors avec le bâti. Mais c'est le même mécanisme qui entre en jeu, celui de dire que d'autres s'en chargeront plus-tard. Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de réparer de manière automatique ce que des humains devraient faire sinon. Dans celui que tu cites, je n'arrive pas à imaginer un processus automatique pour placer des rues entre les bâtiments ou pour savoir où passerait vraiment la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec chevauchement car aucun robot ne pourra le corriger plus tard. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
On mardi 7 février 2012, DH wrote: Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit : Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de christian. Ni moi le tien. C'est ce qui fait le charme (?) de cette liste. C'est même un de ces buts ! confronter des idées et des choix pour tenter d'obtenir une meilleure cohérance. A lire les débats, je crois que moi et christian perdons sur un score sans appel de 7-2 J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce débat démocratique. C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je fasse à la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête de mettre mes cochonneries dans la base. Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur Je me qualifierais de fourmi raisonnée ou de cigale assumée. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti = nettoyage des données cleo carto
Frédéric Rodrigo : - Il y a peut être une solution pas trop compliqué à mettre en œuvre pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction http://postgis.org/documentation/manual-svn/ST_Snap.html Je pense que c'est une solution valable pour nettoyer sa propre copie de la base, pas une méthode pour corriger en amont celle de OSM. Bruno : Un des 2 scripts précédemment postés fait un J JOSM (Join Node to Way)sur tous les noeuds, et donc recolle les bâtiments. Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-) Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je suis sûr que la majorité serait pour un nettoyage automatique, si suffisamment bien fait, de la base OSM (justement pour éviter de se le taper à la main) Le problème a mon avis, il est là : - 10 personnes sur cette liste savent lancer ton programme en python - 6 ont les compétences de l'analyser le tester et l'améliorer - et 0.5 ont le temps de le faire ! En clair, tu as accompli une très bonne première étape : fournir un soft pour nettoyer. Frédéric et/ou jocelyn ont fourni l'outil pour repérer les erreurs (osmose) et Philippe a fourni un export basé sur le soft qadastre de je sais plus qui, qui malheureusement ne fourni pas un export cadastre assez propre (ce n'est pas un reproche) Maintenant, on passe au yaka, c'est à dire trouver celui qui va proposer non pas une brique, mais un résultat final, qui soit facile (ou plutôt très très facile) à contrôler par d'autres. Puis proposer un plan d'action, obtenir l'accord d'une majorité d'exprimés, et le faire. Comme toujours, facile à dire. Donc non, c'est pas qu'on en veut pas, c'est qu'on voudrait bien que tu fasses tout ;-))) Dans la limite de mes compétences+temps, je veux bien filer un coup de main, je vais regarder ce qu'il fait ton bidule et voir comment je peux l'utiliser et voir comment je pourrais par exemple présenter un échantillon avant/après d'un fichier -houses.osm d'une commune. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] nettoyage des imports bâti amont et aval
On mardi 7 février 2012, Bruno Cortial wrote: Salut, Il y a quelques temps, j'avais proposé 2 scripts python pour améliorer les fichiers Cléo. http://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035156.html Je te propose de passer sur la liste dev-fr histoire de ne pas remplir plus ce sujet avant d'y revenir si on a réussi à avancer. Ca n'avait pas eu un grand succès à l'époque je retente ce soir: si des testeurs pouvaient faire un retour sur la qualité des fiabilisations. Hé bé c'est pas facile à lancer ton truc ! les modules python nécessaires ne semblent pas présents dans les debian stables, bon, j'ai réussi à m'en dépêtrer quand même. Quelques remarques à prendre avec pincettes, j'ai pas tout testé : - En effet, comme s'inquiète julien, si deux bâtiments ou deux murs du même bâtiment sont séparés par moins que la tolérance ils sont fusionnés. Si ça pouvait être réservé aux bâtiments qui se chevauches (erreur claire) ça limiterais les fausses corrections - Concernant les noeuds dupliqués, a priori rien à dire, cette correction là me semble tranquille, mais il faudrait peut-être encore abaissé le seuil. J'ai eu le cas d'une entrée d'immeuble qui formait un truc genre : _||__||_ Transformée en : _/\__/\__ Si d'autres veulent se faire une idée de ce que fait le soft de bruno sur un fichier osm réél, on peut s'en faire une idée ici : http://download.letuffe.org/correction-auto-bati/ En bref, ça passe de 320 erreurs de bâtiments se chevauchant, à 60 (selon le validateur) 260 usure de la touche J en moins == concernant le déjà dans la base osm == - J'ai fais une correction pour que le soft conserve les attributs version des relations/ways/noeuds, ce qui permet de travailler sur des données déjà dans osm alors que ta version est prévue pour des fichiers osm neufs (id négatifs) et donc, sans n° de version. Ce qui est logique, pour être lancé juste après l'export par cleocarto -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le dimanche 12 février 2012 11:59:24, Vincent Pottier a écrit : Et bien c'est typiquement ça : tagguer pour le rendu ! +1 A éviter donc ! Si ça avait été un point, une surface... ça aurait qualifié un lieu Heu, selon moi, même pas. quelque soit l'élément si il n'y a que le tag nom, genre : name=pré Je suis bien emmerdé pour savoir ce que c'est. Est-ce un pré et son créateur ne savait pas comment le rentrer ? est-ce le nom d'un lieu ? A la limite, si le hameau est rentré sous la forme d'un segment mais porte bien le place=hamlet, alors au moins on sait ce que c'est. Mais pas sans la tag place. Aucun logiciel ne peut tirer parti de ça sérieusement. Et j'espère que beaucoup l'éliminent dans la chaîne de traitement. Et j'en serais même presque à éliminer le problème à la source, ou en tout cas discuter avec le contributeur sur le pourquoi ce truc. Si l'affichage des nom de lieu ne convient pas sur mapnik, c'est mapnik qu'il faut changer, pas la façon d'entrer l'information dans la base. Ou ne pas l'utiliser, c'est pas les rendus qui manquent ! Il y a le choix ! Pour ma part, je considère le rendu mapnik comme un rendu pour les contributeurs, update rapide, beaucoup d'infos, pas pour les utilisateurs. Le rendu Mapquest ou d'autres, correspondent mieux selon moi à ceux qui veulent du joli pour le montrer -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
On dimanche 12 février 2012, yvecai wrote: C'est vrai que Mapnik (enfin, la feuille de style d'osm) Pour lever l'ambiguité et tenter de rester le plus concis possible, j'aime écrire map...@osm.org à une fâcheuse tendance à marquer tout les tags 'name='. Est-ce vraiment fâcheux ? Le problème est sans doute que ce rendu, dont l'importance en tant que rendu par défaut du site osm.org ne peut être ignorer, est utilisé par différentes personnes aux objectifs divers et aux besoins divers. Avec la disparition programmée de osmarender, qui était un rendu avec l'avantage d'afficher un max de données osm. On va se retrouver selon moi avec un vide à combler, celui d'un rendu pour les contributeurs. Un rendu qui puisse afficher plein de donnée et permettre de contrôler, dans les minutes après sa contribution si on a pas oublié un truc, fait une erreur, dégommé une forêt, etc. Et, selon moi toujours, c'est le rôle du rendu vitrine du site osm.org. osm.org n'est pas google maps, les serveurs d'osm.org n'ont ni les moyens, et ses admins les envies d'en arriver là. Le fait que le rendu map...@osm.org soit visible sur de nombreux sites tiers dans une logique consommation est déjà, à mon sens, une erreur. Erreur dû au passé, avant, il n'y avait simplement pas le choix car il n'y avait que ça. Mais maintenant, les choses ont changées, je suis donc en faveur pour que map...@osm.org deviennent un rendu toujours plus moche, toujours plus à jour, toujours plus saturé d'info, bref toujours plus à destination du contributeur. Alors oui aux noms qui apparaissent à l'arrache, oui aux noms des communes en double des chef-lieu, en double des traits taggués pour le rendu et des relations type=route qui n'ont pas de rendu. Pourquoi ? pour qu'on puisse les voir ! Et qu'on puisse les vérifier, les zigouiller ou les améliorer. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
On lundi 13 février 2012, Hélène PETIT wrote: Le 13/02/2012 12:40, sly (sylvain letuffe) a écrit : Mais maintenant, les choses ont changées, je suis donc en faveur pour que map...@osm.org deviennent un rendu toujours plus moche, toujours plus à jour, toujours plus saturé d'info, bref toujours plus à destination du contributeur. 1) si map...@osm.org devient un outils contributeur, il n'a rien à faire comme visualiseur par défaut du consommateur ordinaire. Tout à fait d'accord. Donc (selon moi bien sûr): - Soit le consommateur ordinaire n'a rien à faire là, celui qui l'y a amené n'a pas présenté osm à un consommateur de la meilleure façon. - Soit le choix du rendu par défaut ne devrait pas être map...@osm.org, ce en quoi on avance doucement, vu que OpenMapquest a fait son apparition dans la liste des rendus possibles. - Soit présenter une carte sur osm.org n'est peut-être pas une bonne idée finalement, et on ferait mieux d'indiquer un top 10 des plus belles utilisations, votées par les consommateurs, et leur dire : va voir là bas si l'utilisation de notre base est pas plus belle. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet
On lundi 13 février 2012, Hélène PETIT wrote: le consommateur ordinaire est arrivé là en tapant : openstreetmap.org dans son navigateur. Il est rare que l'on tape encore des adresses, disons qu'il a cherché openstreetmap dans google. Mais sans doute qu'il a entendu ce nom ou qu'on lui a donné ce nom, et c'est peut-être là qu'il faut faire quelque chose. Avant openstreetmap, si un copain me demande un site pour calculer des itinéraires, voir des cartes et chercher un lieu, je lui donne le nom de mappy par exemple, pas celui de Navtek Aujourd'hui, pareil, mais avec du osm dans le moteur, je ne lui donne pas le nom d'openstreetmap, ou en tout cas pas tout de suite, je lui donne d'abord : maps.cloudmade.com, OpenMapquest, etc. là, il est content car ce sont des trucs qui marche ! Et lorsqu'il repère des erreurs ou qu'il veut aller plus loin, je lui dis qu'il peut aider à compléter la base en allant sur osm.org Si je lui avait donné le site osm.org tout de suite, il se serait peut-être tiré en courant chez gmaps, hé ho il est fou lui, c'est naze son bidule -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès KO au suivi des communes
On jeudi 16 février 2012, Vincent de Chateau-Thierry wrote: Bonjour, J'ai une erreur 403 en voulant accéder au fichier de suivi des communes : Whaaa ! Y'en a qui sont vraiment tout le temps le nez dessus ! J'ai fais deux trois modif il y a même pas 10 minutes que tu es déjà à l'affût ! En tout cas merci pour ta surveillance ! http://suivi.openstreetmap.fr/communes/communes.csv.txt C'est moi, ou bien ? J'en déduis que le dossier que je viens de virer servait en fait à quelque chose. Je pense que je vais retirer le karsher de mes outils pour faire le ménage... -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès KO au suivi des communes
Euh, oui, il vaut mieux, car je l'utilise aussi dans un script. et hop, réparé, et rangé, il devait bien y avoir 3 liens qui se pointaient les uns les autres je savais plus quel fil il fallait tirer. Je te recommande toutefois de faire une mise en cache de ton coté sur tu as besoin du fichier csv de manière un peu plus stable, ça arrive souvent qu'entre ré-import de la base, bidouilles et tests divers je casse le bidule avant le remettre en route ultérieurement. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès KO au suivi des communes
On jeudi 16 février 2012, Vincent de Chateau-Thierry wrote: Je vois que c'est déjà de retour, et à jour siouplaît. Merci m'sieur ! J'ai changé la procédure de vidange des fichiers du cadastre, un calcul est en cours qui devrait se terminer d'ici quelques minutes avec les nouvelles communes vectorisées par le cadastre. Au début je ne voulais pas le faire trop souvent pour éviter de se faire mal voir du cadastre, mais comme la vectorisation avance bien de leur coté, j'ai resserré les délais pour aller chercher les nouvelles communes tous les 5 jours. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès KO au suivi des communes
09, ariège, 6 vectorisées sur 331, depuis la nuit des temps :((( C'est quoi l'ariège ? Et puis, tu es mauvaise langue, je me rappel qu'il y a pas plus tard qu'en 2008 qu'il n'y en avait que 3. x2 en 4 ans, à ce rythme là, ça devrait être vite fini vers 2030 ;-)) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Accès KO au suivi des communes
On jeudi 16 février 2012, THEVENON Julien wrote: il serait peut etre interessant aussi d avoir la possibilite d indiquer qu on a importe/retravaille les limites de la commune pour la sortir de la liste A mon avis, ça n'est pas utile, puisque une fois la limite importée, elle disparaîtra d'elle même de la liste le lendemain à 4h00 quand le calcul sera refait. Seul cas de figure, quand les acharnés des limites se jette sur la même commune le même jour ;-) auquel cas je pourrais voir avec Jocelyn si ça vaudrait le coup de lancer une mise à jour vers 13h00 par exemple -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Accès KO au suivi des communes
On jeudi 16 février 2012, Cedric Viou wrote: Pendant qu'on y est: http://osmose.openstreetmap.fr/map/?item=7020 qui utilise le même .csv. Il est précieux ce fichier!!! Décidément, c'est pas croyable ! C'est si fun que ça d'analyser mes fichiers textes tout pourri prévu pour être lus par un humain ? Pour une fois, yaka demander et je vous en fourni un truc tout joli en csv. Ça sera quand même plus robuste dans le cas où je décide de changer le nombre de # ou la syntaxe ! Je viens de l'ajouter pour la prochaine génération, un joli fichier csv des communes au format image qui restent à importer. Concernant osmose, on dirait que ça ne se base pas que sur le fichier d'ailleurs, tu sais comment les coordonnées de la commune sont récupérées ? car mon fichier ne les contient pas. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Accès KO au suivi des communes
On jeudi 16 février 2012, Christian Quest wrote: Je m'en sert ici: http://openstreetmap.fr/outils/limites-communales-a-importer (en travaux) Oulla, tu utilises le fichier bâtard et tu parses le fichier à la vas y que ça galère ? Genre celui-là : ? http://suivi.openstreetmap.fr/communes/suivi-vectoriel.txt Il ne faut pas hésiter à m'en parler quand tu te lances sur ce genre de truc bancal, sur simple demande je te génère le fichier top moumoute qui va bien, car dans le traitement évidement, j'ai ça sous une forme propre et c'est 2 lignes pour t'en sortir de fichier csv que tu aura quand même moins de mal à traiter. D'ailleurs, pof : http://suivi.openstreetmap.fr/communes/ (enfin, presque pof, la génération est en cours) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Accès KO au suivi des communes
On jeudi 16 février 2012, THEVENON Julien wrote: Je pensais plutot au cas des communes qui ont ete importees a partir du cadastre Raster georeference manuellement et qu on voudrait verifier/retravailler une fois la commune dispo en vectoriel Pas con, mais ça, ça n'est pas possible en se basant uniquement sur les fichiers que je génère concernant le suivi des communes puisque le cas de commune que tu présentes ne sera pas dans la liste vu qu'elle est présente dans OSM. (ne sont listées que les communes dont la limite n'est pas dans OSM) Il faudrait recroiser les informations avec celles d'avant... pas forcément simple. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Accès KO au suivi des communes
On jeudi 16 février 2012, Cedric Viou wrote: complété par un parseur des pages de : http://fr.wikipedia.org/wiki/Listes_des_communes_de_France et le clavier quand le parseur se plante dans une page. Boudiou ! J'imagine qu'a coté de ça, regexper mon fichier ça devait être du gâteau. Mais bon, j'imagine que le csv de chez guichon t'a sans doute fourni une large majorité des coordonnées. Flûte, ça m'étonne qu'il n'y ait pas une source un peu plus exploitable (à part osm bien sûr ;-) ) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Accès KO au suivi des communes
On jeudi 16 février 2012, Vincent de Chateau-Thierry wrote: Désormais, et code postal mis à part, il y a le GeoFLA : code INSEE, nom, et coordonnées arrondies, mais suffisantes pour un affichage Osmose, non ? Ha mais oui ! Bien vu, je l'avais oublié celui-là. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] mongeosource utilise OSM
Le jeudi 16 février 2012 20:38:37, partir-en-vtt a écrit : J'ose espérer que le BRGM avec ses nombreux serveurs n'utilise pas directement le service ! Il serait intéressant de leur poser la question. Peut-être peut-on le savoir en analysant les flux de données avec un firebug par exemple ? Pas besoin d'outils compliqués, avec firefox tu te ballades sur la carte et en bas à gauche à l'endroit qui affiche Terminé tu vois apparaître l'adresse du site où sont télécharger les tuiles (entre autres) et on peu en effet voir tile.openstreetmap.org -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] débat type=waterway, side_stream, source, tributary
Salut, Pour ceux qui seraient intéressé, un vote a été proposé sur la relation type=waterway, ce qui implique discussions ;-). Avec plus de membres de la communauté international que nos petits débats internes qui n'ont jamais trouvés d'issue. Une ouverture plus grande pour faire s'affronter (en tout bien tout honneur et courtoisie) le sly's modèle contre le frédéric's modèle ? Je propose ça sur cette liste car il me semble que la France est un des pays (sinon le plus ?) utilisateur de la relation type=waterway et je trouverais dommage que ça se passe sans nous. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : débat type=waterway, side_stream, source, tributary
Mais quel boulet je fais ;-) J'ai oublié de donner le lien. Il s agit de celle ci http://wiki.openstreetmap.org/wiki/Relations/Proposed/Waterway ? C'est celle-là j ai vu qu il y aussi celle ci http://wiki.openstreetmap.org/wiki/User:Frodrigo/Relation:Waterway Mais celle-là est le modèle de frédéric, et bien utilisée en france, je pense qu'elle peut tout à fait faire partie de la discussion. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] téléchargement d'une zone trop grande
On mercredi 22 février 2012, sukran.geo sukran.geo wrote: Bonjour, J'ai une zone dans OSM que je veux télécharger, mais... apparemment, elle est trop grande, et voici le message qui s'affiche. (voir JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais idem, pb de taille. Que faire ? Il me faut toute la zone, et je ne veux pas pas faire plein de petits morceaux. Elle est grosse comment ta zone ? Parce que si tu veux ouvrir un département complet dans JOSM, il vaut mieux oublier tout de suite et faire autrement ;-) Si c'est raisonnablement petit, mais que l'api officielle te bloque, dans JOSM tu peux tenter de remplacer api.openstreetmap.org par api.openstreetmap.fr les limites en téléchargement son plus élevées -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM
On mercredi 22 février 2012, Philippe Verdy wrote: Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de réplication sur des miroirs synchronisés, capables de répondre de concert à une même requête. Quelques idées suivent... (...) TL;DR yaka http://lists.openstreetmap.org/pipermail/dev/2011-December/023976.html FDIY ps: Zut je m'étais promis de ne pas craquer, au moins la moyenne de nos deux messages atteignent presque une taille raisonnable. -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM
On mercredi 22 février 2012, Emilie Laffray wrote: Postgresql merde quand il y a des tables temporaires. C'est un bug connu qu'on espere voir corrige dans 9.2. Que postgresql s'améliore sur ce point c'est bien, mais je ne suis pas sûr que ça soit la meilleure voie car cela restreindrait à postgresql là ou des mirroirs dans d'autres schémas, base, formats pourraient profiter d'une réplication temps réél. Mais quoi qu'il en soit, ça sera du boulot et je souhaite beaucoup de courage à ceux qui vont se lancer dans le projet -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes)
Au risque de nourrir un troll... Ouais mais on peut, c'est trolldis ;-) PHP dispose de peu de modules pour traiter l'information géographique Il est vrai, mais c'est pas très important car il est possible de faire une grosse partie du traitement géographique du coté du moteur spatial. php, ce n'est que la colle entre le moteur de base de donnée et l'interface utilisateur (html/navigateur/javascript) Le problème à mon avis dans SIG pour tous tel que cyrille le souhaiterais, c'est la non disponibilité de bases spatiales chez la plupart des hébergeurs à pas cher et ça, ça va être difficile de s'en dépêtrer. Pour avoir développé sur www.refuges.info de nombreux éléments qui s'approchent des SIG (polygones, intersections, appartenance, recherche de proximité) je peux dire que le problème n'a pas vraiment été php, mais bien le moteur MySQL sous-jacent que j'ai converti misérablement et à grand frais de CPU perdu et redondance en moteur à peine spatial. (et quand je vois le résultat, je tire mon chapeau à l'équipe postgis !) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Changements incomplets sur les différents niveaux de zoom
On vendredi 24 février 2012, Philippe Verdy wrote: OK, donc le problème est ailleurs. Osmosis sans doûte puisque c'est par lui que ça transite et non l'API utilisée par les éditeurs. Mais comment fait alors Mapquest qui passe aussi par Osmosis ? Sauf erreur, c'est osm2pgsql qui sert à construire et maintenir à jour les bases de la quasi totalité des rendus en ligne par tuiles. (J'exclus les rendu dynamiques offline que l'on trouve sur android/garmin/iOS) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
