Re: [OSM-talk-fr] Osmose et les communes
Nicolas Bouthors a écrit : Exemple : la relation 145705 (commune « Hauteville-Lompnes ») m'est remonté par Osmose dans mes erreurs, or le validateur 1 la voit nikel[1] itou pour le validateur[2][3]. Comment peut-on savoir ce qu'Osmose reproche à ces communes là ? Serait-il possible que le texte d'erreur soit un poil plus informatif que « TEST Relation boundary (1) » ? La liste d'erreurs est regénérée toutes les 24h. Attendons la prochaine génération pour voir si l'erreur est toujours là. [2]http://osmose.openstreetmap.fr/tools/relation_analyser/cgi-bin/relation_result.py?NumRelation=145705 [3] Au passage bravo à celui ou celle qui a fait le validateur 2, Heureux que ça rende service. -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et les communes
Yoann ARNAUD a écrit : Nicolas Bouthors a écrit : [2]http://osmose.openstreetmap.fr/tools/relation_analyser/cgi-bin/relation_result.py?NumRelation=145705 [3] Au passage bravo à celui ou celle qui a fait le validateur 2, Heureux que ça rende service. Bonjour, Oui bien ptratique ! Merci. S'il pouvait y avoir un lien sur l'écran de résultat quand la relation est fautive pour relancer le test après corrections sur JOSM... Merci d'avance Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et les communes
Nicolas Bouthors a écrit : Bonsoir, Osmose remonte maintenant des erreurs sur les relations des communes. C'est pratique pour débugger les imports à partir du cadastre : on peu voir quand elle n'est pas fermée, ou fourchue... Des erreurs que ne voit pas forcément beta.letuffe.org (cas de la fourchue). Zut, on a fait l'annonce à ma place... et moi qui vient de désactiver le plugin je vais être mis au poteau. Par contre dans certains cas il remonte les communes en erreur sans raison apparente/explicite. Les explications détaillées on sauté... je les ai remises. Je prépare la mise en place d'une base de données contenant ces erreurs, ce qui permettra de faire une slippymap, de filtrer certaines erreurs... mais chut c'est encore secret. Exemple : la relation 145705 (commune « Hauteville-Lompnes ») m'est remonté par Osmose dans mes erreurs, or le validateur 1 la voit nikel[1] itou pour le validateur[2][3]. Comment peut-on savoir ce qu'Osmose reproche à ces communes là ? Serait-il possible que le texte d'erreur soit un poil plus informatif que « TEST Relation boundary (1) » ? Les détails sont revenus mais le plugin a été désactivé. En fait ces tests ne sont fait que depuis deux jours, depuis qu'osmose utilise une base de données locale synchronisée sur les minute-slow diff. Je viens de lancer l'indexation de certains champs de la base, ce qui m'empêche de la mettre à jour. Les plugins utilisant cette base sont désactivés. Je ne sait pas combien de temps cela prendra... les deux processeurs d'osmose tournent à plein régime depuis hier soir. [1]http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=145705 [2]http://osmose.openstreetmap.fr/tools/relation_analyser/cgi-bin/relation_result.py?NumRelation=145705 [3]Au passage bravo à celui ou celle qui a fait le validateur 2, c'est un bijou ! Merci, ça fait toujours plaisir de voir que des outils sont bien. Le frontend est de yoann et le backend de moi. -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et les communes
Vincent Pottier a écrit : S'il pouvait y avoir un lien sur l'écran de résultat quand la relation est fautive pour relancer le test après corrections sur JOSM... Bonne idée. Je viens de le rajouter. -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose et les communes
Yoann ARNAUD a écrit : Vincent Pottier a écrit : S'il pouvait y avoir un lien sur l'écran de résultat quand la relation est fautive pour relancer le test après corrections sur JOSM... Bonne idée. Je viens de le rajouter. Merci. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] boundaries : admin_level=10 et démocratie locale, arrondissements et quartiers
Bonjour, La page http://wiki.openstreetmap.org/wiki/Key:boundary précise les usages des admin_level. Ceux-ci sont admis, sauf exception, pour des valeurs de 1 à 10. Pour la France la valeur admin_level=10 est réservée aux arrondissements des villes PLM (Paris, Lyon, Marseille). Comment enregistrer les subdivisions plus fines dans les autres villes (démocratie locale, conseils de quartier...) et autres... 1/ Doit-on introduire un admin_level=11 (les allemands l'ont fait, mais c'est la seule exception répertoriée dans la page) 2/ Est-il envisageable de passer les arrondissements PLM en admin_level=9 pour disposer du 10 pour les autres villes ? Ma préférence est pour le 2. Vincent ___ 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
Bonjour, Jean a écrit : J'ai une première question : c'est quoi ces vilains traits sur la carte de france ? http://www.openstreetmap.org/?lat=47.768lon=-1.621zoom=10layers=B000FTF Un bug ou une mauvaise saisie. On dirait une tentative de déménagement partiel de Vienne du Danube vers le large des côtes françaises ;-) Comme c'est légèrement visible, ça devrait être corrigé rapidement. -- Frantz ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] boundaries : admin_level=10 et démocratie locale, arrondissements et quartier s
2009/5/25 Vincent Pottier vpott...@gmail.com: Bonjour, La page http://wiki.openstreetmap.org/wiki/Key:boundary précise les usages des admin_level. Ceux-ci sont admis, sauf exception, pour des valeurs de 1 à 10. Pour la France la valeur admin_level=10 est réservée aux arrondissements des villes PLM (Paris, Lyon, Marseille). Comment enregistrer les subdivisions plus fines dans les autres villes (démocratie locale, conseils de quartier...) et autres... 1/ Doit-on introduire un admin_level=11 (les allemands l'ont fait, mais c'est la seule exception répertoriée dans la page) 2/ Est-il envisageable de passer les arrondissements PLM en admin_level=9 pour disposer du 10 pour les autres villes ? Ma préférence est pour le 2. Vincent La tendance générale étant de mettre à admin_level=9 les divisions communales qui ont un conseil et à 10 celles qui n'en ont pas, je pencherais plutôt pour le transfert des arrondissements au niveau 9. Pieren ___ 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.768lon=-1.621zoom=10layers=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.768lon=-1.621zoom=10layers=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] Présentation et question sur les t raits sur la carte de france
Frantz a écrit : Bonjour, Jean a écrit : J'ai une première question : c'est quoi ces vilains traits sur la carte de france ? http://www.openstreetmap.org/?lat=47.768lon=-1.621zoom=10layers=B000FTF Un bug ou une mauvaise saisie. On dirait une tentative de déménagement partiel de Vienne du Danube vers le large des côtes françaises ;-) Comme c'est légèrement visible, ça devrait être corrigé rapidement. Moi j'hésite entre un tag highway=OVNI_landing mal rendu ou un projet de super-méga voie expresse primary-tertiary qui doit être réalisé avant l'été pour que les Viennois puissent se dorer sur les plages françaises. Au passage, ils doivent pouvoir inviter leurs copains de Münich, Friboug, goûter le vin de Chablis. Puisque c'est pour très bientôt, ça n'est pas taggué en construction. Étrange, on ne le voit qu'à zoom=10. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Présentation et question s ur les traits sur la carte de france
surtout qu il n apparait qu a un niveau de zoom precis. Au dessus et en dessous en terme de niveau de zoom on ne les voit pas De : sly (sylvain letuffe) sylv...@letuffe.org À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi, 25 Mai 2009, 12h27mn 01s Objet : Re: [OSM-talk-fr] Présentation et question sur les traits 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.768lon=-1.621zoom=10layers=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.768lon=-1.621zoom=10layers=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 ___ 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
sly (sylvain letuffe) a écrit : 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.768lon=-1.621zoom=10layers=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.768lon=-1.621zoom=10layers=B Ou un gros pâté à la saisie (bug à l'enregistrement sur JOSM) et déjà 'reverté'. Le rendu ne reste que sur le zoom=10 jusqu'à recalcul des dales. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] boundaries : admin_level=10 et démocratie locale, arrondissements et quartiers
Pieren a écrit : 2009/5/25 Vincent Pottier vpott...@gmail.com: Bonjour, La page http://wiki.openstreetmap.org/wiki/Key:boundary précise les usages des admin_level. Ceux-ci sont admis, sauf exception, pour des valeurs de 1 à 10. Pour la France la valeur admin_level=10 est réservée aux arrondissements des villes PLM (Paris, Lyon, Marseille). Comment enregistrer les subdivisions plus fines dans les autres villes (démocratie locale, conseils de quartier...) et autres... 1/ Doit-on introduire un admin_level=11 (les allemands l'ont fait, mais c'est la seule exception répertoriée dans la page) 2/ Est-il envisageable de passer les arrondissements PLM en admin_level=9 pour disposer du 10 pour les autres villes ? Ma préférence est pour le 2. Vincent La tendance générale étant de mettre à admin_level=9 les divisions communales qui ont un conseil et à 10 celles qui n'en ont pas, je pencherais plutôt pour le transfert des arrondissements au niveau 9. Pieren Pas de distinction PLM et autres ? Ce ne sont pas les mêmes statuts juridiques. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] boundaries : admin_level=10 et démocratie locale, arrondissements et quartier s
2009/5/25 Vincent Pottier vpott...@gmail.com: Pieren a écrit : Ma préférence est pour le 2. Vincent La tendance générale étant de mettre à admin_level=9 les divisions communales qui ont un conseil et à 10 celles qui n'en ont pas, je pencherais plutôt pour le transfert des arrondissements au niveau 9. C'est à dire que ma préférence irait aussi à la deuxième proposition. Pieren ___ 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
J'ai déjà constaté ce bug vendredi. Mais pensant que je n'étais pas le seul à avoir vu ce trait, je pensais que le bug était déjà connu, ou alors que c'était très passagers. Mais apparament, la communauté ne l'avait pas remarqué. J'étais allé télécharger les données entre Belfort et Epinal, mais je n'avais rien constaté. Mais c'est marrant de voir la ville de Wien translaté de la sorte dans l'océan. :) --- En date de : Lun 25.5.09, Vincent Pottier vpott...@gmail.com a écrit : De: Vincent Pottier vpott...@gmail.com Objet: Re: [OSM-talk-fr] Présentation et question sur les traits sur la carte de france À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Lundi 25 Mai 2009, 12h41 sly (sylvain letuffe) a écrit : 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.768lon=-1.621zoom=10layers=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.768lon=-1.621zoom=10layers=B Ou un gros pâté à la saisie (bug à l'enregistrement sur JOSM) et déjà 'reverté'. Le rendu ne reste que sur le zoom=10 jusqu'à recalcul des dales. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Clarification sur l'usage du cadastre de la DGI
Je pense que dans les villages où existe un point GEODESIQUE IGN (sur le clocher...), on peut retracer depuis le cadastre, sur osm : la précision me paraît suffisante, dans ces coins, voire en ville, effet canyon, souvent meilleure que nos gps. Par contre dans des patelins éloignés, qui n'ont pas de point géodésique au village-même, mais qui seulement ont un point du réseau du NIVELLEMENT IGN (au pied de l'église, de la Mairie, de l'école, sous un pont, au bord d'une route... méfiance : En te tels cas, j'ai récemment encore constaté des écarts en x/y dans les cinquante mètres (pourtant il y avait des points géodésiques aux alentours, à 2 à 3 kilomètres de distance - mais pas visibles directement depuis le patelin : Personne ne s'est donné la peine, de faire des polygones de visée depuis ces points jusqu'au bourg...). Donc, s'il n'existent QUE des points de Nivellement IGN au patelin, pas de point Géodésique (et si aucun géomètre n'a fait de relevé de voirie au gps centimétrique, auquel je pourrai me raccrocher), le cadastre est à prendre avec précaution : En local il probablement est assez correct, mais son géoréférencement peut être beaucoup moins précis que nos gps. Dans ces cas (pour mon boulot) je fais un tirage papier du plan cadastre, vais sur place, et avec gps de rando prends six à dix waypoints sur des angles sud de maisons bien dégagées (≥ cinq sats, et avec les deux sats waas), annote ces wpts sur le tirage du cadastre, et de retour à la maison je ripe le plan cadastre sur la moyenne de ces wpts, avant de tracer dessus. C'est suffisant pour le géoréférencement de la plupart des plans de masse de mes projets. Je pense que c'est suffisant aussi pour osm. Amicalement Gerhard --- Le 22 mai 09 à 14:15, Etienne a écrit : A condition de ne pas cartographier n'importe quoi non plus. Il faut, je trouve, sauf si on est sur de soi, aller voir le terrain avant. un minimum. Pour des villages, bon, normallement, il n'y a pas trop de sens interdit, restriction de tourner, ... Mais en ville, c'est autre chose concernant les voies de circulation, ou les détails à mapper,... Belfort (90) a été fait à partir du cadastre en très très peu de temps. On voyant la carte, on a l'impression qu'elle est bien, mais une fois sur le terrain, il faut retoucher, corriger les erreurs keepright, et deplacer/supprimer certains ways. Resultat, cela demande beaucoup de travail pour voir et corriger les erreurs. Quand je mappe, j'essaye de faire ça completement sur une zone que je me donne, en prenant les petits chemins piétons,... Sur le cadastre, on ne voit pas ces petits chemins, ou autre petit détails. C'est donc plus dur de rajouter les ces détails. Mais après, chacun mappe aussi comme il le peut, et comme il le veut. Etienne --- En date de : Ven 22.5.09, Vincent Pottier vpott...@gmail.com a écrit : De: Vincent Pottier vpott...@gmail.com Objet: Re: [OSM-talk-fr] Clarification sur l'usage du cadastre de la DGI À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Vendredi 22 Mai 2009, 11h47 Charles Nepote a écrit : Bonjour, J'ai une question de débutant qu'il serait peut-être bon d'ajouter à la FAQ. Je connais *très bien* certains villages dont la cartographie est aujourd'hui à peu près nulle. Ces villages sont éloignés de mon domicile et je ne peux donc en faire aujourd'hui aucune trace GPS. Est-ce que cela pose problème que je réalise la cartographie de ces villages en me fondant sur le cadastre de la DGI (merci le plug-in JOSM) et mes connaissances du terrain ? Je ne pense pas, à l'évidence, aux bâtiments mais : -- aux voies de communications -- aux points remarquables (écoles, mairies, lieux de culte, numéros remarquables (aux intersections), etc.) [pas forcément leur contours mais plutôt leur situation] Je pense que oui, car j'effectue une interprétation des données du cadastre (type de voies, sens uniques, type d'école, etc.) mais je voulais avoir votre avis sur la question. Enfin, cartographiquement parlant, les données du cadastre sont- elles fiables ? (je constate souvent entre 5 et 15 mètres de différences entre les relevés d'osmeurs et le cadastre à Marseille). Charles Nepote. Bien sûr qu'on peut cartographier à partir du cadastre ! Sur Besançon, je n'ai pas parcouru toutes les voies qui sont sur OSM. Parfois un bout me suffit à repérer le type de voie, le sens (interdit ou non)... Le Plugin ajoutera le tag source 'cadastre...' ce qui est un peu abusif dans ce cas. Mais bon... Dans les grandes villes, il me semble que le cadastre est bon. bien positionné. Les écarts de traces dans Marseille peuvent s'expliquer de plusieurs façon : - Le GPS a une imprécision intrinsèque qui peut atteindre 20 m, notamment en ville, au milieu de bâtiments élevés quand le nombre de satellites reçus diminue, cette imprécision peut varier d'un jour à l'autre. - Le GPS est sensible aux échos sur les bâtiments : la trace fait des
Re: [OSM-talk-fr] boundaries : admin_level=10 et démocratie locale, arrondissements et quartiers
Pieren a écrit : 2009/5/25 Vincent Pottier vpott...@gmail.com: Pieren a écrit : Ma préférence est pour le 2. Vincent La tendance générale étant de mettre à admin_level=9 les divisions communales qui ont un conseil et à 10 celles qui n'en ont pas, je pencherais plutôt pour le transfert des arrondissements au niveau 9. C'est à dire que ma préférence irait aussi à la deuxième proposition. Pieren Ok, il fallait lire divisions communales qui ont un conseil d'arrondissement... Parce que la démocratie participative introduit un conseil de quartier, d'où ma confusion. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prairie sur beta - corine
Il y a aussi des forêts tracés d'après operaerial, dans osm. Aucun de ces trois tracés n'est d'accord, et quand on regarde les parcelles d'ONF sur le cadastre, des forets domaniales, ça ferait encore un quatrième tracé. Et les fichiers des sig des coms d'agglo, sur les forêts privés donneraient encore un autre. Je pense que c'est une question de l'échelle d'origine, à laquelle chacun de ces plans avait été crée. Et aucun deux paraît suffisamment précis pour rester dans OSM, sans qu'à un moment ou un autre il sera corrigé, au moins en partie, par nous (Eh, je vois bien : Souvent, là où selon l'une ou l'autre source, je serais soit en pleine forêt soit en plein champs, en réalité la route que je gpxe (-osm) est la limite des deux). Donc, puisque tout cela visiblement sera sujet à des modifs ultérieures par nous, il m'est un peu égal, quelle source sera choisie. A la limite, quant à choisir parmi les différentes sources, je dirai, de prendre la plus détaillée, au cas le cas : Prendre celle, qui, découpée en tronçons, montre le plus de nodes par kilomètre. Gerhard --- Ça va se corser, quand nous, on rectifiera partiellement ces polys, d'après nos observations sur place, d'après cadastre, et d'après gps : Dans la plupart des cas, on va pouvoir rectifier seulement une partie du contour de la forêt, mais pas le contour entier du bois. Donc, logiquement, et par acquit de conscience, on découpera le contour du bois en morceaux, pour virer le tag source sur la partie qu'on a corrigé (pas de tag source implique - observation du osm'eur), et le conservera sur le reste. Je m'imagine le rendu foireux des polys :-( Donc là aussi, on devra faire dans les relationships, comme on le fait pour les boudary/admin. Et de même pour tous les autres landuse importés. Quel boulot de galérien, si nous devons ultérieurement créer une relation pour chacun de ces lopins de terre !... Pourrait-on, lors de l'importation de telles masses de polys, les importer dès le départ comme relations, actuellement chacune avec un seul polygone comme membre ? Amha, ça pourrait énormémang facilitationner leur découpage futur en tronçons rectifiés d'après données de terrain... --- --- Le 23 mai 09 à 18:50, Art Penteur a écrit : Le 23 mai 2009 11:18, Emilie Laffray emilie.laff...@gmail.com a écrit : Les donnees de Corine ne sont pas forcement plus precises, car il y a des gens qui ont passe du temps a delimiter certaines forets correctement. Et on va avoir des cas pas facile à résoudre. Par exemple : http://www.openstreetmap.org/? lat=43.4094lon=2.0449zoom=12layers=B000FTF et http://beta.letuffe.org/? lat=43.40566lon=2.02701zoom=12layers=0BTFFF On a l'impression que le tracé actuel dans OSM est plus fin (meilleure résolution spatiale)... mais le tracé Corine distingue mieux les différents types de végétation. Qui choisir ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation et question sur les t raits sur la carte de france
Moi j'ai déjà eu un problème très similaire (mais sans doute limité car j'étais en lambert zone). C'est survenu après un out of memory dans JOSM. En gros une coordonnée s'est retrouvée écrasée par du 0. Et on ne s'en apperçoit qu'après l'upload car l'affichage ne le montre pas tout de suite... Le 25 mai 09 à 13:12, Etienne T a écrit : J'ai déjà constaté ce bug vendredi. Mais pensant que je n'étais pas le seul à avoir vu ce trait, je pensais que le bug était déjà connu, ou alors que c'était très passagers. Mais apparament, la communauté ne l'avait pas remarqué. J'étais allé télécharger les données entre Belfort et Epinal, mais je n'avais rien constaté. Mais c'est marrant de voir la ville de Wien translaté de la sorte dans l'océan. :) ___ 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
J'ai mis des sommets dans osm, sur lesquels je n'étais pas allé moi-même avec le gps : J'ai fait les positionnements x/y par visée croisée depuis deux points gps (mon vieux Magellan de mathusalem permet ça), et y avais reporté les z's (altis) affichés sur les pancartes et textes affichées aux syndicats d'initiative et offices de tourisme, sur la voie publique, à l'extérieur, pas de copyright affiché. J'avais pris ces papiers et pancartes en photo, pour ma bonne foi. Maintenant, si eux mêmes ont escamoté un © dans le cadre du truc, ou ont oublié d'en mettre, j'estime qu'en cas de litige ce n'est pas moi qui serait en cause (pour la transmission d'une donné d'altitude), mais eux. D'autre part, des données d'altitude de sommets français aussi figurent dans le Webster's, et dans des dépliants de gîtes, sans mentions de ©. Aussi, pour le moins en ce qui concerne les sommets majeurs d'un patelin, je pense qu'il ne peut pas y avoir de © sur l'alti (sauf si on irait chercher dans les décimètres) car ces altis métriques sont enseignées publiquement déjà aux élèves de primaire, du coin... (et pour les sommets d'importance nationale, sont enseignés au niveau national...). Peut-être j'ai eu tort ? Par les temps qui courent, où même des des plantes sauvages peuvent être brevetés, on doit s'attendre à tout, même à un copyright sur des montagnes... Dites. Gerhard --- Le 23 mai 09 à 17:11, sylvain letuffe a écrit : Mais les autres sommets dans OSM, ce sont surement les altitudes de l'IGN.(par exemple pour reprendre le Crêt de la neige : 1720 mètres dans OSM et sur l'IGN). C'est hélas ce que je crains aussi, ce qui fait de la base OSM des sommets une donnée un poil litigieuse ___ 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 montagne pour bientôt
Hello ! Sur les histoire de copyright je pense que tu a tore car sauf erreur de ma part le copyright est implicite :( Par contre es-ce qu'il n'existe tout simplement une vielle carte avec les altitude qui ne sois plus couverte par le copyright ? Il me semble que de tel source doive exister ? CU Stéphane 2009/5/25 g.d g...@wanadoo.fr: J'ai mis des sommets dans osm, sur lesquels je n'étais pas allé moi-même avec le gps : J'ai fait les positionnements x/y par visée croisée depuis deux points gps (mon vieux Magellan de mathusalem permet ça), et y avais reporté les z's (altis) affichés sur les pancartes et textes affichées aux syndicats d'initiative et offices de tourisme, sur la voie publique, à l'extérieur, pas de copyright affiché. J'avais pris ces papiers et pancartes en photo, pour ma bonne foi. Maintenant, si eux mêmes ont escamoté un © dans le cadre du truc, ou ont oublié d'en mettre, j'estime qu'en cas de litige ce n'est pas moi qui serait en cause (pour la transmission d'une donné d'altitude), mais eux. D'autre part, des données d'altitude de sommets français aussi figurent dans le Webster's, et dans des dépliants de gîtes, sans mentions de ©. Aussi, pour le moins en ce qui concerne les sommets majeurs d'un patelin, je pense qu'il ne peut pas y avoir de © sur l'alti (sauf si on irait chercher dans les décimètres) car ces altis métriques sont enseignées publiquement déjà aux élèves de primaire, du coin... (et pour les sommets d'importance nationale, sont enseignés au niveau national...). Peut-être j'ai eu tort ? Par les temps qui courent, où même des des plantes sauvages peuvent être brevetés, on doit s'attendre à tout, même à un copyright sur des montagnes... Dites. Gerhard --- Le 23 mai 09 à 17:11, sylvain letuffe a écrit : Mais les autres sommets dans OSM, ce sont surement les altitudes de l'IGN.(par exemple pour reprendre le Crêt de la neige : 1720 mètres dans OSM et sur l'IGN). C'est hélas ce que je crains aussi, ce qui fait de la base OSM des sommets une donnée un poil litigieuse ___ 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://www.ubuntu-fr.org - Distribution Linux ___ 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
Stéphane Brunner a écrit : Hello ! Sur les histoire de copyright je pense que tu a tore car sauf erreur de ma part le copyright est implicite :( Sans mention une information : - n'a pas le droit d'être copiée (copyright des droits anglo-saxons) - appartient à son auteur (droit d'auteur du droit français) -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment taguer une voie de détress e ?
La proposition me semble être la bonne, surtout que le terme anglais/international est escape lane, et c'est vachtément important pour les routiers... (ici on en a une, qui sert quasi toutes les semaines au point que les ouvriers chargés de la remettre en état ont demandé une prime de risque : Une semi s'était plantée dedans, le gros remorqueur était venu pour la sortir de là, une autre semi s'est pointée et a poussée le remorqueur dans le gravillon, puis un attelage, freins arrières et remorque en feu s'est pointé mais heureusement le gars au dernier moment a vu que c'était déjà occupé, s'est mis de l'autre côté à racler la bande centrale sur quelques centaines de mètres et donner un coup de volant pour coucher son train sur le côté, en travers et sauter, lui-même... Ils ont beau afficher voie de secours désactivée, quand un routier, freins défaillants, y en a besoin. Surtout que sur ce tronçon-là, les panneaux ne sont pas corrects : Ça dit 6,5 % là où en en réalité par endroits ça dépasse les 11 %, et ça dit sur 6 kilomètres, là où il y en a sur presque 10 kilomètres. mais pour l'instant je n'ai pas encore vu de tag en ce sens, faudrait la faire, cette proposition de tag... Gerhard --- Hii, pardon, fut un temps Le 23 mai 09 à 23:33, Vincent Pottier a écrit : Lionel Maraval a écrit : Bonsoir, Comment taguer une voie de détresse pour camions dans une forte pente ? Ce sont des voies terminées par un bac à gravier. Il y en a dans la descente du Pas de l'Escalette sur l'A 75 dans l'Hérault, celles qui m'intéressent ici se trouvent à Millau. Petrovsk Je suggère highway=service + service=escape_lane Je ne sais pas si la valeur existe pour ce tag. Mais c'est ce qui me semble le plus cohérent avec le reste d'OSM. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment taguer une voie de détress e ?
Hihi, pardon... :-( c'est précisément de celles-là que je parlais... d'en bas, du village, on entend un barouff de boîtes de conserves renversées, quand ça cartonne dans ces escape lanes déjà occupées... Le 23 mai 09 à 23:33, Vincent Pottier a écrit : Il y en a dans la descente du Pas de l'Escalette sur l'A 75 dans l'Hérault ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment taguer une voie de détress e ?
Maintenant, les GPS intègrent la fonction TMC qui recalcul l'itinéraire en fonction des embouteillages. Et bien j'imagine maintenant le GPS disant dans la descente : Ne tombez pas en panne de frein, la prochaine voie de détresse est déjà occupé, ou sinon, prenez la prochaine dans 1500m avec sa belle voix féminine toute calme ! :D :D --- En date de : Lun 25.5.09, g.d g...@wanadoo.fr a écrit : De: g.d g...@wanadoo.fr Objet: Re: [OSM-talk-fr] Comment taguer une voie de détresse ? À: vpott...@gmail.com, Discussions sur OSM en français talk-fr@openstreetmap.org Date: Lundi 25 Mai 2009, 18h16 Hihi, pardon... :-( c'est précisément de celles-là que je parlais... d'en bas, du village, on entend un barouff de boîtes de conserves renversées, quand ça cartonne dans ces escape lanes déjà occupées... Le 23 mai 09 à 23:33, Vincent Pottier a écrit : Il y en a dans la descente du Pas de l'Escalette sur l'A 75 dans l'Hérault ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Hugues Romain (RCS) a écrit : Bonjour à tous, J'ai pas mal contribué au tracé des rues, voies piétonnes, et transport en commun, et autres sur le secteur de Toulouse (login hromain), en partie grâce au cadastre et à ma connaissance des lieux, de manière très régulière pendant plusieurs mois. Au cours de cette période, plusieurs contributeurs minutieux et importants en nombre de contributions ont été amenés à débattre de certains choix de modélisation sur le secteur, notamment sur la question des choix de statut de voie (unclassified, tertiary, secondary d'une part, et footway / cycleway/ path d'autre part). A chaque fois, la prise de contact fort sympathique s'est faite par message privé, et chacun a exposé ses arguments sur les questions posées, puis un consensus se dégage, etc. Le principe même du collaboratif a très bien fonctionné : tous s'est bien passé ! Il y a environ un moins mon PC est tombé en panne, et j'ai mis un certain temps à reprendre une machine définitive : donc pas de mise à jour OSM depuis. Je reprends maintenant connaissance de la vie de la base autour de Toulouse et je suis assez surpris de voir que pas mal de statuts de voirie ont été changés directement par des nouveaux contributeurs sans entrer en discussion pour éventuellement redéfinir une nouvelle logique et surtout cela n'as pas vraiment été fait proprement (rue qui change de statut en plein milieu, ronds points non modifiés, etc.) Je suis d'autant plus surpris que : - il reste dans la région bon nombre de commune sans aucun nom de rue voire sans aucun tracé en dehors des routes principales, ce n'est donc pas le travail prioritaire qui manquait - la région toulousaine est l'une des plus aboutie suite à plusieurs contributions massives dont la mienne, et il était clair que des choix cohérents étaient faits au moins au niveau de ce territoire, et que la prise de contact s'imposait de soi - à propos de discussion justement, je n'ai pas reçu un seul message privé pour entrer en discussion avant les modifs - souvent l'upgrade d'une rue est fait uniquement sur la base théorique de la présence d'une classification N ou D sans tenir compte de l'usage réel (piège type de la N 224 qui ne doit pas être en primary car le statut national correspond à l'intégration à l'IGG airbus et n'a rien à voir avec le trafic ni la largeur de la route - la N 224 n'est d'ailleurs pas continue) Il est clair que cela est très décourageant car on a un peu la sensation d'avoir bossé pour rien, certains choix de catégories ayant parfois demandé des réflexions non triviales. Cela l'est d'autant plus qu'il y a de bons potentiels de contributions officielles de la part de partenaires institutionnels et qu'en tant que professionnel j'ai jusqu'à présent pris le parti de vanter la solution Openstreetmap avec aller retour de données entre le contributeur officiel et la base collaborative. Cependant se pose réellement la question de la pérennité de l'investissement en temps que des contributeurs pourraient fournir : si chacun peut modifier trop rapidement les éléments constituant la colonne vertébrale du fond de carte, il risque de ne jamais atteindre la stabilité requise pour des utilisations et donc des alimentations autres que ludiques. J'en viens donc à ma question (qui n'est certainement pas nouvelle) : serait il possible et souhaitable d'imaginer un fonctionnement collaboratif moins anarchique ? Par exemple, que certains territoires fassent l'objet d'une modération par un certain groupe d'utilisateurs élus, qui pourraient décider de verrouiller certains éléments. Sur ceux-ci, un contributeur lambda devrait alors motiver sa proposition de modification avant de récupérer le droit en écriture. Ce n'est qu'un début de piste de réflexion. Il faut voir aussi si la technique peut suivre... Qu'en pensez-vous ? Dans tous les cas, étant en train de faire adopter le fond OSM pour des applications officielles sur la région, je connais le résultat d'avance si rien ne change : la base sera pompée une fois quand elle aura atteint un niveau de qualité jugé suffisant, puis sera gérée comme un fork : plus rien ne remontera à OSM car les couts et contraintes de fusion permanente seront trop élevés. Je pense que ce serait dommage. Mais on peut comprendre qu'une entité économique qui mettrait à disposition des moyens pour effectuer des saisies n'acceptera pas de financer un poste à plein temps uniquement pour gérer les conflits à l'upload avec les modifs de contributeurs lambda non aguerris... Se pose donc plus largement la question de la volonté ou non que la base OSM fasse l'objet d'échange avec des bases officielles... (je parle bien d'échanges à double sens et dans la durée) Concrètement sur Toulouse se présentent deux opportunités : - l'import régulier dans OSM de tous les arrêts de bus et métro qui serait géré sur la base d'un champ spécifique permettant de les identifier (cela
[OSM-talk-fr] Carte Madère
Bonjour, Je cherche une carte de Madère pour mettre dans mon Garmin Legend Hcx (tout neuf 8-) ) J'ai trouvé (et installé avec succès) les Canaries, ... mais pas de Madère. Est ce que quelqu'un pourrais m'indiquer où trouver un fichier gmapsupp.img correspondant ? Où sinon le moyen de le fabriquer (avec Ubuntu) ? Merci. P.S. : je ne connais pas du tout le portugais ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Cohérence des voiries, m ises à jour / modération
et etant donne que tu mets l accent sur le cote collaboratif discussions tout ca.. est ce que tu as essaye de contacter les auteurs des modifications pour en parler avec eux ? meme si j en conviens la logique voudrait que se soient eux qui contactent avant de tout casser De : Hugues Romain (RCS) hrom...@reseaux-conseil.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi, 25 Mai 2009, 18h52mn 44s Objet : [OSM-talk-fr] Cohérence des voiries, mises à jour / modération Bonjour à tous, J'ai pas mal contribué au tracé des rues, voies piétonnes, et transport en commun, et autres sur le secteur de Toulouse (login hromain), en partie grâce au cadastre et à ma connaissance des lieux, de manière très régulière pendant plusieurs mois. Au cours de cette période, plusieurs contributeurs minutieux et importants en nombre de contributions ont été amenés à débattre de certains choix de modélisation sur le secteur, notamment sur la question des choix de statut de voie (unclassified, tertiary, secondary d'une part, et footway / cycleway/ path d'autre part). A chaque fois, la prise de contact fort sympathique s'est faite par message privé, et chacun a exposé ses arguments sur les questions posées, puis un consensus se dégage, etc. Le principe même du collaboratif a très bien fonctionné : tous s'est bien passé ! Il y a environ un moins mon PC est tombé en panne, et j'ai mis un certain temps à reprendre une machine définitive : donc pas de mise à jour OSM depuis. Je reprends maintenant connaissance de la vie de la base autour de Toulouse et je suis assez surpris de voir que pas mal de statuts de voirie ont été changés directement par des nouveaux contributeurs sans entrer en discussion pour éventuellement redéfinir une nouvelle logique et surtout cela n'as pas vraiment été fait proprement (rue qui change de statut en plein milieu, ronds points non modifiés, etc.) Je suis d'autant plus surpris que : - il reste dans la région bon nombre de commune sans aucun nom de rue voire sans aucun tracé en dehors des routes principales, ce n'est donc pas le travail prioritaire qui manquait - la région toulousaine est l'une des plus aboutie suite à plusieurs contributions massives dont la mienne, et il était clair que des choix cohérents étaient faits au moins au niveau de ce territoire, et que la prise de contact s'imposait de soi - à propos de discussion justement, je n'ai pas reçu un seul message privé pour entrer en discussion avant les modifs - souvent l'upgrade d'une rue est fait uniquement sur la base théorique de la présence d'une classification N ou D sans tenir compte de l'usage réel (piège type de la N 224 qui ne doit pas être en primary car le statut national correspond à l'intégration à l'IGG airbus et n'a rien à voir avec le trafic ni la largeur de la route - la N 224 n'est d'ailleurs pas continue) Il est clair que cela est très décourageant car on a un peu la sensation d'avoir bossé pour rien, certains choix de catégories ayant parfois demandé des réflexions non triviales. Cela l'est d'autant plus qu'il y a de bons potentiels de contributions officielles de la part de partenaires institutionnels et qu'en tant que professionnel j'ai jusqu'à présent pris le parti de vanter la solution Openstreetmap avec aller retour de données entre le contributeur officiel et la base collaborative. Cependant se pose réellement la question de la pérennité de l'investissement en temps que des contributeurs pourraient fournir : si chacun peut modifier trop rapidement les éléments constituant la colonne vertébrale du fond de carte, il risque de ne jamais atteindre la stabilité requise pour des utilisations et donc des alimentations autres que ludiques. J'en viens donc à ma question (qui n'est certainement pas nouvelle) : serait il possible et souhaitable d'imaginer un fonctionnement collaboratif moins anarchique ? Par exemple, que certains territoires fassent l'objet d'une modération par un certain groupe d'utilisateurs élus, qui pourraient décider de verrouiller certains éléments. Sur ceux-ci, un contributeur lambda devrait alors motiver sa proposition de modification avant de récupérer le droit en écriture. Ce n'est qu'un début de piste de réflexion. Il faut voir aussi si la technique peut suivre... Qu'en pensez-vous ? Dans tous les cas, étant en train de faire adopter le fond OSM pour des applications officielles sur la région, je connais le résultat d'avance si rien ne change : la base sera pompée une fois quand elle aura atteint un niveau de qualité jugé suffisant, puis sera gérée comme un fork : plus rien ne remontera à OSM car les couts et contraintes de fusion permanente seront trop élevés. Je pense que ce serait dommage. Mais on peut comprendre qu'une entité économique qui mettrait à disposition des moyens pour effectuer des saisies n'acceptera pas de financer un poste à plein temps uniquement pour gérer les conflits à l'upload avec les modifs de
[OSM-talk-fr] Re : Carte Madère
Je sais pas si il existe une carte Garmin de l'île Madère. C'est cette île que tu veux ? http://openstreetmap.org/?lat=32.76lon=-16.973zoom=11layers=B000FFT Je te conseille ce blog : http://blog.lionelmaraval.fr/post/2009/03/05/Creer-une-carte-OSM-pour-un-GPS-Garmin Il t'indique comment créer une carte pour GPS Garmin. Pour télécharger les donnéess OSM, utilise JOSM, télécharge la zone que tu veux, puis fais Enregistrer sous. C'est la méthode que je conseille. Ensuite, tu applique mkgmap. Normallement, le fichier par défaut pour le rendu n'est pas mauvais. Il suffit, sauf si tu veux y faire figurer des informations précises.( par exemple, les batiments sont très mal rendu avec le fichier par défaut, dommage, car pour la France, ca commence à devenir intéressant). En bas du tutoriel, tu as même l'explication pour fusionner 2 cartes, donc comme ça, tu pourra fusionner avec la carte que tu as déjà des Canaries ;-) Au fait, le tuto est fait pour un mac, mais exactement la même chose pour ubuntu. --- En date de : Lun 25.5.09, Michel POLLE michel.po...@orange.fr a écrit : De: Michel POLLE michel.po...@orange.fr Objet: [OSM-talk-fr] Carte Madère À: talk-fr@openstreetmap.org Date: Lundi 25 Mai 2009, 19h43 Bonjour, Je cherche une carte de Madère pour mettre dans mon Garmin Legend Hcx (tout neuf 8-) ) J'ai trouvé (et installé avec succès) les Canaries, ... mais pas de Madère. Est ce que quelqu'un pourrais m'indiquer où trouver un fichier gmapsupp.img correspondant ? Où sinon le moyen de le fabriquer (avec Ubuntu) ? Merci. P.S. : je ne connais pas du tout le portugais ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Des données libres pour la montagn e pour bientôt
J'ai un vieil atlas de 1692... Le 25 mai 09 à 14:48, Stéphane Brunner a écrit : Hello ! Sur les histoire de copyright je pense que tu a tore car sauf erreur de ma part le copyright est implicite :( Par contre es-ce qu'il n'existe tout simplement une vielle carte avec les altitude qui ne sois plus couverte par le copyright ? Il me semble que de tel source doive exister ? CU Stéphane 2009/5/25 g.d g...@wanadoo.fr: J'ai mis des sommets dans osm, sur lesquels je n'étais pas allé moi-même avec le gps : J'ai fait les positionnements x/y par visée croisée depuis deux points gps (mon vieux Magellan de mathusalem permet ça), et y avais reporté les z's (altis) affichés sur les pancartes et textes affichées aux syndicats d'initiative et offices de tourisme, sur la voie publique, à l'extérieur, pas de copyright affiché. J'avais pris ces papiers et pancartes en photo, pour ma bonne foi. Maintenant, si eux mêmes ont escamoté un © dans le cadre du truc, ou ont oublié d'en mettre, j'estime qu'en cas de litige ce n'est pas moi qui serait en cause (pour la transmission d'une donné d'altitude), mais eux. D'autre part, des données d'altitude de sommets français aussi figurent dans le Webster's, et dans des dépliants de gîtes, sans mentions de ©. Aussi, pour le moins en ce qui concerne les sommets majeurs d'un patelin, je pense qu'il ne peut pas y avoir de © sur l'alti (sauf si on irait chercher dans les décimètres) car ces altis métriques sont enseignées publiquement déjà aux élèves de primaire, du coin... (et pour les sommets d'importance nationale, sont enseignés au niveau national...). Peut-être j'ai eu tort ? Par les temps qui courent, où même des des plantes sauvages peuvent être brevetés, on doit s'attendre à tout, même à un copyright sur des montagnes... Dites. Gerhard --- Le 23 mai 09 à 17:11, sylvain letuffe a écrit : Mais les autres sommets dans OSM, ce sont surement les altitudes de l'IGN.(par exemple pour reprendre le Crêt de la neige : 1720 mètres dans OSM et sur l'IGN). C'est hélas ce que je crains aussi, ce qui fait de la base OSM des sommets une donnée un poil litigieuse ___ 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://www.ubuntu-fr.org - Distribution Linux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Des données libres pour la montagn e pour bientôt
Précision, c'est à dire : en mètre, décamètre... Si on a ± 5m en xy et ±5m en altitude... C'est cohérent... Vincent Ce n'est malheureusement pas le cas apparement comme cela a été évoqué dans le fil quelques topics plus haut. Les GPS sont optimisés pour déterminer leur position en x et y, mais pas vraiment dans l'espace (z) (altitude). C'était pas le but premier du GPS. Il faudrai faire des mesures pour voir. Donc, si les données sans mentions sont implicitement sous copyright, on a donc aucune donnée à mettre dans OSM qui soit vraiment fiables ? Il y a pas des personnes connaissant bien c2c pouvant nous dire d'ou viennent les informations de la base de CampToCamp ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Présentation et question su r les traits sur la carte de france
THEVENON Julien a écrit : surtout qu il n apparait qu a un niveau de zoom precis. Au dessus et en dessous en terme de niveau de zoom on ne les voit pas J'ai les ovni au zoom 8 http://www.openstreetmap.org/?lat=48.09lon=3.04zoom=8layers=B000FTF Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Carte Madère
Etienne T a écrit : Je sais pas si il existe une carte Garmin de l'île Madère. C'est cette île que tu veux ? http://openstreetmap.org/?lat=32.76lon=-16.973zoom=11layers=B000FFT Je te conseille ce blog : http://blog.lionelmaraval.fr/post/2009/03/05/Creer-une-carte-OSM-pour-un-GPS-Garmin Il t'indique comment créer une carte pour GPS Garmin. Pour télécharger les donnéess OSM, utilise JOSM, télécharge la zone que tu veux, puis fais Enregistrer sous. C'est la méthode que je conseille. Ensuite, tu applique mkgmap. Normallement, le fichier par défaut pour le rendu n'est pas mauvais. Il suffit, sauf si tu veux y faire figurer des informations précises.( par exemple, les batiments sont très mal rendu avec le fichier par défaut, dommage, car pour la France, ca commence à devenir intéressant). En bas du tutoriel, tu as même l'explication pour fusionner 2 cartes, donc comme ça, tu pourra fusionner avec la carte que tu as déjà des Canaries ;-) Au fait, le tuto est fait pour un mac, mais exactement la même chose pour ubuntu. Merci pour l'info. Si ça marche aussi pour Besançon ;-) Je le fais tourner sur mon mac. La carte de Frédéric n'est plus très à jour dans mon coin. (la faute à Frédéric ou à moi...) Vincent ___ 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
g.d a écrit : J'ai un vieil atlas de 1692... On devrait être tranquille avec les ayant-droits ;-) Mais la précision vaut elle le GPS ? Et l'érosion ? Vincent ___ 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
Wow, chapeau, ton Papa ! On en rêvait, de ça... Et à défaut de science, pour pas trop se planter, nous, (eh on fait confiance aux scientifiques, mais rien ne vaut ses propres précautions...) on pendouillait des cordelettes de longueurs différentes avec des plombs à pèche sous les Sykorsky, en traîne, en décalé, dans la brume, fabriqués main avec du fil de bobinage isolé soie (récupéré dans des vieux postes de radio) pour savoir quand réellement on approchait le sol. J'avais onze ans quand j'ai tricoté ça pour la première fois. Le 25 mai 09 à 16:49, Vincent Pottier a écrit : C'est pour ça que mon père avait bossé sur les premiers radio- altimètres avec les vieux hélicos bananes et des cordes à nœuds. La première fois qu'une caravelle s'est posé aux instruments, rideaux sur le cockpit, elle s'est posée 50 cm au dessus de la piste... On avait récupéré un barographe de la Météo Nationale pour ballon stratosphérique. Ça nous faisait rêver... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Carte Madère
J'ai pas fait grand chose. C'est Lionel qu'il faut remercier pour ce tuto ;-) (l'auteur du blog, et du prochain tag pour l'escape lane). A quand le tuto pour modifier le fichier de rendu ? J'ai plutôt de difficultés à comprendre pour ça. Vincent, tu va plutôt faire le Doubs, comme ça j'en profite aussi ;-) Sinon, je viens seulement d'y penser : mais il y aussi Lambertus : http://garmin.na1400.info/routable.php Je pense que les données proviennent directement de la base OSM vu que le fichier gmapsupp.img est généré à la demande, non ? --- En date de : Lun 25.5.09, Vincent Pottier vpott...@gmail.com a écrit : De: Vincent Pottier vpott...@gmail.com Objet: Re: [OSM-talk-fr] Re : Carte Madère À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Lundi 25 Mai 2009, 20h44 Etienne T a écrit : Je sais pas si il existe une carte Garmin de l'île Madère. C'est cette île que tu veux ? http://openstreetmap.org/?lat=32.76lon=-16.973zoom=11layers=B000FFT Je te conseille ce blog : http://blog.lionelmaraval.fr/post/2009/03/05/Creer-une-carte-OSM-pour-un-GPS-Garmin Il t'indique comment créer une carte pour GPS Garmin. Pour télécharger les donnéess OSM, utilise JOSM, télécharge la zone que tu veux, puis fais Enregistrer sous. C'est la méthode que je conseille. Ensuite, tu applique mkgmap. Normallement, le fichier par défaut pour le rendu n'est pas mauvais. Il suffit, sauf si tu veux y faire figurer des informations précises.( par exemple, les batiments sont très mal rendu avec le fichier par défaut, dommage, car pour la France, ca commence à devenir intéressant). En bas du tutoriel, tu as même l'explication pour fusionner 2 cartes, donc comme ça, tu pourra fusionner avec la carte que tu as déjà des Canaries ;-) Au fait, le tuto est fait pour un mac, mais exactement la même chose pour ubuntu. Merci pour l'info. Si ça marche aussi pour Besançon ;-) Je le fais tourner sur mon mac. La carte de Frédéric n'est plus très à jour dans mon coin. (la faute à Frédéric ou à moi...) Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Cohérence des voiries, mi ses à jour / modération
Le 25 mai 2009 19:48, THEVENON Julien julien_theve...@yahoo.fr a écrit : et etant donne que tu mets l accent sur le cote collaboratif discussions tout ca.. est ce que tu as essaye de contacter les auteurs des modifications pour en parler avec eux ? meme si j en conviens la logique voudrait que se soient eux qui contactent avant de tout casser Tiens, ça c'est une piste : comment modifier les outils pour encourager ce genre de comportement ? Actuellement, ce n'est pas forcément naturel : - pour les débutants, savoir identifier qui est le dernier contributeur significatif sur un way qu'on veut modifier n'est pas facile. - pour les gens plus expérimentés, ils ont déjà fait tant d'édition de corrections d'erreurs diverses que, la fois où l'existant est en fait murement réfléchi (même si ça paraît bizarre au premier abord) qu''ils n'ont plus le réflexe d'étudier l'historique. Donc, est-ce que les éditeurs ne devraient pas rendre l'historique (et les commentaires de changeset) plus immédiatement visible ? Art. ___ 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
:p Ca doit être pas mal de pouvoir voir la différence ! Avec ça, tu dois pouvoir aider à cartographier les voies romaines. --- En date de : Lun 25.5.09, g.d g...@wanadoo.fr a écrit : De: g.d g...@wanadoo.fr Objet: Re: [OSM-talk-fr] Des données libres pour la montagne pour bientôt À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Lundi 25 Mai 2009, 20h35 J'ai un vieil atlas de 1692... Le 25 mai 09 à 14:48, Stéphane Brunner a écrit : Hello ! Sur les histoire de copyright je pense que tu a tore car sauf erreur de ma part le copyright est implicite :( Par contre es-ce qu'il n'existe tout simplement une vielle carte avec les altitude qui ne sois plus couverte par le copyright ? Il me semble que de tel source doive exister ? CU Stéphane 2009/5/25 g.d g...@wanadoo.fr: J'ai mis des sommets dans osm, sur lesquels je n'étais pas allé moi-même avec le gps : J'ai fait les positionnements x/y par visée croisée depuis deux points gps (mon vieux Magellan de mathusalem permet ça), et y avais reporté les z's (altis) affichés sur les pancartes et textes affichées aux syndicats d'initiative et offices de tourisme, sur la voie publique, à l'extérieur, pas de copyright affiché. J'avais pris ces papiers et pancartes en photo, pour ma bonne foi. Maintenant, si eux mêmes ont escamoté un © dans le cadre du truc, ou ont oublié d'en mettre, j'estime qu'en cas de litige ce n'est pas moi qui serait en cause (pour la transmission d'une donné d'altitude), mais eux. D'autre part, des données d'altitude de sommets français aussi figurent dans le Webster's, et dans des dépliants de gîtes, sans mentions de ©. Aussi, pour le moins en ce qui concerne les sommets majeurs d'un patelin, je pense qu'il ne peut pas y avoir de © sur l'alti (sauf si on irait chercher dans les décimètres) car ces altis métriques sont enseignées publiquement déjà aux élèves de primaire, du coin... (et pour les sommets d'importance nationale, sont enseignés au niveau national...). Peut-être j'ai eu tort ? Par les temps qui courent, où même des des plantes sauvages peuvent être brevetés, on doit s'attendre à tout, même à un copyright sur des montagnes... Dites. Gerhard --- Le 23 mai 09 à 17:11, sylvain letuffe a écrit : Mais les autres sommets dans OSM, ce sont surement les altitudes de l'IGN.(par exemple pour reprendre le Crêt de la neige : 1720 mètres dans OSM et sur l'IGN). C'est hélas ce que je crains aussi, ce qui fait de la base OSM des sommets une donnée un poil litigieuse ___ 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://www.ubuntu-fr.org - Distribution Linux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Le 25 mai 2009 19:40, Vincent Pottier vpott...@gmail.com a écrit : Je viens de créer la page 'Toulouse' : http://wiki.openstreetmap.org/wiki/Toulouse Vous pouvez l'éditer, la modifier... OK, faisons vivre cette page. J'avais bien vu, il y a quelques mois, qu'un travail général de classification des routes était en cours sur Toulouse : passage primary-secondary de tout ce qui état intérieur au périph, etc. Mais je ne savais pas qui faisait ça, sur quelle base, quelle était la cohérence avec les autres ville françaises. Pour documenter ça, un wiki est mieux qu'une somme de messages perso. D'autant plus que s'il y a une logique claire derrière tout ça, ça peut faire jurisprudence et servir de guide pour d'autres villes. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Hugues Romain (RCS) a écrit : ... Cependant se pose réellement la question de la pérennité de l'investissement en temps que des contributeurs pourraient fournir : si chacun peut modifier trop rapidement les éléments constituant la colonne vertébrale du fond de carte, il risque de ne jamais atteindre la stabilité requise pour des utilisations et donc des alimentations autres que ludiques. J'en viens donc à ma question (qui n'est certainement pas nouvelle) : serait il possible et souhaitable d'imaginer un fonctionnement collaboratif moins anarchique ? Par exemple, que certains territoires fassent l'objet d'une modération par un certain groupe d'utilisateurs élus, qui pourraient décider de verrouiller certains éléments. Sur ceux-ci, un contributeur lambda devrait alors motiver sa proposition de modification avant de récupérer le droit en écriture. Ce n'est qu'un début de piste de réflexion. Il faut voir aussi si la technique peut suivre... ... Voilà plus de questions que de réponses ! :) Bonsoir, Merci pour ce post très intéressant. Moi aussi, j'ai plus de questions que de réponses !!! On ne pourrait JAMAIS complètement se défaire du côté anarchique d'OSM (que, personnellement, je préfère qualifier de bordélique tant ce n'est pas une visée politique). C'est un wiki, mais d'un genre nouveau. Peut-être qu'une page de discussion par changeset serait techniquement faisable (souhaitable ?). Bref on n'a pas (encore) tous les outils d'un wikimedia|pedia. On progresse vite, je trouve. Le(s) mouvement(s) (esprit) collaboratif(s) avance(nt) encore plus vite. Il y a une vitesse de croisière à trouver. OSM est très boulimique en ce moment : avaler le maximum de données par le maximum de contributeurs. Nous sommes frustrés, encore, de constater des zones blanches (ou grises ou noires selon la couleur du fond ;-). Les questions que tu posent, m'interpelle en tant que gestionnaire des données géographiques d'une collectivité (que mes propos ici ne souhait engager, bien sûr). OSM sera-t-elle LA base de données référentielle citoyenne ? Si nous mûrissons, probablement. Hâtons-nous de réfléchir un peu plus à ce que nous faisons : pas seulement en tant que contributeur individuel, mais aussi et surtout en tant qu'entité collective qui est observée à la loupe par beaucoup d'acteurs déjà en place depuis longtemps. Bien loin de moi, l'idée de donner des leçons ou des directions. Juste des impressions. Rien qui ne me fasse réfléchir au-delà des halos. A. Bashung cordialement Denis ___ 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
Etienne T a écrit : Précision, c'est à dire : en mètre, décamètre... Si on a ± 5m en xy et ±5m en altitude... C'est cohérent... Vincent Ce n'est malheureusement pas le cas apparement comme cela a été évoqué dans le fil quelques topics plus haut. Les GPS sont optimisés pour déterminer leur position en x et y, mais pas vraiment dans l'espace (z) (altitude). C'était pas le but premier du GPS. Il faudrai faire des mesures pour voir. Donc, si les données sans mentions sont implicitement sous copyright, on a donc aucune donnée à mettre dans OSM qui soit vraiment fiables ? Il y a le 'manuel du parfait osmeur' datant de 1692... Je vais faire un petit test de différents relevés d'altitude au même point pour tester la variation. Comme on a un repère géodésique au dessus de la tête, je vais m'amuser : http://geodesie.ign.fr/fiche_geodesie.asp?num_site=25410AX=930500Y=6684200 http://geodesie.ign.fr/fiche_point.asp?num_site=25410Ano_ptg=01 Il va falloir que je calcule l'altitude au sol. Au fait, je lis sur la fiche ; Reproduction autorisée avec mention ©IGN 2009 dans le cadre de la cartographie réglementaire. OSM, c'est de la cartographie réglementaire ? Autre réflexion : Quand on importera les fiches géodésiques, il faudra prévoir comment indiquer l'altitude du repère, l'altitude au sol... Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Merci d'avoir soulevé le lièvre, et tu es loin d'être le seul : : Actuellement osm, qui toujours a été rechigné par les Grands, et par les institutions (et pourtant nous, on travaille pour la Liberté...) a des occasions innouïes, de se faire remarquer par son côté collaboratif, mais surtout commence à se faire connaître par sa précision de données jamais vue aupararvant. Plusieurs gouvernements récemment ont tout simplement versé leurs données géo dans osm : Bref, ils prennent avantage de l'offre que fait osm, de tout droit qu'on leur donne, gps ou pas, et MERCI ! Là-dessus, ils s'ajoutent des gens, des individus, comme toi et moi, pauvre ou riche, mendiant ou plouc', voire faux bourgeois (quoique...) chacun de sa façon, chacun avec ses moyens. Restons zen... et ouverts. Nous, osm et osmeurs, sommes tout jeunes, il est appréciable qu'on soit enfin pris au sérieux, comme le démontrent les expériences avec divers fournisseurs d'images, avec la DGI/Cadastre, et avec divers comms, c'est sacrément encourageant. Ensuite, il faudra intégrer/corriger ces imports en masse, chacun de nous dans son coin (Eh, j'ai plus d'un kilomètre de différences entre les limites de commune et limites de région, 'faut pas pousser !)-) Et ai des conneries pô possibles avec la Demoiselle, Corine, ça ne colle pas du tout sur place, mais alors pô du tout... Ma femme mienne, qui pourtant était partie prenante au début, et qui a gpxée plusieurs sentiers de haute montagne dans les Alpes et dans les Pyrénées, commence à rechigner. On se pose la question si on est là pour dresser une carte co-o, (ok), ou si on fait du boulot que d'autres vendent (pas ok). Le 25 mai 09 à 18:52, Hugues Romain ((RCS)) a écrit : Bonjour à tous, J'ai pas mal contribué au tracé des rues, voies piétonnes, et transport en commun, et autres sur le secteur de Toulouse (login hromain), en partie grâce au cadastre et à ma connaissance des lieux, de manière très régulière pendant plusieurs mois. Au cours de cette période, plusieurs contributeurs minutieux et importants en nombre de contributions ont été amenés à débattre de certains choix de modélisation sur le secteur, notamment sur la question des choix de statut de voie (unclassified, tertiary, secondary d'une part, et footway / cycleway/ path d'autre part). A chaque fois, la prise de contact fort sympathique s'est faite par message privé, et chacun a exposé ses arguments sur les questions posées, puis un consensus se dégage, etc. Le principe même du collaboratif a très bien fonctionné : tous s'est bien passé ! Il y a environ un moins mon PC est tombé en panne, et j'ai mis un certain temps à reprendre une machine définitive : donc pas de mise à jour OSM depuis. Je reprends maintenant connaissance de la vie de la base autour de Toulouse et je suis assez surpris de voir que pas mal de statuts de voirie ont été changés directement par des nouveaux contributeurs sans entrer en discussion pour éventuellement redéfinir une nouvelle logique et surtout cela n'as pas vraiment été fait proprement (rue qui change de statut en plein milieu, ronds points non modifiés, etc.) Je suis d'autant plus surpris que : - il reste dans la région bon nombre de commune sans aucun nom de rue voire sans aucun tracé en dehors des routes principales, ce n'est donc pas le travail prioritaire qui manquait - la région toulousaine est l'une des plus aboutie suite à plusieurs contributions massives dont la mienne, et il était clair que des choix cohérents étaient faits au moins au niveau de ce territoire, et que la prise de contact s'imposait de soi - à propos de discussion justement, je n'ai pas reçu un seul message privé pour entrer en discussion avant les modifs - souvent l'upgrade d'une rue est fait uniquement sur la base théorique de la présence d'une classification N ou D sans tenir compte de l'usage réel (piège type de la N 224 qui ne doit pas être en primary car le statut national correspond à l'intégration à l'IGG airbus et n'a rien à voir avec le trafic ni la largeur de la route - la N 224 n'est d'ailleurs pas continue) Il est clair que cela est très décourageant car on a un peu la sensation d'avoir bossé pour rien, certains choix de catégories ayant parfois demandé des réflexions non triviales. Cela l'est d'autant plus qu'il y a de bons potentiels de contributions officielles de la part de partenaires institutionnels et qu'en tant que professionnel j'ai jusqu'à présent pris le parti de vanter la solution Openstreetmap avec aller retour de données entre le contributeur officiel et la base collaborative. Cependant se pose réellement la question de la pérennité de l'investissement en temps que des contributeurs pourraient fournir : si chacun peut modifier trop rapidement les éléments constituant la colonne vertébrale du fond de carte, il risque de ne jamais
Re: [OSM-talk-fr] Des données libres pour la montagn e pour bientôt
Etienne Chové a écrit : Stéphane Brunner a écrit : Hello ! Sur les histoire de copyright je pense que tu a tore car sauf erreur de ma part le copyright est implicite :( Sans mention une information : - n'a pas le droit d'être copiée (copyright des droits anglo-saxons) - appartient à son auteur (droit d'auteur du droit français) Une relecture du Code de la Propriété Intellectuelle s'impose. - notamment sur les conditions d'originalité pour le droit à la protection - notamment sur le caractère substantiel de la violation de copyright - notamment sur le droit à la citation - etc. 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) pas plus que de dire que M. Sarkozy est l'actuel président de la République française alors que c'est le Conseil Constitutionnel qui a l'exclusivité de la publication des résultats d'élections. Arrêtons cette paranose Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Utiliser une relation de type route pour décrire un way
Bonsoir J'ai une discution avec un osmeur concernant mon utilisation d'une relation de type route pour décrire un way. La relation en question est la suivante : http://openstreetmap.org/browse/relation/146142 Est-ce autorisé à faire cela ? Maintenant, les ways contenu dans la relation ne contiennent plus que la source DGI-... comme tag. Pour faire la relation, je m'étais basé sur ce topic : http://forum.letuffe.org/viewtopic.php?f=3t=10 qui parle au début d'utiliser une relation de type route. Malheureusement, je n'avais pas lu jusqu'à la fin. Mais le topic est resté sur une interrogation je trouve. Il ne faut pas confondre le mot route en anglais qui veut dire trajet avec le mot route en français. Mais le rendu affiche parfaitement la relation, donc est-ce que cela pose problème ? Note : j'ai fais cette relation pour faciliter le changement des tags quand la LGV sera fini. Car en ce moment, depuis qu'elle a été tracé, les OSMeus sont en train de la découper pour y intégrer les tunnels et les bridges. Je veux bien revenir en arrière. C'était juste par soucis pratique pour la fin, quand la ligne sera fini. Merci de m'éclairer. ___ 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 monta gne pour bientôt
g.d a écrit : Wow, chapeau, ton Papa ! On en rêvait, de ça... Et à défaut de science, pour pas trop se planter, nous, (eh on fait confiance aux scientifiques, mais rien ne vaut ses propres précautions...) on pendouillait des cordelettes de longueurs différentes avec des plombs à pèche sous les Sykorsky, en traîne, en décalé, dans la brume, fabriqués main avec du fil de bobinage isolé soie (récupéré dans des vieux postes de radio) pour savoir quand réellement on approchait le sol. J'avais onze ans quand j'ai tricoté ça pour la première fois. On a plein d'histoires de ce type dans la famille. On ne sais pas ce qui est de la légende et ce qui est réel, du genre du général venu voir l'avancée des recherches et que les pilotes avait mis au sol à tenir le bout de la corde 'pour être sûr que ça reste bien droit', et ils ont laisser dériver l'hélico, et le général s'est retrouvé dans les betteraves, tout crotté... Dans la brume, il y a eu un retour d'expérience (bien arrosé, je crois), en Auvergne (il fallait du relief). Les pilotes ont posé l'hélico dans un champs, ils ne savaient plus ou ils étaient. Ils ont demandé à un paysan avec son cheval. Au moment de repartir, ils préviennent que le pétard va faire du bruit. 'Mon cheval, il a l'habitude des tracteurs !'. Mais pas des hélicos. Boum ! Le gars, il doit toujours être en train de courir après son cheval... L'époque épique des postes à galène... Les expériences en radio, j'ai participé un peu, plus tard au temps des hyperfréquences... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Le 25 mai 2009 21:27, Denis dhel...@free.fr a écrit : Les questions que tu posent, m'interpelle en tant que gestionnaire des données géographiques d'une collectivité (que mes propos ici ne souhait engager, bien sûr). OSM sera-t-elle LA base de données référentielle citoyenne ? Si nous mûrissons, probablement. Hâtons-nous de réfléchir un peu plus à ce que nous faisons : pas seulement en tant que contributeur individuel, mais aussi et surtout en tant qu'entité collective qui est observée à la loupe par beaucoup d'acteurs déjà en place depuis longtemps. Bien loin de moi, l'idée de donner des leçons ou des directions. Juste des impressions. Et beaucoup de choses qui résonnent dans mes propres interrogations. Allons au bout de la question : La base OSM peut-elle servir à quelquechose d'autre que de la remplir ? OSM, c'est parfait pour apprendre le(s) droit(s) d'auteur, PostgresSQL, python, les imports, les validateurs, les robots, les wiki, les projections, IRC, ... Mais, pour utiliser ? Mais sérieusement, vous partiriez en montagne (une montagne que vous ne connaissez pas) avec une carte 100% OSM ? Un carte où un quartier de Vienne peut se retrouver au milieu du golfe de Gascogne ? où on ne sait pas qui a saisi l'altitude du sommet ? Où un problème de [potlatch|josm|merkartor|xxx] peut laisser la carte dans un état douteux ? Actuellement, les moteurs de routages servent à vérifier qu'ils savent retrouver, dans OSM, le chemin qu'on connait dans la réalité, plus qu'à guider le voyageur qui ne connait pas le terrain. Alors, que manque-t-il pour que je soit convaincu ? Pour que nous soyons nombreux à être convaincus ? Une expérience de la robustesse ? une série de mécanismes de contrôle ? Des échanges bi-directionnels avec d'autres sources de données ? Je ne veux pas avoir l'air de minimiser le travail déjà accompli, mais, à mon avis, OSM ne fait que démarrer, et y'a encore plein de choses à inventer. Art. ___ 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
Bonjour, Un membre de OSM a signal cette discussion au conseil d'administration de camptocamp, dont je fais partie. Pour reprendre l'exemple de mon Crt de la neige qui est mal plac 371m dans la base c2c, comment est-il arriv la ? Bonne question, car sur c2c ce sommet n'a jamais t 371m, et a toujours t plac au bon endroit depuis qu'il est gorfrenc. Vous pouvez consulter la carte disponible sur la page du sommet, et l'historique du sommet pour vrifier : http://www.camptocamp.org/summits/41969/fr/cret-de-la-neige Peut tre qu'il existait un doublon comportant ces erreurs et qui a t supprim depuis. Malgr tout, il peut y avoir de grosses erreurs sur certains sommets, car le gorfrencement est utilis pour dterminer le massif et rgions dans lesquels un sommet se situe. Donc pour que les documents associs un sommet soient aussi gorfrencs, et puissent tre filtrs selon ses prfrences, il est prfrable de gorfrencer approximativement un sommet (mme qq km prs) que de ne pas le gorfrencer du tout. Mais bon normalement c'est rapidement corrig, et je vous invite trouver de telles erreurs sur c2c et nous les signaler, a nous permettra de les corriger :-)) OSM a depuis le dbut t trs vigilant sur l'origine des donnes. De nombreuses sources ont t rejetes parce qu'il y avait des problmes de droit d'auteur. Et c'est justement parce qu'il y avait tous ces problmes de droits qu'OSM a t cr... A ce titre, ce projet est sans-doute le plus parano de tous les projets collaboratifs et a serait bien que a reste comme a. Sur c2c, il n'y a aucune garantie d'origine des donnes : un contributeur peut saisir les coordonnes 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 enregistre). De toute faon, les coordonnes trop prcises sont arrondies (dgr 6 dcimales il me semble). Par ailleurs, je ne vois pas comment sur OSM vous garantissez plus l'origine des donnes ??? Si je saisis une trace d'un chemin sur Cartoexplorer par exemple, en vrifiant sur une photo arienne 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 dtecter la supercherie ? Les coordonnes des sommets suisses ont t releves pour la plupart sur les cartes Swisstopo. Nous avons l'accord de Swisstopo pour diffuser ces coordonnes sous licence libre : Vous pouvez utiliser et publier sans outre les coordonnes de points des Cartes nationales. Ces donnes sont libres de droits et aucune autorisation n'est ncessaire. Pour les sommets franais, une partie a pu tre releve sur le goportail : c'est en effet le moyen le plus simple et accessible en ligne pour des relevs de prcision, avec vrification sur photo arienne. Pour les autres sommets, a peut tre sur google map. Il y a aussi des relevs GPS. Mais impossible de garantir l'origine encore une fois ! (je me demande vraiment comment vous faites). Donc concernant l'import des donnes de c2c, je ne peux pas vous aider, vous faites comme vous voulez. En tout cas, nous remercions OSM pour ses cartes que nous mettons disposition pour la saisie des coordonnes. Par ailleurs, qqun demandait s'il y avait des cols sur c2c : oui, sur c2c un "sommet" peut tre un point culminant (sommet, parfois antcime), un col (ou brche), mais aussi un lac, ou un point remarquable dans un vallon ou une falaise (ce dernier cas est surtout utilis pour les secteurs de cascade de glace et de grandes voies). Concernant les altitudes, on peut dj 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 prfre 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 ?). En effet, dans la culture montagnarde, l'altitude d'un sommet, col, refuge est importante et fait quasiment partie du nom du sommet : on mmorise souvent en mme temps le nom et l'altitude d'un sommet. Lorsque depuis un sommet on fait le tour du panorama, on essaie souvent de trouver le nom des sommets et leur altitude, et on corrige en regardant une carte ou en demandant qqun. Si cet apprentissage de base (car j'estime que c'est la base, comme l'orthographe pour une langue) peut tre fait sur c2c, c'est trs bien. Mais si on inculque des altitudes fausses ceux qui apprennent les sommets sur c2c, a ne va pas le faire. Ca reviendrait ce que moi (nous), qui ai profit de sources fiables d'infos pour acqurir rapidement cette culture de base, je mette en place une source d'infos qui se voudrait quivalente, mais qui en faite serait toute errone, afin que ceux qui viennent aprs moi se trompent ds le dpart, et se prennent des buts en montagne, permettant qu'il y ait moins de monde en montagne en fin de compte : c'est une ide, mais je ne cautionne pas cette hypocrisie. Vous
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Art Penteur a écrit : Allons au bout de la question : La base OSM peut-elle servir à quelquechose d'autre que de la remplir ? A préparer le terrain de mes prochaines campagnes photos, vacances, contacts avec les autochtones (surtout s'ils produisent du vin) voir : http://www.openstreetmap.org/browse/changeset/1119158 Alors, que manque-t-il pour que je soit convaincu ? Pour que nous soyons nombreux à être convaincus ? Une expérience de la robustesse ? une série de mécanismes de contrôle ? Des échanges bi-directionnels avec d'autres sources de données ? Juste du temps, in fine ? Je ne veux pas avoir l'air de minimiser le travail déjà accompli, mais, à mon avis, OSM ne fait que démarrer, et y'a encore plein de choses à inventer. C'est pour cela qu'on n'a pas abandonné au premier revert. OSM est un adolescent boutoneux. C'est pas très gracieux, c'est capricieux et susceptible, mais c'est tellement tout le monde est passé par là. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Cohérence des voiries, mi ses à jour / modération
Art Penteur a écrit : Le 25 mai 2009 19:48, THEVENON Julien julien_theve...@yahoo.fr a écrit : et etant donne que tu mets l accent sur le cote collaboratif discussions tout ca.. est ce que tu as essaye de contacter les auteurs des modifications pour en parler avec eux ? meme si j en conviens la logique voudrait que se soient eux qui contactent avant de tout casser Tiens, ça c'est une piste : comment modifier les outils pour encourager ce genre de comportement ? Actuellement, ce n'est pas forcément naturel : - pour les débutants, savoir identifier qui est le dernier contributeur significatif sur un way qu'on veut modifier n'est pas facile. Un statut type 'admin', définit pour une zone devrait pouvoir créer un tag 'alert' sur des objets sensibles. Le contributeur en herbe (en fait tous les contributeurs) qui fait des modifs avec ses gros sabots en croyant faire bien serait alerté qu'un bon niveau de précision, de cohérence est atteint pour l'objet donné et qu'il a intérêt à savoir ce qu'il fait, ou qu'il est invité à visiter telle page du wiki avant d'appliquer les modifs. Après il faut que les éditeurs sachent intégrer ça. Wikimedia a des statuts et des protections de pages 'semi-protégées, protégées' pour éviter le vandalisme ou la maladresse des newbies. - pour les gens plus expérimentés, ils ont déjà fait tant d'édition de corrections d'erreurs diverses que, la fois où l'existant est en fait murement réfléchi (même si ça paraît bizarre au premier abord) qu''ils n'ont plus le réflexe d'étudier l'historique. Il y a le très pratique : http://www.itoworld.com/static/osmmapper qui affiche les noms des contributeurs Il y a le flux rss, que je n'utilise pas. Donc, est-ce que les éditeurs ne devraient pas rendre l'historique (et les commentaires de changeset) plus immédiatement visible ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Denis a écrit : Art Penteur a écrit : Allons au bout de la question : La base OSM peut-elle servir à quelquechose d'autre que de la remplir ? A préparer le terrain de mes prochaines campagnes photos, vacances, contacts avec les autochtones (surtout s'ils produisent du vin) voir : http://www.openstreetmap.org/browse/changeset/1119158 À développer la culture du Libre et du Bien commun : les ados se passionnent pour le GPS et la carto libre. À voir la ville où je suis autrement. Je ne passe plus deux fois par la même route, ou je découvre des nouvelles choses. À rêver... Alors, que manque-t-il pour que je soit convaincu ? Pour que nous soyons nombreux à être convaincus ? Une expérience de la robustesse ? une série de mécanismes de contrôle ? Des échanges bi-directionnels avec d'autres sources de données ? Juste du temps, in fine ? et un peu de méthode arrosée d'imagination. Je ne veux pas avoir l'air de minimiser le travail déjà accompli, mais, à mon avis, OSM ne fait que démarrer, et y'a encore plein de choses à inventer. C'est pour cela qu'on n'a pas abandonné au premier revert. OSM est un adolescent boutoneux. C'est pas très gracieux, c'est capricieux et susceptible, mais c'est tellement tout le monde est passé par là. Wikipedia n'est toujours pas tellement admis dans les milieux universitaires. N'empêche que beaucoup d'étudiants utilisent. La quantité, ça vient pas mal : même s'il reste des déserts (merci CLC). La qualité, ça commence à venir (merci le cadastre) La garantie de qualité, là il faut inventer. Quand à l'exhaustivité... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Re : Cohérence des voiri es, mises à jour / modération
c est vrai que le flux RSS est tres pratique :) quand il y a des modifs dans les zones sur lesquelles je mappe ( bon ça n arrive pas souvent :-( ) je vais jeter un coup d oeuil histoire de voir si tout va bien je pense que comme wikipedia c est globalement la masse qui va faire le controle...mais a mon avis l ideal reste le dialogue et comme l a dit quelqu un precedemment renvoyer les gens sur les pages wikis pour les good practice etc De : Vincent Pottier vpott...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi, 25 Mai 2009, 22h06mn 52s Objet : Re: [OSM-talk-fr] Re : Cohérence des voiries, mises à jour / modération Art Penteur a écrit : Le 25 mai 2009 19:48, THEVENON Julien julien_theve...@yahoo.fr a écrit : et etant donne que tu mets l accent sur le cote collaboratif discussions tout ca.. est ce que tu as essaye de contacter les auteurs des modifications pour en parler avec eux ? meme si j en conviens la logique voudrait que se soient eux qui contactent avant de tout casser Tiens, ça c'est une piste : comment modifier les outils pour encourager ce genre de comportement ? Actuellement, ce n'est pas forcément naturel : - pour les débutants, savoir identifier qui est le dernier contributeur significatif sur un way qu'on veut modifier n'est pas facile. Un statut type 'admin', définit pour une zone devrait pouvoir créer un tag 'alert' sur des objets sensibles. Le contributeur en herbe (en fait tous les contributeurs) qui fait des modifs avec ses gros sabots en croyant faire bien serait alerté qu'un bon niveau de précision, de cohérence est atteint pour l'objet donné et qu'il a intérêt à savoir ce qu'il fait, ou qu'il est invité à visiter telle page du wiki avant d'appliquer les modifs. Après il faut que les éditeurs sachent intégrer ça. Wikimedia a des statuts et des protections de pages 'semi-protégées, protégées' pour éviter le vandalisme ou la maladresse des newbies. - pour les gens plus expérimentés, ils ont déjà fait tant d'édition de corrections d'erreurs diverses que, la fois où l'existant est en fait murement réfléchi (même si ça paraît bizarre au premier abord) qu''ils n'ont plus le réflexe d'étudier l'historique. Il y a le très pratique : http://www.itoworld.com/static/osmmapper qui affiche les noms des contributeurs Il y a le flux rss, que je n'utilise pas. Donc, est-ce que les éditeurs ne devraient pas rendre l'historique (et les commentaires de changeset) plus immédiatement visible ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser une relation de type route pour décrire un way
Etienne T a écrit : Bonsoir J'ai une discution avec un osmeur concernant mon utilisation d'une relation de type route pour décrire un way. La relation en question est la suivante : http://openstreetmap.org/browse/relation/146142 Est-ce autorisé à faire cela ? Maintenant, les ways contenu dans la relation ne contiennent plus que la source DGI-... comme tag. Pour faire la relation, je m'étais basé sur ce topic : http://forum.letuffe.org/viewtopic.php?f=3t=10 http://forum.letuffe.org/viewtopic.php?f=3t=10 qui parle au début d'utiliser une relation de type route. Malheureusement, je n'avais pas lu jusqu'à la fin. Mais le topic est resté sur une interrogation je trouve. Il ne faut pas confondre le mot route en anglais qui veut dire trajet avec le mot route en français. Mais le rendu affiche parfaitement la relation, donc est-ce que cela pose problème ? Note : j'ai fais cette relation pour faciliter le changement des tags quand la LGV sera fini. Car en ce moment, depuis qu'elle a été tracé, les OSMeus sont en train de la découper pour y intégrer les tunnels et les bridges. Je veux bien revenir en arrière. C'était juste par soucis pratique pour la fin, quand la ligne sera fini. Merci de m'éclairer. Salut, J'avais remarqué que la ligne avait changé en entrant des communes dans le coin. J'ai été surpris : ça apparaissait tout gris dans JOSM, ça n'avait l'air de rien. J'ai failli remettre des tags, puis j'ai vu la relation. Je trouve ça malin ! Plus technique que de tagguer les ways, pas simple pour un débutant (j'imagine le gars sous potlatch qui découvre un chemin sans tag et qui va chercher dans sa carte Michelin quelle départementale ça peut être : plein de bonnes intentions) Je vote pour d'autant qu'un bout que j'ai entré se trouve dedans ! Vincent ___ 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
2009/5/25 Etienne T gustrimai...@yahoo.fr: Je ne vois pas trop l'intérêt de créer une relation juste pour faciliter la sélection de plusieurs ways. Il faut que cette relation route corresponde à un réseau complet au final. On pourrait imaginer que ce soit fait pour le réseau TGV avec les refs, etc mais je ne crois pas que ce soit ce que tu veux faire ici. De plus, il faut conserver le tag principal highway ou railway sur le way lui-même. 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. 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... Donc, le way devrait porter le tag railway=construction par exemple: http://wiki.openstreetmap.org/wiki/Key:construction et la relation route, pourquoi pas, mais à condition qu'elle couvre la ligne complète. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prairie sur beta - corine
@ sly : Qu'en est de l'idée d'importer les polygones corine en tant que relations, dès le départ ? Je suis désolé de ne pas pouvoir suivre la discussion, viens de rentrer à Montpellier de déplacement sur la côte atlantique, et repars ce soir sur chantier en Essonne, sans internet. Retour dans une semaine. --- Le 25 mai 09 à 14:08, g.d a écrit : Il y a aussi des forêts tracés d'après operaerial, dans osm. Aucun de ces trois tracés n'est d'accord, et quand on regarde les parcelles d'ONF sur le cadastre, des forets domaniales, ça ferait encore un quatrième tracé. Et les fichiers des sig des coms d'agglo, sur les forêts privés donneraient encore un autre. Je pense que c'est une question de l'échelle d'origine, à laquelle chacun de ces plans avait été crée. Et aucun deux paraît suffisamment précis pour rester dans OSM, sans qu'à un moment ou un autre il sera corrigé, au moins en partie, par nous (Eh, je vois bien : Souvent, là où selon l'une ou l'autre source, je serais soit en pleine forêt soit en plein champs, en réalité la route que je gpxe (-osm) est la limite des deux). Donc, puisque tout cela visiblement sera sujet à des modifs ultérieures par nous, il m'est un peu égal, quelle source sera choisie. A la limite, quant à choisir parmi les différentes sources, je dirai, de prendre la plus détaillée, au cas le cas : Prendre celle, qui, découpée en tronçons, montre le plus de nodes par kilomètre. Gerhard --- Ça va se corser, quand nous, on rectifiera partiellement ces polys, d'après nos observations sur place, d'après cadastre, et d'après gps : Dans la plupart des cas, on va pouvoir rectifier seulement une partie du contour de la forêt, mais pas le contour entier du bois. Donc, logiquement, et par acquit de conscience, on découpera le contour du bois en morceaux, pour virer le tag source sur la partie qu'on a corrigé (pas de tag source implique - observation du osm'eur), et le conservera sur le reste. Je m'imagine le rendu foireux des polys :-( Donc là aussi, on devra faire dans les relationships, comme on le fait pour les boudary/admin. Et de même pour tous les autres landuse importés. Quel boulot de galérien, si nous devons ultérieurement créer une relation pour chacun de ces lopins de terre !... Pourrait-on, lors de l'importation de telles masses de polys, les importer dès le départ comme relations, actuellement chacune avec un seul polygone comme membre ? Amha, ça pourrait énormémang facilitationner leur découpage futur en tronçons rectifiés d'après données de terrain... --- --- Le 23 mai 09 à 18:50, Art Penteur a écrit : Le 23 mai 2009 11:18, Emilie Laffray emilie.laff...@gmail.com a écrit : Les donnees de Corine ne sont pas forcement plus precises, car il y a des gens qui ont passe du temps a delimiter certaines forets correctement. Et on va avoir des cas pas facile à résoudre. Par exemple : http://www.openstreetmap.org/? lat=43.4094lon=2.0449zoom=12layers=B000FTF et http://beta.letuffe.org/? lat=43.40566lon=2.02701zoom=12layers=0BTFFF On a l'impression que le tracé actuel dans OSM est plus fin (meilleure résolution spatiale)... mais le tracé Corine distingue mieux les différents types de végétation. Qui choisir ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prairie sur beta - corine
Pieren a commence a organiser l'organisation des donnees de Corine via les tags. J'ai commence a produire des fichiers au format OSM tout en faisant des tests d'intersection sur les geometries existantes de OSM. Je n'ai pas verifie mais je crois que l'outil de conversion de SHP a OSM cree des relations. Emilie Laffray g.d wrote: @ sly : Qu'en est de l'idée d'importer les polygones corine en tant que relations, dès le départ ? Je suis désolé de ne pas pouvoir suivre la discussion, viens de rentrer à Montpellier de déplacement sur la côte atlantique, et repars ce soir sur chantier en Essonne, sans internet. Retour dans une semaine. --- Le 25 mai 09 à 14:08, g.d a écrit : Il y a aussi des forêts tracés d'après operaerial, dans osm. Aucun de ces trois tracés n'est d'accord, et quand on regarde les parcelles d'ONF sur le cadastre, des forets domaniales, ça ferait encore un quatrième tracé. Et les fichiers des sig des coms d'agglo, sur les forêts privés donneraient encore un autre. Je pense que c'est une question de l'échelle d'origine, à laquelle chacun de ces plans avait été crée. Et aucun deux paraît suffisamment précis pour rester dans OSM, sans qu'à un moment ou un autre il sera corrigé, au moins en partie, par nous (Eh, je vois bien : Souvent, là où selon l'une ou l'autre source, je serais soit en pleine forêt soit en plein champs, en réalité la route que je gpxe (-osm) est la limite des deux). Donc, puisque tout cela visiblement sera sujet à des modifs ultérieures par nous, il m'est un peu égal, quelle source sera choisie. A la limite, quant à choisir parmi les différentes sources, je dirai, de prendre la plus détaillée, au cas le cas : Prendre celle, qui, découpée en tronçons, montre le plus de nodes par kilomètre. Gerhard --- Ça va se corser, quand nous, on rectifiera partiellement ces polys, d'après nos observations sur place, d'après cadastre, et d'après gps : Dans la plupart des cas, on va pouvoir rectifier seulement une partie du contour de la forêt, mais pas le contour entier du bois. Donc, logiquement, et par acquit de conscience, on découpera le contour du bois en morceaux, pour virer le tag source sur la partie qu'on a corrigé (pas de tag source implique - observation du osm'eur), et le conservera sur le reste. Je m'imagine le rendu foireux des polys :-( Donc là aussi, on devra faire dans les relationships, comme on le fait pour les boudary/admin. Et de même pour tous les autres landuse importés. Quel boulot de galérien, si nous devons ultérieurement créer une relation pour chacun de ces lopins de terre !... Pourrait-on, lors de l'importation de telles masses de polys, les importer dès le départ comme relations, actuellement chacune avec un seul polygone comme membre ? Amha, ça pourrait énormémang facilitationner leur découpage futur en tronçons rectifiés d'après données de terrain... --- --- Le 23 mai 09 à 18:50, Art Penteur a écrit : Le 23 mai 2009 11:18, Emilie Laffray emilie.laff...@gmail.com a écrit : Les donnees de Corine ne sont pas forcement plus precises, car il y a des gens qui ont passe du temps a delimiter certaines forets correctement. Et on va avoir des cas pas facile à résoudre. Par exemple : http://www.openstreetmap.org/? lat=43.4094lon=2.0449zoom=12layers=B000FTF et http://beta.letuffe.org/? lat=43.40566lon=2.02701zoom=12layers=0BTFFF On a l'impression que le tracé actuel dans OSM est plus fin (meilleure résolution spatiale)... mais le tracé Corine distingue mieux les différents types de végétation. Qui choisir ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Un bruit qui court...
Bonsoir, On me souffle dans l'oreillette que : - le backend d'osmose veut bien traiter les relations boundary ce test n'est visible que sur un nouveau frontend - un nouveau front-end va voir le jour : http://osmose.openstreetmap.fr/cgi-bin/osmose.py Il paraitrait que le front-end a été codé très salement durant cette dure journée pluvieuse... il lui reste peut être encore des bugs. Mon voisin de bureau commence déjà à râler parce qu'il ne voit pas la liste des utilisateurs... On me souffle aussi que pour le moment on ne peut pas ignorer d'erreur. -- Etienne ___ 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
2009/5/25 Frédéric Bunoz frederic.bu...@camptocamp.org: Les coordonnées des sommets suisses ont été relevées pour la plupart sur les cartes Swisstopo. Nous avons l'accord de Swisstopo pour diffuser ces coordonnées sous licence libre : Vous pouvez utiliser et publier sans outre les coordonnées de points des Cartes nationales. Ces données sont libres de droits et aucune autorisation n'est nécessaire. Ca fait rêver ;-) Malheureusement, en France, l'IGN n'a pas le même altruisme (ni peut-être les moyens) qu'en Suisse. Je pense aussi que les altitudes sont du domaine public mais quid des positions ? Si vous les placez à partir d'images yahoo et/ou des lignes de contours, pourquoi pas. Mais je ne pense pas qu'on puisse utiliser les cartes de l'IGN pour ça. Sinon pourquoi se l'autoriser pour les sommets et pas pour les routes, les lacs, etc ? Pieren ___ 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
Le 25 mai 2009 23:30, Pieren pier...@gmail.com a écrit : Ca fait rêver ;-) Malheureusement, en France, l'IGN n'a pas le même altruisme (ni peut-être les moyens) qu'en Suisse. Je pense aussi que les altitudes sont du domaine public mais quid des positions ? Si vous les placez à partir d'images yahoo et/ou des lignes de contours, pourquoi pas. Mais je ne pense pas qu'on puisse utiliser les cartes de l'IGN pour ça. Sinon pourquoi se l'autoriser pour les sommets et pas pour les routes, les lacs, etc ? Pieren Je pense que le droit d'auteur des bases de données s'applique : http://fr.wikipedia.org/wiki/Aide:FAQ/juridique/Bases_de_donn%C3%A9es et http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06069414idArticle=LEGIARTI06279252dateTexte=20090525 « Lorsqu'une base de données est mise à la disposition du public par le titulaire des droits, celui-ci ne peut interdire : 1. L'extraction ou la réutilisation d'une partie non substantielle, appréciée de façon qualitative ou quantitative, du contenu de la base, par la personne qui y a licitement accès ; 2. [...] » Donc on a le droit de réutiliser une partie non substantielle de la base de données de l'IGN. -- Guillaume DELUGEARD ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Vincent Pottier wrote: Wikipedia n'est toujours pas tellement admis dans les milieux universitaires. N'empêche que beaucoup d'étudiants utilisent. La quantité, ça vient pas mal : même s'il reste des déserts (merci CLC). La qualité, ça commence à venir (merci le cadastre) La garantie de qualité, là il faut inventer. Quand à l'exhaustivité... Personnellement, je suis convaincue que OSM est un projet qui va de loin depasser les sources commerciales dans un temps relativement court. Des societes comme TeleAtlas et Naveteq n'ont pas forcement une qualite fantastique quand on y regarde de pres et ce n'est pas que des Easter eggs. La garantie de qualite, elle viendra a mesure que les gens repasseront sur les routes deja existantes. A mesure que les sources vont se developper, de plus en plus de gens vont utiliser les cartes et corrigeront de maniere implicite (certains programmes sont capables d'envoyer les donnees automatiquement). Quant a l'exhaustivite, OSM est deja plus exhaustif que ce que la majorite des societes vous propose sur le net. Par exemple, allez voir en Coree du sud sur Google map et vous vous rendrez compte de l'exhaustivite des donnees de l'endroit. TeleAtlas vient toutefois de signer un accord avec la societe en charge des cartes en Coree du sud. Mais ca va prendre du temps a integrer les donnees. Il n'y a pas une seule compagnie qui ait une cartographie aussi poussee que OSM dans une seule base de donnee, et c'est quelque chose qui progresse a vitesse grand V. Il est evident que le projet va trouver des utilisations auxquelles personne ne pensait. C'est quelque chose qui va apparaitre avec le temps. C'est avec de bons outils (logiciel et materiel) qu'on verra une utilisation innovante de OSM. Emilie Laffray signature.asc Description: OpenPGP digital signature ___ 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
Il faut voir. La future license de OSM est basee sur le droit des bases de donnee aussi; il faudrait voir si potentiellement ca clashe. Je verrais si une amie a le temps de regarder ca un peu, mais je ne peux rien promettre. Je pense que de toute facon on entendra bientot parler de la nouvelle license. La liste de discussion legale est en plein buzz sur comment definir certains elements de la future license sur par exemple qu'est ce qui constituent un derived work ou un produced work. Donc on verra si c'est compatible ou pas. Il faudrait voir si le BRGM (si ca existe toujours) n'a pas des cartes qui trainent et qui pourraient etre utilisees. Ils ont beaucoup de cartes geologiques mais ils peuvent avoir des donnees du type Corine etc Emilie Laffray tiot wrote: Le 25 mai 2009 23:30, Pieren pier...@gmail.com mailto:pier...@gmail.com a écrit : Ca fait rêver ;-) Malheureusement, en France, l'IGN n'a pas le même altruisme (ni peut-être les moyens) qu'en Suisse. Je pense aussi que les altitudes sont du domaine public mais quid des positions ? Si vous les placez à partir d'images yahoo et/ou des lignes de contours, pourquoi pas. Mais je ne pense pas qu'on puisse utiliser les cartes de l'IGN pour ça. Sinon pourquoi se l'autoriser pour les sommets et pas pour les routes, les lacs, etc ? Pieren Je pense que le droit d'auteur des bases de données s'applique : http://fr.wikipedia.org/wiki/Aide:FAQ/juridique/Bases_de_donn%C3%A9es et http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06069414idArticle=LEGIARTI06279252dateTexte=20090525 http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06069414idArticle=LEGIARTI06279252dateTexte=20090525 « Lorsqu'une base de données est mise à la disposition du public par le titulaire des droits, celui-ci ne peut interdire : 1. L'extraction ou la réutilisation d'une partie non substantielle, appréciée de façon qualitative ou quantitative, du contenu de la base, par la personne qui y a licitement accès ; 2. [...] » Donc on a le droit de réutiliser une partie non substantielle de la base de données de l'IGN. -- Guillaume DELUGEARD ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr signature.asc Description: OpenPGP digital signature ___ 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
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. Ca unifie un la route avec les tags communs pour chaque morceau de way qui forment au final une seule et unique route. Les morceaux de way contiennent les tags qui leurs sont propres (tunnel et bridge dans la majeur partie des cas). et la relation route, pourquoi pas, mais à condition qu'elle couvre la ligne complète. J'éspere qu'à terme, elle sera complète. Pour le côté pratique, on pourra changer le railway d'un seul coup. Et pour le côté géographique, je trouve ça pratique d'avoir une page présentant un objet précis : http://openstreetmap.org/browse/relation/146142 en sachant que dans la base de données il y a un objet représentant chaque petit morceau spécifique de cette objet. 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. Ceci n'est à mon avis qu'un exemple parmis tant d'autres et celui qui est le plus accessible à mon niveau d'OSM. 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). Le rendu est bien passé sur la relation, donc je me dis pourquoi pas d'autre outils ? Il faudrait que JOSM lise le contenu de la relation pour éviter qu'il l'affiche en gris. Bon, je sais pas si tout ce que j'ai écris est compréhensible, mais c'était juste un point de vue. --- En date de : Lun 25.5.09, Pieren pier...@gmail.com a écrit : De: Pieren pier...@gmail.com Objet: Re: [OSM-talk-fr] Utiliser une relation de type route pour décrire un way À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Lundi 25 Mai 2009, 23h17 2009/5/25 Etienne T gustrimai...@yahoo.fr: Je ne vois pas trop l'intérêt de créer une relation juste pour faciliter la sélection de plusieurs ways. Il faut que cette relation route corresponde à un réseau complet au final. On pourrait imaginer que ce soit fait pour le réseau TGV avec les refs, etc mais je ne crois pas que ce soit ce que tu veux faire ici. De plus, il faut conserver le tag principal highway ou railway sur le way lui-même. 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. 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... Donc, le way devrait porter le tag railway=construction par exemple: http://wiki.openstreetmap.org/wiki/Key:construction et la relation route, pourquoi pas, mais à condition qu'elle couvre la ligne complète. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un bruit qui court...
Génial, ça m'a permis de corriger des défauts qui n'étaient pas visibles avant. -- Matthieu 2009/5/25 Etienne Chové ch...@crans.org Bonsoir, On me souffle dans l'oreillette que : - le backend d'osmose veut bien traiter les relations boundary ce test n'est visible que sur un nouveau frontend - un nouveau front-end va voir le jour : http://osmose.openstreetmap.fr/cgi-bin/osmose.py Il paraitrait que le front-end a été codé très salement durant cette dure journée pluvieuse... il lui reste peut être encore des bugs. Mon voisin de bureau commence déjà à râler parce qu'il ne voit pas la liste des utilisateurs... On me souffle aussi que pour le moment on ne peut pas ignorer d'erreur. -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Utiliser une relation de type route pour décrire un way
Etienne T a écrit : 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. Ca unifie un la route avec les tags communs pour chaque morceau de way qui forment au final une seule et unique route. Les morceaux de way contiennent les tags qui leurs sont propres (tunnel et bridge dans la majeur partie des cas). et la relation route, pourquoi pas, mais à condition qu'elle couvre la ligne complète. J'éspere qu'à terme, elle sera complète. Pour le côté pratique, on pourra changer le railway d'un seul coup. Et pour le côté géographique, je trouve ça pratique d'avoir une page présentant un objet précis : http://openstreetmap.org/browse/relation/146142 en sachant que dans la base de données il y a un objet représentant chaque petit morceau spécifique de cette objet. 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. Ceci n'est à mon avis qu'un exemple parmis tant d'autres et celui qui est le plus accessible à mon niveau d'OSM. 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). Le rendu est bien passé sur la relation, donc je me dis pourquoi pas d'autre outils ? Il faudrait que JOSM lise le contenu de la relation pour éviter qu'il l'affiche en gris. Bon, je sais pas si tout ce que j'ai écris est compréhensible, mais c'était juste un point de vue. 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' ? Je crois que la relation est en plein développement : site... Et que la sémantique d'OSM va devoir s'organiser... Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
J'allais dire que sur Madagascar aussi OSM a une qualité très largement supérieure aux autres bases de données... mais je viens de voir que Google a fait un gros bond qualitatif et quantitatif sur les villes et plus généralement les zones couvertes en haute résolution. Donc, en quantitatif et qualitatif, ils sont bien devant mais ils ont des problèmes de contrôle qualité. J'ai au moins trouvé un bout de piste (15 km) complètement à côté de la plaque. Manque de contrôle sur le terrain. Et dans les zones en basse résolution, Google indique facilement les routes avec plusieurs kilomètres d'erreur. En résumé, OSM devrait être à assez court terme une bonne source de données pour faire les fonds de carte de mes rapports. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Bonsoir, OSM est basé sur le même principe que wikipedia et consort. Et comme dans wikipedia, il peut y avoir du vandalisme ou des erreurs de débutants. Mais le fondement de ce genre de projet est basé sur la confiance que l'on met dans la masse des contributeurs, qui dans l'ensemble fait évoluer le projet dans le bon sens et corrige ses erreurs. Concernant la question du reclassement des highways, c'est votre méthode qui est critiquable. Faire des choix en petit comité avec messages privés était le moyen le plus sûr de voir apparaître tôt ou tard ces requalifications des highways, surtout s'ils le sont en dehors des règles que nous essayons tant bien que mal de définir ensemble. Ces règles, nous devons les définir pour tout le territoire français et sans remettre en cause vos choix, je ne vois pas OSM Toulouse avoir ses propres définitions des primary, secondary, tertiary, OSM Marseille faire les siennes, et OSM Strasbourg faire encore autrement, etc... Maintenant, il est possible que vos choix correspondent aux règles communes, auquel cas vous pouvez avoir affaire à un débutant qui n'a pas saisi la portée de ses modifications. C'est un risque que nous connaissons tous. La plupart de temps, un message direct à cette personne avec renvoi vers la documentation suffit. Maintenant on peut tomber sur un psycho-rigide qui pense avoir raison contre tout le monde. Il faudrait dans ce cas bloquer l'accès au site à cette personne en en faisant la demande auprès des admins. Pour finir, concernant votre question de savoir si OSM peut être une source fiable, je suis encore sceptique. Il est clair qu'OSM - grâce à son principe d'ouverture - va devenir un point de collecte central et qu'il sera plus complet et plus à jour que n'importe quel autre source commerciale fermée. Mais, c'est contrebalancé par cet inconvénient majeur du risque d'altération qui pèse sur les données. A ma connaissance, il y a deux entreprises qui font commerce des données OSM : Cloudmade et Geofabrik. Et une part de leur business est justement de fiabiliser les données OSM avant de les revendre. Cela doit probablement passer par des outils de surveillance automatique et il est possible qu'ils maintiennent une base parallèle et ne transfèrent les nouvelles contributions que sous certaines conditions. Une autre option est de surveiller la base directement sur la partie des données qui vous intéresse et de faire des reverts automatiques avec message informant la personne du pourquoi. Mais en faisant cela, vous prenez le risque de 1. figer la situation et 2. de dégouter les contributeurs sur cette zone. Deux choses qui vont à l'encontre de l'esprit d'OSM. C'est pourquoi je pense que la meilleure solution reste une bdd séparée avec un outil intelligent qui prend les nouvelles données d'OSM après évaluation (automatique et/ou manuelle). Grâce à un tel outil, vous pouvez conserver aussi une certaine liberté dans vos choix (par exemple, fusionner des tags ou ne pas adopter de nouvelles conventions de nommage, etc). Quant à la suggestion de mettre des modérateurs qui verrouilleraient certaines données, cette idée a été suggérée sur la ML anglaise par quelqu'un qui avait la même démarche que vous (sur New-York si ma mémoire est bonne) et a été farouchement rejetée. Soit vous mettez vos données à disposition d'OSM (avec le risque des modifications), soit vous créez votre propre base (certains diront mashup) en important ce qui vous intéresse d'OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Cohérence des voiries, m ises à jour / modération
entierement d accord :-) c est vrai qu il ne faut pas oublier que tout n est pas aussi bien couvert que la France par Google De : Emilie Laffray emilie.laff...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi, 25 Mai 2009, 23h40mn 47s Objet : Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération Vincent Pottier wrote: Wikipedia n'est toujours pas tellement admis dans les milieux universitaires. N'empêche que beaucoup d'étudiants utilisent. La quantité, ça vient pas mal : même s'il reste des déserts (merci CLC). La qualité, ça commence à venir (merci le cadastre) La garantie de qualité, là il faut inventer. Quand à l'exhaustivité... Personnellement, je suis convaincue que OSM est un projet qui va de loin depasser les sources commerciales dans un temps relativement court. Des societes comme TeleAtlas et Naveteq n'ont pas forcement une qualite fantastique quand on y regarde de pres et ce n'est pas que des Easter eggs. La garantie de qualite, elle viendra a mesure que les gens repasseront sur les routes deja existantes. A mesure que les sources vont se developper, de plus en plus de gens vont utiliser les cartes et corrigeront de maniere implicite (certains programmes sont capables d'envoyer les donnees automatiquement). Quant a l'exhaustivite, OSM est deja plus exhaustif que ce que la majorite des societes vous propose sur le net. Par exemple, allez voir en Coree du sud sur Google map et vous vous rendrez compte de l'exhaustivite des donnees de l'endroit. TeleAtlas vient toutefois de signer un accord avec la societe en charge des cartes en Coree du sud. Mais ca va prendre du temps a integrer les donnees. Il n'y a pas une seule compagnie qui ait une cartographie aussi poussee que OSM dans une seule base de donnee, et c'est quelque chose qui progresse a vitesse grand V. Il est evident que le projet va trouver des utilisations auxquelles personne ne pensait. C'est quelque chose qui va apparaitre avec le temps. C'est avec de bons outils (logiciel et materiel) qu'on verra une utilisation innovante de OSM. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] josm problème connexion serveur
Salut Ce soir, il m'est impossible de rapatrier une zone provenant d'un serveur avec josm. J'ai un code erreur 403 pour l'url http://www.openstreetmap.org/api/0.5/map?bbox voici la réponse à la tentative de connexion : GET /api/0.5/map?bbox=-1.6997612912371125,48.065653090400765,-1.6940343840206176,48.07096526011468 HTTP/1.1 Accept-Encoding: gzip, deflate User-Agent: Java/1.6.0_0 Host: www.openstreetmap.org Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive HTTP/1.1 403 Forbidden Content-Type: text/html Content-Length: 345 Date: Mon, 25 May 2009 22:25:26 GMT Server: lighttpd/1.4.22 ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en head title403 - Forbidden/title /head body h1403 - Forbidden/h1 /body /html Une idée ? nono signature.asc Description: Ceci est une partie de message numériquement signée ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] josm problème connexion serveur
2009/5/26 pingvenono pingven...@free.fr: http://www.openstreetmap.org/api/0.5/map?bbox GET /api/0.5/map?bbox=-1.6997612912371125,48.065653090400765,-1.6940343840206176,48.07096526011468 HTTP/1.1 D'après tes URL, ton JOSM en est encore à la version 0.5 de l'API. Si tu le met à jour, il va détecter automatiquement le passage à l'API 0.6 et tout devrait rentrer dans l'ordre ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un bruit qui court...
Matthieu Lochegnies a écrit : Génial, ça m'a permis de corriger des défauts qui n'étaient pas visibles avant. -- Matthieu 2009/5/25 Etienne Chové ch...@crans.org mailto:ch...@crans.org Bonsoir, On me souffle dans l'oreillette que : - le backend d'osmose veut bien traiter les relations boundary ce test n'est visible que sur un nouveau frontend - un nouveau front-end va voir le jour : http://osmose.openstreetmap.fr/cgi-bin/osmose.py Il paraitrait que le front-end a été codé très salement durant cette dure journée pluvieuse... il lui reste peut être encore des bugs. Mon voisin de bureau commence déjà à râler parce qu'il ne voit pas la liste des utilisateurs... On me souffle aussi que pour le moment on ne peut pas ignorer d'erreur. Mois aussi. Mai je ne trouve plus le timestamp du test. Vincent ___ 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' ? Sur la carte que j'utilisais jusqu'à hier sur mon GPS, tout le centre-ville de Besançon était couvert de bleu en indiquant le Doubs. Ceci dit, ma carte était vieille, je n'ai pas regardé si c'était corrigé dans la nouvelle version. Je crois que la relation est en plein développement : site... Et que la sémantique d'OSM va devoir s'organiser... Sincérement, je trouve que les relations, c'est un plus extraordinaire pour OSM. La semaine dernière, on ma demandé une carte de la véloroute 6 allant de Nantes à Budapest en vélo. Cette même personne m'a demandé aussi si il existait le fichier pour GPS. Alors déjà, allez chercher sur internet une carte de l'EV6, on en trouve pas. Ou alors si, on en trouve, mais elles sont grossières, les traits ne passent pas par les chemins officiels, mais font du vol d'oiseau de ville en ville. Et la, on dit merci opencyclemap d'afficher l'EV6 avec un gros très rouge qui passe exactement ou passe le trajet officiel de l'EV6, c'est à dire piste cyclable, voie partagé sur des petites routes communales, Et pour le fichier gpx, la on dit encore merci à OpenStreetMap pour générer automatiquement ce fichier. Ceci est impossible à trouver sur internet. Il n'y a pas de projet semblable pouvant fournir de telles informations ! Merci la relation 28 853 : http://www.openstreetmap.org/browse/relation/28853 Manquerait juste une carte à faire pour afficher la relation voulu sur une grande carte, mais ça, il ne manque que quelques lignes de codes, et chacun est libre de se pencher dessus. Merci OSM de pouvoir développer ce qu'on veut. Ce que je disais dans l'autre mail, ça ma fait penser exactement à de la programmation objet pour ceux qui connaissent : on a des classes abstraites (les relations) comportant des objets qui héritent de la classe abstraite (les way). Et ces classes héritent donc des méthodes de la classe abstraites : les tags dans notre cas. Le relations sont, je trouve un outil formidable pour de la cartographie. Elles permettent de manipuler par lot tout les ways formant le même objet au final. Personnellement, malgré mon très faible niveau en cartographie sur OSM (je sais juste ouvrir JOSM, ajouter des ways et des nodes et uploader, bref rien de particulier, juste l'utilisation basique), et bien je vois plein de possibilité avec les relations. Ou alors est-ce peut-être du à mon faible niveau que je crois en de multiples possibilitées dans les relations, et qu'avec un peu plus d'expérience, avec une requète SQL bien placé ou alors une bonne commande osmxapi j'arriverai à imaginer la même chose. Mais je trouve pas çà une bonne logique de tout découper un petit morceau ( en très petit morceau de 2 nodes dans une grande partie des cas pour mettre un pont ou un tunnel) indépendant des uns des autres, alors qu'ils représentent le même éléments physiques. Mais ceci n'est que mon point de vue. Comme dit dans l'autre fil de discussion, OSM n'est qu'au début de son aventure. Les utilisations vont venir plus tard. Pensons pour le futur ;-) (bon, je m'emporte peut-être un la :) ) Bon, pour clore ma petite dissertation sur les relations, et tout ça pour justifier mon emploi de la relation concernant la LGV, je pense qu'OSM a pas mal de possibilitées en vue (notament avec les relations par exemple que j'aimerais bien développer). Mais, je suis d'accord, ca fait un peu bizarre d'avoir des ways sans tag, mais qui appartiennent à une relation. C'est encore plus bizarre quand sur ce way il n'y a que le tag bridge=yes. Mais faut juste s'y habituer, et que JOSM gère les cas comme çà. :) Non ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Utiliser une relation de typ e route pour décrire un way
ou alors il faudrait que les outils affichent pour le way les tags des relations auxquelles il appartient avec une signaletique speciale pour indique que se sont des tags de la relation.. en tout ça me fait plus penser a une jointure en base de donnee qu a la programmation objet ;-) De : Etienne T gustrimai...@yahoo.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mardi, 26 Mai 2009, 1h10mn 28s Objet : Re: [OSM-talk-fr] Utiliser une relation de type route pour décrire un way Mais, je suis d'accord, ca fait un peu bizarre d'avoir des ways sans tag, mais qui appartiennent à une relation. C'est encore plus bizarre quand sur ce way il n'y a que le tag bridge=yes. Mais faut juste s'y habituer, et que JOSM gère les cas comme çà. :) Non ? ___ 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
2009/5/26 Etienne T gustrimai...@yahoo.fr: Ce que je disais dans l'autre mail, ça ma fait penser exactement à de la programmation objet pour ceux qui connaissent : on a des classes abstraites (les relations) comportant des objets qui héritent de la classe abstraite (les way). Et ces classes héritent donc des méthodes de la classe abstraites : les tags dans notre cas. On peut aussi voir la relation comme un agrégateur et pas comme un héritage. Les tags sur le way décrivent le way. Les tags sur la relation décrivent la relation. C'est vrai, on pourrait tout mettre dans la relation. On pourrait aussi ne mettre que des nodes et virer les ways. Comment vous allez faire avec votre way sans tag et faisant partie de 25 relations ? Pour décrire le way, vous devrez faire la somme de tous les tags des 25 relations et faire le tri entre ce qui décrit le way et ce qui décrit la relation ? Bon courage. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Key:enforcement
Bonsoir, Suite à la validation du tag enforcement (contrôle routier/respect des limitations), je me suis lancé dans la mise au point de la page http://wiki.openstreetmap.org/wiki/FR:Key:enforcement, en tout cas pour la version française. Je m'inspire évidemment de http://wiki.openstreetmap.org/wiki/Approved_features/Relation:enforcement. Je suis à la recherche de forces vives pour m'aider (et me corriger) dans cette tache, voir dans sa traduction en anglais. Finalité : coder les emplacements des différents radars et autres appareils de mesure présents sur le réseau routier. -- Marcus On a pas le temps de s'ennuyer avec OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Corine Land Cover : nomenclature 23 Prairies
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. 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. * la classe 231 Prairies est proposée sur le wiki en landuse=meadow qui est déjà assez largement utilisé (2700 sur l'Europe d'après tagwatch) et documenté dans Map Features. Pieren ___ 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 peut aussi voir la relation comme un agrégateur et pas comme un héritage. Les tags sur le way décrivent le way. Les tags sur la relation décrivent la relation. C'est vrai, on pourrait tout mettre dans la relation. On pourrait aussi ne mettre que des nodes et virer les ways. Comment vous allez faire avec votre way sans tag et faisant partie de 25 relations ? Pour décrire le way, vous devrez faire la somme de tous les tags des 25 relations et faire le tri entre ce qui décrit le way et ce qui décrit la relation ? Bon courage. L'exemple de la prog objet n'est qu'une image. C'était un peu pour illustrer mon point de vue, et j'ai juste dis a quoi cela me faisait penser. Je suis débutant en prog objet, et j'ai donc pas aussi des masses de connaissances dans le domaine. Bien sur, 25 relations, c'est la misère a gèrer. Même si il existe les supers relations, ca risque d'être galère à partir d'un certain niveau. Et il reste encore du travail à approfondir. Mais je trouve ça dommage que , alors que nous construisons une base géographique, et certainement la plus complète, les éléments géographiques les plus simples que nous cartographions telles que les routes soient découpés. On doit perdre des possibilités pour OSM. --- En date de : Mar 26.5.09, Pieren pier...@gmail.com a écrit : De: Pieren pier...@gmail.com Objet: Re: [OSM-talk-fr] Utiliser une relation de type route pour décrire un way À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Mardi 26 Mai 2009, 1h28 2009/5/26 Etienne T gustrimai...@yahoo.fr: Ce que je disais dans l'autre mail, ça ma fait penser exactement à de la programmation objet pour ceux qui connaissent : on a des classes abstraites (les relations) comportant des objets qui héritent de la classe abstraite (les way). Et ces classes héritent donc des méthodes de la classe abstraites : les tags dans notre cas. On peut aussi voir la relation comme un agrégateur et pas comme un héritage. Les tags sur le way décrivent le way. Les tags sur la relation décrivent la relation. C'est vrai, on pourrait tout mettre dans la relation. On pourrait aussi ne mettre que des nodes et virer les ways. Comment vous allez faire avec votre way sans tag et faisant partie de 25 relations ? Pour décrire le way, vous devrez faire la somme de tous les tags des 25 relations et faire le tri entre ce qui décrit le way et ce qui décrit la relation ? Bon courage. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Key:enforcement
j'ai pas mal participé à la discussion de la proposition. Je veux bien t'aider... Yann Le 26 mai 09 à 01:40, Marc SIBERT a écrit : Bonsoir, Suite à la validation du tag enforcement (contrôle routier/respect des limitations), je me suis lancé dans la mise au point de la page http://wiki.openstreetmap.org/wiki/FR:Key:enforcement, en tout cas pour la version française. Je m'inspire évidemment de http://wiki.openstreetmap.org/wiki/Approved_features/Relation:enforcement . Je suis à la recherche de forces vives pour m'aider (et me corriger) dans cette tache, voir dans sa traduction en anglais. Finalité : coder les emplacements des différents radars et autres appareils de mesure présents sur le réseau routier. -- Marcus On a pas le temps de s'ennuyer avec OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Corine Land Cover : nomenclature 2 4 Zones agricoles hétérogènes
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. Une catégorie plus difficile qui dessine des zones agricoles mixtes. * la classe 241 Cultures annuelles associées aux cultures permanentes est proposée sur le wiki en landuse=farm alors que la description plus détaillée dit Cultures temporaires (terres arables ou prairies) en association avec des cultures permanentes sur les mêmes parcelles.. Donc cela pourrait aussi bien être landuse=meadow. La solution pourrait être de suivre l'exemple de la classe 121 et taguer avec landuse=farm;meadow et une note explicative. * la classe 242 Systèmes culturaux et parcellaires complexes est sous-titrée Juxtaposition de petites parcelles de cultures annuelles diversifiées, de prairies et / ou de cultures permanentes complexes.. Là aussi, je proposerais la même solution que pour la classe 241 avec landuse=farm;meadow et une note explicative. * la classe 243 Surfaces essentiellement agricoles, interrompues par des espaces naturels importants est délicate à traduire. C'est majoritairement agricole mais on prend un risque à mettre landuse=farm, qui confondrait la zone avec du terrain purement agricole comme dans la catégorie 21. De plus, on masquerait les espaces naturels apparemment trop petits pour mériter leur propre polygone (mais qui pourraient porter un tag natural). * la classe 244 Territoires agro-forestiers avec le sous-titre Cultures annuelles ou pâturages sous couvert arboré composé d'espèces forestières n'a pas d'équivalent direct dans OSM. Je n'ai pas trouvé d'exemple sur la carte et je ne sais pas à quelle densité de forêt on fait référence. Est-ce suffisamment dense pour parler de landuse=forest ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un bruit qui court...
+--On 25 mai 2009 22:14:02 +0200 Etienne Chové ch...@crans.org wrote: | Bonsoir, | | On me souffle dans l'oreillette que : | - le backend d'osmose veut bien traiter les relations boundary | ce test n'est visible que sur un nouveau frontend | - un nouveau front-end va voir le jour : | http://osmose.openstreetmap.fr/cgi-bin/osmose.py Ahhh, cl :-) Et moi qui desesperait de ne pas pouvoir faire la deuxième moitié des erreurs de relations boundary... :-) -- Mathieu Arnold ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] josm problème connexion serveur
Le mardi 26 mai 2009 à 00:49 +0200, Pieren a écrit : 2009/5/26 pingvenono pingven...@free.fr: http://www.openstreetmap.org/api/0.5/map?bbox GET /api/0.5/map?bbox=-1.6997612912371125,48.065653090400765,-1.6940343840206176,48.07096526011468 HTTP/1.1 D'après tes URL, ton JOSM en est encore à la version 0.5 de l'API. Si tu le met à jour, il va détecter automatiquement le passage à l'API 0.6 et tout devrait rentrer dans l'ordre ;-) Pieren ok merci, le paquet josm pour ma debian (lenny) n'est pas à jour. J'ai dû le désinstaller et prendre celui du site josm.latest.jar. dankon nono signature.asc Description: Ceci est une partie de message numériquement signée ___ 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
Bonjour, Le 25 mai 2009 23:30, Pieren pier...@gmail.com a écrit : Je pense aussi que les altitudes sont du domaine public mais quid des positions ? Si vous les placez à partir d'images yahoo et/ou des lignes de contours, pourquoi pas. Une fois identifié sur le site Camptocamp.org, un contributeur a plusieurs moyens pour saisir les coordonnées d'un objet ponctuel : - depuis une carte OpenStreetMap (pratique pour saisir un point de départ de rando comme fin de route par exemple) - depuis une carte OpenAerialMap (ces données raster sont sous CreativeCommons Attribution License ou dans le domaine public): ceci peut etre utile pour un lac, un col ... - depuis un formulaire. Une note préliminaire demande aux contributeurs de respecter les droits d'auteur. Cette manière de faire ne diffère en rien de la pratique sur OpenStreetMap. Lors de la conception du site camptocamp, nous avons bien réfléchi à ce widget de saisie de coordonnées, de telle sorte que les données saisies soient libres. Il serait dommage de tourner leur dos, à mon avis. Cordialement, F. ___ 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
Le 26 mai 2009 07:44, Francois Van Der Biest francois.vanderbi...@camptocamp.com a écrit : Il serait dommage de tourner leur dos, à mon avis. ... de leur tourner le dos, pardon ;-) F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
