Re: [OSM-talk-fr] Carte de randonnée
> http://beta.letuffe.org/?zoom=15&lat=46.36174&lon=6.83624&layers=000B00FFFet > les zooms supérieurs. Celui-là, à la limite, je dirais que c'est encore bon, pour ceux d'après les couleurs et les ombres ne veulent plus rien dire. > > Pourquoi la retirer ? Elle m'est au contraire assez utile, c'est juste > qu'il serait bien qu'elle soit plus fine. Sans blagues ? ;-) C'est juste que la donnée n'est pas disponible librement pour du plus "fin" > > > > Par ailleurs, ne serait-il pas possible de mettre en blanc les régions de > > > neiges éternelles (disons 3000m pour prendre un peu de marge) ? > > > > J'y avais pensé, ce sera pour la prochaine version > > > > Te serait-il possible de m'adresser la feuille de style que tu utilises ? > Je voudrai lancer le même genre de truc. hop + l'indispensable : http://wiki.openstreetmap.org/wiki/HikingBikingMaps Bon courage tout de même, il faut du temps, et c'est loin d'être simple -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org hiking.xml.gz Description: GNU Zip compressed data ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : limite communales - Etat d'avancement
> J'aurais imaginé une région frontalière Pourquoi l'Autriche ? > Ah, le mystere des polygones. Je n'ai pas basée ma requête sur un polygone mais sur le fait qu'il y est une ref, ce qui n'est le cas quasiment que des départements français... "quasiment" -- 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] Re : limite communales - Etat d'avancement
> Bon, j'ai essayé quelques bidouilles, j'ai même supprimé et réenvoyé > les données pour la relation 122751, rien n'y fait :( Et bien ma foi, j'y retourne. L'import que j'ai fais depuis geofabrik était le tout premier "réparé" selon frédérik. Peut-être ne l'était-il pas. Je tente actuellement un import de la france uniquement (plus rapide ~1h) pour vérifier si oui où non le problème vient bien de là. Je solliciterais votre aide de béta-testeurs sous peu -- 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] Re : limite communales - Etat d'avancement
> Ben, le coin dont je parle allait très bien jusqu'a ce que j'upload cette > commune hier. N'arrivant pas à me connecter sur l'api OSM pour contrôler, je livre ce que j'ai dans ma base : Je viens de passer le layer commune et département sur un import de la france, merci de me dire ce que ça change pour vous. ( ne pas tenir compte, comme l'a dit étienne, des frontières) En ce qui concerne la relation 122751 Frayssinet-le-Gélat, dans ma base il manque le boundary=administrative dans l'import de ce midi. Dès que j'ai accès à http://www.openstreetmap.org/browse/relation/122751 je regarde si c'est confirmé dans l'historique. Sinon, l'oise est de retour, ce qui confirme un problème sur mon import de la semaine dernière (way manquant, noeud perdu, relation incomplète, que sais-je) -- 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] Re : limite communales - Etat d'avancement
> Qui bien sur, vient d'apparaître :-) Donc, rien à remarquer de spécial avec cet import ? (données de cette nuit 0h00) si le problème est confirmé comme réglé, je vais ré-importer l'europe -- 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] Re : limite communales - Etat d'avancement
> Qui bien sur, vient d'apparaître :-) Openstreetmap ne m'aime pas aujourd'hui, je peux pas utiliser l'api et la liste de diffusion ne me transmet que 50% des mails, d'après http://lists.openstreetmap.org/pipermail/talk-fr/2009-April/008865.html tu sembles dire que c'est bon. Je lance le ré-import de l'europe, downtime de ~12h Non seulement on va me guillotiner, mais on m'éléctrocutera juste après... -- 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
[OSM-talk-fr] Carte de randonnée - bis
(Désolé de casser le thread, mais je n'ai pas eu cette partie de la discussion que je viens de voir sur les archives talk-fr ) > Sylvain refait un import global si j'ai bien compris, la base est sans > doute vide, seul le cache subsiste pour les zoom ≥13 mais n'est donc > pas à jour... > Yann C'est exactement ça, sauf que le cache subsiste pour les zooms inférieurs ou égaux à 13 et pas supérieurs. Mais... histoire de dire que je suis tordu ça n'est pas vrai pour 3 layers : "hiking", "relief" et "cfd" qui ont du cache pour absolument tous les zooms Pour ceux qui ont tenté de dessiner des courbes de niveaux, ils comprendront pourquoi j'ai fais ça ;-) >Le 30 avr. 09 à 15:26, Stéphane Brunner a écrit : > Hello ! > > Pour ce zoom c'est normale, par contre il me semble qu'il y a un > problème sur les zoom 10, 11 et 12 ! > http://beta.letuffe.org/?zoom=10&lat=46.36174&lon=6.83624&layers=000B00FFF Donc bref, dans les liens que stéphane vient de donner vu qu'on voit quelque chose, c'est qu'il y a bien du cache (sinon on verrait un truc tout rose) et là, je ne comprends pas trop de quoi vous parlez. Stéphane, tu as vu quoi exactement ? "The truth is out there ?" qu'entends tu par "problème" ? (parce que je peux en lister bien 5 ou 6, mais je parlerais alors de "comportement connu, non souhaité, mais difficilement contournable" ) PS: n'hésitez pas à me mettre en copie en direct aussi, la liste ne m'envoi pas tout -- 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] Carte de randonnée - bis
Tiens, je me reçois... Pour éric : >A défaut de données plus précises, rien n'interdit de faire un petite >interpolation, style bi-cubique, pour lisser les pixels quand ils >deviennent gros. Ca risque par contre de plomber un peu le serveur >mais les coefs de l'interpolation étant constants d'un carré au >l'autre, ça doit pouvoir se tabuler. >Idem, pourquoi ne pas tenter de lisser les courbes de niveau? Genre >spline ou bézier (vérifier quand même que les courbes voisines ne se >croisent pas!!!) > Mes 0,02 € 2 cents ? t'es pas cher de l'heure ;-) Pour info, j'ai tenté pas mal de truc avec les outils gdal et l'aide précieux de stéphane, mais tout n'est pas simple et j'ai fini par abandonner et laisser ce que vous voyez, mais il y aurait plein de truc à améliorer. Je passe par une première interpolation de ma source pour effectuer une reprojection vers mercator et une augmentation de la résolution en bilinear pour passer à une donnée lissée dont les pixels d'origine de précision 90m passent à 30m pour avoir une meilleure granularité (pas de miracle, ça ne rajoute pas de donnée, ça rend juste moins moche pour la suite) Ensuite, je peinture le bazar avec ombres et couleur. Mon pixel fait toujours 30x30m et Mon fichier pour les alpes fait la bagatelle de 1.5Go, idéalement il faudrait passer encore en dessous genre 10x10 par un nouveau bilinear filtering sur les pixels de couleurs, mais je vous laisse imaginer la taille final de mon fichier. Géotiff que j'utilise étant limité à 4Go, boom je suis dedans Ou alors comme tu le propose, le faire en temps réél sur les tuiles que je sert, mais on verrait de pas belles jonctions, et bonjour la charge sur le serveur. On notera également dans ma bagarre de conversion un très laid phénomène d'intérférence que je n'ai pas identifié qui créer des bandes de O-NO à E-SE Concernant les courbes de niveau, je les constituent avant interpolation, et je m'en sort avec 15Go de courbes dans la base !! j'ai eu tenté de faire l'interpolation 90x90m->30x30m avant de générer mes courbes, et il fallait environ 5s pour une seule tuile (courbes tous les 10m) et je sais plus combien de Go dans la base. Je n'ose même pas imaginer après une interpolation par courbes de bézier que postgres ne saura stocker que en linestring !! Ma conclusion fût que j'ai d'autres trucs à améliorer avant d'en arriver là, et que des machines avec 16Go de RAM à pas cher m'aideront bien dans l'avenir -- 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] Re : limite communales - Etat d'avancement
On Thursday 30 April 2009 11:59, Yann Coupin wrote: > Sly, si tu nous lis, tu peux jetter un coup d'œil au contenu de ta > base stp ? Au moins sur les exemples donnés, je suis curieux de savoir > ce qu'il en est... Ou ben ! Je viens de le recevoir celui-là, ben donc je ré-importe, après avoir été convaincu que mon dernier import en avait oublié dans les coins -- 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] Re : limite communales - Etat d'avancement
On Monday 04 May 2009 10:06, Pieren wrote: > 2009/5/4 Antoine : > > De quand date ton export ? > > > > Antoine > > > > Je n'ai pas fait d'export. Pour la progression dans OSM, j'ai repris > le message de Sly du 29 avril. Je n'ai pas changé les départements > manquants. Ma méthode de détermination du nombre de commune dans un département semble buggée, ces résultats ne sont donc qu'indicatifs. La cause probable étant que les communes en bordures ne sont pas toujours considérées comme étant à l'intérieur. Le fonctionnement de postgis n'étant pas encore complètement clair, je soupçonne des histoires d'arrondis et de nombre réél qui font que une commune de bordure peut ou non être considérer comme dedans. Je n'ai pas de solution dans l'immédiat. -- 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] Problèmes avec un mapnik compilé maison
On Tuesday 05 May 2009 15:15, Stéphane Brunner wrote: > Hello, > > dans ton fichier de style tu réfère des fichiers de world-boundaries > que tu n'a certainement pas télécharger ! > http://wiki.openstreetmap.org/wiki/Mapnik#World_Boundaries $ strace ./generate_image.py 2>&1 | grep open peut aussi s'avérer très utile pour vérifier ce qui lui manque > 2009/5/5 OSM Léon : > > Bonjour, > > > > Vous êtes mon dernier espoir :D > > > > J'essaie de suivre le tutoriel suivant > > (http://www.drazzib.com/projets:openstreetmap:postgis_mapnik_tile_server ) > > pour installer mod_tile sur un serveur perso. Je compile mapnik, tout va > > bien, sauf quand je cherche à lancer ./generate_image de mapnik. > > > > Quelque soit la bbox que je spécifie et bien que les world_boundaries soient > > dans le bon répertoire, j'obtiens le message suivant : > > > > File "./generate_image.py", line 37, in > > load_map(m,mapfile) > > UserWarning: /home/X/carto/data/world-boundaries/shoreline_300 does not > > exist in layer 'world' > > > > Quelqu'un saurait-il m'aider ? Merci d'avance. > > > > Thomas > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-fr > > > > > > > > -- > Stéphane Brunner > mail : stephane.brun...@gmail.com > messageries instantanées : stephane.brun...@gmail.com (http://talk.google.com) > -- > Un peu d'espace qui vous suis partout - > https://www.getdropbox.com/referrals/NTk2OTU2Mjk > -- > http://mozilla-europe.org - Navigateur internet / Client de messagerie > > ___ > 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] Problèmes avec un mapnik compil é maison
> Quant à strace (là je comprends plus rien...) il m'indique plein de fichiers > qu'il ouvre mais aucun dans mon /home/goon/data... > > $ strace ./generate_image.py 2>&1 | grep open Une fois que tu as fais le "| grep open" il te sortira toute la liste des appels systèmes visant à ouvrir un flux local (en général un fichier) à toi de rajouter le bon grep qui va bien en plus pour éviter de le voir ouvrir toutes les librairies et autres fichiers de config genre : $ strace ./generate_image.py 2>&1 | grep open | grep goon et là, les "-1 ENOENT (No such file or directory)" devraient s'éclairer -- 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] CORINE Land Cover France comme sou rce de données
Vraiment chouette nouvelle en effet ! Bravo a toi pour le boulot. Comme qui dirait l'autre, yapuka. A la lecture du wiki, je me dis qu'il y a déjà un sacré boulot de fait pour la correspondance, je vais y faire un tour -- 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] Beta letuffe - avancement communes - erreur bizarre
> Ce soir je me suis aperçu que sur beta letuffe un certain nombre de communes > sont rendues en gris. > Qu est ce que cela signifie ? Que les humeurs de l'admin ont changées ;-) Petit blabla du pourquoi j'en suis arrivé là : - j'avais déjà fourni des statistiques concernant le nombre de commune présentes dans OSM par département. Comme beaucoup l'ont remarqué, c'était assez peu fiable dû à un problème technique que je n'ai pas trop compris. Pour améliorer les choses, j'ai trouvé une fonction postgis qui donne un point à l'intérieur d'une surface et évitait les erreurs de bordures. Bref, en voilà le résultat (en annexe) qui me semble bien plus cohérent et bien meilleur. Mais je me suis heurté à un nouveau problème, sur certaines communes j'obtenais l'erreur : "TopologyException: found non-noded intersection" (erreur de topologie) J'ai pu ignorer ces communes problématiques en les passants à la fonction st_isvalid() qui détermine si la géométrie est "valide" ou non. Les communes en gris sont considérées comme invalides dont la définition en langage postgis est : "Returns true if this Geometry has no anomalous geometric points, such as self intersection or self tangency." Ce n'est pas nécessairement un problème, j'imagine que des communes peuvent quand même avoir cette forme (quoi que ?) mais ça permet de les indiquer et vérifier ce qui plus probablement est une erreur. Cependant, j'en ai vérifié une rapidement pour voir et je n'ai pas trouvé d'auto-croisement ni de truc bizzarre, c'est peut-être donc des fausses alertes Annexe 1 stats : Total:6784 (sans compter les départements oubliés) donc 18.5% de communes françaises sont présentes dans OSM ref;name;id relation;count 01;Ain;7387;22 02;Aisne;7411;114 03;Allier;7414;139 04;Alpes-de-Haute-Provence;7380;2 05;Hautes-Alpes;7436;21 06;Alpes-Maritimes;7385;21 07;Ardèche;7430;124 08;(none);(not in db);(unknown) 09;Ariège;7439;2 10;(none);(not in db);(unknown) 11;(none);(not in db);(unknown) 12;Aveyron;7451;159 13;Bouches-du-Rhône;7393;101 14;Calvados;7453;119 15;Cantal;7381;22 16;Charente;7428;146 17;Charente-Maritime;7431;117 18;Cher;7456;15 19;Corrèze;7464;94 20;(none);(not in db);(unknown) 21;Côte-d'Or;7424;134 22;(none);(not in db);(unknown) 23;Creuse;7459;236 24;(none);(not in db);(unknown) 25;Doubs;7462;206 26;Drôme;7434;302 27;Eure;7435;47 28;Eure-et-Loir;7374;24 29;Finistère;102430;8 30;Gard;7461;46 31;Haute-Garonne;7413;67 32;Gers;7422;399 33;Gironde;7405;297 34;(none);(not in db);(unknown) 35;(none);(not in db);(unknown) 36;Indre;7417;30 37;Indre-et-Loire;7408;129 38;Isère;7437;213 39;Jura;7460;21 40;Landes;7376;211 41;Loir-et-Cher;7399;2 42;Loire;7420;100 43;Haute-Loire;7452;25 44;Loire-Atlantique;7432;135 45;Loiret;7440;30 46;Lot;7454;323 47;Lot-et-Garonne;7416;44 48;Lozère;7421;31 49;Maine-et-Loire;7409;9 50;Manche;7404;19 51;Marne;7379;7 52;(none);(not in db);(unknown) 53;Mayenne;7438;2 54;(none);(not in db);(unknown) 55;(none);(not in db);(unknown) 56;(none);(not in db);(unknown) 57;(none);(not in db);(unknown) 58;(none);(not in db);(unknown) 59;(none);(not in db);(unknown) 60;Oise;7427;3 61;Orne;7419;2 62;Pas-de-Calais;7394;11 63;Puy-de-Dôme;7406;182 64;Pyrénées-Atlantiques;7450;2 65;(none);(not in db);(unknown) 66;Pyrénées-Orientales;7466;90 67;Bas-Rhin;7415;187 68;Haut-Rhin;7403;218 69;Rhône;7378;36 70;Haute-Saône;7423;8 71;Saône-et-Loire;7397;17 72;Sarthe;7443;326 73;Savoie;7425;300 74;Haute-Savoie;7407;293 75;Paris;71525;1 76;Seine-Maritime;7426;124 77;Seine-et-Marne;7383;86 78;Yvelines;7457;90 79;(none);(not in db);(unknown) 80;Somme;7463;40 81;(none);(not in db);(unknown) 82;Tarn-et-Garonne;7388;58 83;Var;7390;21 84;Vaucluse;7445;63 85;Vendée;7402;20 86;(none);(not in db);(unknown) 87;(none);(not in db);(unknown) 88;(none);(not in db);(unknown) 89;(none);(not in db);(unknown) 90;Territoire-de-Belfort;7410;102 91;Essonne;7401;56 92;Hauts-de-Seine;7449;36 93;Seine-Saint-Denis;7389;16 94;Val-de-Marne;7458;47 95;Val-d'Oise;7433;34 96;(none);(not in db);(unknown) 97;(none);(not in db);(unknown) 98;(none);(not in db);(unknown) 99;(none);(not in db);(unknown) Total:6784 -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ref;name;id relation;count 01;Ain;7387;22 02;Aisne;7411;114 03;Allier;7414;139 04;Alpes-de-Haute-Provence;7380;2 05;Hautes-Alpes;7436;21 06;Alpes-Maritimes;7385;21 07;ArdÚche;7430;124 08;(none);(not in db);(unknown) 09;AriÚge;7439;2 10;(none);(not in db);(unknown) 11;(none);(not in db);(unknown) 12;Aveyron;7451;159 13;Bouches-du-RhÃŽne;7393;101 14;Calvados;7453;119 15;Cantal;7381;22 16;Charente;7428;146 17;Charente-Maritime;7431;117 18;Cher;7456;15 19;CorrÚze;7464;94 20;(none);(not in db);(unknown) 21;CÃŽte-d'Or;7424;134 22;(none);(not in db);(unknown) 23;Creuse;7459;236 24;(none);(not in db);(unknown) 25;Doubs;7462;20
Re: [OSM-talk-fr] Beta letuffe - avancement communes - erreur bizarre
> Ca peut être une deuxième boucle mais aussi un segment du way qui > revient en arrière puis à nouveau vers l'avant sur les mêmes noeuds. J'ai fini par trouvé, c'était bien un croisement, merci pour l'idée en tout cas. > C'est assez difficile à trouver (il faut bien regarder les flèches sur > Josm ou - si mes souvenirs sont bon - utiliser le plugin validator). J'avais bien pensé que la validator m'aiderait, mais je viens de re-vérifier et il n'annonce pas un auto-croisement comme une erreur -- 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] Beta letuffe - avancement communes - erreur bizarre
> Cependant, j'en ai vérifié une rapidement pour voir et je n'ai pas trouvé > d'auto-croisement ni de truc bizzarre, c'est peut-être donc des fausses > alertes Je viens de trouver un cas de fausse alerte : Lorsque la commune est en deux parties ou plus une erreur "Hole lies outside shell at or near point" est sortie par postgis ce qui ne rend pas pour autant la commune erronée. J'aimerais vous proposer une jolie croix à l'endroit du problème, mais je n'ai pas trouvé comment faire, donc c'est peu fastidieux -- 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] Beta letuffe - avancement communes - erreur bizarre
> Donc, on va dire que les communes que j'ai fait qui ont enclave/exclave > sont bonnes et que je ne vais pas avoir à les corriger :-) hop j'ai trouvé comment retirer l'erreur pour les communes en plusieurs morceaux -- 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] Polygone france
On Tuesday 12 May 2009 17:26, Sibert Marc wrote: > Bonjour, > Je suis à la recherche d'un polygone de la france pas trop riche 100 points. http://wiki.openstreetmap.org/wiki/WikiProject_France/Fonds_de_cartes france.gpx et un coup de gpsbabel simplify ? -- 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] Beta letuffe - avancement communes - erreur bizarre
> Et donc, toutes les communes pas en plusieurs morceaux sont en gris ? > (parce que c'est comme ça, là) L'art des modifications sans tests, heureusement qu'ils y'a des bétatesteurs qui me surveille C'était un poil terne ;-) -- 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
[OSM-talk-fr] corine, corine, je t'aime ! (shp et autres projections)
Depuis les bonnes nouvelles sur corine, je me suis lancé dans l'intégration et la représentation, couplé à osm, de leurs données. Histoire d'avoir une idée de ce que pourrait rendre la france quand on aura fait l'import. Mais je patauge, quelqu'un a-t-il déjà fait des tests avec les données dispo ici : http://sd1878-2.sivit.org/ J'utilise la projection WGS84, j'importe dans postgis, je bidouille, et ça ne sort rien. J'ai l'impression bizarre que lat et long ont été intervertis dans leur fichiers. Alors j'ai tenté d'en ouvrir un petit avec qgis histoire de voir, et mon qgis me plante à la g bilan, j'arrive pas à tester. Quelqu'un peut me dire ce qui se passe quand il ouvre ce petit shp ? http://slyserv.dyndns.org/osm/CLC06_WGS.zip les coordonnées ont elles l'air correctes ? -- 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] corine, corine, je t'aime ! (shp et autres projections )
> le layer=-1 permet : > - d'avoir une sortie qui n'efface pas les rivières (...) >. layer=1 signifierait, "occupation du > terrain par défaut". Hmmm, ça ressemble typiquement à l'adage "on ne tague pas pour le rendu" Le tag layer est prévu pour : http://wiki.openstreetmap.org/wiki/Layer "It describes the relative position of map features and is most commonly seen with bridges and tunnels." "Some people also use the layer tag to "fix" render issues. This is not an appropriate use." ça s'occupe des élévation des éléments les uns par dessus les autres, une forêt, une zone industrielle ou résidentielle, n'est pas ni au dessus ni au dessous de la route qui passe, mais au même niveau. C'est au rendu de prendre la décision de son choix selon ce qui est à représenter dessus ou dessous. Le cas des tunnels et ponts est assez explicite, c'est pour fournir une information qui ne pourrait être déterminer autrement. Dans ton exemple, une rivière passe sur le sol, et une forêt pousse aussi sur le sol, donc layer=0. Après, doit on afficher la rivière par dessus la forêt (mon avis) ou ne pas l'afficher dans une forêt est une affaire de rendu. Je ne suis pas en faveur d'une bidouille ajoutant layer=-1 aux données corine. -- 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] corine, corine, je t'aime ! (shp et autres projections )
> Je pense que je vais travailler sur Postgis initialement et ensuite > exporter a nouveau en SHP. Postgis a le script inverse: pgsql2shp. Si ça peut gagner du temps, j'ai ré-exporter en shp après ma "réparation", c'est plus rapide que le site corine et les coordonnées sont "justes" http://beta.letuffe.org/ressources/corine/ -- 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] corine, corine, je t'aime ! (shp et autres projections )
>
http://beta.letuffe.org/?zoom=10&lat=45.69171&lon=5.50457&layers=0BTFFF
> > --
> > sly
> >
> Ah ouais ! Joli !
> Je suppose que ce sont les codes 11 (tissus urbain) et 31 (forêt) qui
> ont été importé.
Non, j'ai tout importé, il "suffit" juste de compléter le style mapnik pour
afficher ce que l'on veut.
Pour l'instant j'ai fait l'essai avec :
<Rule>
<Filter>[code_06] = '312' or [code_06] = '313'</Filter>
<MaxScaleDenominator>200</MaxScaleDenominator>
<MinScaleDenominator>5</MinScaleDenominator>
<PolygonSymbolizer>
<CssParameter name="fill">#8dc56c</CssParameter>
</PolygonSymbolizer>
</Rule>
<Rule>
<Filter>[code_06] = '311'</Filter>
<MaxScaleDenominator>100</MaxScaleDenominator>
<PolygonSymbolizer>
<CssParameter name="fill">#aed1a0</CssParameter>
</PolygonSymbolizer>
</Rule>
<Rule>
<Filter>[code_06] = '221'</Filter>
<MaxScaleDenominator>100</MaxScaleDenominator>
<MinScaleDenominator>10</MinScaleDenominator>
<PolygonSymbolizer>
<CssParameter name="fill">#abdf96</CssParameter>
</PolygonSymbolizer>
</Rule>
<Rule>
<MaxScaleDenominator>100</MaxScaleDenominator>
<MinScaleDenominator>1000</MinScaleDenominator>
<Filter>[code_06] = '112' or [code_06] = '111'</Filter>
<PolygonSymbolizer>
<CssParameter name="fill">#ddd</CssParameter>
</PolygonSymbolizer>
</Rule>
--
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] corine, corine, je t'aime ! (shp et autres projections )
> Pieren > Je viens de voir la réponse de Sly. Nous sommes d'accord pour la > forêt. Mais je vois très souvent des landuse=residential combinés avec > layer=-1. Là, ça peut se discuter. http://wiki.openstreetmap.org/wiki/Landuse ne conseille pas particulièrement l'utilisation combinée avec layer. Je n'en vois d'ailleurs pas trop l'intérêt si ce n'est corriger le rendu. un landuse=residential est une donnée peu physique, aucun traits sur le sol n'en indique l'étendue, il n'est pas plus sur le sol que sous terre. Si je veux faire un rendu qui mette landuse=residential en avant, je le passerais au dessus de tout, et peut m'importe le layer. Si je le considère comme secondaire par rapport à mon projet, je le placerais en dessous. Mais je ne vois pas pourquoi je tiendrais compte du layer. Une route peut être sur, sous ou au dessus de terre, il ne me semble pas que ce soit le cas de residential, il n'est pas layer=0 non plus, il a valeur en sa définition seule et le sens (représentation) qu'on veut lui donner Dans l'actuel rendu osm, http://svn.openstreetmap.org/applications/rendering/mapnik/osm.xml la requête des surfaces de ce type est faite ainsi : select * from planet_osm_polygon order by z_order,way_area desc Elles sont dessinées en dessous de toute route ou chemin qui seront donc au dessus (même tunnel), le z_order provient du tag layer et permet de placer par exemple une prairie présente en layer=1 par dessus une forêt. Mais ça reste de la bidouille selon moi, la solution du multipolygon étant largement préférable plutôt que d'entasser des surfaces -- 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] Re : corine, corine, je t'aime ! (shp et autres projections )
On Wednesday 13 May 2009 14:44, THEVENON Julien wrote: > Pour cette histoire de foret qui cache la riviere, est ce qu il ne serait > pas plus logique d avoir deux polygones landuse=forest separes par les > waterway=riverbank , plutot qu un seul polygone landuse=forest superpose > avec la riviere ? > Il ne me parait pas tres logique que la riviere fasse partie du landuse > forest M, je pense que c'est en effet la solution la plus propre, pas la plus simple, mais la plus propre. Dire : "cette surface est une forêt" "dedans passe une rivière" implique la réflexion qu'un programme n'a pas de base qui est : "les arbres ne poussent pas dans l'eau" Ou alors considérer que la surface rivière est une forêt Et de l'eau (une mangrove ?) bref, ta solution : - 2 polygones dont les frontières sont la rivière ou la riverbank OU - 1 seule polygone forêt avec en membre "inner" le morceau de rivière à l'intérieur -- 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] corine, corine, je t'aime ! (shp et autres projections )
> Tadam ! > Et voilà : > http://beta.letuffe.org/?zoom=10&lat=45.69171&lon=5.50457&layers=0BTFFF Mon serveur est sur les genoux, la génération de corine était temps réél et il a pris cher, j'ai rajouté du cache pour tenter de le laisser vivre, les layers ont un peu changer d'ordre : http://beta.letuffe.org/?zoom=11&lat=45.56951&lon=5.91244&layers=0BTFFF -- 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] Re : corine, corine, je t'ai me ! (shp et autres projections )
> C'est théoriquement juste mais irréaliste. Je suis tout à fait d'accord, nous menions notre réflexion en commençant par : "où se trouve la perfection" puis, ensuite, comme ce n'est pas utilisable, quel compromis trouver. Beaucoup d'information sont considérées implicites : - des arbres ne poussent pas sur la route, ni dans une rivière, ni sur un bâtiment, sans doute pour ça que chaque rendu dessine route/rivière/... par dessus les landuse= et natural= ensuite, on peut voir l'interaction entre deux landuse : une forêt intersecte une prairie, qui gagne ? En bref, tout ça pour constater que ce que nous faisons est déjà un compromis et que ça ne va pas si mal. Les multipolygones venants à la rescousse des cas tordus -- 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] Re : limite départementales/r égionales
> Ah, j'ai oublié de mettre ça dans mon mail, j'ai corrigé la limite > Loire/Ardèche. Et visiblement pas que ça !! Bravo, tu as eu le courage de faire ce que j'avais laissé tomber. J'en profiterais pour relancer mon outils de stats d'avancée communes par départements. et ça devrait servir à Émilie qui cherchait les limites de départements. -- 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] Re : Nodes communes
> > sly nous sorte un rendu des communes n'ayant pas de node :)
Un sujet de ce type me donne des frissons, (certes, je radote). Une commune
est une surface, un point non.
Bref, je suppose que ce que vous cherchez, ce sont les communes (surface)
présentes dans OSM pour lesquelles il n'existe pas de chef-lieu (point OU
surface landuse=residential) présent dans OSM.
Histoire de savoir où chercher, et ensuite utiliser le cadastre ou corine pour
placer le chef-lieu.
C'est louable
> SELECT name from planet_osm_polygon WHERE name NOT IN (SELECT name from
> planet_osm_point WHERE place IN ('city', 'town') AND name != '') AND
> admin_level = '8';
>
> Soit 8521 communes (mais je rouille en SQL, peut-être que je me suis
> foiré) ; la liste ici :
M. 8521 communes ? d'après mon dernier recensement, il y aurait au max
~8000 surfaces communes dans osm.
Comme tu compares les noms, je suppose que si ça diverge ne serait-ce que d'un
tiret...
Mais même ça n'explique pas le nombre, des communes italiennes ou allemande
prises dans le tas ?
--
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] Beta letuffe - avancement communes - erreur
> Si tu as des fonctions postgis gourmandes en CPU, tu peux peut-être > tenter un simplify() sur la colone geometry, avant de passer aux > fonctions qui bourrinent. Et bien l'idée valait le coup d'être tentée, y'a pas à chier, ça gagne en temps : sans st_simplify : http://beta.letuffe.org/cartes/communes.png : 1 minutes 30 avec : http://beta.letuffe.org/cartes/communes2.png : 15 secondes ( avec ST_SimplifyPreserveTopology : http://beta.letuffe.org/cartes/communes3.png : 1 minute) Hélas comme j'en avais peur, le st_simplify sort des géométries valides sur la base de géométries non valides (le ST_SimplifyPreserveTopology semble carrément toutes les corriger ) Mais par essais/erreurs, j'ai rajouté des st_simplify sur les grosses géométries type départements avant de les donner à mapnik et ça gagne de 20 à 30% (parfois bien plus, mais je pense heurter un problème de tunning de mon postgres qui doit s' emmêler les buffers ) A noter finalement que après tous ces tests, une vérité revient super régulièrement : Ce sont les disques durs qui sont limitant. Si je lance deux rendus identiques à la suite l'un de l'autre (histoire que le noyau linux me laisse tout dans un cache RAM) le temps varie de diviser par 3 à diviser par 10. Conclusion : mettre 16Go de RAM et laisser la base postgis sur un RAM-disque ;-) -- 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
[OSM-talk-fr] gpx des communes françaises
La liste se complète, - L'oise demandée par Yann - L'orne ajoutée par Jocelyn http://beta.letuffe.org/ressources/communes/ J'ai arrêté la production pour l'instant, j'attendrais des manifestations de besoins pour continuer la liste. -- 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] Mega-bug sur les boundary administra tive dans la région de Dole
> wouldsmina a écrit : > > quelqu'un peut me dire ou est l'erreur? Il faut se rappeler que depuis que les mises à jour de beta.letuffe.org sont approximatives (cf problème des minutes diffs), les longues opérations (ajouts de plein de communes d'un coup, grosses relations, etc. ) peuvent très bien passer à la trappe et mon serveur n'affiche pas, alors que c'est pourtant juste. Je ne veux pas y faire grand chose pour l'instant, j'attends simplement que le problème se tasse. A noter que ré-envoyer la commune "louche" résout souvent le problème si vraiment elle est juste (ajouter un tag inutile, puis envoyer) On Monday 18 May 2009 11:29, Vincent Pottier wrote: > Pourquoi ? Cache du navigateur ? Petite paresse du beta pendant le > week-end ? J'ai commandé un quad-core au père noël, mais c'est loin noël ! On dirait que certains ont préféré passer leur dimanche à mapper plutôt que dehors ;-) et lorsque il sature le serveur prend du retard (parfois beaucoup) par rapport à la base OSM La date de la base est indiquée en bas de page, à l'instant : DB update : 200905180811 UTC soit 08h11 le 19/05/2009 UTC soit 10h11 heure française (en gros déjà 2h de retard) -- 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] gpx des communes françaises
On Monday 18 May 2009 14:28, Nicolas Bouthors wrote: > Vincent Pottier a écrit : > > Le Doubs avance, pour ce qui est dans le cadastre, mais il y a des trous. > > Tout pareil pour l'Ain, alors que la page du wiki dit que c'est dispo à 100% Il n'est pas exclu que j'en ai oublié dans mes listes de gpx, n'ayant évidement rien contrôlé à la main ;-( Donc, soit c'est coup de bol et la commune manquante est entourée de communes présentes. Soit il faut ré-utiliser l'outil de frédéric sur les communes manquantes, soit à l'ancienne : avec le plugin cadastre en traçant par dessus "a la main" PS pour l'ain: par exemple, je cherchais dans le fichier de liste de commune style : VIRIGNIN,01300,40454,VECT avec le mot clef ",VECT" et je découvre qu'il en existe sans, donc passées à la trappe : ABERGEMENT-DE-VAREY,L ,01640,'40002' GRAND-ABERGEMENT,LE,01260,'40176' PETIT-ABERGEMENT,LE,01260,'40292' -- 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] Présentation et question sur les t raits sur la carte de france
On Monday 25 May 2009 11:42, Jean wrote: > > Bonjour, > > Je me présente succinctement : Jean CARTIER > Je travaille dans le monde du web et je m'intéresse à OSM depuis quelques temps déjà. > > J'ai une première question : c'est quoi ces vilains traits sur la carte de france ? > http://www.openstreetmap.org/?lat=47.768&lon=-1.621&zoom=10&layers=B000FTF > > Un bug ou une mauvaise saisie. Je paris pour un bug sur osm, mon rendu ne montre pas ce joli trait http://beta.letuffe.org/?lat=47.768&lon=-1.621&zoom=10&layers=B -- 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] Corine Land Cover : nomenclature 23 "Prairies"
> La catégorie 23 est assez simple. Elle ne contient qu'une seule classe > qui devrait faire consensus. Mais bon, j'en parle quand même pour le > principe. Alors je répond, sans problème pour moi (pour le principe) -- 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] Corine Land Cover : nomenclature 2 4 "Zones agricoles hétérogènes "
> * la classe 241 "Cultures annuelles associées aux cultures > permanentes" Cette classe m'a l'air un peu le fourre tout de CLC pour englober les surfaces trop petites pour obtenir leur propre tag et pour dire : "y'a un peu d'arbres ou y'a un peu de tout" ça me semble bien vague, je me prononcerais plutôt pour pas d'import de cette classe plutôt que de conserver dans osm des landuse=farm;meadow;forest;orchard car finalement c'est un regroupement de plusieurs cultures difficile à différencier par leurs photos d'avion -- 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] Utiliser une relation de type route pour décrire un way
> De plus, il faut conserver le tag principal highway ou railway sur le > way lui-même. Ce sont les usages en cours... > Cette idée de vouloir tout transférer dans la relation > vient de Sly uniquement, qui en a fait une idée fixe lorsqu'il est > arrivé sur le projet mais il est bien le seul à raisonner de cette > manière au niveau international. hopopop ! C'est que je suis un précurseur voilà tout ;-) Vu les réponses, d'autres commencent à voir l'intérêt que cela peut représenter. Sinon, pas de désinformation, le sujet chauffe depuis un moment et la seule chose dont on est sûr, c'est que c'est pas simple : http://wiki.openstreetmap.org/wiki/Relation:route http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street ( les idées vont loin et certaines propositions ne se limitent pas aux rails, aux autoroute et au chemins de randos regroupés mais impliquent tout ce qui peut aurait contenu 2 way ou plus du même nom/ref/paramètre ) Je pense que le premier frein c'est la complexité que cela implique ensuite à tagger. Actuellement les primitives de OSM on les taguent direct dans JOSM/potlatch, ça implique qu'il faut comprendre ce qui se passe et forcément c'est chiant, si l'editeur faisait le boulot, ça ne poserait plus de problème. Mais faut pas aller trop vite, les solutions viendront après les problèmes. (ce qui ne m'empêche pas de tagguer de temps en temps comme ça histoire de montrer que ce n'est pas que virtuel ) > Et je regrette que ces commentaires > induisent d'autres personnes en erreur. Même en amendant le forum, il > y aura toujours des gens comme toi qui ne liront pas le topic en > entier... Alors j'ai mis un message clair juste avant que je n'ouvre ma gueule ;-) -- 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] Utiliser une relation de type route pour décrire un way
On Monday 25 May 2009 23:49, Etienne T wrote: > Honnetement, mais après, je suis loin d'être expert OSM, mais je trouve > l'idée de Sly pas mal. Beaucoup de route non pas de tag ref, ou alors lors > de la dénationnalisation des routes de France il y a quelques années, les > relations simplifient le travail. ça c'est l'argument du fainéant ;-) Mais c'est déjà (un peu) valable selon moi. L'aspect intéressant est l'augmentation de la cohérence, moins d'erreur possible sur ref, name, etc. si on doit les recopier autant de fois qu'il y a de way. > C'est qu'un exemple bidon que j'ai pu trouvé, mais si par exemple j'ai envie > d'obtenir le fichier gpx de la LGV ? Pas facile quand se sont que des petits > bouts. C'est l'autre aspect qui me semble très intéressant. A la question, "quelle est la longueur du rhône", l'algorithme de regoupement par nom,type et noeud de jonction est assez délicat. Possible, mais délicat. La relation peut rendre ça plus simple. > Après, si c'est pas le but d'une relation "route", je veux bien changer, il > n'y a aucun soucis. Faut-il créer les relation de type "way" ? :p Ou alors > qu'est-ce qu'on peut faire pour représenter ce que j'ai envie ? (je sais > bien que je suis pas le seul, mais on a le droit d'émetre des idées). route me semble bien, et le gros avantage, c'est que si on doit changer pour une des autres propositions, il n'y a que les tags de la relation à changer. -- 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] Utiliser une relation de type route pour décrire un way
> Moi, je rêve d'une relation "river" qui puisse inclure les morceaux de > chemin (waterway=river) qui indiquent le flux, la navigabilité..., les > polygones (waterway=riverbank) qui décrivent sa surface et ses rives > (baignable... ), ses accidents (barrage...) et qui permette de placer le > nom ailleurs que sur la terre ferme dans les boucles. > Un cas de 'route' ? pas de chance, mais le mot route n'est pas le mieux choisi, de par son ambiguïté dans notre langue. Mais je ferais du "..." noté dans route=road / bicycle / foot / hiking / bus / ferry /pilgrimage / detour / railway / tram / mtb (mountainbike) / roller_skate / running / horse / ... un river ou river_way (pourquoi exclure les ruisseaux) que ça ne me paraîtrait pas illogique Collected_Ways avait le mérite de bien donne la teneur générique de la relation -- 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] Des données libres pour la montagn e pour bientôt
> Une relecture du Code de la Propriété Intellectuelle s'impose. (...) > Dire, dans OSM, que le Mont-Blanc est situé à 4810 m. d'altitude n'est > pas un violation du droit d'auteur de l'IGN (quand bien même il est seul > habilité à en déterminer l'altitude) Oui, mais au regard du droit sur les constitutions de bases de donnée, c'est déjà plus délicat. Tous ceux qui ont tenté de "pomper" la base des pages jaunes par exemple pour obtenir les adresses et nom, certes, il aurait été possible de le faire "sur le terrain", mais le résultat est que ça c'est mal fini. on revient sur l'histoire de citation, je publie un bouquin et dedans j'indique la position et l'alti données par IGN de 50 sommets, je pense que tout ira bien. Maintenant je duplique la base sommet de l'IGN sur toute la france et... je publie une carte de substitution (au hasard, osm) et ça risque d'aller beaucoup moins bien. La parano me semble alors assez justifiée dans l'état actuel de notre fonctionnement en société au regard du droit et du nombre de dossier traités par les magistrats sur ce thème ! -- 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] Des données libres pour la montag ne pour bientôt
Merci beaucoup pour votre intervention, et bravo encore pour cette ouverture vers le libre ! Pas simple que ces histoires de licence... On Monday 25 May 2009 21:51, Frédéric Bunoz wrote: > Bonjour, > Sur c2c, il n'y a aucune garantie d'origine des données : un contributeur > peut saisir les coordonnées d'un sommet à la main (issues d'un relevé GPS > ou sur une carte), ou en cliquant sur une carte OSM, mais en fin de compte > on ne sait pas d'où ça vient (l'origine n'est pas enregistrée). Si le positionnement a été fait grâce à une carte OSM, on se retrouve dans le cas de l'oeuf et la poule, c'est donc peu probable, la base c2c étant bien plus fournie que celle d'osm. Mais comme tu l'as bien dit en définitif "on ne sait pas" , ne reste que des suppositions. Et parmi celles-ci, avec un peu de recul sur le milieu de la montagne, et le GPS n'ayant que quelques année de "grand public", il est à craindre qu'une grande partie soit en provenance direct d'un relevé carte papier IGN ou géoportail > De toute façon, les coordonnées trop précises sont arrondies (dégré à 6 > décimales il me semble). Oui, mais ça devrait aller, après calcul, à nos latitudes, un 6ème de degré ça fait 9cm > Par ailleurs, je ne vois pas comment sur OSM vous garantissez plus > l'origine des données ??? Pas mieux hélas, mais comme disent les anglais : Don't add sewage to the already polluted pond > Si je saisis une trace d'un chemin sur Cartoexplorer par exemple, en > vérifiant sur une photo aérienne que la carte est juste (pas de grosse > erreur), et que je l'enregistre sur OSM en disant qu'elle provient de GPS, > comment pouvez vous détecter la supercherie ? On peut pas, la défense est "a la wikipedia" : le maximum a été fait pour limiter - indiquer qu'il est interdit de prendre sur googlemaps ou géoportail - ne pas autoriser les outils qui permettent de saisir sur une carte sous copyright - surveiller les imports de masse >> Concernant les altitudes, on peut déjà copier sans scrupule les altitudes >> des cartes qui ont plus de 70 ans :-)) > > Personnellement (ce n'est pas l'avis du CA de c2c), je préfère bien plus un > sommet avec une altitude juste mais limite du point du vue licence, qu'avec > une altitude fausse mais bien dans les clous (alors que tout ça devrait > être publique sans condition ! et quid du droit de citation ?). Tout dépend de ce qu'on veut, certains ici préfèrent rien que litigieux. La question est de déterminer a quel point "litigieux". L'utilisateur final qui ne prend aucun risque, quant à lui, préférera toujours de la donnée juste. Mais osm n'est pas vraiment un produit fini, c'est une base de donnée qui à vocation à être réutilisée. Et ceux qui la réutilise pour la diffuser en bout de chaîne sont en situation de risque juridique avec des données litigieuses. > En effet, dans la culture montagnarde, l'altitude d'un sommet, col, refuge > est importante et fait quasiment partie du nom du sommet Je commence à penser (comme l'expliquait Eric il y a peu) aussi que l'altitude n'est plus une donnée originale au sens de la loi, sur google, il y aura plein de site qui vont me donner l'altitude du crêt de la neige, et pourtant la provenance vient sans doute d'IGN, mais la connaissance de cette info et vieille comme la première ascension du sommet (ou presque) > Alors que l'altitude d'un sommet, c'est 4 chiffres, et quel que soit son > auteur, si elle est juste, il n'y a pas de raison de la modifier. Oui, je commence à revoir mes positions sur l'altitude. Alors reste la position... je dis pas non, je dis pas oui... j'en sais rien ;-) Mais je ne m'opposerais pas à un import avec la source=contributeurs camp2camp en bonne est dû forme pour revenir dessus en cas de problème avéré et pour respecter la licence tout en remerciant c2c -- 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] Maintenir sa base OSM à jour
On Tuesday 26 May 2009 12:13, OSM Léon wrote: > Bonjour à tous, > > J'ai probablement mal cherché sur Internet mais quelqu'un aurait il un > script simple pour maintenir sa base de données à jour à partir des fichiers > dits "daily diffs" ? Merci d'avance. > > Thomas > http://wiki.openstreetmap.org/wiki/Minutely_Mapnik -- 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] Des données libres pour la montagn e pour bientôt
From: Dani Bach :
Salut à tous.
Je ne sais pas si ce que je vais dire peut contribuer ou débat ou pas... mais
je me lance:
Dans le domaine de la propriété intellectuelle, toute découverte, nouvelle
information...etc est protégéable par un brevet, uniquement à condition
que cette information n'aie pas été divulguée avant de la dépose du brevet!
que cette nouvelle information, découverte... etc ne soit pas évidente - il
doit avoir un composant d'originalité, de nouveauté.
Exemple: un scientifique découvre une molécule pour traiter le cancer.
s'il publie l'information avant de déposer le brevet (structure de la
molécule, effets contre les tumeurs... etc) cette information n'est plus
patentable
Elle devienne ce que l'on appel "domaine publique" et ni lui (l'inventeur) ni
personne d'autre peut bloquer qui ce soit de copier ou même exploiter
commercialement l'invention.
Exemple2: je ne peux pas déposer un brevet pour patenter une mélange de
citron + miel en tant que thérapie pour les maux de gorge, parce que c'est
quelque chose du domaine publique. Je ne peux pas bloquer qui que ce soit de
préparer des mélanges citron+miel et de les vendre en tant que thérapie.
Exemple3: je ne peux pas breveter la séquence d'un gène que j'ai découvert.
Parce qu'il n'y a aucune originalité à lire la séquence d'un gène, même si
personne ne l'a fait avant, si ça m'a coûté beaucoup d'efforts et si le
produit de ce travail a beaucoup d'utilités possibles. Et je ne peux pas
empêcher la copie et distributions de cette information une foi je l'ai
publiée.
Mesurer les altitudes des sommets est similaire, à mon avis, à lire la
séquence d'un gène. Au début de la génomique (dans les années 80) c'était la
mode de patenter les gènes, et au passage tout usage que l'on pouvait faire
de cette information. Et les bureaux de patentes jouaient le jeu.
Maintenant ce n'est plus possible et les anciens brevets autrefois acceptés
ne sont pas "reinforceables" (en anglais). La séquence des gènes est
considéré comme des informations qui sont dans la nature et que la seule
mensuration ne justifie pas en avoir l'exclusivité de son usage. Il n'y a
aucune "invention" en cela.
Tout comme les altitudes des sommets, à mon avis.
Autre que les brevets il y a le code de la propriété intellectuelle, qui
empêche la copie des créations artistiques ("créations de l'esprit").
Évidement mesurer l'altitude d'un sommet n'est pas une création artistique.
Voir quel genre d'ouvres est protégé par le droit d'auteur et voir aussi les
commentaires. Par exemple celui-ci (mettez-le dans le contexte de
la "lecture" des gènes ou des altitudes)
L'Expansion industrielle / Coprosa, C.Cass., 1ère ch. civile, 2 mai 1989, DIT
1990/2, p. 38, note Ph. Gaudrat.
Un travail de compilation d'informations n'est pas protégé en soi par le
droit d'auteur. L'effort de recherche et la composition nouvelle ne suffisent
pas pour prétendre à la protection.
D.
--
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] Des données libres pour la montagn e pour bientôt
> La séquence des gènes est > considéré comme des informations qui sont dans la nature et que la seule > mensuration ne justifie pas en avoir l'exclusivité de son usage. Il n'y a > aucune "invention" en cela. > Tout comme les altitudes des sommets, à mon avis. C'est bien le cas ! Mais le problème n'est pas là... > Évidement mesurer l'altitude d'un sommet n'est pas une création artistique. Tout à fait... > 1990/2, p. 38, note Ph. Gaudrat. > Un travail de compilation d'informations n'est pas protégé en soi par le > droit d'auteur. L'effort de recherche et la composition nouvelle ne > suffisent > pas pour prétendre à la protection. C'était vrai en 1990, mais cela ne l'est plus : http://www.les-infostrateges.com/article/031027/fiche-technique-pratique-droit-des-producteurs-de-bases-de-donnees Avec mes mots approximatifs : La compilation d'informations dont chaque élément pris séparément peut être non brevetable ou non soumis à un autre droit peut être protégé par celui ayant constitué cette compilation ( IGN dans notre cas) La constitution d'une base de donnée par recopie du géoportail rentrerait dans ce cadre il me semble. PS: sur mon lien je découvre un point intéressant : Les droits prévus à l'article L. 342-1 prennent effet à compter de l'achèvement de la fabrication de la base de données. Ils expirent quinze ans après le 1er janvier de l'année civile qui suit celle de cet achèvement. Lorsqu'une base de données a fait l'objet d'une mise à la disposition du public avant l'expiration de la période prévue à l'alinéa précédent, les droits expirent quinze ans après le 1er janvier de l'année civile suivant celle de cette première mise à disposition. 2006+15 = 2021, rendez vous dans 12 ans pour avoir le droit de relever les informations des sommets ? -- 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] Corine Land Cover : nomenclature 2 4 "Zones agricoles hétérogènes "
On Tuesday 26 May 2009 18:07, Vincent Pottier wrote: > Sly : une petite stat sur les 241, 242, 243, 244 pour savoir combien ça > nous encombre ces surfaces hétérogènes ? > Si ça représente des milliers de polygones et la surface d'un > département, on cherche une vraie solution. Si ça représente une > broutille, on zappe... yop là : Ben on aurait dû commencer par là, ça en aurait déjà fait quelques une où il n'est pas nécessaire de se prendre la tête. pas de 241 et deux 244. et un gros paquet pour les autres, ça sent le fourre tout ;-) ( je pense pas m'être gouré, mais c'est étrange tout de même) not_osm=# select count(*) as nombre,code_06 from corine group by code_06 order by code_06; nombre | code_06 +- 494 | 111 24633 | 112 4410 | 121 795 | 122 123 | 123 253 | 124 1684 | 131 146 | 132 185 | 133 428 | 141 2155 | 142 26425 | 211 5 | 212 29 | 213 4035 | 221 2085 | 222 134 | 223 36057 | 231 42309 | 242 23883 | 243 2 | 244 39569 | 311 14692 | 312 14109 | 313 5464 | 321 3595 | 322 1509 | 323 14785 | 324 341 | 331 1272 | 332 3329 | 333 64 | 334 144 | 335 692 | 411 65 | 412 280 | 421 33 | 422 293 | 423 59 | 511 2373 | 512 90 | 521 30 | 522 4 | 523 (43 rows) -- 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] Corine Land Cover : nomenclature 1 4 "Espaces verts artificialisés , non agricol es"
> Je suppose que l'on pourrait aussi mettre au point un layer pour > afficher les zones qui sont bonnes ou pas. Si on me défini "bonnes" alors je dois pouvoir aider ;-) > J'avoue que je ne maitrise pas du tout la partie carte de OSM. > Manipuler la base de donnee, et ecrire du code, il n'y a pas de > probleme pour moi mais le reste c'est flou pour le moment. Parfait, moi c'est exactement l'inverse ! -- 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] Re : Encore plus de fichiers Corine
On Wednesday 27 May 2009 01:07, Emilie Laffray wrote: > Bonsoir, > > Euh il n'y a pas grand chose a admirer honnetement. Quelle modestie ! Si si, bravo, coller plein d'outils les uns à la suite des autres pour obtenir un résultat n'est pas si simple, et c'est du boulot ! On se rapproche à grands pas du bulk-upload. Avant que quelques uns tentent par eux même d'insérer tes fichiers, on tente de réfléchir à la procédure ? ou sais-tu déjà comment tu vas t'y prendre ? - doit-on ajouter source=corine sur chacun des noeuds ainsi importés ? - L'api python de étienne ? - http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/ - que les "noverlap" de façon automatique, le reste à la main - D'un seul coup ? classe par classe ? Mes remarques après analyse rapide de tes fichiers : * Il semble que les relations multipolygon soient gérées par polyshp2osm. dans nooverlapmdc.osm : 4.3419 - 46.6638 ( lorsqu'il y a un trou) D'après par là, mais cela fait-il consensus ? http://wiki.openstreetmap.org/wiki/Multipolygon#Tagging "It is suggested to apply all tags which describe the area to the relation, and not to the ways." Mais on peut faire un mi-chemin et tagger la relation Et le ways autour. (A moins que ces cas soient marginaux dans corine, et dans ce cas, on s'en fiche un peu ) * Noeuds dupliqués Tout à l'heure tu disais : "j'ai trouve le moyen de fusionner les points de polygones existants" Tu veux dire, avec ceux dans OSM ?? Pourtant il n'y a aucune raison que les points de corine correspondent à ceux d'osm, par détection de distance ? Ou alors tu parles des polygones entre eux dans corine, et en effet, je constate dans tes exports, exemple : nooverlapmdc.osm 6.888/49.203 que les polygones de nature différentes collés se retrouvent avec des noeuds de coordonnées identiques superposés. Si on peut y faire quelque chose, ce serait évidement super. * On pourrait avoir la génération avec forêt ? Il m'avait semblé voir des polygones de même nature et collés (mais peut-être que je me goure) -- 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] Re : Encore plus de fichiers Corine
On Wednesday 27 May 2009 00:22, THEVENON Julien wrote: > mais je me demandais si on peut deja essayer de les exploiter ou si il faut > attendre quelque chose d automatique genre ce qu a fait sly en experi,ental > sur beta letuffe ? Moi je n'ai rien importé, je ne fais que afficher les données corine. Pour ton autre question, je recommanderais chaudement de ne surtout rien utiliser pour l'instant. Ce serait perte de temps à cette étape, et il faut garder notre énergie pour les problèmes que nous ne manquerons pas de rencontrer... Patience patience, j'espère qu'on va se mettre d'accord sur la manière de faire, tout ça chauffe ! -- 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] Re : Encore plus de fichiers Corine
> 2009/5/27 Pieren : > > Je pense qu'on pourrait uploader toutes les classes qui n'ont pas > > d'overlap en un seul script sur toute la France. ça me semble en effet la bonne démarche. > > Attention toutefois à > > réorganiser le fichier OSM des nouvelles données pour qu'il ne fasse > > pas tous les nodes, puis tous les ways, puis toutes les relations mais > > qu'il procède par polygone (mais ça peut être un problème pour > > l'histoire de réutiliser les noeuds). Oui, ça devient un nouveau problème, mais je conçois parfaitement que envoyer 400Mo de donnée OSM en commençant par tous les noeuds, ne peut que mal finir avec des paquets d'orphelins donc d'incohérences. > > On Wednesday 27 May 2009 14:26, Emilie Laffray wrote: > Donc pas de fusions des points. A noter que j'avais fait un sort sur > les donnees afin que le fichier final ressemble le resultat d'un dump > (nodes, ways et finalement relations). Bien que cette approche me semble la plus logique j'ai vraiment peur que tout partent en foirage car les raisons pour qu'un upload de 20 heures (au pif) soit interrompus sont légions. En le faisant polygone par polygone, j'en arrive même à imaginer un script qui fasse quelque chose genre : ( sur la base de http://wiki.openstreetmap.org/wiki/Corine_Data_Import#Exporting_the_table_to_a_0.6_osm_file ) une boucle qui rempli OSM au fûr et à mesure qu'il vide la base ou les fichiers temporaires permettant ainsi une reprise en cas de pépin, minimisation des risques de doublons, état d'avancement, etc, numérotage des changeset par polygone pour avoir une bonne tracabilité. Rien de pire qu'un traitement énorme qui foire en cours de route mais on ne sait pas où. C'est une idée, je ne suis peut-être pas assez développeur et trop admin sys pour préférer ce type de méthode. > A noter que l'on peut faire la fusion des points a posteriori une fois > que tous les polygones ont ete importes. Oui, je pense qu'en plus c'est quelque chose qui existe déjà pour éviter les points aux coordonnées identiques par nettoyage de la base. Ainsi on garde un découpage en étapes "plus simples" >Il faudra que je regarde mais c'est faisable. On pourrait aussi se faire aider sur la liste dev, je suis presque sûr que quelqu'un à déjà ça dans un carton -- 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
[OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
J'aide un peu pieren à avancer, courage on y est presque ;-) ## Rappel : ce fil de discussion aborde les tags à adopter lors de l'intégration des données Corine Land Cover France (CLCF). Voir http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009395.html pour le début de la discussion. Le document de référence est la page wiki : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature Aucun fil de discussion n'est clos par le suivant. Tous les commentaires sont les bienvenues et vous pouvez revenir à tout moment sur les plus anciens. ## * 511 (59) Cours et voies d’eau Vu le peu de polygone, et vu leur qualité après quelques repérages, je propose tout simplement de laisser tomber le 511, OSM étant déjà bien plus fourni et précis * 512 (2 373) Plans d’eau Étendues d’eau, naturelles ou artificielles, de plus de 25 hectares. natural=water me va bien, OSM ne faisant pour l'instant pas de distinction naturel/artificiel * 521 (90) "Étendues d’eau salée ou saumâtre sans végétation, séparées de la mer" OSM ne fait pas de distinction entre les lacs d'eau douce et ce qu'on appellerais nous les étangs salés qu'on retrouve en bord de mer. Donc je propose le même traitement que pour les plan d'eau (soit natural=water) le tag corine étant conservé, il sera possible de garder une trace et de passer à natural=salted_water le jour où ça existera * 522 (30) "Estuaires" Je propose de ne pas importer * 523 (4) "Mers et océans" Je suppose que c'est déjà dans OSM, je propose de ne pas importer non plus. -- 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] Bug sur beta ou restes de pâté d ans le Jura ?
On Thursday 28 May 2009 15:06, Vincent Pottier wrote: > http://beta.letuffe.org/?zoom=13&lat=46.86325&lon=5.6831&layers=B0 > > Ce sont les restes de pâté du Jura de l'autre week-end ou un bug récent > ? Je n'ai pas vu la marmelade annoncé l'autre week-end et qu'il a fallu > 'reverter'. Donc je ne sais pas si ça ressemble à ce qu'on voit maintenant. Très joli en tout cas, comme c'est en zoom 13, c'est un reste du cache, en passant en zoom 14 il n'y a plus rien, je suppose donc que c'est propre. > Comme il y a un problème sur l'affichage de communes dans le même coin > (communes rouge-sang) : Comme dirait coluche : "il est fort au ballons, y'avait des couleurs même pas marquées dans le manuel" Je pense qu'il s'agit de plusieurs couches de rouge qui se superposent, donc plusieurs communes qui s'entrecroisent. Soit c'est normal parce qu'il y a des enclaves/exclaves (que mon outils ne gère pas), soit il y a superposition anormal. -- 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] Communes révolutionaires
> Un autre donnera peut-être les durées précises pour chaque couleur. > Pratique pour voir où ça avance, et où d'autres travaillent pour éviter > de se marcher sur les villes ;-) Le code couleur ne donne qu'une très vague idée de l'âge dans la base d'une commune car je n'ai pas réussi à disposer de cette information. Les couleurs changent au fur et à mesure que d'autres relations sont insérées dans la base OSM mondiale. ( Je prend par exemple le paris que juste après l'import de corine, toutes les communes passeront en vert ;-( ) -- 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] Communes révolutionaires
On Thursday 28 May 2009 15:46, Yann Coupin wrote: > Je vais peut-être dire une bêtise, Non non, tu as bien raison. > mais si je prend le fichier > correspondant à un changeset que j'ai fait (c'en est un au hasard il > n'a rien de particulier), je vois un timestamp sur l'objet relation, > on pourrait utiliser ça non ? > > http://www.openstreetmap.org/api/0.6/changeset/861268/download c'est possible ;-) J'utilise simplement des outils qui ne savent pas faire. (osm2pgsql) Ou, s'ils le font, je ne sais où ils mettent cette information. -- 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] Communes révolutionaires
On Thursday 28 May 2009 16:14, Yann Coupin wrote: > Bon je confirme ça ne stocke pas le timestamp, mais osm2pgsql a un > code simple et je pense que je pourrais faire la modif en une heure, > tu veux que j'y jete un coup d'œil ce soir ? Ha ben si tu as le courage ! Mais le jeu en vaut il la chandelle ? à toi de voir. L'ajout d'un timestamp unix correspondant à la dernière modification de la relation dans un champ de la table marcherait au poil. -- 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] Corine Land Cover : nomenclature 5 Surfaces en eau
On Thursday 28 May 2009 16:26, Pieren wrote: > 2009/5/28 sly (sylvain letuffe) : > > J'aide un peu pieren à avancer, courage on y est presque ;-) > > Il fallait le dire si j'avançais trop lentement ;-) > Mais c'est vrai que ça prend du temps sur certaines catégories Je tente de filer un coup de main ;-) et c'est clair que ce n'est pas si simple, il faut mener une petite recherche pour ne pas faire que survoler. > Par exemple, pour la 511, il faudrait d'abord regarder s'il n'y a > aucun polygone de fleuve qui pourrait nous être utile et si OSM a déjà > couvert tous les fleuves et si c'est vraiment plus précis avant de > décider d'abandonner cette classe. Dans l'absolu, ça vaudrait le coût de se creuser la tête, mais dans le cas français (que nous traitons ici, avant de propager chez les autres qui en feront un peu ce qu'ils veulent) il n'y a que peu de polygones, et mes recherches rhône, Isère, Saône des coins que je connais un peu me montre que OSM est quasiment à chaque fois plus précis. L'importation avec une relation de type riverbank va créer une complexité à l'import pour pas grand chose à mon avis. Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. -- 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] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec osm)
> Previens moi quand tu as besoin d'aide pour produire les fichiers OSM > facilement. Je pense qu'il serait plus facile de commencer par des > bbox. Et que pensez vous de mon idée qui consiste à produire un dépot (contenant les polygones qui ne seront pas importés automatiquement) qui contiendrait un fichier par polygone ? - J'y vois comme avantage une plus grande simplicité à produire - Plus facile à traiter avec JOSM qu'un découpage par département - Plus facile à lister ce qui a été importé de ce qui ne l'a pas été (Restera tout de même une petite interface de sélection pour trouver ceux qui intéressent par zone, mais qui me semble plus simple qu'un découage et génération de fichier osm à la volée ) L'idée bbox avec plugin JOSM peut faire rêver, mais honnêtement, je ne crois pas que nous ayons la ressource pour le mettre en place. KIFS -- 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] Bug sur beta ou restes de pâté dans le Jura ?
> Les relations sont présentes quater fois. Ce qui me semble être 3 en > trop. On va se retrouver avec 132 000 communes en France. > Voir : Le Villey, Sellière et autres... > > Or ces communes ne sont pas rouge-sang su beta. Il y a un autre problème > pour les communes rouge-sang que je n'ai pas encore identifié. Je dirais pas "Or", je dirais "donc". Si il y a 4 communes ayant la même surface, alors ça fait 4 couches de rouge ;-) -- 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] Bug sur beta ou restes de pâté d ans le Jura ?
> Arlay : quatre relations correctes : 147597, 147696, 147799, 147909 > rose sur beta > > Mantry : quatre relations correctes : 147586, 147685, 147788, 147898 > rouge sang sur beta > > Why ? Aucune idée, 3 des 4 Arlay n'ont pas été importé. Yaka nettoyer on y verra plus clair. -- 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] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec osm)
> Je pense qu'il serait assez facile de creer un script PHP (name your > favorite poison) permettant de generer un fichier OSM pour chaque > polygone on the fly. La requete SQL serait assez rapide. La taille de > la bd est petite et donc une bbox serait tres rapide. Mais cela implique une architecture plus conséquente et plus de boulot. Mais ma foi, pourquoi pas si c'est "possible". Prévoir un moyen pour dire "import fait" évitera de se marcher sur les pieds. > La solution d'avoir un fichier par polygone me parait effrayante de > devoir gerer autant de fichiers. Après rapide estimation, 270,000 polygones corine, en supposant que 10% seront en conflict dans OSM (c'était à la louche le ratio de tes overlap/nooverlap) et une moyenne à 10ko par fichier. 270 Mo et 27,000 fichiers. L'avantage est que si c'est la procédure retenu pour l'import des "no overlap" c'est peu de coût pour fournir le dépot des "overlap" et on est indépendant d'un service qui peut ne plus marcher, dépendre d'un seul contributeur, etc. J'avoue avoir gardé cette méthode, sitôt que de la donnée est disponible, j'en fais une copie, on sait pas ce que deviendra l'endroit où elle était... Mais bon, si quelqu'un à la motivation pour l'outil du départ, ça me va aussi bien... "Un chien vaut mieux que deux kilo de rat" -- 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] Corine Land Cover : nomenclature 3 3 "Espaces ouverts, sans ou avec peu de vég étation "
On Thursday 28 May 2009 22:12, Didier HALATRE wrote: > Pieren a écrit : > > * la classe 332 "Roches nues" est proposée en "natural=cliff" > > (falaises) ou "natural=scree" (caillasse) sur le wiki. En fait, c'est > > tous les endroits où la roche est à nue. J'aurais tendance à dire que > > là où il n'y a rien, on ne met rien d'autant plus que cela concerne un > > faible nombre de polygones (~1300). Mais j'entends déjà les > > randonneurs et grimpeurs qui vont râler. Donc à eux de s'exprimer ici. > > > En tant que randonneur, je suis d'accord avec le « là où il n'y a rien, > on ne met rien » T'es un drôle de randonneur ;-) moi je dirais qu'une falaise, c'est pas rien ! Par contre "roches nues" c'est vraiment vague, comme on peut supposer que c'est par avion que ça a été fait, les falaises se voient moins. Mais par prudence, je dirais que rien importer automatiquement me semble le mieux. Il sera toujours temps de faire des imports à la main en connaissance du lieu pour différencier un sol plat jonché de cailloux, d'une falaise. -- 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] Communes révolutionaires
On Friday 29 May 2009 01:20, Yann Coupin wrote: > Et voilà, c'était finalement un peu plus long que prévu mais pas très > compliqué... Chapeau bas, ça marche au poil. Il faudra cependant que je refasse l'import complet avec cette nouvelle version de osm2pgsql avant de refaire des plus beau style, mais j'ai le nouveau binaire de coté et son style, au prochain import complet j'y passe. ça me donne pas mal d'idées supplémentaires sans rapport avec les communes comme par exemple indiquer les derniers ajouts et dernières modifications sur une zone. PS: bien que dans la config j'ai placé : wayts timestamppolygon Le timestamp est quand même importé pour les roads et ligne (pas les points) Il me semble que ça n'a jamais vraiment marché de toute façon, et finalement tant mieux, mais c'était juste pour dire. -- 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] Corine Land Cover : nomenclature 3 3 "Espaces ouverts, sans ou avec peu de vég étation "
> T'es gentil ;-) mais on voit tout de suite en regardant les données corine > qu'on > arrivera jamais à détecter une falaise (et c'est bien dommage). Donc j'en > reste > à "roches nues" seules et je trouve que c'est pas très intéressant [pour > moi] à > importer. Sur le principe je suis pour l'import, mais comment être sûr que ce n'est pas une falaise ? toutes les falaises ne sont pas verticales, comment distinguer falaise de roches nues. Pour un chamois, c'est peut-être un angle de 70°, pour un humain, 55°. c'est finalement relatif. Je vais tenter un rendu dans les alpes en dessinant les falaises/roches nues de corine, on aura une idée un peu meilleure de ce que c'est. > Bon maintenant, vu tout ce qu'on importe, ça va être tout nu au dessus de > 1800m > ou environ, là où il n'y a plus grand chose qui pousse... :-) Y'aura aussi "Pelouses et pâturages naturels", pis glacier. Mais je suis d'accord que roches nues est tout aussi intéressant, voyons ce qu'on a -- 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] quelques questions sur les limites cadastrales
On Friday 29 May 2009 14:34, Axel R. wrote: > Bonjour, > J'essaye d'avancer un peu sur les limites des communes du loiret et j'ai > quelques questions : > > - comment gérer la différence entre les limites du département et celles > des communes "du bord" ? qu'est ce qui est le plus "fiable" ? le > cadastre ou les limites du département ? Le cadastre sans aucun problème, de plus, les actuelles limites de département sont sous une licence incertaine que nous pensons retirer ensuite (sitôt que les limites seront refaites avec le cadastre) > - entre deux communes, il faut un seul way qui appartient à deux > relations (pour chaque commune), c'est bien ça ? comment faire pour > fusionner les différents ways ? (j'y arrive en bidouillant comme un > malade et je me demande si y'a une meilleure solution... sous JOSM, tu sélectionnes les deux ways puis touche "c", les relations sont alors toutes utilisées (si le chemin 1 était frontière de commune A et chemin 2 commune B, et que ton but c'est que chemin 1 et 2 soient fusionnés car ils forment la frontières entre A et B) > - est il préférable de lancer la moulinette de création automatique des > contours sur une seule commune ou sur un ensemble ? Sur plusieurs, c'est tout son intérêt, sinon autant prendre le GPX de la commune à importer et le traiter dans JOSM directement. > Merci, > > Axel > > > _______________ > 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] problème sur limite cadastrale
On Friday 29 May 2009 14:36, Axel R. wrote: > j'ai remarqué que certaines communes ne s'importe pas, en les lançant > toute seule, j'obtiens ce message d'erreur (il s'agit de TRINAY dans le > 45) : Il faut voir si le problème vient d'avant (autotrace par exemple), j'avais eu des problèmes de manque de RAM sur les grosses communes > > trinay/*.vect.gpx... > GPX cannot open 'trinay/*.vect.gpx' for read. Error was 'No such file > or direct > ory'. > Chargement trinay/*.simp.gpx... > java.io.FileNotFoundException: > /arthur/home/axel/r-cadastre-client-20090424-2/tr > inay/*.simp.gpx (No such file or directory) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at java.io.FileInputStream.(FileInputStream.java:66) > at > sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection > .java:70) > at > sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLCon > nection.java:161) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrent > Entity(XMLEntityManager.java:653) > at > com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineD > ocVersion(XMLVersionDetector.java:186) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(X > ML11Configuration.java:771) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(X > ML11Configuration.java:737) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser. > java:107) > at > com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser. > java:225) > at > com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Doc > umentBuilderImpl.java:283) > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:180) > at fr.free.rodrigo.f.osm.A.loadGPX(A.java:61) > at fr.free.rodrigo.f.osm.A.getSubject(A.java:191) > at fr.free.rodrigo.f.osm.A.run(A.java:256) > at fr.free.rodrigo.f.osm.A.main(A.java:301) > Exception in thread "main" > sun.reflect.generics.reflectiveObjects.NotImplemented > Exception > at fr.free.rodrigo.f.osm.A.loadGPX(A.java:91) > at fr.free.rodrigo.f.osm.A.getSubject(A.java:191) > at fr.free.rodrigo.f.osm.A.run(A.java:256) > at fr.free.rodrigo.f.osm.A.main(A.java:301) > Chargement trinay/*.conf.gpx... > tools/rccc-gpxs2osm.rb:10:in `initialize': No such file or directory - > trinay/*. > conf.gpx (Errno::ENOENT) > from tools/rccc-gpxs2osm.rb:10:in `new' > from tools/rccc-gpxs2osm.rb:10 > from tools/rccc-gpxs2osm.rb:8:in `collect' > from tools/rccc-gpxs2osm.rb:8 > === A faire ensuite === > 1) Passer le checker et corriger > 2) Faire le split > > > > ___ > 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] Corine Land Cover : nomenclature 3 3 "Espaces ouverts, sans ou avec peu de vég étation "
On Friday 29 May 2009 14:33, sly (sylvain letuffe) wrote: > > Bon maintenant, vu tout ce qu'on importe, ça va être tout nu au dessus de > > 1800m > > ou environ, là où il n'y a plus grand chose qui pousse... :-) > Y'aura aussi "Pelouses et pâturages naturels", pis glacier. Mais je suis > d'accord que roches nues est tout aussi intéressant, voyons ce qu'on a Et ben c'est si mal que ça : http://beta.letuffe.org/cartes/roches_nues.jpeg Je ne trouve finalement qu'une assez faible proportion de ce que j'aurais appelé "falaise", et il sera toujours temps d'affiner à la main ce qui doit l'être. Je change mon avis pour l'import de 332 finalement. PS: ils ont disciminé les lanfonnets par rapport aux lanfons alors que c'est pourtant bien similaire, sans doute une histoire de taille limite... -- 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] quelques questions sur les limites
> et donc pour le coup, sur la frontière, il y aura 4 relations (une par > commune voisine et une par département voisin) ? Tout à fait, et je peux te dire que 4 c'est rien ! J'ai tracé la frontière franco/italienne et je me retrouve avec des bouts de ways appartenant à : 1 commune française, une italienne 1 dép français un italien 1 régions française, (pas d'italienne, z'en ont pas on dirait) France et talie Donc 7 relations > > sous JOSM, tu sélectionnes les deux ways puis touche "c", les relations > c'est aussi simple que cela ? Parce que ça marche pas à tout les coups > (pour ne pas dire rarement...) Beuh ??? > y'a toujours des petites merdes (des bouts de way de 3 noeuds qui forme > un triangle dans un coin et que l'on n'arrive pas à regrouper avec le > reste...) Une capture d'écran pour comprendre ? Je viens de remarquer sur ma version de JOSM que si je tente de fusionner un chemin fermé avec un chemin ouvert j'ai le message "ne peut être fusionner en une seule chaîne de noeud" Mais normalement il n'y en a rarement besoin -- 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
[OSM-talk-fr] Etat d'avancement commune le 29 de chaque mois
Les départements non présents n'ont aucune communes, sauf Mozelle et Meurthe-et-Mozelle qui ne sont pas complet dans la base OSM, donc pas de stats. (les communes en plusieurs morceaux ne sont pas comptabilisées, il faut que je trouve une technique) bilan : 10685 communes dans OSM soit 53.4% du nombre de commune au format vecteur dans le cadastre et 29.2% du nombre total de commune. ref;name;id relation;count 01;Ain;7387;395 02;Aisne;7411;115 03;Allier;7414;141 04;Alpes-de-Haute-Provence;7380;2 05;Hautes-Alpes;7436;21 06;Alpes-Maritimes;7385;22 07;Ardèche;7430;129 09;Ariège;7439;2 11;Aude;7446;46 12;Aveyron;7451;196 13;Bouches-du-Rhône;7393;101 14;Calvados;7453;236 15;Cantal;7381;30 16;Charente;7428;147 17;Charente-Maritime;7431;210 18;Cher;7456;15 19;Corrèze;7464;94 2A;Corse-du-Sud;76932;25 2B;Haute-Corse;76931;32 21;Côte-d'Or;7424;451 23;Creuse;7459;234 24;Dordogne;7375;127 25;Doubs;7462;316 26;Drôme;7434;301 27;Eure;7435;49 28;Eure-et-Loir;7374;29 29;Finistère;102430;13 30;Gard;7461;48 31;Haute-Garonne;7413;85 32;Gers;7422;408 33;Gironde;7405;297 34;Hérault;7429;49 35;Ille-et-Vilaine;7465;211 36;Indre;7417;31 37;Indre-et-Loire;7408;131 38;Isère;7437;224 39;Jura;7460;242 40;Landes;7376;233 41;Loir-et-Cher;7399;3 42;Loire;7420;113 43;Haute-Loire;7452;41 44;Loire-Atlantique;7432;156 45;Loiret;7440;73 46;Lot;7454;331 47;Lot-et-Garonne;7416;95 48;Lozère;7421;32 49;Maine-et-Loire;7409;9 50;Manche;7404;19 51;Marne;7379;7 53;Mayenne;7438;6 56;Morbihan;7447;204 59;Nord;7400;644 60;Oise;7427;14 61;Orne;7419;2 62;Pas-de-Calais;7394;9 63;Puy-de-Dôme;7406;230 64;Pyrénées-Atlantiques;7450;2 66;Pyrénées-Orientales;7466;90 67;Bas-Rhin;7415;187 68;Haut-Rhin;7403;218 69;Rhône;7378;89 70;Haute-Saône;7423;8 71;Saône-et-Loire;7397;20 72;Sarthe;7443;326 73;Savoie;7425;304 74;Haute-Savoie;7407;293 75;Paris;71525;1 76;Seine-Maritime;7426;200 77;Seine-et-Marne;7383;86 78;Yvelines;7457;94 79;Deux-Sèvres;7455;57 80;Somme;7463;40 81;Tarn;7442;99 82;Tarn-et-Garonne;7388;180 83;Var;7390;22 84;Vaucluse;7445;93 85;Vendée;7402;20 86;Vienne;7377;231 87;Haute-Vienne;7418;134 88;Vosges;7384;152 90;Territoire-de-Belfort;7410;102 91;Essonne;7401;60 92;Hauts-de-Seine;7449;36 93;Seine-Saint-Denis;7389;17 94;Val-de-Marne;7458;47 95;Val-d'Oise;7433;51 Total:10685 -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ref;name;id relation;count 01;Ain;7387;395 02;Aisne;7411;115 03;Allier;7414;141 04;Alpes-de-Haute-Provence;7380;2 05;Hautes-Alpes;7436;21 06;Alpes-Maritimes;7385;22 07;Ardèche;7430;129 09;Ariège;7439;2 11;Aude;7446;46 12;Aveyron;7451;196 13;Bouches-du-Rhône;7393;101 14;Calvados;7453;236 15;Cantal;7381;30 16;Charente;7428;147 17;Charente-Maritime;7431;210 18;Cher;7456;15 19;Corrèze;7464;94 2A;Corse-du-Sud;76932;25 2B;Haute-Corse;76931;32 21;Côte-d'Or;7424;451 23;Creuse;7459;234 24;Dordogne;7375;127 25;Doubs;7462;316 26;Drôme;7434;301 27;Eure;7435;49 28;Eure-et-Loir;7374;29 29;Finistère;102430;13 30;Gard;7461;48 31;Haute-Garonne;7413;85 32;Gers;7422;408 33;Gironde;7405;297 34;Hérault;7429;49 35;Ille-et-Vilaine;7465;211 36;Indre;7417;31 37;Indre-et-Loire;7408;131 38;Isère;7437;224 39;Jura;7460;242 40;Landes;7376;233 41;Loir-et-Cher;7399;3 42;Loire;7420;113 43;Haute-Loire;7452;41 44;Loire-Atlantique;7432;156 45;Loiret;7440;73 46;Lot;7454;331 47;Lot-et-Garonne;7416;95 48;Lozère;7421;32 49;Maine-et-Loire;7409;9 50;Manche;7404;19 51;Marne;7379;7 53;Mayenne;7438;6 56;Morbihan;7447;204 59;Nord;7400;644 60;Oise;7427;14 61;Orne;7419;2 62;Pas-de-Calais;7394;9 63;Puy-de-Dôme;7406;230 64;Pyrénées-Atlantiques;7450;2 66;Pyrénées-Orientales;7466;90 67;Bas-Rhin;7415;187 68;Haut-Rhin;7403;218 69;Rhône;7378;89 70;Haute-Saône;7423;8 71;Saône-et-Loire;7397;20 72;Sarthe;7443;326 73;Savoie;7425;304 74;Haute-Savoie;7407;293 75;Paris;71525;1 76;Seine-Maritime;7426;200 77;Seine-et-Marne;7383;86 78;Yvelines;7457;94 79;Deux-Sèvres;7455;57 80;Somme;7463;40 81;Tarn;7442;99 82;Tarn-et-Garonne;7388;180 83;Var;7390;22 84;Vaucluse;7445;93 85;Vendée;7402;20 86;Vienne;7377;231 87;Haute-Vienne;7418;134 88;Vosges;7384;152 90;Territoire-de-Belfort;7410;102 91;Essonne;7401;60 92;Hauts-de-Seine;7449;36 93;Seine-Saint-Denis;7389;17 94;Val-de-Marne;7458;47 95;Val-d'Oise;7433;51 Total:10685 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Etat d'avancement commune le 29 de chaque mois
On Friday 29 May 2009 18:11, Mathieu Arnold wrote: > > +--le 29.05.2009 17:45:37 +0200, sly (sylvain letuffe) écrivait : > | Les départements non présents n'ont aucune communes, sauf Mozelle et > | Meurthe-et-Mozelle qui ne sont pas complet dans la base OSM, donc pas de > | stats. > > Hum, y'a une raison particulière, ou juste ils sont cassés et il faut les > réparer ? > Si c'est ça, peut être je vais tenter de le faire. Ils sont bien cassés (y'a un paquet de trous), je suis aller jeter un oeil, j'ai vu qu'il y avait un chantier par là haut, et je ne voulais pas affronter les terribles Vikings venus du Nord (Pieren et Denis) donc je les laisse gérer. ( J'entend la voix de ma raison qui dit : dis plutôt que tu as la flemme !) -- 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] Corine Land Cover : nomenclature 3 3 "Espaces ouverts, sans ou avec peu de vég étation "
> Un "natural=rock" qui pourrait aussi être utilisé sur un point pour un > rocher isolé et remarquable. > Mon harrap's pocket indique " roche, rocher (bloc, substance) rock" > (plus loin, il ajoute : musique :-). > > Le "natural=scree" que j'avais proposé sur le wiki, et qui reprend une > valeur enregistrée dans ls Features, ne s'appliquera qu'a quelques > polygones, et encore : 25 ha de pierrier... Je viens de relire que la proposition était "natural=scree" sur le wiki pour l'instant, or il est vrai que ce que nous avons dans corine, c'est de la roche nue sans pour autant que soit un éboulis, or "scree" selon wikipedia : http://en.wikipedia.org/wiki/Scree c'est plutôt éboulis. Donc pas terrible, peut-être natural=rock était il finalement le mieux mais toujours en "proposition" dans le wiki. J'ai cherché dans les mapfeatures sans succès, il faudrait un cliff mais à plat ;-) -- 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] Réunion IRC spéciale Corine Land Cover ?
On Wednesday 03 June 2009 10:52, Pieren wrote: > Bonjour, > > Comme il n'y a plus d'activité sur les fils de discussion concernant > la migration de Corine Land Cover France, je proposerais de faire une > réunion IRC la semaine prochaine pour: > - discuter les derniers tags qui posent encore problème ou qui n'ont > pas trouver de consensus > - obtenir un accord général sur la liste des catégories qui seront > importées ou rejetées > - voir comment on procède pour la suite et qui fait quoi > > Bien sûr, la discussion devrait être la plus large possible. Je pense > qu'un jour comme mardi prochain devrait faire l'affaire. > > Vous en pensez quoi ? Je suis plutôt pour continuer ce fil ici même et terminer les dernières classes que sont 4 et 33, si je compte bien il en reste plus que 11. IRC ne me semble pas la méthode "la plus large possible", ce qui n'empêche pas cette réunion pour autant. Ensuite on pourra passer à la question des "rebus", mais je suis pour le faire dans cet ordre : 1) on fini le choix des tags pour les 11 derniers types 2) on trouve une méthode pour générer les polygones sans conflits avec ceux d'osm 3) on discute de la meilleure manière d'importer 4) on importe 5) on commence la réflexion sur les polygones restants qui sont en conflit dans OSM 6)... -- 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] Corine Land Cover : nomenclature 3 3 "Espaces ouverts, sans ou avec peu de vég étation "
Reprenons cette classe 33 :
> * la classe 331 "Plages, dunes et sable" serait traduite en
> "natural=beach" . Pas d'objection bien que ces polygones soient assez
> mal délimités et débordent souvent sur des quais ou des zones urbaines
> souvent adjacentes.
Cette remarque pertinente fais que je pense moi qu'il est préférable de ne pas
importer, voici mes essais a coté de sète, (seul côte que je connais un peu)
de loin :
http://beta.letuffe.org/cartes/beach.jpeg
de près :
http://beta.letuffe.org/cartes/beach2.jpeg
Je dirais pas que c'est "mauvais", mais je dirais pas non plus que c'est "bon"
> * la classe 332 "Roches nues" est proposée en "natural=cliff"
> (falaises) ou "natural=scree" (caillasse) sur le wiki.
natural=rock me semble être le meilleur compromis (la présence du code corine
permettra de revenir dessus en cas de changement)
> * la classe 333 "Végétation clairsemée" est proposée en
> "natural=scrub" comme la classe 323 mais sur les photos, c'est très
> proche du type de terrain 332 "Roches nues" mais avec un peu de
> végétation parmi les rochers. Donc si on adopte la classe 332, je
> serais plutôt pour choisir le même tag ici ("natural=scree" par
> exemple)
Voici un résultat dans les alpes remis à jour et plus joli :
http://beta.letuffe.org/cartes/roches_nues.jpeg
en gris clair, les roches à nues, en vert clair cette classe 333
Et voici typiquement une photo du terrain que corine note en 333 :
http://slyserv.dyndns.org/osm/img_0497.jpg
Donc c'est bien ce que corine prétend ce que c'est :
"Végétation clairsemée" entourée de caillasses
scrub, c'est pas ça, scree pas tout à fait non plus et rock non plus. Pour un
randonneur, ça fait pas mal de différences.
J'en arrive à la solution déjà utilisée, quand c'est un peu de plusieurs, mais
que osm n'a pas de tag pour le dire, ben tant pis, pas d'import.
> * 64 polygones sont de la classes 334 "Zones incendiées". Je n'ai pas
> trouvé de proposition sur ce sujet brûlant. Ça serait pourtant
> intéressant de recouper les zones incendiées transformées en zones
> urbaines et les noms des promoteurs immobiliers concernés.
incendiées n'est à mon avis pas quelque chose de fiable sur le long terme,
l'herbe va repousser, donc pas d'import
> * 144 polygones pour la classe 335 "Glaciers et neiges éternelles" qui
> seraient tagués en "natural=glacier"
> (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dglacier)
ça me va
--
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] Corine Land Cover : nomenclature 4 1 "Zones humides intérieures "
> * la classe 411 "Marais intérieurs" est titrée "Inland marshes" dans > la nomenclature CLC en anglais. Le wiki propose "natural=wetland" + > "wetland=marsh". > > * la classe 412 "Tourbières" (Peat bogs) serait traduite en > "natural=wetland" + "wetland=bog" C'est bon aussi pour moi -- 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] Conf Guilde 16/06 : OpenStreetMap
On Wednesday 03 June 2009 16:58, THEVENON Julien wrote: > Pour information, cela va avoir lieu a Grenoble > > je compte y assister pour voir ce qui se dit :-) si d autres personnes y > vont ca peut etre l occaz de se rencontrer ça alors, il semble que je ne sois pas le seul inscrit sur l'une des meilleure liste linux de france ;-) Grenoble est un peu loin pour moi, mais j'y serais bien allé ! > > > - Message transféré > De : Guillaume Allegre > À : guilde-anno...@guilde.asso.fr > Envoyé le : Mercredi, 3 Juin 2009, 16h11mn 56s > Objet : Conf Guilde 16/06 : OpenStreetMap > > > OpenStreetMap > > Découvrez le wikipedia de la cartographie > >Mardi 16 juin 2009 à 19:30, >à l'ENSIMAG. > >Conférence par Raphael Jacquot et Lionel Roux. > >[1]OpenStreetMap est un projet collaboratif destiné à créer des cartes >libres du monde entier, en utilisant le système GPS ou d'autres données >libres. Les cartes sont disponibles sous les termes de la licence >[2]Creative Commons Attribution-ShareAlike 2.0. > > Communication > >Aidez-nous : relayez cette annonce, par mail ou par un lien sur cette >page. > > >1. http://www.openstreetmap.org/ >2. http://creativecommons.org/licenses/by-sa/2.0/fr/ > > > -- > ° /\Guillaume AllègreMembre de l'April > /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre > / /~~\tél. 04.76.63.26.99 http://www.april.org > > > -- 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] Chemin ruraux
On Wednesday 03 June 2009 17:19, Emilie Laffray wrote: > Bonjour, > > comment taggueriez vous des chemins ruraux? Je suis en train de travailler > sur une ville rurale ou la moitie des "rues" sont des chemins ruraux avec > sur le cadastre des noms comme chemin rural dit rue de trucmuche. Par expérience sur le terrain, les chemins ruraux du cadastre n'ont pas tous le même "sol" Tentôt c'est goudronné et je place highway=unclassified/residential selon le nombre d'habitation déservies Tentôt c'est non goudronné et je place un highway=track. Le cadastre ne résoud pas tout... Je reste néanmoins non satisfait du distingo track/unclassified selon le wiki. J'aurais tendance à dire track implique non pavé, mais le wiki précise "usually unpaved/unsealed but may occasionally apply to paved tracks as well" Un petit chapitre sur la page http://wiki.openstreetmap.org/wiki/Unclassified tente de clarifier la différence, mais ça reste un peu vague je trouve. Au final, je ne tag jamais en unclassified un chemin non goudronné, mais ma méthode n'est pas forcément la meilleure > Yahoo > n'est d'aucun secours vu la resolution. Je me rappelle juste de memoire que > ce sont generalement des petites routes de terre pas vraiment pratiquable a > moins bien sur de suivre betement son GPS. > > Emilie Laffray > -- 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] Re : Chemin ruraux
> Pour qu'elle soit taguée en unclassified, il faut que la voie soit une > voie de transit pour le public et pas seulement un accès aux terrains > agricoles ou forestiers pour leur exploitation ou la promenade. Je lis ça comme ça aussi, mais il y reste du vague je trouve : L'entête dit que unclassified c'est pavé, puis après que : "unclassified if (...) The road is the only connection of a village" Mais si une route n'est pas pavée mais est l'uniquement manière de rejoindre un village, on fait quoi ? A mon avis, et ça avait déjà été discuté sur la liste anglaise, le schéma osm a été pensé villes et occidentaux (dans le sens "riches" du terme) et l'aspect physique d'un chemin est venu cotoyer l'utilisation qui en est faite dans cette classification primary/secondary/tertiary/unclassified qui suppose de façon implicite "oui c'est goudronné" (ce qui est a mon avis une erreur de schéma) ( les allemands sont ensuite venu rajouter des track+grade1 pour qu'un chemin goudronné qui ne va "nul part" puisse devenir track. Ce qui me semble est très sensé, mais mal expliqué ) On tagguerait les grands axes du burkina fasso en : highway=primary + surface=unpaved et les chemins de terre qui donnent accès en 4x4 à des maisons en highway=unclassified + smoothness=horrible (fallait que je le place) -- 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] Petites questions sur les îles et les barrages
> En parcouran la version anglaise de cette page, j'ai découvert un > exemple de relation incluant plusieurs « outer ». J'ai donc intégré tous > les plans d'eau indépendants à la relation. J'aurais fais ça > J'en ai profité pour déplacer le tag « name=Lac de Montbel » des plans > d'eau vers la relation. Ai-je bien fait ? Je n'aurais pas "déplacé" mais copié. Dans un soucis de transition pour les outils qui cherche le nom sur le/les polygones outer, je l'aurais placé dans la relation ET dans le(s) polygone outer. -- 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] Bug sur beta ou restes de pâté d ans le Jura ?
On Thursday 04 June 2009 14:34, Vincent Pottier wrote: > @Sly et bons avis : > > Je n'ai pas fait une étude exaustive mais il semble qu'il y a un écart > entre les outils de validation et beta > http://beta.letuffe.org/?zoom=12&lat=46.77327&lon=5.60088&layers=B0FFTF > voir > http://www.openstreetmap.org/?zoom=12&lat=46.77327&lon=5.60088&layers=B000FTF Places toi en zoom 14 quand tu as un doute, le 12 est sans doute dans le cache et on ne voit donc pas la même chose. > Mantry (absent sur beta, présent sur osm, valide sur osmose) > http://osmose.openstreetmap.fr/tools/relation_analyser/cgi-bin/relation.py?NumRelation=147898 Je dirais qu'un énorme upload de beaucoup de communes à eu lieu, et le serveur de l'API a mouliné très fort pendant plus de 30 minutes pour faire je ne sais quoi, de sorte que les diffs que je récupère avec un retard de 30minutes ont été incomplets sur ce coup là. (voir en zoom 14 le nombre de trous) > Peut-on se fier aux outils et ignorer beta ? On ne peut se fier à 100% à aucun outils ;-) il faut toujours recouper plusieurs sources en cas de doute. > Faut-il nettoyer et réimporter les communes de la zone ? Lors de mon prochain import total, je suppose que le problème se résoudra de lui même. -- 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] ajouter une way dans une relation...
On Friday 05 June 2009 10:05, Axel R. wrote: > Bonjour, > J'ai créé une relation sans aucun membre pour le moment, je l'ai uploadé Heu... je crois que c'est mal barré, quand tu envoi une relation "vide", après elle est dans le néant... > et j'ai récupéré son numéro. Avec son numéro, il reste un peu d'espoir Je tenterais : http://www.openstreetmap.org/browse/relation/X (X son numéro) Télécharger le xml, l'ouvrir dans josm, lui ajouter un membre, et ré-envoyer -- 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] Re : interpolations pour les adresses ? - GRENOBLE
On Friday 05 June 2009 12:54, THEVENON Julien wrote: > je qu il fait reference a des zones comme celle-ci > http://www.openstreetmap.org/?lat=45.187478&lon=5.72003&zoom=18&layers=B000FTF Na di diou ! Que c'est beau !! Quel travail ! Quel est le cinglé* qui a pu réaliser une telle oeuvre? à moins qu'il/elle n'est profité du cadastre vectoriel quand il était disponible ? * Ha, bien sûr, sur grenoble, c'est FredB ;-) -- 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] Re : interpolations pour les adresses ? - GRENOBLE
> > Quel est le cinglé* qui a pu réaliser une telle oeuvre? à moins qu'il/elle > > n'est profité du cadastre vectoriel quand il était disponible ? > > > > * Ha, bien sûr, sur grenoble, c'est FredB ;-) > > j'ai ma part aussi ;) Hé ben bravo à tout les deux, et quand vous en aurez marre de grenoble, viendez faire un tour au nord du coté de chambé, y'a besoin de vous ;-) -- 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] Re : interpolations pour les adresses ? - GRENOBLE
> Petite question technique : > Les bâtiments portent uniquement le tag adr:housenumber mais pas de tag > adr:street, adr::city, adr:postcode... Ça suffit pour l'adressage ? C'est pas moi qu'a fait, mais voilà quand même mon avis : adr:city et adr:postcode ont tout intérêt à ne pas être répété 1,000 fois pour chaque bâtiment, mais déterminé par l'appartenance à une surface. - city, j'imagine un landuse=residential + name - postcode, ben oui, l'idée des commune avec adr:postcode, j'y crois toujours Pour adr:street, le système http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema est rusé (mais laborieux à tagger j'imagine) Fred semble avoir créé des relations type=street avec comme membres les buildings dont le numéro est sur la rue en question et la rue. Mais je me dis aussi que ça ne pas être simple dans les cas suivants : rue : ==###zone30###== La logique habituelle veut que l'on coupe la rue en 3 morceaux, là, j'imagine que ça va foutre une sacrée grouille vis à vis du schéma karlsruhe. Où alors j'ai pas trouvé la bidouille "recommandée" -- 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] Re : interpolations pour les adresses ? - GRENOBLE
> L'outil de recherche d'OSM ne gère pas encore les numéros de rues ? > Question plus large : quel outil aujourd'hui les gère ? Les outils de rendus d'osm.org, et c'est déjà ça ! L'outil de Marcus (il parait) "traveling salesman", mais j'ai ni vu tourner ni éssayé. http://wiki.openstreetmap.org/wiki/Traveling_salesman -- 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] Re : interpolations pour les adresses ? - GRENOBLE
(grrr, smtp de merde qui est parti en vacances) > Petite question technique : > Les bâtiments portent uniquement le tag adr:housenumber mais pas de tag > adr:street, adr::city, adr:postcode... Ça suffit pour l'adressage ? C'est pas moi qu'a fait, mais voilà quand même mon avis : adr:city et adr:postcode ont tout intérêt à ne pas être répété 1,000 fois pour chaque bâtiment, mais déterminé par l'appartenance à une surface. - city, j'imagine un landuse=residential + name - postcode, ben oui, l'idée des commune avec adr:postcode, j'y crois toujours Pour adr:street, le système http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema est rusé (mais laborieux à tagger j'imagine) Fred semble avoir créé des relations type=street avec comme membres les buildings dont le numéro est sur la rue en question et la rue. Mais je me dis aussi que ça ne pas être simple dans les cas suivants : rue : ==###zone30###== La logique habituelle veut que l'on coupe la rue en 3 morceaux, là, j'imagine que ça va foutre une sacrée grouille vis à vis du schéma karlsruhe. Où alors j'ai pas trouvé la bidouille "recommandée" -- 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] Re : interpolations pour les adresses ? - GRENOBLE
> Vous allez voir que Sly va bientôt nous proposer de virer le tag name > de la rue pour la mettre dans la relation address ;-) Comment ? je ne l'ai pas encore proposé ? > > Compliqué : > > on fait une relation pour chaque route découpée et une relation sur cette > > dernière :) > > Moyennement presque pas compliqué : On fait une seule relation dès le départ qui contient l'unique way rue (comme c'est déjà fait là), mais au lieu de placer le nom dans le way, on le place dans la relation. Ensuite on découpe la rue en 3, JOSM le gérant déjà on se retrouve avec 3 ways connectés qui se retrouvent dans la relation sans rien faire (Donc 3 membres role=street pour ceux qui suivent) On place le maxspeed=30 sur le way du milieu Et le tour est joué. Facile ;-) Bon, bien sûr, derrière la scène, les développeurs vont utiliser un parseur plus compliqué, qui, détectant la présente de plusieurs role "street", va déterminer l'interpolation et le numéro de rue sur l'ensemble de la relation type=street au lieu du way. Mais faut bien qu'ils bossent un peu ses développeurs ! -- 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
[OSM-talk-fr] Vote sur le tag pour les marais salants - entrainement avant le week end
Pour ceux qui ont un compte sur le wiki et/ou qui veulent voter la proposition est là : http://wiki.openstreetmap.org/wiki/Proposed_features/Salt_Pond Comme il est probable que l'on importe nos ~33 marais salants français avec ce tag autant le rendre un poil officiel. ça casse pas des briques car c'est basique, mais ça donne de la matière pour les futurs imports de corine en europe PS: comment ça pression électoral ? -- 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
[OSM-talk-fr] Corine au point mort - On Importe !!
Bon, j'ai fais le bourrin, oui je sais, c'est pas bien, mais le projet corine n'avançait plus, je me suis donc concerté avec moi même pour finir les 5 classes en stand-by. C'est par là : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature - 324 (14 785) Forêt et végétation arbustive en mutation ( Pas d'importation pour l'instant, on fera ça plus tard/à la main) - 331 (341) Plages, dunes et sable ( Pas d'importation pour l'instant, qualité médiocre beaucoup de débordement) - 332 (1 272) Roches nues Éboulis, falaises, rochers, affleurements. ###import avec* natural=rock - 333 (3 329) Végétation clairsemée ( Pas d'importation pour l'instant, on fera ça plus tard/à la main) - 334 (64) Zones incendiées ( pas d'importation, trop louche comme classe et peu durable ) - 335 (144) Glaciers et neiges éternelles ###import avec* natural=glacier On attaque ce week end pluvieux ? -- 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] Vote sur le tag pour les marais salants - entrainement avant le week end
On Friday 05 June 2009 17:55, Emilie Laffray wrote: > Je vote Sly!! > > (Tire de Wikipedia > > *Sly* is an adjective <http://en.wikipedia.org/wiki/Adjective>, meaning > one of the following: > >1. Clever in practical matters. >2. Hiding ones true intentions or goals. ;-) Serait-ce exactement ça ? (l'avouer en auto-dérision faisant bien sûr parti d'un projet à long terme de décrédibilisation de cet état de fait tout en maintenant un doute sur les intentions réelles, niark niark) On trouve en français des synonymes du style : rusé, sournois, manipulateur, menteur dans un but, ... que du bon en somme ;-) Je n'eu pas choisi en connaissance de cause, mais ça tombe pas trop loin -- 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] Corine au point mort - On Importe !!
On Friday 05 June 2009 17:58, Emilie Laffray wrote: > Il n'y a pas une reunion prevu ce mardi qui vient a ce propos? Parfait, y'aura plus qu'a dire "ok" et se concentrer sur la méthode d'import et la répartition des tâches -- 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] Corine au point mort - On Importe !!
On Friday 05 June 2009 18:21, Pieren wrote: > 2009/6/5 sly (sylvain letuffe) : > > On Friday 05 June 2009 17:58, Emilie Laffray wrote: > >> Il n'y a pas une reunion prevu ce mardi qui vient a ce propos? > > > > Parfait, y'aura plus qu'a dire "ok" et se concentrer sur la méthode d'import > > et la répartition des tâches > > C'est encore mieux en demandant si tout le monde est d'accord, non ? Bien sûr, c'était une boutade. C'est que j'ai toujours du mal à imaginer qu'une réunion irc, rassemblant forcément moins de monde (l'annonce étant faite ici sur cette liste) puisse avancer plus qu'une discussion sur la liste. Mais j'espère avoir tort et pouvoir être là mardi -- 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] Pistes cyclables - routes fermées aux véhicules à moteur
Rien que mon avis à moi : > - piste cyclable unidirectionnelle : cycleway=track;oneway highway=cycleway + cycleway=track + oneway=yes > - piste cyclable bidirectionnelle : cycleway=track (par défaut ?) highway=cycleway + cycleway=track > - piste cyclable unidirectionnelle à gauche : cycleway=track:left;oneway > - piste cyclable bidirectionnelle à droite : cycleway=track:right Si c'est séparé de la rue, alors je trace un nouveau chemin, le left/right devenant inutile > - route goudronnée non ouverte aux véhicules à moteur (bois de Boulogne, > Vincennes, Saint Germain ...) : highway=path foot=designated > bicycle=designated surface=paved (retrouvé sur le wiki) > j'ai aussi trouvé des highway=service access=no foot=yes bicycle=yes (Bois de > Boulogne) Je taggue juste "highway=path", le "non motorisé" est inclu dans path > Souvent, on retrouve des highway=footway (Bois de Vincennes) Si vélo ET piéton y sont autorisés, je fais juste un "highway=path", de sorte qu'en france je ne tag que très peu de cycleway/footway > Par ailleurs, comment tagger les blocks bloquant la circulation automobile : > barrier=bollard ou barrier=gate (comme on le retrouve déjà au Bois de > Boulogne > ?) ça dépend du type de blocage http://wiki.openstreetmap.org/wiki/Key:barrier ensuite, je place un noeud sur le chemin. > - chemin en terre partagé entre cyclistes et piétons (exemple de nombreux > chemins de halage en IDF) highway=path foot=designated bicycle=designated > surface=unpaved highway=path (+ surface) (+ smoothness) > - et enfin, voie bus en contresens ouverte aux vélos (rue de Ménilmontant en > descente) : highway=tertiary oneway=yes busway:opposite line > cycleway=share_busway Galère ça, il y a un manque sur les restrictions par catégories de véhicule, donc je ne sais pas trop comment faire -- 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] Pistes cyclables - routes fermées aux véhicules à moteur
> >> - route goudronnée non ouverte aux véhicules à moteur (bois de Boulogne, > >> Vincennes, Saint Germain ...) : highway=path foot=designated > > Je taggue juste "highway=path", le "non motorisé" est inclu dans path > Hum, troll en perspective. Pour moi, un path est un chemin/sentier > trop étroit pour voiture, donc +1 avec Sly. Trollons un peu alors (mais tu as trop l'air d'être d'accord avec moi, ça va pas être drôle), pour moi la notion de largeur ou même de surface n'est pas incluse dans path, mais comme ce wiki a encore moins de pérennité que les données OSM, une des phrases qui décrivait également path (au moment où j'avais voté), mais a été retirée était : highway=path is a generic path, either multi-use, or unspecified usage. The default access restriction of highway=path is "open to all non-motorized vehicles, but emergency vehicles are allowed". - c'est un endroit utilisable légalement par plusieurs moyens de transport - Du moment qu'ils sont non motorisés - les secours on le droit de les emprunter Après, il est sûr que l'argument largeur va entrer en ligne de compte dans les faits, puisque si un chemin est construit large, c'est en général pour être emprunté par des 4 roues, mais un path de 10m de large bloqué par des rochers de chaque coté ne me choquerait pas. > > highway=path (+ surface) (+ smoothness) > argh ! smoothness=tagness_horribleness... highway=path est bien suffisant En parenthèse c'est facultatif et selon l'utilité estimé du mappeur, mais en effet j'ai oublié d'être objectif ;-) en rajoutant : (+tracktype) "highway=path bien suffisant", je dirais que ça dépend des cas, il y a plein de cas où c'est goudronné, utilisable par vélo, roller, pied, chien, skate et là je ne fais rien de spécial je dis juste "path", mais des fois, si passer en roller devient galère, si c'est super pentu, bien foireux je rajoute des info de surface et/ou smoothness et/ou incline -- 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] Mapnik perso - pas de rendu des routes
On Monday 08 June 2009 17:00, kimaidou wrote: > Mon rendu ressemble à celui d'osm.org, mais sans les lignes qui représentent > les routes. > Je me souviens avoir vu ce type de rendu "sans routes" sur le site de sly, > et donc je me sens moins seul :) ha tiens, j'allais le dire... > Quelqu'un aurait-il une idée svp ? Je n'ai pas eu le courage de tenter de régler le problème, donc je suis revenu à ma version du fichier xml. Je soupçonne, mais sans preuve, qu'il te faut la dernière version de osm2pgsql car le rangement dans les tables a, il me semble, un poil changé. Je serais intéressé toutefois par tes découvertes (mon fichier xml se fait vieux et certains trucs ne sont pas affichés) -- 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] Pistes cyclables - routes fermées aux véhicules à moteur
On Monday 08 June 2009 17:22, Esperanza wrote: > Merci pour vos réponses, mais il me reste encore quelque doutes ... > > Faut-il tracer chaque piste cyclable à côté de la route, même si elle est > strictement parallèle ? Y'a pas vraiment de "faut-il", chacun fait un peu ce qu'il veut, mais en tout cas je tente de respecter cette règle : "si élément infranchissable pour véhicules à roues existe, je sépare les chemins" (terre plein central, barrière de sécurité, bout de trottoir, rangée d'arbres,...) -- 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] Fwd: Corine processing
> En tout cas, ils semblent déjà d'accord avec nos choix de tags ;-) Pas drôle, on va croire qu'on est les meilleurs. J'aurais bien aimé une solution pour le 324 et le 333. Tu lui a dit qu'on en saurait certainement plus sous peu ? (histoire d'éviter qu'ils commencent de leur coté la création d'un programme) > -- Forwarded message -- > From: Jaak Laineste > Date: Mon, Jun 8, 2009 at 2:54 PM > Subject: Corine processing > To: Pieren > > > Hello Pieren, > > I am dealing with CLC upload, the data is for 10x smaller country than > France, but still quite big (roughly doubles data in terms of OSM file > size). Your approved classification seems to be quite final and ok; we > decided to take it also as basis. > > Question: have you found or prepared an usable tool for node merging before > final uploading? I have used JOSM validator plugin, which is ok for some of > the datasets, but not for big ones like forests and fields. > > > Thank you! > > /JaakL > > ___ > 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] Pistes cyclables - routes fermées aux véhicules à moteur
On Monday 08 June 2009 17:36, Eric Sibert wrote: > Dans la catégorie des problèmes de parcours cyclables: > > - route à double sens pour les voitures > - dans un sens, bande cyclable séparée de la chaussée par une ligne blanche > - dans l'autre sens, piste cyclable sur la moitié du trottoir > > Vous faites comment pour indiquer tout ça? L'idée du opposite_lane que proposait pieren tout à l'heure est une solution à ton cas 2 (perso j'aime pas du tout, ça fait trop "rustine") Pour ton 3, dès que ça touche aux trottoirs je ne fais rien car tout reste à définir je trouve ; et je compenserais par une logique plus macroscopique en indiquant que cette route fait partie d'un réseau cyclable (relation type=route), et à moins d'être un cycliste aveugle, ça devrait suffire et bien se passer. > En cherchant un peu, je dois pouvoir trouver d'autres cas tordus sur > Grenoble. Je pense qu'on en a tous plein dans la tête et qu'on a laissé tombé par manque d'intérêt ou de tags, les choses s'améliore au fûr et à mesure -- 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] Mapnik perso - pas de rendu des routes
On Monday 08 June 2009 18:17, kimaidou wrote: > Un 2ème retour : j'essayais de modifier mapnik/osm.xml pour tester mes > rendus, mais cela ne fonctionnait pas , malgré le bon paramètre passé à > generate_tiles.py > mapfile= /home/kimaidou/tmp/osm/mapnik/osm.xml > tile_dir= /home/kimaidou/tmp/osm/mapnik/tiles/ > render_tiles( (3.83470002, 43.5844998, 3.92240001, > 43.6360999) /home/kimaidou/tmp/osm/mapnik/osm.xml > /home/kimaidou/tmp/osm/mapnik/tiles/ 15 15 Montpellier ) > > Après moultes tests, j'ai essayé d'éditer le fichier osm-template.xml, et > non osm.xml, et PAF, cela fonctionne... > Heu..je ne comprends pas bien pourquoi. Quelqu'un aurait-il une explication > ? Désolé, j'ai rien compris, tu peux détailler ce que tu fais dans l'ordre ? ( conseil, ouvre le fichier generate_tiles.py ça te parlera peut-être) -- 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] Mapnik perso - pas de rendu des routes
On Monday 08 June 2009 18:35, kimaidou wrote: > Désolé Sly, je suis allé un peu vite. > > J'avais mis le nez dans le fichier generate_tiles.py , et c'est là que j'ai > ajouté les 2 print pour le debug (cf lignes 113 et 119 : > http://pastebin.com/m15817849 ) > Et donc apparemment c'est le fichier osm.xml qui est utilisé. > > Mais, bizarrement, si je veux modifier le rendu, rien ne change si je > modifie osm.xml, alors que j'ai des changements lorsque j'édite > osm-template.xml. Ou ben ! "The truth is out there" (mais peut-être pas là !) Ce coup ci j'ai compris, mais j'ai pas plus d'explication. (Sans méchanceté, ni moquerie, ni, ni ni) : Tu dois lancer un truc que t'as pas compris pourquoi tu le lançais et qui te bidouille ton osm.xml Tu peux copier la session de ton terminal pour voir exactement ce que tu lances ? genre (après sauvegarde): $ ls -l (blabla) $ echo "prout" > osm.xml $ set-mapnik-env generate_image.py (blabla crash ou pas ?) $ cat set-mapnik-env (blibli) -- 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] Question concernant osmose
Saint-Lyé-La-Forêt => Saint-Lyé-la-Forêt L'es tatillon le osmose, L != l -- 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] Lignes de bus, besoin d'aide
> Le mien (spécifique pour les bus) : > > http://news.openstreetmap.fr/public/bus.xml Juste une remarque inutile ;-), au début je n'avais pas compris comme traiter le contenu d'un champ et par recopie j'en suis arrivé à faire comme toi : SELECT ref as name (pour lui changer son nom) mais en fait, dans ta définition : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lignes de bus, besoin d'aide
On Tuesday 09 June 2009 11:38, kimaidou wrote: > J'ai regardé un peu, et en fait: > * osm2pgsql n'importe pas tous les tags présents dans le fichier osm. Par > exemple, pas de colonne "operator", qui nous serait bien utile pour > n'appliquer une couleur qu'à la ligne 15 (ref=15) de l'opérateur RATP > (operator=RATP). Change le fichier default.style > * osm2pgsql fait 4 tables : une pour les points, une pour les polygones, une > pour les lignes, et une pour les "roads". Je ne sais pas bien si cette > dernière enregistre les relations ou autre chose. Une idée ? si polygone, prefix_polygon, si linéaire prefix_roads (ça dépend donc des type de relation) Je t'accorde que c'est une peu le bazar, il n'y aurait dû avoir que point/ligne/surface > Pour moi, cela est plutôt super limitant, car on perd la puissance du couple > tag=valeur de la bdd OSM. On perd des tags, notamment les tags color, > operator, name de la relation, A toi de dire à osm2pgsql de les importer. Il existe une autre solution qui est de créer un schéma avec osmosis à la place de osm2pgsql, qui, lui, fait de l'import .osm <=> postgis une équivalence Mais j'ai cru comprendre que toute la force de osm2pgsql n'est pas de garder l'équivalence, mais de faire plein de pré-traitement pour accélérer les choses dans une logique "temps réél" > et donc on ne peut pas styler en fonction de > ces tags Ce problème est sans rapport, cf plus loin > Par contre, vu qu'on travaille avec Posgis, on pourrait limiter les requêtes > via des bouding box Trop galère. > Le 9 juin 2009 11:24, Pierre Mauduit a écrit : > > Une des limitations de mapnik, que j'ai découvert récemment en tentant > > un rendu perso du plan de métro RATP : Apparemment on ne peut pas > > utiliser une colone de la base de données directement dans les options > > de style CSS de mapnik, et c'est bien dommage, Petite rectification, mapnik (le moteur) n'est pas en cause, c'est le module de traitement des fichiers de config xml qui est en cause. Et en effet, pour l'instant, je n'ai pas réussi à changer le style dynamiquement en fonction de la base, j'ai dû faire comme toi : > > on est obligé de se faire > > des fichiers XML hyper lourds qui filtrent en fonction du nom, de la ref > > ... pour déterminer de quelle ligne il s'agit et ainsi choisir la bonne > > couleur. Autant dire, que quand on va vouloir prendre en compte de tag color qui est 24bit, ça va faire un paquet de bloc style ;-) > > Si quelqu'un a une autre technique afin d'utiliser les données en base > > directement dans les définitions des balises de style CSS je suis preneur Pareil, il semblerait qu'utiliser l'API python puisse nous sortir d'affaire, mais j'ai pas fais assez de tests pour le confirmer -- 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
