Re: [OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)
Salut, Le mardi 27 juillet 2010 à 18:36 +0200, arno a écrit : comme je l'avais annoncé il y a quelques semaines sur la liste, je suis en train de faire un site web de partage d'itinéraires. L'idée du site, c'est qu'on trace un itinéraire sur un fond de carte osm, et ensuite, ça permet d'avoir un lien direct vers le tracé. Ça permet par exemple de montrer des trajets rando, des trajets vélo malin, ... Qu'est-ce que vous en pensez, est-ce qu'il y a des choses à améliorer, des bugs ? est-ce que vous pensez que vous allez l'utiliser ? ou pas ? et pourquoi ? — Avoir plusieurs couleurs pour distinguer les types de transports (voiture, train, bus, pied, vélo …) — Avoir un historique d'annulation et pouvoir sélectionner un point pour le supprimer — Fin du fin, avoir une petite fonction qui tente d'accoler la trace aux chemins Si le projet est libre, je veux bien tâcher de coder moi-même ces fonctions. Joli travail, Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Argumentaire pour des données lib res
Le mardi 27 juillet 2010 18:46:46 Christophe Bayle, vous avez écrit : From: François Van Der Biestfrancois.vanderbi...@camptocamp.com To: Discussions sur OSM en français talk-fr@openstreetmap.org Bonsoir, J'embraye sur la suite dès que j'ai un peu de temps... Génial, je viens d'ailleurs de me rendre compte que tu étais celui avait crée le document sur le wiki de OSGeo, merci à toi =) Bonjour, Pensez à relayer la discussion sur la liste OSGéo-FR ;-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( =?utf-8?q?pr=C3=A9visualisations?=)
Le mardi 27 juillet 2010 18:36:08 arno, vous avez écrit : salut, comme je l'avais annoncé il y a quelques semaines sur la liste, je suis en train de faire un site web de partage d'itinéraires. Super ! Il est loin d'être fini, mais il est suffisamment avancé pour que je vous le présente et que vous me disiez ce que vous en pensez. En le présentant dés maintenant, si vous avez des idées de choses à améliorer, à changer etc, ça sera plus facile pour moi que si j'attends qu'il soit fini ! Bon déjà, je ne sais pas quelles technos tu utilises, mais ce serait bien que ce soit un poil modulaire. Car en fait gérer des traces c'est bien, mais on peut aussi gérer des POI, des objets géolocalisés (photos), toussa … Donc si c'est bien conçu à la base, et vu que ça a l'air déjà pas trop mal foutu, ce serait bien de pouvoir l'étendre facilement. Ensuite, le top serait de pouvoir suivre des ways (ou des relations, bien sûr ;-)) existants et non poser des nodes un par un. Bon courage pour la suite. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : syj: partage d'itinérai res (prévisualisations)
Le mercredi 28 juillet 2010, à 00:29:09 +, THEVENON a écrit : Ce qui serait sympa se serait de _ pouvoir uploader un gpx plutot que faire le tracer a la main c'est prévu pour plus tard _ pouvoir faire un export gpx dans le cas ou on trace a la mano c'est prévu pour plus tard _ pouvoir indiquer la localisation d un gpx distant ( par exemple via un parametre d url ) et qu il soit affiche a la volee sur le site sans devoir etre uploade et stocke via la creation d un compte ça, c'est le bordel, il faut bien régler le serveur sur lequel est stocké le gpx, et en plus, ça ne marchera pas avec beaucoup de navigateurs. Bref, c'est un coup à recevoir 10 mails de çamarchepa par jour. a+ arno signature.asc Description: Digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)
Le mercredi 28 juillet 2010, à 08:00:37 +0200, Philippe a écrit : Salut, Le mardi 27 juillet 2010 à 18:36 +0200, arno a écrit : comme je l'avais annoncé il y a quelques semaines sur la liste, je suis en train de faire un site web de partage d'itinéraires. L'idée du site, c'est qu'on trace un itinéraire sur un fond de carte osm, et ensuite, ça permet d'avoir un lien direct vers le tracé. Ça permet par exemple de montrer des trajets rando, des trajets vélo malin, ... Qu'est-ce que vous en pensez, est-ce qu'il y a des choses à améliorer, des bugs ? est-ce que vous pensez que vous allez l'utiliser ? ou pas ? et pourquoi ? — Avoir plusieurs couleurs pour distinguer les types de transports (voiture, train, bus, pied, vélo …) Je suis pas sûr que ce soit pertinent de choisir une couleur en fonction du type de transport. Il y aura toujours quelqun pour faire du multimodal avec son monocycle, ou un autre truc pas prévu. En plus, ça m'embête de rajouter des boutons pour demander le type de trajet, un de mes objectifs est de ne pas surcharger l'interface. — Avoir un historique d'annulation et pouvoir sélectionner un point pour le supprimer On peut supprimer un point en maintenant shift enfoncé. J'ai prévu de faire un faq pour le dire dedans. Est-ce que tu penses, — Fin du fin, avoir une petite fonction qui tente d'accoler la trace aux chemins Ce ne serait pas une petite fonction, mais plutôt un énorme boulot à réaliser. En plus, il y a deux soucis: - tous les chemins ne sont pas sur osm, et je veux qu'on puisse utiliser le site, même dans les endroits où osm n'est pas complet. - Suivant le moyen de transport utilisé, on peut vouloir accrocher, sur un même carrefour, soit la route, soit la piste cyclable, soit le souterrain piéton, soit la voie de tramway. Du coup, dans une zone dense, la fonctionnalité risque d'être plus pénible qu'autre chose. Si le projet est libre, je veux bien tâcher de coder moi-même ces fonctions. le code est là: http://dev.renevier.net/?p=syj.git;a=tree par contre, c'est pas forcément hyper simple à installer. a+ arno signature.asc Description: Digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( =?utf-8?q?pr=C3=A9visualisations?= )
Le mercredi 28 juillet 2010, à 08:46:14 +0200, Nicolas a écrit : Il est loin d'être fini, mais il est suffisamment avancé pour que je vous le présente et que vous me disiez ce que vous en pensez. En le présentant dés maintenant, si vous avez des idées de choses à améliorer, à changer etc, ça sera plus facile pour moi que si j'attends qu'il soit fini ! Bon déjà, je ne sais pas quelles technos tu utilises, mais ce serait bien que ce soit un poil modulaire. Car en fait gérer des traces c'est bien, mais on peut aussi gérer des POI, des objets géolocalisés (photos), toussa … Donc si c'est bien conçu à la base, et vu que ça a l'air déjà pas trop mal foutu, ce serait bien de pouvoir l'étendre facilement. pourquoi pas, je n'y avais pas pensé, mais ça fait deux fois qu'on me le propose. signature.asc Description: Digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel
8. Une rue à sens unique dispose d'une bande cyclable en sens contraire à ses extrémités, sur 10m, puis de marquages répétés au sol, chevrons+sigle cycliste, sur le reste de la rue. Je mappe : pour les extremites sur 10 m : [cycleway]=lane sur le way qui represente la bande cyclable en question, le sens du way indique le sens de circulation pour le reste : [bicycle]=opposite Ce qui est important dans ce cas là c'est que la rue est ouverte en double sens pour les velos. un cycleway=opposite_lane suffit largement Vu que le marquage répété au sol matérialise la bande sans qu'il y ai une bande. De même (pour une autre question du quizz) un cycleway:left=track n'a pas de sens je trouve. Si c'est une track elle merite une way, c'est une voie de circulation a part entière qui a sa propre vie. -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fusionner des ways redondants resultants d'imports successifs
Le 23 juil. 2010 à 17:46, jul...@krilin.org a écrit : il y a des orthophotos de bonne qualité pour le littorale. http://wiki.openstreetmap.org/wiki/WikiProject_France/G%C3%A9oLittoral Super, merci pour ce lien ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel
Julien Balas a écrit : 8. Une rue à sens unique dispose d'une bande cyclable en sens contraire à ses extrémités, sur 10m, puis de marquages répétés au sol, chevrons+sigle cycliste, sur le reste de la rue. Je mappe : pour les extremites sur 10 m : [cycleway]=lane sur le way qui represente la bande cyclable en question, le sens du way indique le sens de circulation pour le reste : [bicycle]=opposite Ce qui est important dans ce cas là c'est que la rue est ouverte en double sens pour les velos. un cycleway=opposite_lane suffit largement Vu que le marquage répété au sol matérialise la bande sans qu'il y ai une bande. Faux. On ne doit pas pas mettre de LANE / OPPOSITE_LANE s'il n'y a pas de bande expressément. C'est induire l'utilisateur en erreur sur un point de sécurité. Comme il n'y a pas de ligne séparatrice, les véhicules peuvent largement empiéter sur ce pseudo couloir de vélo. Il faut donc mettre cycleway=opposite De même (pour une autre question du quizz) un cycleway:left=track n'a pas de sens je trouve. Si c'est une track elle merite une way, c'est une voie de circulation a part entière qui a sa propre vie. -- JB ___ 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] qualitystreetmap.org is back ! (was: Re: 888 Mo (taille de l'extrait france.osm.bz2))
Merci pour cet outil dont je compte bien me servir. Mes suggestions: - Faire basculer le bouton Réserver en bouton Libérer pour éviter de rajouter l'entrée Dé-réserver. Et vice-versa. - Rajouter une propriété OSBClean synchronisé sur OpenStreetBugs si un ticket est encore ouvert dans la zone. La propriété OSBClean affichant true/false (non modifiable), et permettant uniquement l'action Rafraîchir. J'imagine aussi une synchronisation avec KeepRight et Osmose (enfin pour la France). L'inconvénient, c'est que ça rend l'outil dépendant d'autres outils externes. Pour éviter ça, on peut imaginer une simple option +/- pour ajouter ses propres propriétés en true/false. - Rajouter une aide pour expliquer le fonctionnement du site et les subtilités (par exemple, réserver une zone empêche-t-il définitivement quiconque de la modifier, gestion du facteur temps). - Rajouter un champ Notes par zone pour commentaires divers (limité en caractères) - Rajouter la date de dernière modification (avec une propriété supplémentaire?). Modifier les champs true en true? (old) après 2 ans sans modif. - Rajouter un champ Identifiant (pseudo/email) afin de savoir qui a réservé une zone. Affiché sur la zone survolée par exemple. - Une coloration progressive des zones serait effectivement la bienvenue comme ça a déjà été évoqué. - Pouvoir appliquer une même propriété à l'ensemble des zones sélectionnées - Pouvoir sélectionner plusieurs zones contiguës à l'aide d'un cadre à la souris (avec Ctrl par exemple). Bon courage A+ -- Guillaume ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel
Le 28 juillet 2010 10:43, Lapinos03 lapino...@free.fr a écrit : Julien Balas a écrit : 8. Une rue à sens unique dispose d'une bande cyclable en sens contraire à ses extrémités, sur 10m, puis de marquages répétés au sol, chevrons+sigle cycliste, sur le reste de la rue. Je mappe : pour les extremites sur 10 m : [cycleway]=lane sur le way qui represente la bande cyclable en question, le sens du way indique le sens de circulation pour le reste : [bicycle]=opposite Ce qui est important dans ce cas là c'est que la rue est ouverte en double sens pour les velos. un cycleway=opposite_lane suffit largement Vu que le marquage répété au sol matérialise la bande sans qu'il y ai une bande. Faux. On ne doit pas pas mettre de LANE / OPPOSITE_LANE s'il n'y a pas de bande expressément. C'est induire l'utilisateur en erreur sur un point de sécurité. Il n'y a pas de pb de securité : bande ou pas bande on n'écrase pas un vélo. Comme il n'y a pas de ligne séparatrice, les véhicules peuvent largement empiéter sur ce pseudo couloir de vélo. Il faut donc mettre cycleway=opposite sur un cas comme ca http://avignonavelo.free.fr/public/images/contre-sens/2sc-poste328.jpg moi je taggerais opposite_lane tous le long, même si les 5-6 premiers metres de la rue n'ont pas de bande matezrialisé. si il y a un bout de bande a chaque intersection on ne vas pas passer de l'opposite à l'opposite_lane tous les 10m ... -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le mercredi 28 juillet 2010, Julien Balas a écrit : Il n'y a pas de pb de securité : bande ou pas bande on n'écrase pas un vélo. Il y a un problème de sécurité, et de toute façon peu importe : si c'est une bande, on la marque comme telle, si c'est juste un marquage sans bande un le marque comme tel. Si l'utilisateur veut considérer ça comme une bande, c'est son problème, mais ce n'est pas au cartographe de prendre cette décision. -- Tanguy Ortolo signature.asc Description: Digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)
Le mercredi 28 juillet 2010 à 09:29 +0200, arno a écrit : — Avoir un historique d'annulation et pouvoir sélectionner un point pour le supprimer On peut supprimer un point en maintenant shift enfoncé. J'ai prévu de faire un faq pour le dire dedans. Est-ce que tu penses, La phrase n'est pas finie, mais ça correspond à ce que je proposais — Fin du fin, avoir une petite fonction qui tente d'accoler la trace aux chemins Ce ne serait pas une petite fonction, mais plutôt un énorme boulot à réaliser. En plus, il y a deux soucis: - tous les chemins ne sont pas sur osm, et je veux qu'on puisse utiliser le site, même dans les endroits où osm n'est pas complet. Je me doute que c'est du travail. Énorme je ne sais pas, c'est pas mortel à coder. Par contre il est possible que ce soit mortel en puissance de calcul. L'algo en gros irait d'un point A à B. Il trouve les ways dont un nœud passe par A (avec une petite tolérence) et parmi ces nœuds, il regarde ceux qui passent par B. Si oui, on prend tous les nœuds compris entre A et B et on les ajoute au chemin que tu traces. - Suivant le moyen de transport utilisé, on peut vouloir accrocher, sur un même carrefour, soit la route, soit la piste cyclable, soit le souterrain piéton, soit la voie de tramway. Du coup, dans une zone dense, la fonctionnalité risque d'être plus pénible qu'autre chose. Si le projet est libre, je veux bien tâcher de coder moi-même ces fonctions. le code est là: http://dev.renevier.net/?p=syj.git;a=tree par contre, c'est pas forcément hyper simple à installer. Super, je m'y mets cet après-midi Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)
2010/7/28 arno a...@renevier.net: — Fin du fin, avoir une petite fonction qui tente d'accoler la trace aux chemins Ce ne serait pas une petite fonction, mais plutôt un énorme boulot à réaliser. Pas forcément ... Il suffirait de surveiller les moments de pause de la souris (controle OL GetFeature en mode 'hover'), lancer une requête à la xapi (pour ne pas avoir la base en local) avec en argument une petite bbox autour de la souris, afficher les objects vectoriels avec un style transparent (ou non), et utiliser le control de snapping d'openlayers (http://openlayers.org/dev/examples/snapping.html) pour s'y accrocher. Sinon, bravo pour ce qui a déjà été réalisé ! J'ai juste eu des soucis pour enregistrer ma trace après premiere inscription, parce que je n'avais pas encore recu le mail de confirmation et activé mon compte (ce qui est gênant). Je rejoins donc les avis qui demandent une ouverture du site aux anonymes (philosophie open à la doodle, ietherpad, et autres...). F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)
Le mercredi 28 juillet 2010, à 11:55:42 +0200, François a écrit : 2010/7/28 arno a...@renevier.net: — Fin du fin, avoir une petite fonction qui tente d'accoler la trace aux chemins Ce ne serait pas une petite fonction, mais plutôt un énorme boulot à réaliser. Pas forcément ... Il suffirait de surveiller les moments de pause de la souris (controle OL GetFeature en mode 'hover'), lancer une requête à la xapi (pour ne pas avoir la base en local) avec en argument une petite bbox autour de la souris, afficher les objects vectoriels avec un style transparent (ou non), et utiliser le control de snapping d'openlayers (http://openlayers.org/dev/examples/snapping.html) pour s'y accrocher. Effectivement, je n'avais pas pensé à ça. Mais je sais pas si lancer plein de requêtes à la xapi est une bonne idée. De toutes manières, la fonctionalité d'accrochage, ça peut améliorer l'ergonomie dans certains cas, mais ça peut aussi la détériorer dans d'autres. Et justement, je veux pas la détériorer dans ces cas là. Par contre, si effectivement, tout peut être fait en javascript côté client, la solution passe peut-être par un script greasemonkey ou qqc d'équivalent. Sinon, bravo pour ce qui a déjà été réalisé ! J'ai juste eu des soucis pour enregistrer ma trace après premiere inscription, parce que je n'avais pas encore recu le mail de confirmation et activé mon compte (ce qui est gênant). C'est étrange, j'ai fait en sorte qu'on puisse enregistrer les trajets avant de confirmer l'inscription. On a 7 jours pour le faire avant que le compte ne soit détruit. Quels soucis a tu rencontré ? Je rejoins donc les avis qui demandent une ouverture du site aux anonymes (philosophie open à la doodle, ietherpad, et autres...). Je vais sérieusement y réfléchir. Je viens de penser à un nouveau souci avec cette démarche d'ailleurs: sous quelle licence va se retrouver du contenu créé par des anonymes ? Est-ce qu'on peut mettre du contenu sous licence cc ou sous domaine public de manière anonyme ? a+ arno signature.asc Description: Digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqû re de rappel
Je rajouterais les M3 : Le tag oneway:bicycle=no m’indiquent explicitement que les cyclistes circulent dans les deux sens. Or sur les schémas ce n’est pas le cas. Pourtant, si ! Trafic normal (incluant les vélos) + trafic vélo opposé. La différence entre les 2 propositions, c'est que la 1ere décrit une configuration physique, la 2e un schéma de circulation. La 1ere induit naturellement la 2e, mais pour l'inverse, il faut cogiter un peu. Oui, je remarque surtout que le cas M3b donne tort à tout le monde, pour la configuration des voies en sens oneway=yes du moins. D'abord, on peut s'intéresser au tag recommandé. La voie est en sens unique, et la bande de contresens cyclable est à droite, or il est recommandé de noter simplement cycleway=opposite_lane, sans préciser :right. Comme quoi il n'est peut-être pas complètement abracadabrantesque de préférer décrire simplement un schéma de circulation plutôt qu'une configuration physique complexe. D'ailleurs, si la configuration physique précise est vraiment si importante, je suis curieux de savoir si quelqu'un est capable de taguer la configuration de B1 (et particulièrement l'emplacement de la bande cyclable dans le sens du way) ou de B2 (et particulièrement l'emplacement de la bande bus), sans que les tags mobilisés soient en contradiction avec d'autres usages recommandés de ces mêmes tags, et sans tracer 4 ou 5 ways indépendants (ce qui serait tricher). Ensuite, si on s'intéresse au tag non recommandé, mais reconnu valide, on s'aperçoit que cette bande de contresens cyclable placée à droite, peut être décrite avec oneway=yes + cycleway:right=lane + oneway:bicycle=yes. Ce dont on peut déduire que, pour les sens uniques en tout cas, le sens de circulation des vélos n'est pas donné forcément par les suffixes :right/:left (puisque là on est en cycleway:right et que pourtant on ne roule pas dans le sens du way), ni non plus par les valeurs lane/opposite_lane (puisque là on est en lane et que pourtant on ne roule pas dans le sens du way), ni non plus par le sens de circulation des voitures (on a mis lane alors qu'on est en contresens). Dans les sens uniques, ce qui donne le sens de circulation des vélos en dernière instance, apparement, c'est le tag oneway:bicycle=no/yes. Ca c'est réglé. Reste un problème quand même : c'est que ce tag n'est pas utilisable dans les voies à double sens de circulation voiture. Du coup, encore cette question pénible : qu'est-ce qui définit le sens de circulation des vélos (ou des bus) dans les voies à double sens ? Il faut choisir : Est-ce que ce sont les suffixes :right/:left qui donnent le sens de circulation implicite (ce qui est la tendance de la page http://wiki.openstreetmap.org/wiki/Bicycle), mais alors on doit se contenter de décrire un schéma de circulation plutôt qu'une configuration précise de la voirie ? ou bien Est-ce que ce sont les valeurs lane/opposite_lane qui peuvent seules définir le sens de circulation des vélos en fonction du tracé du way (ce qui est en contradiction avec la tendance de la page http://wiki.openstreetmap.org/wiki/Bicycle, et particulièrement avec B3, mais en accord avec ce qui semble être indiqué dans l'exemple de la page http://wiki.openstreetmap.org/wiki/Proposed_features/right_left), mais alors on est bien embété pour taguer la configuration précise de B1 et B2 de la page http://wiki.openstreetmap.org/wiki/Bicycle ? Qu'est-ce qu'on choisit ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophoto du Doubs
Quelqu'un sur cette liste aurait un contact avec le CG du Doubs, afin de leur présenter l'intérêt d'ouvrir les usages de leur orthophoto ? La photo aérienne du département du Doubs est visible ici : http://sigd.doubs.fr/mapguide2010/mapviewerajax/?WEBLAYOUT=Library%3a%2f%2fApplication+Fonciere%2fCadastre_INTERNET.WebLayoutLOCALE=frUSERNAME=Anonymous Il suffit de zoomer assez pour voir apparaître dans la catégorie Fonds de plan (à gauche en bas) le calque Photos aériennes 2007. Le lien est accessible depuis la page SIG du site du CG du Doubs : http://www.doubs.fr/v3/index.php?option=com_contenttask=viewid=163Itemid=32 Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel
2010/7/28 jos sinet josi...@hotmail.fr Qu'est-ce qu'on choisit ? Wow, 24 heures sans lire la liste et voila 74 messages sur ce fil... Il y a tellement de choses que je ne sais pas par quoi commencer. Mais peut-être juste quelques remarques: - opposite_xxx, c'est par rapport au sens de circulation des voitures et ne s'applique qu'aux sens uniques. Il n'y a aucun consensus pour l'appliquer à d'autres cas. - il y a déjà eu des discussions pour voir comment tagguer des voies complexes avec notamment couloirs de bus/taxi. J'ai vu passé une proposition sur une liste interminable de tags avec numérotation des pistes mais cela n'a pas eu un franc succès. Il n'y a donc aucun consensus sur ces cas de figures (je pense en particulier à la question posée sur la double voie de bus centrale). Par contre, certains pensent (dont une certaine personne que je ne nommerais pas qui monopolise la liste osm-talk) que la seule issue est de tracer chaque piste avec son propre way (ou même polygone), levant ainsi toute ambiguïté sur leur topographie. Mais là encore, comme la demande est faible, il y a eu peu de réactions (il faut aussi dire que cela fait exploser le temps nécessaire au tracé et qu'il faut une source de très haute qualité, genre photos aériennes, comme seuls les australiens en disposent). Il y a par contre un consensus sur le fait de tracer séparément les voies lorsqu'il y a une séparation physique, même minime comme sur Paris où un certain nombre de couloirs de bus sont présents dans OSM. S'il y a deux couloirs de bus au milieu de la route, on pourrait légitimement se demander si cela ne vaudrait pas la peine de tracer des ways séparés (un pour les bus et un pour chaque sens de circulation des voitures) même si physiquement il resterait possible de franchir le milieu (et de toute façon, ces cas ne se rencontrent que pour de larges avenues, donc il y a la place pour tracer et pour afficher). Quelqu'un l'a bien fait pour les Champs-Élysées bien que théoriquement, on pourrait en discuter (mais cela a aussi l'avantage d'éviter de créer de nombreuses relations turning_restriction). - la page Bicycle recommande clairement dans T1 et T2 qu'un track soit tracé dans un way séparé. Il y a un consensus assez fort pour cela, le tag cycleway=track n'ayant été proposé que comme pis-aller pour ceux qui ont des traces GPS de la route et non de la piste. Ceux qui se posent la question de vouloir tagguer avec précision ces pistes doivent se demander pourquoi ils ne les tracent pas séparément de la route. Ceci pour éviter justement les discusions que l'on voit avec le quiz 2b. ou 2c. - on cite plusieurs fois la page du wiki right_left mais je ne vois pas ce qui contredit les exemples sur Bicycle. J'ai dû raté un truc. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophoto du Doubs
2010/7/28 Damouns damo...@gmail.com: Quelqu'un sur cette liste aurait un contact avec le CG du Doubs, afin de leur présenter l'intérêt d'ouvrir les usages de leur orthophoto ? La photo aérienne du département du Doubs est visible ici : http://sigd.doubs.fr/mapguide2010/mapviewerajax/?WEBLAYOUT=Library%3a%2f%2fApplication+Fonciere%2fCadastre_INTERNET.WebLayoutLOCALE=frUSERNAME=Anonymous Il suffit de zoomer assez pour voir apparaître dans la catégorie Fonds de plan (à gauche en bas) le calque Photos aériennes 2007. Le lien est accessible depuis la page SIG du site du CG du Doubs : http://www.doubs.fr/v3/index.php?option=com_contenttask=viewid=163Itemid=32 Merci, je leur ai laissé un message via l'interface dédiée. F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)
2010/7/28 arno a...@renevier.net: Sinon, bravo pour ce qui a déjà été réalisé ! J'ai juste eu des soucis pour enregistrer ma trace après premiere inscription, parce que je n'avais pas encore recu le mail de confirmation et activé mon compte (ce qui est gênant). C'est étrange, j'ai fait en sorte qu'on puisse enregistrer les trajets avant de confirmer l'inscription. On a 7 jours pour le faire avant que le compte ne soit détruit. Quels soucis a tu rencontré ? Trace pas enregistrable. Je rejoins donc les avis qui demandent une ouverture du site aux anonymes (philosophie open à la doodle, ietherpad, et autres...). Je vais sérieusement y réfléchir. Je viens de penser à un nouveau souci avec cette démarche d'ailleurs: sous quelle licence va se retrouver du contenu créé par des anonymes ? Est-ce qu'on peut mettre du contenu sous licence cc ou sous domaine public de manière anonyme ? Il suffit de mettre un disclaimer au moment de sauver la trace : vous acceptez de publier cette trace sous licence XX au profit de syj F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)
Le mercredi 28 juillet 2010, à 14:18:57 +0200, François a écrit : C'est étrange, j'ai fait en sorte qu'on puisse enregistrer les trajets avant de confirmer l'inscription. On a 7 jours pour le faire avant que le compte ne soit détruit. Quels soucis a tu rencontré ? Trace pas enregistrable. ok, je regarderais. Il suffit de mettre un disclaimer au moment de sauver la trace : vous acceptez de publier cette trace sous licence XX au profit de syj le souci c'est évidemment de remplir le XX. Sous quelle licence/status, on peut mettre des données tout en restant anonyme ? signature.asc Description: Digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj: partage d'itinéraires ( prévisualisations)
2010/7/28 arno a...@renevier.net: Il suffit de mettre un disclaimer au moment de sauver la trace : vous acceptez de publier cette trace sous licence XX au profit de syj le souci c'est évidemment de remplir le XX. Sous quelle licence/status, on peut mettre des données tout en restant anonyme ? Tu peux mettre ce que tu veux, en endossant la propriété de la trace. il me semble que le droit français retient un droit moral au créateur, mais celui-ci étant inconnu ... F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel
Julien Balas a écrit : sur un cas comme ca http://avignonavelo.free.fr/public/images/contre-sens/2sc-poste328.jpg moi je taggerais opposite_lane tous le long, même si les 5-6 premiers metres de la rue n'ont pas de bande matezrialisé. Sur cette photo, c'est sans conteste cycleway=OPPOSITE ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
je dirais plutot cycleway=jyvepa - Mail d'origine - De: Lapinos03 lapino...@free.fr À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Wed, 28 Jul 2010 16:29:05 +0200 (CEST) Objet: Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel Julien Balas a écrit : sur un cas comme ca http://avignonavelo.free.fr/public/images/contre-sens/2sc-poste328.jpg moi je taggerais opposite_lane tous le long, même si les 5-6 premiers metres de la rue n'ont pas de bande matezrialisé. Sur cette photo, c'est sans conteste cycleway=OPPOSITE ___ 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] Suffixes :left/:right - piqûre de rappel
Le mercredi 28 juillet 2010 à 14:03 +0200, Pieren a écrit : 2010/7/28 jos sinet josi...@hotmail.fr Qu'est-ce qu'on choisit ? - on cite plusieurs fois la page du wiki right_left mais je ne vois pas ce qui contredit les exemples sur Bicycle. J'ai dû raté un truc. Je vient de comprendre la mauvaise compréhension de la page http://wiki.openstreetmap.org/wiki/Proposed_features/right_left c'est le tag sous la photo de l'exemple pour la clef :left qui n'est pas cohérent avec la photo. ces tags ne s'appliquent uniquement pour dire que le tag que l'on décrit est sur la partie gauche ou droit de la rue. Le coté gauche ou droit est défini a partir du sens du way. Ensuite on utilise la description courante du tag, le sens du way n'a plus rien a voir. Dans l'exemple avec le nom de rue, tous le monde comprend que cela s'applique sur le coté gauche dans les deux sens de circulation et non uniquement dans le sens du way car on utilise la dénomination courante du nom de rue qui ne tient pas compte des sens de circulation. Pour le cas des bandes cyclable c'est la même chose le tag left right indique le coté ou se trouve la piste par rapport au sens du tracé, ensuite le cycleway=* en fonction du sens de circulation sur ce coté de la route. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreet Map
Bonjour, Le Centre Régional Auvergnat de l'Information Géographique (http://www.craig.fr) est une structure publique ayant pour but de mutualiser l'information géographique entre les différents acteurs publics de la région Auvergne. Dans le cadre de son programme d'acquisition de données, le CRAIG a fait réaliser courant 2009 une orthophotographie à 30cm sur les départements de l'Allier et du Puy de Dôme et à 15cm sur les agglomérations (étendues) de Vichy, Moulins et Montluçon. Une seconde prise de vue est programmée cette année pour couvrir les départements Cantal et la Haute Loire à 30cm, ainsi que l'agglomération du Puy-en-Velay à 15cm. Cette orthophotographie est consultable (entre autres) à l'adresse suivante : http://carto.craig.fr. Cette visionneuse est basée sur les outils libres mapfish et mapserver. Cette donnée étant la propriété du CRAIG, et ayant vocation à être largement diffusée/rendue publique (cf. Directive européenne INSPIRE), nous nous proposons de la mettre à disposition des contributeurs d'OpenStreetMap pour enrichir la base de données (autant sous licence ODBL que CC-BY-SA). En espérant que ca montre la voie pour les autres... Un flux WMS est donc disponible pour l'utilisation dans les outils d'édition OSM (josm, merkaartor..) ici : http://wms.craig.fr/osm 4 couches sont disponibles: - departements : Allier/Puy de Dôme à 30cm (~16000 km²) - Montluçon : agglomération de Montluçon à 15cm (~180 km²) - Moulins : agglomération de moulins à 15cm (~760 km²) - Vichy : agglomération de Vichy à 15cm (~ 330 km²) Des tests avec josm ont montré qu'il n'y avait pas de problème pour afficher ce WMS en fond, avec Merkaartor il est conseillé d'utiliser EPSG:2154 (projection native Lambert 93), les autres projections ne renvoyant que des images vides (d'ailleurs, si quelqu'un veut bien nous aider sur ce point.. surement un détail dans la configuration de mapserver, merkaartor fait des requêtes avec une BBOX invalide) Si vous utilisez ce service pour ajouter des objets à la base, merci de penser à utiliser le tag source='Orthophotographie CRAIG/TopoGEODIS 2009'.. Et si quelqu'un se sent de remplir une page/compléter Potential_Datasources#france sur le wiki, il est le bienvenu :) N'hésitez pas à nous envoyer un mail (geomatique at craig dot fr) pour toute question/information, et bon mapping ! Pour le CRAIG, Landry BREUIL ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreetMap
Le 28/07/2010 17:52, Landry Breuil a écrit : Un flux WMS est donc disponible pour l'utilisation dans les outils d'édition OSM (josm, merkaartor..) ici : http://wms.craig.fr/osm 4 couches sont disponibles: - departements : Allier/Puy de Dôme à 30cm (~16000 km²) - Montluçon : agglomération de Montluçon à 15cm (~180 km²) - Moulins : agglomération de moulins à 15cm (~760 km²) - Vichy : agglomération de Vichy à 15cm (~ 330 km²) Youhou ! Il y a plein de départements par encore numérisés par le cadastre dans l'Allier. C'est trop bien. Euh, ah non, j'ai une thèse à rédiger :( Bravo et merci. Je testerai un de ces 4. -- Yoann. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreetMap
Landry Breuil a écrit : Bonjour, Le Centre Régional Auvergnat de l'Information Géographique (http://www.craig.fr) est une structure publique ayant pour but de mutualiser l'information géographique entre les différents acteurs publics de la région Auvergne. Dans le cadre de son programme d'acquisition de données, le CRAIG a fait réaliser courant 2009 une orthophotographie à 30cm sur les départements de l'Allier et du Puy de Dôme et à 15cm sur les agglomérations (étendues) de Vichy, Moulins et Montluçon. Une seconde prise de vue est programmée cette année pour couvrir les départements Cantal et la Haute Loire à 30cm, ainsi que l'agglomération du Puy-en-Velay à 15cm. Cette orthophotographie est consultable (entre autres) à l'adresse suivante : http://carto.craig.fr. Cette visionneuse est basée sur les outils libres mapfish et mapserver. Cette donnée étant la propriété du CRAIG, et ayant vocation à être largement diffusée/rendue publique (cf. Directive européenne INSPIRE), nous nous proposons de la mettre à disposition des contributeurs d'OpenStreetMap pour enrichir la base de données (autant sous licence ODBL que CC-BY-SA). En espérant que ca montre la voie pour les autres... Un flux WMS est donc disponible pour l'utilisation dans les outils d'édition OSM (josm, merkaartor..) ici : http://wms.craig.fr/osm 4 couches sont disponibles: - departements : Allier/Puy de Dôme à 30cm (~16000 km²) - Montluçon : agglomération de Montluçon à 15cm (~180 km²) - Moulins : agglomération de moulins à 15cm (~760 km²) - Vichy : agglomération de Vichy à 15cm (~ 330 km²) Des tests avec josm ont montré qu'il n'y avait pas de problème pour afficher ce WMS en fond, avec Merkaartor il est conseillé d'utiliser EPSG:2154 (projection native Lambert 93), les autres projections ne renvoyant que des images vides (d'ailleurs, si quelqu'un veut bien nous aider sur ce point.. surement un détail dans la configuration de mapserver, merkaartor fait des requêtes avec une BBOX invalide) Si vous utilisez ce service pour ajouter des objets à la base, merci de penser à utiliser le tag source='Orthophotographie CRAIG/TopoGEODIS 2009'.. Et si quelqu'un se sent de remplir une page/compléter Potential_Datasources#france sur le wiki, il est le bienvenu :) N'hésitez pas à nous envoyer un mail (geomatique at craig dot fr) pour toute question/information, et bon mapping ! merci beaucoup pour l'ouerture d'esprit dont vous faites preuve, c'est pas tous les jours que la cooperation avec des institutionnels se passe aussi bien je suis un peu etonne que clermont (et pourquoi pas aurillac) ne figure pas dans la liste des zones couvertes a 15 cm mais c'est deja tres bien comme ca j'attends avec impatience la partie cantalouse de la photo ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nodes created_by almien_coastlines
Salut ! Ca vous dit quelque chose ce genre de nodes ? http://www.openstreetmap.org/browse/node/28282144 Il y en a plusieurs, mais ils ne semblent pas servir à grand chose. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le mercredi 28 juillet 2010 12:20:19, jos sinet a écrit : Je rajouterais les M3 : Le tag oneway:bicycle=no m’indiquent explicitement que les cyclistes circulent dans les deux sens. Or sur les schémas ce n’est pas le cas. Pourtant, si ! Trafic normal (incluant les vélos) + trafic vélo opposé. La différence entre les 2 propositions, c'est que la 1ere décrit une configuration physique, la 2e un schéma de circulation. La 1ere induit naturellement la 2e, mais pour l'inverse, il faut cogiter un peu. Oui, je remarque surtout que le cas M3b donne tort à tout le monde, pour la configuration des voies en sens oneway=yes du moins. +1 ! D'abord, on peut s'intéresser au tag recommandé. La voie est en sens unique, et la bande de contresens cyclable est à droite, or il est recommandé de noter simplement cycleway=opposite_lane, sans préciser :right. Comme quoi il n'est peut-être pas complètement abracadabrantesque de préférer décrire simplement un schéma de circulation plutôt qu'une configuration physique complexe. D'ailleurs, si la configuration physique précise est vraiment si importante, je suis curieux de savoir si quelqu'un est capable de taguer la configuration de B1 (et particulièrement l'emplacement de la bande cyclable dans le sens du way) ou de B2 (et particulièrement l'emplacement de la bande bus), sans que les tags mobilisés soient en contradiction avec d'autres usages recommandés de ces mêmes tags, et sans tracer 4 ou 5 ways indépendants (ce qui serait tricher). Au risque de me répéter… (désolé pour ceux qui avaient déjà compris) Si on modélise tous les *way comme les highway et il n’y plus aucune ambiguïté. Avec le modèle des highway, que tout le monde connaît bien et utilise bien, personne ne se torture l’esprit à calculer le sens des voies c’est décrit. Je propose qu’on pense sérieusement à utiliser une méthode générique à tous les *way ! Avec les highway : — highway=primary, secondary, tertiary (le type de la voie pour voiture suivant le tracé) — oneway=-1, 0, 1, no, yes (le sens de circulation par rapport au tracé, double sens si non précisé) — lanes=n (le nombre de « voies » parallèles lesquelles on peut passer des unes aux autres sans changer de sens de circulation ni chevaucher une autre voie) Avec les xxxway ⇒ highway, cycleway, busway, footway, tramway, airway (soyons fous), etc. — xxxway=* (le type de voie suivant le tracé) — oneway:xxx=-1, 0, 1 no, yes (le sens de circulation par rapport au tracé, double sens si non précisé), cette notation n’est pas très sexy, j’en conviens, on aurait pu utiliser xxxway:oneway=* — lanes:xxx=n (le nombre de voies parallèles lesquelles on peut passer des unes aux autres sans changer de sens de circulation ni chevaucher une autre voie) — xxxway:placement=* (placement des voies par rapport au tracé) ; :left, :right, :center, :left:2, :left:3, :right:2, :right:3, etc. Avec cette méthode, le sens de chaque voie est simple à modéliser, on peut même avoir des rues sans voiture et avoir un sens de circulation !! (Exploit) Avec cette méthode, on peut modéliser sans équivoque tous les cas de figure de la page wiki:Bicycle. (Exercice : prenez les tags des situations du wiki:Bicycle et essayez de retrouver le dessin à gauche, sans le regarder évidemment) Avec le modèle des xxxway, on peut même modéliser des extras : — C1 : (c : cycliste ; v : voiture ; b : bus) |↓:↑| ↓ : ↑ | ↓ : ↑ | |c:c| v : v | b : b | highway=* ; cycleway:left=lane ; busway:right=lane — C2 : | ↓ : ↑ |↓:↑| ↓ : ↑ | | v : v |c:c| b : b | highway=* ; cycleway:right=lane ; busway:right:2=lane — C3 (plus costaud, mais se rencontre) : | ↓ : ↓ |↑| ↑ | ↑ | | v : v |c| v | b | highway=* ; lanes:left=2 ; cycleway:center=lane ; oneway:bicycle=1 ; busway:right=lane ; oneway:bus=1 — C4 (se rencontre régulièrement à Poitiers) : |↓| ↑ | ↑ |↑| |c| v | b |c| highway=* ; oneway=1 ; cycleway:left=opposite_lane ; cycleway:right:2=lane ; oneway:bicycle=1 ; busway:right=lane ; oneway:bus=1 — C5 (plus fort, sans les voitures !) : |↓|↑ ↑| |c|b c| busway=lane ; oneway:bus=1 ; cycleway:left=opposite_lane ; cycleway:right=share_busway ; oneway:bicycle=1 La modélisation est systématique et si une voie est changée les autres sont inchangées. Les tags et les valeurs se lisent sans calculer avec les autres voies et n’ont pas de définition cachée ou d’exception dans certaines situation. Je remarquerais aussi, que la tendance dans les villes est à la disparition des voitures, et que faire des modèles prenant pour base la circulation des voitures pour déduire les autres voies me paraît assez déplacé. Autre remarque, ce modèle n’est pas si éloigné de l’actuel, il entre rarement en conflit, et souvent même, lève les ambiguïtés. Évidemment, vous aurez
Re: [OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreet Map
J'ai rajouté l'info sur le wiki: http://wiki.openstreetmap.org/wiki/WikiProject_France/CRAIG -- Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreet Map
Bravo ! Et voici l'URL qui va bien dans JOSM: http://wms.craig.fr/osm?service=wmsrequest=getmapversion=1.1.1layers=departementsSRS=EPSG:4326format=image/jpeg; -- Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] video mapping
Ca ne doit pas étre compliqué: tu mets ton ordi dans ton sac à dos (ou cas où il pleuve!), tu branche une webcam sur bus USB, sur un autre bus USB tu branches un GPS (par ex un freerunner :)) et tu synchronise en post production via les données temporelles. Pour être certain d'avoir une bonne synchro de l'heure, tu installes un serveur NTP sur le PC et un client sur le freerunner. Le 27/07/2010 18:58, Ab_fab a écrit : Dans le même genre, j'ai vu ceci dans le numéro de juillet de Science et Vie http://www.gobandit.com/overview.html http://www.gobandit.com/tecspecs.html Le 26 juillet 2010 18:11, simonmsr...@gmail.com a écrit : Bonjour Une petite photo de mon vélo pour cartographier et faire des video de mon parcours :) Il ne reste plus qu'à un gentil développeur de faire un plu gin pour synchroniser la vidéo avec la trace GPS sur JOSM (maleureusement je n'ai pas les compétences requise) Librement Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreet Map
Merci à vous pour cette mise à disposition des orthophotos ! Je viens d'ajouter le WMS en overlay dans QualityStreetMap [http://goo.gl/61Tc], ce qui pourra s'avérer pratique pour coordonner le mapping sur la base de cette ortho. F. 2010/7/28 Landry Breuil landry.bre...@gmail.com: Bonjour, Le Centre Régional Auvergnat de l'Information Géographique (http://www.craig.fr) est une structure publique ayant pour but de mutualiser l'information géographique entre les différents acteurs publics de la région Auvergne. Dans le cadre de son programme d'acquisition de données, le CRAIG a fait réaliser courant 2009 une orthophotographie à 30cm sur les départements de l'Allier et du Puy de Dôme et à 15cm sur les agglomérations (étendues) de Vichy, Moulins et Montluçon. Une seconde prise de vue est programmée cette année pour couvrir les départements Cantal et la Haute Loire à 30cm, ainsi que l'agglomération du Puy-en-Velay à 15cm. Cette orthophotographie est consultable (entre autres) à l'adresse suivante : http://carto.craig.fr. Cette visionneuse est basée sur les outils libres mapfish et mapserver. Cette donnée étant la propriété du CRAIG, et ayant vocation à être largement diffusée/rendue publique (cf. Directive européenne INSPIRE), nous nous proposons de la mettre à disposition des contributeurs d'OpenStreetMap pour enrichir la base de données (autant sous licence ODBL que CC-BY-SA). En espérant que ca montre la voie pour les autres... Un flux WMS est donc disponible pour l'utilisation dans les outils d'édition OSM (josm, merkaartor..) ici : http://wms.craig.fr/osm 4 couches sont disponibles: - departements : Allier/Puy de Dôme à 30cm (~16000 km²) - Montluçon : agglomération de Montluçon à 15cm (~180 km²) - Moulins : agglomération de moulins à 15cm (~760 km²) - Vichy : agglomération de Vichy à 15cm (~ 330 km²) Des tests avec josm ont montré qu'il n'y avait pas de problème pour afficher ce WMS en fond, avec Merkaartor il est conseillé d'utiliser EPSG:2154 (projection native Lambert 93), les autres projections ne renvoyant que des images vides (d'ailleurs, si quelqu'un veut bien nous aider sur ce point.. surement un détail dans la configuration de mapserver, merkaartor fait des requêtes avec une BBOX invalide) Si vous utilisez ce service pour ajouter des objets à la base, merci de penser à utiliser le tag source='Orthophotographie CRAIG/TopoGEODIS 2009'.. Et si quelqu'un se sent de remplir une page/compléter Potential_Datasources#france sur le wiki, il est le bienvenu :) N'hésitez pas à nous envoyer un mail (geomatique at craig dot fr) pour toute question/information, et bon mapping ! Pour le CRAIG, Landry BREUIL ___ 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] qualitystreetmap.org is back ! (was: Re: 888 Mo (taille de l'extrait france.osm.bz2))
2010/7/28 Guillaume Audirac guillaume.audi...@gmail.com: Merci pour cet outil dont je compte bien me servir. Cool :-) Ca fait toujours plaisir quand ce qu'on fait est utilisé ... Mes suggestions: - Faire basculer le bouton Réserver en bouton Libérer pour éviter de rajouter l'entrée Dé-réserver. Et vice-versa. Oui, un collègue me l'avait dit aussi. Je viens de créer le ticket : http://code.google.com/p/osmqa/issues/detail?id=19 - Rajouter une propriété OSBClean synchronisé sur OpenStreetBugs si un ticket est encore ouvert dans la zone. La propriété OSBClean affichant true/false (non modifiable), et permettant uniquement l'action Rafraîchir. J'imagine aussi une synchronisation avec KeepRight et Osmose (enfin pour la France). Je n'ai pas encore étudié cette question de l'interfaçage avec d'autres outils... Cela suppose qu'ils disposent d'une API convenable pour y accéder. L'inconvénient, c'est que ça rend l'outil dépendant d'autres outils externes. Pour éviter ça, on peut imaginer une simple option +/- pour ajouter ses propres propriétés en true/false. Oui, il est prévu (dans un futur plus ou moins proche) de pouvoir définir des grilles avec des critères personnalisés. - Rajouter une aide pour expliquer le fonctionnement du site et les subtilités (par exemple, réserver une zone empêche-t-il définitivement quiconque de la modifier, gestion du facteur temps). Oui, j'avais pensé à un bandeau refermable en haut du site, ou une popup d'aide qui ne s'affiche que la première fois. http://code.google.com/p/osmqa/issues/detail?id=6 - Rajouter un champ Notes par zone pour commentaires divers (limité en caractères) OK : http://code.google.com/p/osmqa/issues/detail?id=20 - Rajouter la date de dernière modification (avec une propriété supplémentaire?). J'ai déjà le champ en base pour ça. Reste à l'afficher : http://code.google.com/p/osmqa/issues/detail?id=21 Modifier les champs true en true? (old) après 2 ans sans modif. Je prévois un cron pour faire ça, oui ... - Rajouter un champ Identifiant (pseudo/email) afin de savoir qui a réservé une zone. Affiché sur la zone survolée par exemple. Déjà référencé celui-là: http://code.google.com/p/osmqa/issues/detail?id=10 - Une coloration progressive des zones serait effectivement la bienvenue comme ça a déjà été évoqué. Ce qui suppose d'abandonner le champ binaire ... Je ne suis pas encore complètement convaincu : je veux rester simple. - Pouvoir appliquer une même propriété à l'ensemble des zones sélectionnées Oui, déjà référencé aussi : http://code.google.com/p/osmqa/issues/detail?id=18 - Pouvoir sélectionner plusieurs zones contiguës à l'aide d'un cadre à la souris (avec Ctrl par exemple). OK, merci pour toutes ces idées ! Il reste à trouver le temps ... F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Mise à disposition des ort hophotos sur l'Allier et le Puy de Dôme pour OpenStree tMap
De : hamster hams...@suna.fdn.fr Bonjour, Le Centre Régional Auvergnat de l'Information Géographique (http://www.craig.fr) est une structure publique ayant pour but de . N'hésitez pas à nous envoyer un mail (geomatique at craig dot fr) pour toute question/information, et bon mapping ! merci beaucoup pour l'ouverture d'esprit dont vous faites preuve, c'est pas tous les jours que la cooperation avec des institutionnels se passe aussi bien Un grand Merci egalement ! Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] qualitystreetmap.org is back !
François Van Der Biest a écrit : 2010/7/28 Guillaume Audirac guillaume.audi...@gmail.com: Merci pour cet outil dont je compte bien me servir. Cool :-) Ca fait toujours plaisir quand ce qu'on fait est utilisé ... C'est toujours utile quand des utilisateurs/développeurs comprennent la nécessité de chercher à promouvoir la qualité de notre travail. Je continue à me poser des questions sur la meilleure manière de rendre compte de l'avancée de la base et par uniquement sur un mode quantitatif et/ou binaire. On a le choix actuellement entre les annonces des journaux personnels, les pages spécialisées de suivi du wiki ou des outils comme qualitystreet. Le problème est qu'un contributeur, mais s'il n'est pas novice, n'ira pas sur tous ces outils en même temps ; il en privilégiera l'un ou l'autre en fonction de ses affinités/compétences, de la mode ... Bien sûr, on fourmille d'idées toutes aussi intéressantes et constructives les unes que les autres, mais, reconnaissons-le, nous avons aussi besoin de convergence en termes d'outils. C'est un challenge, c'est clair. ... OK, merci pour toutes ces idées ! Il reste à trouver le temps ... Entre le document LA PROBLEMATIQUE DE LA QUALITE DES DONNEES GEOGRAPHIQUES COLLABORATIVES, Cas d'OpenStreetMap, pistes de solutions produit par Gaiago (Serge Mang), les outils de contrôle osmosiens et autre openstreetbugs ou qualitystreetmap , la communauté OSM avance à pas de géant dans la gestion de son capital-qualité (eh oui, c'est le fameux caqua) ; nous faisons envie pour cela aussi. Nous nous sommes engagés sur une course de fond et donc il faudra gérer la résistance à l'effort. Denis, consommateur de chocolats fins ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreetMap
Landry Breuil a écrit : Bonjour, Le Centre Régional Auvergnat de l'Information Géographique (http://www.craig.fr) est une structure publique ayant pour but de mutualiser l'information géographique entre les différents acteurs publics de la région Auvergne. Dans le cadre de son programme d'acquisition de données, le CRAIG a fait réaliser courant 2009 une orthophotographie à 30cm sur les départements de l'Allier et du Puy de Dôme et à 15cm sur les agglomérations (étendues) de Vichy, Moulins et Montluçon. Une seconde prise de vue est programmée cette année pour couvrir les départements Cantal et la Haute Loire à 30cm, ainsi que l'agglomération du Puy-en-Velay à 15cm. ... N'hésitez pas à nous envoyer un mail (geomatique at craig dot fr) pour toute question/information, et bon mapping ! Bravo et merci à vous pour ce nouveau gisement d'informations (particulièrement utile en zone montagneuse). Avez-vous pensé à un communiqué sur georezo ? Je crois qu'il faut faire connaître ce genre d'initiative bien au-delà du cercle strict d'OSM (je sais que de grandes et sages oreilles nous écoutent et peuvent relayer l'info) Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Détection d'overlap sur les land uses
2010/7/28 Balooval val.p...@gmail.com Dans le même ordre d'idée que la détection des bâtiments se chevauchant, existe-t-il un outil qui révelerait les landuse qui se chevauchent? Je me pose cette question car suite à l'annonce de la mise à disposition des orthophotos sur l'Allier, j'ai jeté un oeil du côté de Moulin voir ce que ça donne, et j'y ai découvert des polygones Corine (essentiellement) se chevauchant, ainsi qu'avec des landuses fait à la main. J'ai trouvé cet enchevêtrement pas très propre, du coup je me demande si le cas est courant. Il n'y a pas d'outil mais il serait simple d'en créer un si besoin. Quand Corine a été importé automatiquement, un calcul de chevauchement a été effectué a partir d'une base de donnée Postgres/Postgis. Généralement les polygones qui se chevauchent sont des imports manuels. La question est ensuite de se poser de ce qu'on veut faire de ces chevauchements. Est ce qu'on les coupe pour enlever les chevauchements etc... ? La réponse a cela est bien plus compliquée a mes yeux que de trouver ce qui se chevauchent. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Détection d'overlap sur les land uses
Qu'est ce qu'on fait des chevauchement? Et bien on les affiche, et charge à la communauté de les corriger, comme pour les bâtiments :) L'objectif étant d'aller directement vers les landuses qui posent problème, plutôt que de les chercher, comme tout outil de tracking d'erreur. Je sais que l'import de Corine a été fait proprement, et apparemment là c'est des polygones modifiés après coup, voir non modifié mais qui chevauchent des polygone non Corine. Le 28 juillet 2010 23:50, Emilie Laffray emilie.laff...@gmail.com a écrit : 2010/7/28 Balooval val.p...@gmail.com Dans le même ordre d'idée que la détection des bâtiments se chevauchant, existe-t-il un outil qui révelerait les landuse qui se chevauchent? Je me pose cette question car suite à l'annonce de la mise à disposition des orthophotos sur l'Allier, j'ai jeté un oeil du côté de Moulin voir ce que ça donne, et j'y ai découvert des polygones Corine (essentiellement) se chevauchant, ainsi qu'avec des landuses fait à la main. J'ai trouvé cet enchevêtrement pas très propre, du coup je me demande si le cas est courant. Il n'y a pas d'outil mais il serait simple d'en créer un si besoin. Quand Corine a été importé automatiquement, un calcul de chevauchement a été effectué a partir d'une base de donnée Postgres/Postgis. Généralement les polygones qui se chevauchent sont des imports manuels. La question est ensuite de se poser de ce qu'on veut faire de ces chevauchements. Est ce qu'on les coupe pour enlever les chevauchements etc... ? La réponse a cela est bien plus compliquée a mes yeux que de trouver ce qui se chevauchent. Emilie Laffray ___ 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] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreetMap
internet c'est bien mais c'est assez vite lent, surtout avec les photos a 15 cm est-ce que quelqu'un sait si il y a moyen de telecharger une zone une fois pour toute et qu'ensuite josm affiche l'image a partir du disque et non pas en telechargeant et retelechargeant les tuiles a travers internet ? (c'est ce que fait deja le plugin cadastre d'ailleurs) j'ai un peu cherche un systeme de cache, mais j'ai rien trouve au mieux il y a la fonction enregistrer le calque wms comme un fichier mais ca fait une toute petite zone de photo (a moins d'avoir enormement de RAM), il faut commencer par parcourir toute la zone a fort grossissement pour qu'il charge les tuiles, et ensuite quand j'essaie de re-ouvrir le fichier en question il plante en plus d'etre plus rapide ca aurait l'avantage d'etre utilisable hors connection ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreetMap
Le 29/07/2010 à 02:52:25 +1100 Landry Breuil landry.bre...@gmail.com a écrit Objet: [OSM-talk-fr] Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour OpenStreetMap : Cette orthophotographie est consultable (entre autres) à l'adresse suivante : http://carto.craig.fr. Cette visionneuse est basée sur les outils libres mapfish et mapserver. Très bonne initiative! Par contre, sous WinXP avec Opera 10.60 Build 3445 j'ai un problème pour afficher la page. Opera plante et doit être redémarré, et cela en boucle. FireFox 3.6.6 marche bien. -- Cordialement Hendrik Oesterlin - Nouvelle-Calédonie ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre de rappel
2010/7/28 Mikaël Cordon mikael.cor...@gmail.com Avec le modèle des xxxway, on peut même modéliser des extras : — C1 : (c : cycliste ; v : voiture ; b : bus) |↓:↑| ↓ : ↑ | ↓ : ↑ | |c:c| v : v | b : b | highway=* ; cycleway:left=lane ; busway:right=lane Mais avec ce système, comment tu taggues une route: :c:v:v:c: et :c:v:v: ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt
Le 26/07/2010 11:52, Marc SIBERT a écrit : Bonjour, Voilà, j'ai envoyé le dernier lot de suppressions ce matin : http://www.openstreetmap.org/browse/changeset/5318380 Enfin, pour Osmose, il en reste encore : http://osmose.openstreetmap.fr/cgi-bin/all-update.py?source=64 A+ -- Marc Sibert m...@sibert.fr mailto:m...@sibert.fr Encore un petit 10k way de supprimés : http://www.openstreetmap.org/browse/changeset/5343124 Bon, je vais insisté, faut tuer le problème dans l'oeuf. Et pendant que j'y suis je suggère un coup de râteau sur les noeuds orphelins. A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt
Marc Sibert a crit: Le 26/07/2010 11:52, Marc SIBERT a crit: Bonjour, Voil, j'ai envoy le dernier lot de suppressions ce matin : http://www.openstreetmap.org/browse/changeset/5318380 Enfin, pour Osmose, il en reste encore : http://osmose.openstreetmap.fr/cgi-bin/all-update.py?source=64 A+ -- Marc Sibert m...@sibert.fr Encore un petit 10k way de supprims : http://www.openstreetmap.org/browse/changeset/5343124 Bon, je vais insist, faut tuer le problme dans l'uf. Et pendant que j'y suis je suggre un coup de rteau sur les nuds orphelins. A+ -- Marc Sibert m...@sibert.fr Ok je lance le ratissage... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte ! Les doublons, ça grossi t sans arrêt
Benot ROUSSEAU a crit: Marc Sibert a crit: Le 26/07/2010 11:52, Marc SIBERT a crit: Bonjour, Voil, j'ai envoy le dernier lot de suppressions ce matin : http://www.openstreetmap.org/browse/changeset/5318380 Enfin, pour Osmose, il en reste encore : http://osmose.openstreetmap.fr/cgi-bin/all-update.py?source=64 A+ -- Marc Sibert m...@sibert.fr Encore un petit 10k way de supprims : http://www.openstreetmap.org/browse/changeset/5343124 Bon, je vais insist, faut tuer le problme dans l'uf. Et pendant que j'y suis je suggre un coup de rteau sur les nuds orphelins. A+ -- Marc Sibert m...@sibert.fr Ok je lance le ratissage... Le rteau demande aujourd'hui des capacits mmoire que je n'ai pas et qui sont indcentes. Je vais changer l'ago pour que a tourne dans des limites raisonnables. Nouveau ratissage au plus tard dimanche. Benot R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le jeudi 29 juillet 2010 02:13:39, Pieren a écrit : 2010/7/28 Mikaël Cordon mikael.cor...@gmail.com Avec le modèle des xxxway, on peut même modéliser des extras : — C1 : (c : cycliste ; v : voiture ; b : bus) |↓:↑| ↓ : ↑ | ↓ : ↑ | |c:c| v : v | b : b | highway=* ; cycleway:left=lane ; busway:right=lane Mais avec ce système, comment tu taggues une route: :c:v:v:c: highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ; oneway:bicycle=1 et :c:v:v: highway=* ; cycleway:left=opposite_lane ; oneway:bicycle=1 ou highway=* ; cycleway:left=lane ; oneway:bicycle=-1 (pour s’économiser quelques caractères) ? Pieren Cordialement, -- Mickey86 Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
