[OSM-talk-fr] source=inconnue
Je tombe de temps en temps sur un tag source=inconnue (dans la Drôme par exemple, sur certains tracés comme les fleuves et rivières). On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. Ce genre de tag est plus nuisible qu'autre chose, si la source n'est pas connue ou pas précisée, il vaut mieux ne rien mettre du tout. Il peut s'agir d'un oubli par son contributeur initial, mais alors il peut le voir et corriger lui-même ou bien on peut aller consulter une plance cadastrale ou une imagerie Bing pour aller vérifier et éventuellement affiner un tracé (s'il s'écarte trop de la réalité de sorte que le tracé d'une route, voie ferrée, ou rivière sort de sa surface réelle occupée (et peut entrer en conflit avec des éléments adjascents comme des polygones landuse=*, natural=*, building=*, et...). Bref le tag source=inconnue est à supprimer (et Osmose pourrait éventuellement vérifier cette valeur pour la marquer comme inutile et à supprimer, et malgré tout signaler un tracé comme étant sans source de référence). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Bonjour, De mon côté, il m'arrive parfois de mettre des tags source=unknown. La raison ? Le plugin cadastre qui ajoute automatiquement le tag source=cadastre à tous les noeuds/ways modifiés. Or parfois, il m'arrive de couper un way déjà présent en base sans notion de source, pour adapter une partie conformément au cadastre, l'autre partie du way restant inchangée. Mais pour le plugin, le way a changé (puisque coupé) et veut mettre son tag source. Ce que je contourne en mettant un tag source=unknown. Erik Le 6 mars 2013 09:44, Philippe Verdy verd...@wanadoo.fr a écrit : Je tombe de temps en temps sur un tag source=inconnue (dans la Drôme par exemple, sur certains tracés comme les fleuves et rivières). On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. Ce genre de tag est plus nuisible qu'autre chose, si la source n'est pas connue ou pas précisée, il vaut mieux ne rien mettre du tout. Il peut s'agir d'un oubli par son contributeur initial, mais alors il peut le voir et corriger lui-même ou bien on peut aller consulter une plance cadastrale ou une imagerie Bing pour aller vérifier et éventuellement affiner un tracé (s'il s'écarte trop de la réalité de sorte que le tracé d'une route, voie ferrée, ou rivière sort de sa surface réelle occupée (et peut entrer en conflit avec des éléments adjascents comme des polygones landuse=*, natural=*, building=*, et...). Bref le tag source=inconnue est à supprimer (et Osmose pourrait éventuellement vérifier cette valeur pour la marquer comme inutile et à supprimer, et malgré tout signaler un tracé comme étant sans source de référence). ___ 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] Frontière et/ou eaux territoriales Guyane française
2013/3/6 Philippe Verdy verd...@wanadoo.fr: admin_level=1 puisse s'appliquer car il n'existe encore aucune entité administrative supranationale. L'union européenne et ses 50.000 fonctionnaires seront contents d'apprendre qu'ils ne sont pas une entité administrative. Et pour ceux qui auraient raté les infos de ces cinquante dernières années, une large partie du droit européen est effectivement supranationale. Au niveau des frontières et de leur incidence sur la circulation des biens et des personnes, on devrait effectivement définir deux zones, les pays dans l'UE et ceux qui font partie de l'espace Schengen. Pas sûr cependant que toutes ces nuances entrent dans le schéma classique des admin_level. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
2013/3/6 Philippe Verdy verd...@wanadoo.fr: On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. De quelle analyse Osmose parle-t-on ? La seule que je vois qui pourrait correspondre à un problème de source manquante est l'item 2040 mais cela ne concerne que les limites administratives. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rappel pour l'appel à contributions FROG 2013
2013/3/5 Pieren pier...@gmail.com:
Bouh, les vilains d'osgeo, sur la carte d'accès au site, ils utilisent
la version OSM d'Open MapQuest (ben) mais ils créditent la version
commerciale MapQuest NAVTEQ (pas ben):
Faute non avouée mais corrigée, donc pardonnée :))
{attribution: Tuiles de fond a target='_blank'
href='http://www.mapquest.com/'© MapQuest/a img
src='http://developer.mapquest.com/content/osm/mq_logo.png'br/Données
a href='http://www.openstreetmap.org/copyright'© les contributeurs
OpenStreetMap/a}
Pieren
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Bonjour, Nous sommes une équipes de bénévoles qui intervenons actuellement sur le cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et Morombé. Le bilan provisoire d'hier est de : 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara I, 1 Sakaraha, 4 Toliara II, 1 Betroka) ;16 disparus (Toliara I) ;127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29 Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano);40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II, 16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 265 CR Soanala, 115 CU Betroka, 2 459 Antakataka Sud, 1 315 Vangaindrano, 1 562 Ankazoabo) ;13 882 sans abris (892 Toliara I, 2 000 Sakaraha, 2 271 Toliara II, 1 680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459 Antakataka Sud, 332 Vangaindrano, 1 562 Ankazoabo) ;7 402 cases totalement détruites (100 Sakahara, 120 Morombe, 1 729 Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 920 Toliara II) ; 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044 Sakaraha, 372 Ampanihy, 32 Betroka) Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes pour des soins en urgence. Nos membres sont celui du VOST Francophone (nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue de la communauté des #MSGU, Médias sociaux en gestion d'urgence : http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity Road s'est également jointe à notre action. Grâce au travail d'impacts sur les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées d'infos des médias sociaux et sites internet, nous avons pu mieux orienter l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara. Nous utilisons une carte collaborative pour recenser les besoins humanitaires et améliorer la réponse de crise : https://haruna.crowdmap.com Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM et de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut car il nous permet d'avoir une vision en image satellite, importante pour comprendre la géographie locale tout comme pour bénéificier des infos toponymiques. Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie, notamment sur le centre-ville où les données sont beaucoup plus détaillées et qui nous ont été précisieuses pour localiser les écoles (centres d'hébergement, cycbercafés...). Nous demandons donc à tout membre de la communauté d'OSM votre participation bénévole pour :- Extraire le sud-ouest de Madagascar en format KML ou KMZ afin de l'intégrer comme couche dans Crowdmap. Nous pouvons chercher techniquement comment faire de notre côté mais nous y gagnerons du temps si quelqu'un de chez vous s'en occupe.- Participer sur le terrain à de la remontée d'informations humanitaires géolocalisées sur les secteurs de Tuléar à Toliari, de Morombé, voir de Sakaraha, Betiky, Betroka, Vangaindrano, Antakataka, Ampanihy, Soanala.- Compléter notre liste de cyber-cafés fonctionnels et y distribuer des affiches pour mobiliser les internautes sur place afin qu'ils remontent des informations sur les besoins humanitaires et leurs attentes en général face à cette catastrophe.- Ou toute autre action qui pourrait améliorer la réponse humanitaire. Pour les deux derniers point, auriez-vous svp un contact sur place ? Nous vous remercions de votre attention. Cédric +33 5 35 54 19 27Skype : roomilissimoTwitter : @Moro_Cedric Coordinateur du VOST FrancophoneMembre de la communauté MSGU (Médias sociaux en gestion d'urgence) Webmaster des Pompiers de l'urgence internationalewww.pompiers-urgence.org www.i-resilience.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Bonjour, à priori c'est une tâche pour HOT, l'équipe de cartographie pour l'humanitaire de OSM : http://hot.openstreetmap.org ils ont déjà travaillé sur des cas semblables, et ont déjà en place un système de partage des tâches plutôt efficace ! et d'ailleurs si je ne me trompe pas, certains des membres actifs lisent cette liste ... Sylvain Le 6 mars 2013 11:23, Cédric Moro moro_geogra...@hotmail.com a écrit : Bonjour, Nous sommes une équipes de bénévoles qui intervenons actuellement sur le cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et Morombé. Le bilan provisoire d'hier est de : ** - 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara I, 1 Sakaraha, 4 Toliara II, 1 Betroka) ; - 16 disparus (Toliara I) ; - 127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29 Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano); - 40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II, 16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 265 CR Soanala, 115 CU Betroka, 2 459 Antakataka Sud, 1 315 Vangaindrano, 1 562 Ankazoabo) ; - 13 882 sans abris (892 Toliara I, 2 000 Sakaraha, 2 271 Toliara II, 1 680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459 Antakataka Sud, 332 Vangaindrano, *1 *562 Ankazoabo) ; - 7 402 cases totalement détruites (100 Sakahara, 120 Morombe, 1 729 Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 920 Toliara II) ; - 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044 Sakaraha, 372 Ampanihy, 32 Betroka) Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes pour des soins en urgence. Nos membres sont celui du VOST Francophone (nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue de la communauté des #MSGU, Médias sociaux en gestion d'urgence : http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity Road s'est également jointe à notre action. Grâce au travail d'impacts sur les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées d'infos des médias sociaux et sites internet, nous avons pu mieux orienter l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara. Nous utilisons une carte collaborative pour recenser les besoins humanitaires et améliorer la réponse de crise : https://haruna.crowdmap.com Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM et de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut car il nous permet d'avoir une vision en image satellite, importante pour comprendre la géographie locale tout comme pour bénéificier des infos toponymiques. Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie, notamment sur le centre-ville où les données sont beaucoup plus détaillées et qui nous ont été précisieuses pour localiser les écoles (centres d'hébergement, cycbercafés...). Nous demandons donc à tout membre de la communauté d'OSM votre participation bénévole pour : - Extraire le sud-ouest de Madagascar en format KML ou KMZ afin de l'intégrer comme couche dans Crowdmap. Nous pouvons chercher techniquement comment faire de notre côté mais nous y gagnerons du temps si quelqu'un de chez vous s'en occupe. - Participer sur le terrain à de la remontée d'informations humanitaires géolocalisées sur les secteurs de Tuléar à Toliari, de Morombé, voir de Sakaraha, Betiky, Betroka, Vangaindrano, Antakataka, Ampanihy, Soanala. - Compléter notre liste de cyber-cafés fonctionnels et y distribuer des affiches pour mobiliser les internautes sur place afin qu'ils remontent des informations sur les besoins humanitaires et leurs attentes en général face à cette catastrophe. - Ou toute autre action qui pourrait améliorer la réponse humanitaire. Pour les deux derniers point, auriez-vous svp un contact sur place ? Nous vous remercions de votre attention. Cédric +33 5 35 54 19 27 Skype : roomilissimo Twitter : @Moro_Cedric Coordinateur du VOST Francophone Membre de la communauté MSGU (Médias sociaux en gestion d'urgence) Webmaster des Pompiers de l'urgence internationale www.pompiers-urgence.org www.i-resilience.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] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Bonjour, Je connais pas mal Madagascar et un peu Tuléar. On peut trouver quelques généralités sur la cartographie du pays dans le wiki: http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie, notamment sur le centre-ville où les données sont beaucoup plus détaillées et qui nous ont été précisieuses pour localiser les écoles (centres d'hébergement, cycbercafés...). Je suis fort aise que mon modeste travail de fourmi ait pu être utile :-p Par contre, je n'ai pas vraiment de contacts sur place actuellement. Nous demandons donc à tout membre de la communauté d'OSM votre participation bénévole pour :- Extraire le sud-ouest de Madagascar en format KML ou KMZ afin Ca, je ne sais pas faire et comme je suis au boulot, je ne peux pas faire d'essais. Néanmoins, si certains veulent le faire, on peut récupérer toutes les données de Madagascar d'un seul coup chez geofabrik : http://download.geofabrik.de/openstreetmap/africa/ Ce n'est pas bien gros (20 Mo max). Pour revenir à Tuléar (http://osm.org/go/k~5RokPm-), donc, avec le cyclone, la digue protégeant la ville de la rivière au nord a cédé d'où linondation du centre-ville (très plat). Ca a aussi coupé la RN9 au sud du pont franchissant la dite rivière, coupant la circulation vers le nord dont Morombe. Pour se repérer en ville, il reste certes des noms de rues d'époque coloniale mais personne ne s'en sert. Les malgaches se repèrent avec les noms des quartiers. Il y en a quelques uns dans OSM mais je pense qu'il en manque pas mal. Il y a un découpage administratifs sous les communes, les fokontany. Ils possèdent des bureaux. Ils peuvent avoir le même nom que le quartier. Ils ne sont pas renseignés dans OSM. Il y a aussi une identifications des bâtiments et des ilots par lot (http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar#Adresses) mais si ce n'est pas renseigné avant la catastrophe, c'est trop tard. D'où l'intérêt d'avoir des éléments (centre de santé, écoles...) directement géo-référencés dans OSM. S'il y a des questions sur les spécificités malgaches, je peux essayer d'y répondre. Je peux peut-être aussi contacter des personnes en France qui connaissent mieux la ville. Et, quand vous serez revenus, je suis aussi intéressé par savoir quelles sont les informations que vous avez trouvé dans OSM qui vont ont été utiles et celles qui vous ont manquées. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Justement, des rivières, routes, voies ferrées sont parfois aussi des limites administratives. Et c'est là qu'on trouve le plus des source=inconnue ! Et ça commence à se propager ailleurs sur d'autres objets. Le 6 mars 2013 10:51, Pieren pier...@gmail.com a écrit : 2013/3/6 Philippe Verdy verd...@wanadoo.fr: On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. De quelle analyse Osmose parle-t-on ? La seule que je vois qui pourrait correspondre à un problème de source manquante est l'item 2040 mais cela ne concerne que les limites administratives. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Bonjour, Concernant le dernier point toute autre action..., je me posais la question de la disponibilité des images SPOT sous une licence compatible avec OSM afin que des contributeurs non-locaux (contributions dans le fauteuil :-) puissent participer. En particulier, suivant la date des images (avant/après) il sera possible d'affiner le bati sur la zone concernée par l'inondation et/ou d'indiquer dans OSM les détails visibles de l’infrastructure routière ; ces éléments pouvant servir de repère géographique pour des remontées d'informations locales. En cas de réponse positive, je pense (et je m'avance sur ce point) que l'asso OSM-FR pourra fournir les moyens techniques pour exploiter les images (tuilage, hébergement, etc.) Cordialement, A+ Le 6 mars 2013 11:23, Cédric Moro moro_geogra...@hotmail.com a écrit : Bonjour, Nous sommes une équipes de bénévoles qui intervenons actuellement sur le cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et Morombé. Le bilan provisoire d'hier est de : ** - 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara I, 1 Sakaraha, 4 Toliara II, 1 Betroka) ; - 16 disparus (Toliara I) ; - 127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29 Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano); - 40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II, 16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 265 CR Soanala, 115 CU Betroka, 2 459 Antakataka Sud, 1 315 Vangaindrano, 1 562 Ankazoabo) ; - 13 882 sans abris (892 Toliara I, 2 000 Sakaraha, 2 271 Toliara II, 1 680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459 Antakataka Sud, 332 Vangaindrano, *1 *562 Ankazoabo) ; - 7 402 cases totalement détruites (100 Sakahara, 120 Morombe, 1 729 Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 920 Toliara II) ; - 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044 Sakaraha, 372 Ampanihy, 32 Betroka) Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes pour des soins en urgence. Nos membres sont celui du VOST Francophone (nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue de la communauté des #MSGU, Médias sociaux en gestion d'urgence : http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity Road s'est également jointe à notre action. Grâce au travail d'impacts sur les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées d'infos des médias sociaux et sites internet, nous avons pu mieux orienter l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara. Nous utilisons une carte collaborative pour recenser les besoins humanitaires et améliorer la réponse de crise : https://haruna.crowdmap.com Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM et de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut car il nous permet d'avoir une vision en image satellite, importante pour comprendre la géographie locale tout comme pour bénéificier des infos toponymiques. Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie, notamment sur le centre-ville où les données sont beaucoup plus détaillées et qui nous ont été précisieuses pour localiser les écoles (centres d'hébergement, cycbercafés...). Nous demandons donc à tout membre de la communauté d'OSM votre participation bénévole pour : - Extraire le sud-ouest de Madagascar en format KML ou KMZ afin de l'intégrer comme couche dans Crowdmap. Nous pouvons chercher techniquement comment faire de notre côté mais nous y gagnerons du temps si quelqu'un de chez vous s'en occupe. - Participer sur le terrain à de la remontée d'informations humanitaires géolocalisées sur les secteurs de Tuléar à Toliari, de Morombé, voir de Sakaraha, Betiky, Betroka, Vangaindrano, Antakataka, Ampanihy, Soanala. - Compléter notre liste de cyber-cafés fonctionnels et y distribuer des affiches pour mobiliser les internautes sur place afin qu'ils remontent des informations sur les besoins humanitaires et leurs attentes en général face à cette catastrophe. - Ou toute autre action qui pourrait améliorer la réponse humanitaire. Pour les deux derniers point, auriez-vous svp un contact sur place ? Nous vous remercions de votre attention. Cédric +33 5 35 54 19 27 Skype : roomilissimo Twitter : @Moro_Cedric Coordinateur du VOST Francophone Membre de la communauté MSGU (Médias sociaux en gestion d'urgence) Webmaster des Pompiers de l'urgence internationale www.pompiers-urgence.org www.i-resilience.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___
Re: [OSM-talk-fr] source=inconnue
Bonjour, De : Philippe Verdy Justement, des rivières, routes, voies ferrées sont parfois aussi des limites administratives. Et c'est là qu'on trouve le plus des source=inconnue ! Et ça commence à se propager ailleurs sur d'autres objets. Pas de panique. À te lire la base est en train d'être envahie par ce tag. Concrètement, on trouve d'après taginfo 8 ways avec le tag source=inconnue. Oui, 8, pas 800 ou 8000. Il proviennent tous d'un groupe de modification pas tout jeune (2010) : http://www.openstreetmap.org/browse/changeset/5210200 de sly. Et donc non ça [ne] commence [pas] à se propager. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
Le 6 mars 2013 10:42, Pieren pier...@gmail.com a écrit : 2013/3/6 Philippe Verdy verd...@wanadoo.fr: admin_level=1 puisse s'appliquer car il n'existe encore aucune entité administrative supranationale. L'union européenne et ses 50.000 fonctionnaires seront contents d'apprendre qu'ils ne sont pas une entité administrative. C'est une administration mais les pays membres n'en sont pas des sous-entités. Le modèle hiérarchique ne s'applique pas à l'Union européenne, ni aux autres organisations européennes même si elles ont leur propre structure administrative. Au niveau des frontières et de leur incidence sur la circulation des biens et des personnes, on devrait effectivement définir deux zones, les pays dans l'UE et ceux qui font partie de l'espace Schengen. Pas sûr cependant que toutes ces nuances entrent dans le schéma classique des admin_level. C'est tellement compliqué et il y a tellement d'exceptions que c'est impossible à faire rentrer dans le moule. L'Union européenne peut être cartographiée dans OSM mais à part (et il faudra effectivement une collection de relations selon ce qu'on veut représenter, selon les statuts d'adhésion pleine des parties de territoires nationaux inclus ou pas, ou statuts de collaboration renforcée ou associée, et selon aussi diverses exceptions incluses dans les traités selon les domaines... Pour certaines cartes simplifiées on peut ne pas vouloir faire le détail, mais si on est précis, les frontières de l'UE sont très difficiles à définir car il faur retenir certains critères, assez arbitrairement. Shengen en est un exemple : ce n'est pas non plus une subdivision de l'Union européenne car on y trouve aussi des territoires qui ne font PAS partie de l'Unione européenne, et des parties de l'Union européenne (parties de certains pays membres, ou pays membres tout entiers) qui n'en font pas partie. La zone euro en est un autre exemple similaire (formellement le Vatican ne fait pas partie de l'UE, n'est pas pleinement membre de la zone euro et pourtant dispose d'un accord de la explicite de la Commission pour l'utiliser; le Kosovo l'utilise officiellement chez lui, mais son gouvernement n'a pas reçu lui-même cet agrément qui n'a été accordé qu'à la mission intérimaire des Nations unies qui auparavant utilisait le mark allemand en vertu d'un traité avalisé par l'ONU Le Monténégro a décidé unilatéralement aussi d'utiliser l'euro, mais sans aucun accord; pour Andorre, il ne fait pas partie non plus de l'UE ni de la zone euro, mais les accords monétaires préexistants avec la France et l'Espagne ont été maintenus : Andorre ne peut utiliser l'euro que parce que la France et/ou l'Espagne ont voulu perpétuer leur accord avec l'Andorre : c'est l'adhésion de la France et de l'Espagne qui a entrainé celle de l'Andorre, et si la France et l'Espagne quittaient l'euro, Andorre devrait le faire aussi (sauf si les traités entre Andorre et la France et l'Espagne sont dénoncés conjointement par les parties). Pour s'en convaincre il faut regarder l'extrême complexité des annexes au traité d'union : la liste complète des exceptions pour chaque pays membre est impressionnante, et chaque modification des traités européens en a ajouté d'autres. A un point tel qu'il me semble que formellement il n'y a plus aucun pays membre de l'Union qui ait adopté la totalité des textes sur la totalité de leur territoire. L'Union européenne est un véritable patchwork d'exceptions sur presque tous les sujets (et les mêmes sujets incluent aussi des parties qui ont été admises à collaborer dans certains domaines sans faire partie formellement de l'Union). Je te mets au défit alors de tracer les frontières effectives de l'UE, ne serait-ce que pour ce qu'on appelle les acquis européens (autrement dit les points non négociables du traité, les mêmes points sur lesquels il reste pourtant des pays membres qui ne les ont pas adoptés lors des amendements successifs, parce qu'il n'était pas question qu'ils sortent pour autant de la nouvelle entité...). L'UE reste une entité en construction permanente. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Je ne me rappel plus si c'était un conseil d'édition (sans obligation) mais si possible on ne doit pas fusionner sur le même segment une route ou un cours d'eau avec un frontière. Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et fausser les limites administrative. Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre et je ne pense pas qu'on met à jour le cadastre après chaque hivers. Le 6 mars 2013 13:38, Philippe Verdy verd...@wanadoo.fr a écrit : Justement, des rivières, routes, voies ferrées sont parfois aussi des limites administratives. Et c'est là qu'on trouve le plus des source=inconnue ! Et ça commence à se propager ailleurs sur d'autres objets. Le 6 mars 2013 10:51, Pieren pier...@gmail.com a écrit : 2013/3/6 Philippe Verdy verd...@wanadoo.fr: On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. De quelle analyse Osmose parle-t-on ? La seule que je vois qui pourrait correspondre à un problème de source manquante est l'item 2040 mais cela ne concerne que les limites administratives. ___ 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] source=inconnue
Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de lignes superposées, ce que le validateur de Josm n'apprécie que très modérément ! Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le temps pour pouvoir être utilisé comme frontière. Les (rares) cas où un cours d'eau change de lit tous les ans (en France) sont sans doute justement les cas où la frontière n'a plus rien à voir avec le cours d'eau depuis longtemps (je pense à la limite Bretagne/Basse-Normandie, où l'embouchure du Couesnon n'est plus la frontière entre ces 2 régions depuis...) Francescu Le 6 mars 2013 14:07, Jo. perche...@gmail.com a écrit : Je ne me rappel plus si c'était un conseil d'édition (sans obligation) mais si possible on ne doit pas fusionner sur le même segment une route ou un cours d'eau avec un frontière. Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et fausser les limites administrative. Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre et je ne pense pas qu'on met à jour le cadastre après chaque hivers. Le 6 mars 2013 13:38, Philippe Verdy verd...@wanadoo.fr a écrit : Justement, des rivières, routes, voies ferrées sont parfois aussi des limites administratives. Et c'est là qu'on trouve le plus des source=inconnue ! Et ça commence à se propager ailleurs sur d'autres objets. Le 6 mars 2013 10:51, Pieren pier...@gmail.com a écrit : 2013/3/6 Philippe Verdy verd...@wanadoo.fr: On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. De quelle analyse Osmose parle-t-on ? La seule que je vois qui pourrait correspondre à un problème de source manquante est l'item 2040 mais cela ne concerne que les limites administratives. ___ 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 -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Le 6 mars 2013 14:12, Francescu GAROBY windu...@gmail.com a écrit : Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de lignes superposées, ce que le validateur de Josm n'apprécie que très modérément ! Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le temps pour pouvoir être utilisé comme frontière. Les (rares) cas où un cours d'eau change de lit tous les ans (en France) sont sans doute justement les cas où la frontière n'a plus rien à voir avec le cours d'eau depuis longtemps (je pense à la limite Bretagne/Basse-Normandie, où l'embouchure du Couesnon n'est plus la frontière entre ces 2 régions depuis...) Une rivière ne change plus radicalement de lit en France, hormis les ruisseaux de montagne. Elles sont presque toutes aménagées alors par l'homme, et tant que la ligne passe dans le lit, mêm esi ce lit change de largeur selon les nivaux d'eau, la ligne reste dans la rivière et il n'y a pas de raison d'avori deux tracés différents pour le cours central (imaginaire) et la ligne administrative (aussi imaginaire) : même si cette ligne bouge de quelques mètres la limite entre les deux communes reste tout de même cette rivière indépendamment du fait que ses rives peuvent bouger (sans jamais toucher la ligne centrale imaginaire). Le cas où c'est réellement défini de façon précise, avec des coordonnées exactes et des bornes d'alignement, c'est pour les frontières internationales (le tracé de la frontière franco-allemande par exemple au milieu du Rhin : il y a des points précis positionnés par exemple au milieu des ponts, et parfois des bouées ou balises. Ce qui bouge réellement alors ce sont les rives, pas la ligne imaginaire passant entre les rives (il n'y a pas de cas où une rive change d'une année sur l'autre de territoire, même si le partage des eaux peut bouger un peu, cela ne fait aucune importance car le cours d'eau est géré en collaboration sur toute sa surface entre les rives. L'autre cas plus problématique c'est pour les routes car là il y a bien des terrains qui entrent en compte et peuvent changer d'usage : si un rond-point est construit, il faut acheter du terrain pour une collectivité ou une autre. La France n'est pas le Bengladesh, les cours d'eau sont presque tous maîtrisés, hormis les ruisseaux de montagne dont le lit est très variable mais sur une surface déjà repérée comme inondable et normalement laissée à son état naturel (le lit est donc plus large que l'état actuel ou le plus courant du cours d'eau : cela se voit par es enrochements, les galets déplacés, les zones boueuses). C'est seulement si on décide de construire une route ou voie ferrée ou un immeuble le long de ce cours d'eau qu'on prend un risque que l'ouvrage soit emporté lors d'une crue, et qu'il est alors important de savoir à quel territoire on attribue l'ouvrage construit (et cela ne peut se faire sans accord mutuel des collectivités mitoyennes concernées, et une expropriation légale des éventuels propriétaires. Avant que cela arrive, il va s'écouler du temps. Si jamais survient une catastrophe (crue exceptionnelle par exemple, effondrement d'une falaise, glissement de terrain), il intervient une autre procédure légale (l'arrêté de catastrophe naturelle qui permet des indemnisations, ou de ne plus admettre d'autres constructions, et de désigner une collectivité qui prendra en charge les nouveaux terrains laissés après la catastrophe et éventuellement de reconstruire différemment). Ce sera de toute façon assez visible et l'effet sera durable (et on aura vite fait de modifier nos cartes dans OSM, la catastrophe ne passera pas inaperçue). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
2013/3/6 Francescu GAROBY windu...@gmail.com: Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de lignes superposées, ce que le validateur de Josm n'apprécie que très modérément ! Si c'est le cas, c'est un problème dans le validateur (ça ne serait pas la première fois). Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le temps pour pouvoir être utilisé comme frontière. Euh, ça dépend vraiment de la largeur du cour d'eau, de la force des courants, de l'intensité d'événements exceptionnels (crues), des aménagements. De nombreuses limites sont aussi basées sur des ruisseaux avec un relevé déjà approximatif dans les vieux plans cadastraux d'origine (qui ne disposaient pas de vues aériennes comme aujourd'hui). Non, on ne peut vraiment pas dire que les tracés de cours d'eaux soient stables dans le temps. Il y a malheureusement des gens qui se contentent d'ajouter un waterway comme limite communale par facilité alors que seul le tracé du cadastre compte (au risque de mettre des parcelles dans la mauvaise commune). Bien-sûr, on n'est pas obligé de mettre le waterway pile poil au milieu de la rivière pour être plus conforme avec le tracé du cadastre. Mais il y a ensuite toujours quelqu'un qui repassera derrière pour corriger le waterway à partir de Bing. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Bonjour, Le mieux est effectivement de récupérer les données directement chez Geofabrik, où elles sont mises à jour quotidiennement. Au cas où cela pourrait être utile, j'ai fait une conversion rapide de leurs shapefiles pour Madagascar en KML, avec ogr2ogr. Le résultat est dans : http://osm.arkemie.org/madagascar/madagascar.kml.zip et les fichiers individuels sont dans le répertoire : http://osm.arkemie.org/madagascar/ (Le fichier LISEZMOI liste les commandes - toutes simples - que j'ai utilisées). Lundi dernier, j'avais entré dans OSM les villages que je voyais dans Bing le long de la côte entre Toliara et Morombe, et qui n'y étaient pas déjà (emprises indiquées comme landuse=residential). Pour trouver les noms, j'ai eu l'impression que GNS (https://wiki.openstreetmap.org/wiki/GNS - http://geonames.nga.mil/ggmagaz/) est une source relativement précise et complète à Madagascar (par rapport à son état dans d'autres pays). Au point qu'il semble qu'on puisse même utiliser leur couche WMS pour trouver les lieux habités. (Et bien sûr leur moteur de recherche pour géolocaliser des lieux qui ne sont pas (encore) dans OSM). Je ne savais pas si ça avait une chance de servir. Content de voir que oui, et qu'il y a des gens sur le terrain. Bien cordialement, Jean-Guilhem Le 06/03/2013 13:15, Eric Sibert a écrit : Bonjour, Je connais pas mal Madagascar et un peu Tuléar. On peut trouver quelques généralités sur la cartographie du pays dans le wiki: http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie, notamment sur le centre-ville où les données sont beaucoup plus détaillées et qui nous ont été précisieuses pour localiser les écoles (centres d'hébergement, cycbercafés...). Je suis fort aise que mon modeste travail de fourmi ait pu être utile :-p Par contre, je n'ai pas vraiment de contacts sur place actuellement. Nous demandons donc à tout membre de la communauté d'OSM votre participation bénévole pour :- Extraire le sud-ouest de Madagascar en format KML ou KMZ afin Ca, je ne sais pas faire et comme je suis au boulot, je ne peux pas faire d'essais. Néanmoins, si certains veulent le faire, on peut récupérer toutes les données de Madagascar d'un seul coup chez geofabrik : http://download.geofabrik.de/openstreetmap/africa/ Ce n'est pas bien gros (20 Mo max). Pour revenir à Tuléar (http://osm.org/go/k~5RokPm-), donc, avec le cyclone, la digue protégeant la ville de la rivière au nord a cédé d'où l’inondation du centre-ville (très plat). Ca a aussi coupé la RN9 au sud du pont franchissant la dite rivière, coupant la circulation vers le nord dont Morombe. Pour se repérer en ville, il reste certes des noms de rues d'époque coloniale mais personne ne s'en sert. Les malgaches se repèrent avec les noms des quartiers. Il y en a quelques uns dans OSM mais je pense qu'il en manque pas mal. Il y a un découpage administratifs sous les communes, les fokontany. Ils possèdent des bureaux. Ils peuvent avoir le même nom que le quartier. Ils ne sont pas renseignés dans OSM. Il y a aussi une identifications des bâtiments et des ilots par lot (http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar#Adresses) mais si ce n'est pas renseigné avant la catastrophe, c'est trop tard. D'où l'intérêt d'avoir des éléments (centre de santé, écoles...) directement géo-référencés dans OSM. S'il y a des questions sur les spécificités malgaches, je peux essayer d'y répondre. Je peux peut-être aussi contacter des personnes en France qui connaissent mieux la ville. Et, quand vous serez revenus, je suis aussi intéressé par savoir quelles sont les informations que vous avez trouvé dans OSM qui vont ont été utiles et celles qui vous ont manquées. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- gpg 0x5939EAE2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Sauf qu'il m'est déjà arrivé que l'export généré par le cadastre définisse la limite d'une commune comme étant la rive (gauche ou droite, selon) d'un cours d'eau, et la même chose (droite ou gauche, cette fois) pour l'autre commune, créant alors un vide, qui correspond au lit de la rivière. D'où le choix de prendre le tracé central dudit cours d'eau. Et je plaide coupable (et j'assume complètement) le fait que, lorsqu'une frontière de commune et un tracé de cours d'eau/route se superpose, c'est ce dernier que je retiens pour les relations. Voyez là une interprétation de la règle le terrain prévaut. Francescu Le 6 mars 2013 14:37, Pieren pier...@gmail.com a écrit : 2013/3/6 Francescu GAROBY windu...@gmail.com: Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de lignes superposées, ce que le validateur de Josm n'apprécie que très modérément ! Si c'est le cas, c'est un problème dans le validateur (ça ne serait pas la première fois). Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le temps pour pouvoir être utilisé comme frontière. Euh, ça dépend vraiment de la largeur du cour d'eau, de la force des courants, de l'intensité d'événements exceptionnels (crues), des aménagements. De nombreuses limites sont aussi basées sur des ruisseaux avec un relevé déjà approximatif dans les vieux plans cadastraux d'origine (qui ne disposaient pas de vues aériennes comme aujourd'hui). Non, on ne peut vraiment pas dire que les tracés de cours d'eaux soient stables dans le temps. Il y a malheureusement des gens qui se contentent d'ajouter un waterway comme limite communale par facilité alors que seul le tracé du cadastre compte (au risque de mettre des parcelles dans la mauvaise commune). Bien-sûr, on n'est pas obligé de mettre le waterway pile poil au milieu de la rivière pour être plus conforme avec le tracé du cadastre. Mais il y a ensuite toujours quelqu'un qui repassera derrière pour corriger le waterway à partir de Bing. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
le 06/03/2013 14:36, Philippe Verdy a écrit: Une rivière ne change plus radicalement de lit en France, hormis les ruisseaux de montagne. Elles sont presque toutes aménagées alors par l'homme, et tant que la ligne passe dans le lit, mêm esi ce lit change de largeur selon les nivaux d'eau, la ligne reste dans la rivière et Bonjour, Tu es déjà allé voir la Loire ou le Doubs ? Tu constateras que, oui, une rivière peut changer radicalement de lit en très peu de temps, par seulement en montagne. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Voir le lien suivant où on peut observer l'imagerie Bing disponible. http://www.harrywood.co.uk/maps/bingosm.html?lat=-23.362526698877858lon=43.67677691268953zoom=18bingopacity=50 Nous pouvons définir une zone à cartographier et ajouter une tâche sur le Gestionnaire de tâches de HOT si vous le jugez à propos. Nous pourrons ainsi faire la carte OSM de base Avant. A partir de openstreetmap.org vous pouvez simplement zoomer pour definir la zone a couvrir. Le bouton exporter vous permettra d'obtenir les le bbox définissant cette zone, Je pourrai aussi alerter la communauté Humanitarian OpenStreetMap (HOT). Pierre Béland Humanitarian OpenStreetMap De : Marc SIBERT m...@sibert.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 6 mars 2013 7h49 Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Concernant le dernier point toute autre action..., je me posais la question de la disponibilité des images SPOT sous une licence compatible avec OSM afin que des contributeurs non-locaux (contributions dans le fauteuil :-) puissent participer. En particulier, suivant la date des images (avant/après) il sera possible d'affiner le bati sur la zone concernée par l'inondation et/ou d'indiquer dans OSM les détails visibles de l’infrastructure routière ; ces éléments pouvant servir de repère géographique pour des remontées d'informations locales. En cas de réponse positive, je pense (et je m'avance sur ce point) que l'asso OSM-FR pourra fournir les moyens techniques pour exploiter les images (tuilage, hébergement, etc.) Cordialement, A+ Le 6 mars 2013 11:23, Cédric Moro moro_geogra...@hotmail.com a écrit : Bonjour, Nous sommes une équipes de bénévoles qui intervenons actuellement sur le cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et Morombé. Le bilan provisoire d'hier est de : * 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara I, 1 Sakaraha, 4 Toliara II, 1 Betroka) ; * 16 disparus (Toliara I) ; * 127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29 Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano); * 40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II, 16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 265 CR Soanala, 115 CU Betroka, 2 459 Antakataka Sud, 1 315 Vangaindrano, 1 562 Ankazoabo) ; * 13 882 sans abris (892 Toliara I,2 000 Sakaraha, 2 271 Toliara II, 1 680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459 Antakataka Sud, 332 Vangaindrano, 1 562 Ankazoabo) ; * 7 402 cases totalement détruites (100 Sakahara, 120 Morombe, 1 729 Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 920 Toliara II) ; * 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044 Sakaraha, 372 Ampanihy, 32 Betroka) Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes pour des soins en urgence. Nos membres sont celui du VOST Francophone (nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue de la communauté des #MSGU, Médias sociaux en gestion d'urgence : http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity Road s'est également jointe à notre action. Grâce au travail d'impacts sur les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées d'infos des médias sociaux et sites internet, nous avons pu mieux orienter l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara. Nous utilisons une carte collaborative pour recenser les besoins humanitaires et améliorer la réponse de crise : https://haruna.crowdmap.com Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM et de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut car il nous permet d'avoir une vision en image satellite, importante pour comprendre la géographie locale tout comme pour bénéificier des infos toponymiques. Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie, notamment sur le centre-ville où les données sont beaucoup plus détaillées et qui nous ont été précisieuses pour localiser les écoles (centres d'hébergement, cycbercafés...). Nous demandons donc à tout membre de la communauté d'OSM votre participation bénévole pour : - Extraire le sud-ouest de Madagascar en format KML ou KMZ afin de l'intégrer comme couche dans Crowdmap. Nous pouvons chercher techniquement comment faire de notre côté mais nous y gagnerons du temps si quelqu'un de chez vous s'en occupe. - Participer sur le terrain à de la remontée d'informations humanitaires géolocalisées sur les secteurs de Tuléar à Toliari, de Morombé, voir de Sakaraha, Betiky, Betroka, Vangaindrano, Antakataka, Ampanihy, Soanala. - Compléter notre liste de
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Merci de vos réponses. 1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci 2/ Images SPOT/Pléiades : Elles sont dispo à ces adresses : http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434 Nous avons eu un contact téléphonique et fait une demande écrite au SERTIT qui a effectué le traitement des images en télédétection. Nous avions une difficulté à importer leurs images KML dans crowdmap ou même googlemap et nous avons pu les ouvrir seulement dans Googleearth pour les avoir sous une forme géolocalisée. Le problème était que les traitements et légendes étaient incrustés dans le raster de l'image (qui n'est qu'une JPG) et pas sous forme d'objets vecteurs géoloc qui auraient été plus facilement exportables. Pour la région de Tuléar, nous avons donc mis des dizaines d'heures à refaire les polygones et points. On a perdu beaucoup de temps et de la précision, et sur cette zone seulement. Nous avons eu un contact avec le SERTIT hier soir et nous leur avons donc demander de bénéficier des couches de traitement en télédétection au format KML/KMZ pour pouvoir les intégrer à notre crowdmap, surtout pour d'autres régions touchées sur lesquelles nous n'avons pas encore déployé de données spatiales. La demande est en cours d'approbation au siège. Concernant l'utilisation des images satellites en dehors de la catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous rapporte (sans jugement personnel) : Les droits d'auteurs à de fins commerciales et la non réutilisation en dehors de la situation de la catastrophe naturelle et de sa réponse d'urgence. Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique des formats d'échange de données en période de catastrophe pour qu'à l'avenir, on ne perde plus autant de temps. 4/ Ceux qui gèrent la carte, dont moi, ne sommes pas sur le terrain mais en contact avec les acteurs sur place par téléphone et email , surtout avec les Pompiers de l'urgence internationale, et par Réseaux sociaux pour certains habitants sur place. 5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite. 6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais sur place, certains s'intéressent en détail dans la carto libre, je leur montrerai le chemin d'OSM et d'Ushahidi :-) Merci encore à tous et à bientôt, +33 5 35 54 19 27 Skype : roomilissimo Twitter : @Moro_Cedric Coordinateur du VOST Francophone Membre de la communauté MSGU (Médias sociaux en gestion d'urgence) Webmaster des Pompiers de l'urgence internationale www.pompiers-urgence.org www.i-resilience.fr Date: Wed, 6 Mar 2013 14:43:25 +0100 From: j...@arkemie.com To: talk-fr@openstreetmap.org; moro_geogra...@hotmail.com Subject: Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Le mieux est effectivement de récupérer les données directement chez Geofabrik, où elles sont mises à jour quotidiennement. Au cas où cela pourrait être utile, j'ai fait une conversion rapide de leurs shapefiles pour Madagascar en KML, avec ogr2ogr. Le résultat est dans : http://osm.arkemie.org/madagascar/madagascar.kml.zip et les fichiers individuels sont dans le répertoire : http://osm.arkemie.org/madagascar/ (Le fichier LISEZMOI liste les commandes - toutes simples - que j'ai utilisées). Lundi dernier, j'avais entré dans OSM les villages que je voyais dans Bing le long de la côte entre Toliara et Morombe, et qui n'y étaient pas déjà (emprises indiquées comme landuse=residential). Pour trouver les noms, j'ai eu l'impression que GNS (https://wiki.openstreetmap.org/wiki/GNS - http://geonames.nga.mil/ggmagaz/) est une source relativement précise et complète à Madagascar (par rapport à son état dans d'autres pays). Au point qu'il semble qu'on puisse même utiliser leur couche WMS pour trouver les lieux habités. (Et bien sûr leur moteur de recherche pour géolocaliser des lieux qui ne sont pas (encore) dans OSM). Je ne savais pas si ça avait une chance de servir. Content de voir que oui, et qu'il y a des gens sur le terrain. Bien cordialement, Jean-Guilhem Le 06/03/2013 13:15, Eric Sibert a écrit : Bonjour, Je connais pas mal Madagascar et un peu Tuléar. On peut trouver quelques généralités sur la cartographie du pays dans le wiki: http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie, notamment sur le centre-ville où les données sont beaucoup plus détaillées et qui nous ont été précisieuses pour localiser les écoles (centres d'hébergement, cycbercafés...). Je suis fort aise que mon modeste travail de fourmi ait pu être utile :-p Par contre, je n'ai pas vraiment de contacts sur place actuellement. Nous demandons donc à tout
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
De mémoire, j'ai du relever un nombre significatif de points caractéristiques au GPS dans Tuléar, ainsi qu'à l'aéroport au sud et sans doute à Mangily 15 km au nord. J'ai aussi transféré mes traces GPS dans OSM. Ça peut permettre de caler des vues aériennes ou satellites (Bing inclus). Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Quand physiquement ce n'est pas la meme chose il est souvent judicieux de ne pas le faire supporter par le meme objet effectivement ca evite des éditions sauvages lorsque qu'un cours d'eau est modifié a priori la limite administrative n'a pas a l’être trivialement. On a le meme souci avec les landuse supporté par des highway ou meme des building! Pour ce qui est d'avoir deux objet superposé et de même géométrie ca génere une alerte certes mais ce n'est pas forcément un doublon. Le 6 mars 2013 14:07, Jo. perche...@gmail.com a écrit : Je ne me rappel plus si c'était un conseil d'édition (sans obligation) mais si possible on ne doit pas fusionner sur le même segment une route ou un cours d'eau avec un frontière. Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et fausser les limites administrative. Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre et je ne pense pas qu'on met à jour le cadastre après chaque hivers. Le 6 mars 2013 13:38, Philippe Verdy verd...@wanadoo.fr a écrit : Justement, des rivières, routes, voies ferrées sont parfois aussi des limites administratives. Et c'est là qu'on trouve le plus des source=inconnue ! Et ça commence à se propager ailleurs sur d'autres objets. Le 6 mars 2013 10:51, Pieren pier...@gmail.com a écrit : 2013/3/6 Philippe Verdy verd...@wanadoo.fr: On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. De quelle analyse Osmose parle-t-on ? La seule que je vois qui pourrait correspondre à un problème de source manquante est l'item 2040 mais cela ne concerne que les limites administratives. ___ 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
[OSM-talk-fr] Cartopartie des panneaux publicitaires à Paris - samedi 16 mars 2013
Bonjour à tous, Simplement pour vous signaler une cartopartie un peu particulière à Paris : http://www.cartographiepublicitaire.org/2013/02/cartopartie/ Cette cartopartie sera spécifique aux panneaux publicitaires. Récolter des informations sur les panneaux environnants, leur emplacement géographique, le nom de l’afficheur, la taille, le type de panneau, etc. Pour plus d'informations sur l'initiative voir le site : http://www.cartographiepublicitaire.org/ J'avais discuté de cette initiative sur la liste il y a plusieurs mois, la cartographie avance ainsi que les visualisations. Nous nous basons sur http://wiki.openstreetmap.org/wiki/FR:Key:advertising si certains ont des retours constructifs à faire, ils sont les bienvenus. Vous êtes bien évidemment aussi les bienvenus à la cartopartie. J'éspère par ce type de cartographie spécifique eveiller la curiosité pour OSM et éventuellement initier de nouveaux contributeurs. Arthur -- http://arthur.lutz.im ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
2013/3/6 Francescu GAROBY windu...@gmail.com: commune, créant alors un vide, qui correspond au lit de la rivière. D'où le choix de prendre le tracé central dudit cours d'eau. J'ai rencontré des cas similaires avec des chemins. Soit une commune fixait la limite au milieu et l'autre commune au bord, soit chacune un bord avec un vide, soit chacune un bord avec superposition. Ou même un choix qui variait à l'intérieur de la commune d'une planche à l'autre... Evidemment, dans ces cas-là, on est obligé de faire un choix subjectif. A moins de contacter les maires des communes concernées pour savoir qui est en charge de l'entretien du dit chemin (en espérant qu'ils disent la même chose ;-) Certaines régions semblent plus touchées que d'autres par ces aberrations. On espère que la future intégration des cadastres DGFiP et IGN permettront de remettre à plat ces erreurs géométriques Et je plaide coupable (et j'assume complètement) le fait que, lorsqu'une frontière de commune et un tracé de cours d'eau/route se superpose, c'est ce dernier que je retiens pour les relations. Voyez là une interprétation de la règle le terrain prévaut. Le terrain n'a aucune valeur en matière de limite administrative puisqu'elle est invisible. Sauf si on peut voir sur le sol une jolie ligne blanche ou une clôture symbolisant cette limite dans certaines contrées. Je connais au moins un exemple de parcelles agricoles qui sont passées au fil des ans de l'autre côté d'un ruisseau (disons plutôt que c'est le ruisseau qui a bougé et pas les parcelles, hein). Et bien ces parcelles font toujours parties de la même commune. La règle du terrain prévaut est donc fausse dans ce cas. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartopartie des panneaux publicitaires à Paris - samedi 16 mars 2013
Bonjour, Très bonne idée ! Je remarque cependant qu'il manque (selon moi) quelque chose dans la page du wiki : comment indiquer qu'un panneau publicitaire est aussi (sur l'autre face, celle qui n'est pas tournée vers la route) un panneau affichant un plan de la ville/du quartier ? Francescu Le 6 mars 2013 15:12, Arthur Lutz arthur.l...@gmail.com a écrit : Bonjour à tous, Simplement pour vous signaler une cartopartie un peu particulière à Paris : http://www.cartographiepublicitaire.org/2013/02/cartopartie/ Cette cartopartie sera spécifique aux panneaux publicitaires. Récolter des informations sur les panneaux environnants, leur emplacement géographique, le nom de l’afficheur, la taille, le type de panneau, etc. Pour plus d'informations sur l'initiative voir le site : http://www.cartographiepublicitaire.org/ J'avais discuté de cette initiative sur la liste il y a plusieurs mois, la cartographie avance ainsi que les visualisations. Nous nous basons sur http://wiki.openstreetmap.org/wiki/FR:Key:advertising si certains ont des retours constructifs à faire, ils sont les bienvenus. Vous êtes bien évidemment aussi les bienvenus à la cartopartie. J'éspère par ce type de cartographie spécifique eveiller la curiosité pour OSM et éventuellement initier de nouveaux contributeurs. Arthur -- http://arthur.lutz.im ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Bonjour Fracescu, Oui cela peut arriver si on superpose à l'identique les deux segments mais on peut souvent différencier les segments en les laissant proche. Ce matin j'ai encore séparer une frontière et une départementale. Il y avait de petit décalage avec le cadastre (maxi 2 mètres) alors que la route suivait parfaitement l'imagerie Bing. Par défaut je crée une parallèle et définie la route (ou cours d'eau) sur le nouveau segment, j'en profite pour l'ajuster à l'imagerie et effectue une simplification du segment. Après ce travail, les segments sont toujours proche mais les nœuds ne peuvent plus être fusionné car ils ont été retouché. Le 6 mars 2013 14:12, Francescu GAROBY windu...@gmail.com a écrit : Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de lignes superposées, ce que le validateur de Josm n'apprécie que très modérément ! Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le temps pour pouvoir être utilisé comme frontière. Les (rares) cas où un cours d'eau change de lit tous les ans (en France) sont sans doute justement les cas où la frontière n'a plus rien à voir avec le cours d'eau depuis longtemps (je pense à la limite Bretagne/Basse-Normandie, où l'embouchure du Couesnon n'est plus la frontière entre ces 2 régions depuis...) Francescu Le 6 mars 2013 14:07, Jo. perche...@gmail.com a écrit : Je ne me rappel plus si c'était un conseil d'édition (sans obligation) mais si possible on ne doit pas fusionner sur le même segment une route ou un cours d'eau avec un frontière. Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et fausser les limites administrative. Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre et je ne pense pas qu'on met à jour le cadastre après chaque hivers. Le 6 mars 2013 13:38, Philippe Verdy verd...@wanadoo.fr a écrit : Justement, des rivières, routes, voies ferrées sont parfois aussi des limites administratives. Et c'est là qu'on trouve le plus des source=inconnue ! Et ça commence à se propager ailleurs sur d'autres objets. Le 6 mars 2013 10:51, Pieren pier...@gmail.com a écrit : 2013/3/6 Philippe Verdy verd...@wanadoo.fr: On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. De quelle analyse Osmose parle-t-on ? La seule que je vois qui pourrait correspondre à un problème de source manquante est l'item 2040 mais cela ne concerne que les limites administratives. ___ 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 -- Cordialement, Francescu GAROBY ___ 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] source=inconnue
Pour les cours d'eau, ce sont des éléments physique qui sont mouvant alors que les frontières sont fixée. On peut avoir la même logique avec les routes dont les autorité locale peuvent modifier le tracé sans respecter à la lettre les frontière. Près de chez moi, un cours d'eau change doucement chaque année pourtant il est en plaine et le débit en hivers n'est pas très fort. J'avais par erreur modifier les frontières en suivant le cours d'eau mais le cadastre indiquai autre chose même si les écarts sont de quelques mètres, j'ai du tout séparer et réparer pendant une longue demie journée de perdue : http://osm.org/go/xVlCOin3O- Pareil pour les routes et ponts avec un exemple passant au dessus d'une autoroute : http://osm.org/go/xVlmmAVBA-- Après *ce n'est qu'un conseil d'édition*, c'est simplement pour éviter de créer/propager une erreur. Séparer les éléments physique des éléments immatériel me semble conseillé pour éviter de nombreuses heures de correction. Le 6 mars 2013 15:15, Pieren pier...@gmail.com a écrit : 2013/3/6 Francescu GAROBY windu...@gmail.com: commune, créant alors un vide, qui correspond au lit de la rivière. D'où le choix de prendre le tracé central dudit cours d'eau. J'ai rencontré des cas similaires avec des chemins. Soit une commune fixait la limite au milieu et l'autre commune au bord, soit chacune un bord avec un vide, soit chacune un bord avec superposition. Ou même un choix qui variait à l'intérieur de la commune d'une planche à l'autre... Evidemment, dans ces cas-là, on est obligé de faire un choix subjectif. A moins de contacter les maires des communes concernées pour savoir qui est en charge de l'entretien du dit chemin (en espérant qu'ils disent la même chose ;-) Certaines régions semblent plus touchées que d'autres par ces aberrations. On espère que la future intégration des cadastres DGFiP et IGN permettront de remettre à plat ces erreurs géométriques Et je plaide coupable (et j'assume complètement) le fait que, lorsqu'une frontière de commune et un tracé de cours d'eau/route se superpose, c'est ce dernier que je retiens pour les relations. Voyez là une interprétation de la règle le terrain prévaut. Le terrain n'a aucune valeur en matière de limite administrative puisqu'elle est invisible. Sauf si on peut voir sur le sol une jolie ligne blanche ou une clôture symbolisant cette limite dans certaines contrées. Je connais au moins un exemple de parcelles agricoles qui sont passées au fil des ans de l'autre côté d'un ruisseau (disons plutôt que c'est le ruisseau qui a bougé et pas les parcelles, hein). Et bien ces parcelles font toujours parties de la même commune. La règle du terrain prévaut est donc fausse dans ce cas. 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] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
J'ai interprété la zone à partir de l'application Crowdmap. Je suggère que cette application-ci soit révisée pour y mettre la carte OSM comme carte de base. La tâche suivante peut être utilisée pour cartographier la zone de Toliera (Tulear) à partir de l'imagerie Bing. http://tasks.hotosm.org/job/206 J'ai aussi publié un message twitter pour annoncer cette tâche. Vous pouvez faire un Retweet. https://twitter.com/pierzen Si la zone est mal définie, prière de m'aviser. Pierre De : Pierre Béland pierz...@yahoo.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 6 mars 2013 8h50 Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Voir le lien suivant où on peut observer l'imagerie Bing disponible. http://www.harrywood.co.uk/maps/bingosm.html?lat=-23.362526698877858lon=43.67677691268953zoom=18bingopacity=50 Nous pouvons définir une zone à cartographier et ajouter une tâche sur le Gestionnaire de tâches de HOT si vous le jugez à propos. Nous pourrons ainsi faire la carte OSM de base Avant. A partir de openstreetmap.org vous pouvez simplement zoomer pour definir la zone a couvrir. Le bouton exporter vous permettra d'obtenir les le bbox définissant cette zone, Je pourrai aussi alerter la communauté Humanitarian OpenStreetMap (HOT). Pierre Béland Humanitarian OpenStreetMap De : Marc SIBERT m...@sibert.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 6 mars 2013 7h49 Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Concernant le dernier point toute autre action..., je me posais la question de la disponibilité des images SPOT sous une licence compatible avec OSM afin que des contributeurs non-locaux (contributions dans le fauteuil :-) puissent participer. En particulier, suivant la date des images (avant/après) il sera possible d'affiner le bati sur la zone concernée par l'inondation et/ou d'indiquer dans OSM les détails visibles de l’infrastructure routière ; ces éléments pouvant servir de repère géographique pour des remontées d'informations locales. En cas de réponse positive, je pense (et je m'avance sur ce point) que l'asso OSM-FR pourra fournir les moyens techniques pour exploiter les images (tuilage, hébergement, etc.) Cordialement, A+ Le 6 mars 2013 11:23, Cédric Moro moro_geogra...@hotmail.com a écrit : Bonjour, Nous sommes une équipes de bénévoles qui intervenons actuellement sur le cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et Morombé. Le bilan provisoire d'hier est de : * 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara I, 1 Sakaraha, 4 Toliara II, 1 Betroka) ; * 16 disparus (Toliara I) ; * 127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29 Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano); * 40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II, 16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 265 CR Soanala, 115 CU Betroka, 2 459 Antakataka Sud, 1 315 Vangaindrano, 1 562 Ankazoabo) ; * 13 882 sans abris (892 Toliara I,2 000 Sakaraha, 2 271 Toliara II, 1 680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459 Antakataka Sud, 332 Vangaindrano, 1 562 Ankazoabo) ; * 7 402 cases totalement détruites (100 Sakahara, 120 Morombe, 1 729 Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 920 Toliara II) ; * 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044 Sakaraha, 372 Ampanihy, 32 Betroka) Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes pour des soins en urgence. Nos membres sont celui du VOST Francophone (nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue de la communauté des #MSGU, Médias sociaux en gestion d'urgence : http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity Road s'est également jointe à notre action. Grâce au travail d'impacts sur les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées d'infos des médias sociaux et sites internet, nous avons pu mieux orienter l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara. Nous utilisons une carte collaborative pour recenser les besoins humanitaires et améliorer la réponse de crise : https://haruna.crowdmap.com Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM et de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut car il nous permet d'avoir une vision en image satellite, importante pour comprendre la géographie locale tout comme pour bénéificier des infos toponymiques. Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie,
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Bonjour, Je viens de contacter M. JF Faudi de Spot Image (rencontré lors du barcamp 2010) pour lui demander les images originales libérées des contraintes de réutilisation. A+ Le 6 mars 2013 14:56, Cédric Moro moro_geogra...@hotmail.com a écrit : Merci de vos réponses. 1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci 2/ Images SPOT/Pléiades : Elles sont dispo à ces adresses : http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434 Nous avons eu un contact téléphonique et fait une demande écrite au SERTIT qui a effectué le traitement des images en télédétection. Nous avions une difficulté à importer leurs images KML dans crowdmap ou même googlemap et nous avons pu les ouvrir seulement dans Googleearth pour les avoir sous une forme géolocalisée. Le problème était que les traitements et légendes étaient incrustés dans le raster de l'image (qui n'est qu'une JPG) et pas sous forme d'objets vecteurs géoloc qui auraient été plus facilement exportables. Pour la région de Tuléar, nous avons donc mis des dizaines d'heures à refaire les polygones et points. On a perdu beaucoup de temps et de la précision, et sur cette zone seulement. Nous avons eu un contact avec le SERTIT hier soir et nous leur avons donc demander de bénéficier des couches de traitement en télédétection au format KML/KMZ pour pouvoir les intégrer à notre crowdmap, surtout pour d'autres régions touchées sur lesquelles nous n'avons pas encore déployé de données spatiales. La demande est en cours d'approbation au siège. Concernant l'utilisation des images satellites en dehors de la catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous rapporte (sans jugement personnel) : Les droits d'auteurs à de fins commerciales et la non réutilisation en dehors de la situation de la catastrophe naturelle et de sa réponse d'urgence. Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique des formats d'échange de données en période de catastrophe pour qu'à l'avenir, on ne perde plus autant de temps. 4/ Ceux qui gèrent la carte, dont moi, ne sommes pas sur le terrain mais en contact avec les acteurs sur place par téléphone et email , surtout avec les Pompiers de l'urgence internationale, et par Réseaux sociaux pour certains habitants sur place. 5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite. 6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais sur place, certains s'intéressent en détail dans la carto libre, je leur montrerai le chemin d'OSM et d'Ushahidi :-) Merci encore à tous et à bientôt, +33 5 35 54 19 27 Skype : roomilissimo Twitter : @Moro_Cedric Coordinateur du VOST Francophone Membre de la communauté MSGU (Médias sociaux en gestion d'urgence) Webmaster des Pompiers de l'urgence internationale www.pompiers-urgence.org www.i-resilience.fr Date: Wed, 6 Mar 2013 14:43:25 +0100 From: j...@arkemie.com To: talk-fr@openstreetmap.org; moro_geogra...@hotmail.com Subject: Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Le mieux est effectivement de récupérer les données directement chez Geofabrik, où elles sont mises à jour quotidiennement. Au cas où cela pourrait être utile, j'ai fait une conversion rapide de leurs shapefiles pour Madagascar en KML, avec ogr2ogr. Le résultat est dans : http://osm.arkemie.org/madagascar/madagascar.kml.zip et les fichiers individuels sont dans le répertoire : http://osm.arkemie.org/madagascar/ (Le fichier LISEZMOI liste les commandes - toutes simples - que j'ai utilisées). Lundi dernier, j'avais entré dans OSM les villages que je voyais dans Bing le long de la côte entre Toliara et Morombe, et qui n'y étaient pas déjà (emprises indiquées comme landuse=residential). Pour trouver les noms, j'ai eu l'impression que GNS (https://wiki.openstreetmap.org/wiki/GNS - http://geonames.nga.mil/ggmagaz/) est une source relativement précise et complète à Madagascar (par rapport à son état dans d'autres pays). Au point qu'il semble qu'on puisse même utiliser leur couche WMS pour trouver les lieux habités. (Et bien sûr leur moteur de recherche pour géolocaliser des lieux qui ne sont pas (encore) dans OSM). Je ne savais pas si ça avait une chance de servir. Content de voir que oui, et qu'il y a des gens sur le terrain. Bien cordialement, Jean-Guilhem Le 06/03/2013 13:15, Eric Sibert a écrit : Bonjour, Je connais pas mal Madagascar et un peu Tuléar. On peut trouver quelques généralités sur la cartographie du pays dans le wiki: http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette cartographie, notamment sur le centre-ville où les données sont
Re: [OSM-talk-fr] source=inconnue
JOSM ne va râler dns son validateur QUE si les segments qui se superposent utilisent les mêmes noeuds (gros carrés au lieux de petits carrés). Comme il est impossible de faire la différence, le fait d'avoir deux traits au lieu d'un seul, alors que ce sont les mêmes noeuds, n'empêchera jamais la modification du lit d'une riière ou d'une route de bouger aussi la limite administrative puisque ce seront de toute façon les mêmes noeuds qui seront déplacés. Bref si les noeuds sont déjà superposés, fusionner les segments communs a du sens et ne change rien au fait qu'ils peuvent bouger si la route ou la rivière a physiquement bougé. De plus si les plans cadastraux d'une commune et d'une autre ne sont pas d'accord sur la position des frontières, on est bien obligé de faire une conflation sur des éléments communs. Les défauts d'alignement sont nombreux, et si on n'est pas capable même de différencier les deux traits d'origine de la route ou de la rivière qui passe entre les deux, je ne vois strictement aucun intérêt à vouloir multiplier les tracés pour rien. Même si le cours d'eau bouge un peu ou est réaligné pour rester entre les tracé des rives, cela ne changera strictement rien à la précision du tracé des frontières administratives. Note: je ne parlais évidemment pas du cas où un cours d'eau change de lit pour passer par un autre bras en asséchant l'ancien. le bras mort reste là où il est, même si c'est une frontière administrative. Et s'il est alors utilisé pour faire quelquechose, les communes iront faire du repérage voire un bornage sur les parcelles afin de se partager récupérées les terrains équitablement, ou négocieront avec les propriétaires qui ne souhaiteraient pas garder des microparcelles séparées sur deux communes Les échanges de parcelles entre communes c'est assez courant, surtout lors de la construction de voiries, et quand cela se produit le cadastre est mis à jour dans l'année ; par exemple si pour aménager un carrefour au départ entièrement sur une commune, pour en faire un rond-point dont une infime partie va empiéter sur la commune voisine, qui ne veut pas prendre en charge les travaux et l'entretien de ce rond-point, une opération de cession de parcelles, va avoir lieu, ou d'échange équitable, et la limite entre les communes restera malgré tout au bord de ce même carrefour réaménagé C'est assez facile si les parcelles sont déjà dans le domaine public d'une des deux communes concernées, plus compliqué s'il faut pour ça des expropriations partielles de propriétés privées ou si l'aménagement coupe une propriété privée de telle façon qu'il reste alors une petite bande privée inutilisable par l'ancien propriétaire car devenu impossible à clotûrer par exemple pour n'en faire qu'un carré de pelouse; la commune devra acheter la bande résiduelle aussi. C'est plus compliqué aussi si un échange de parcelles n'est pas possible dans le même secteur pour conserver la surface des terres d'une des communes (et il n'est pas question pour des raisons fiscales de déplacer des propriétés privées d'une commune à l'autre, du moins pas sans l'accord des propriétaires qui pourraient cependant y être incités par d'autres mesures de compensation, y compris le fait de rendre une parcelle constructible ou lotissable, car viabilisée sans frais pour lui en même temps que l'arrivée de la nouvelle voirie et des réseaux qui vont avec) Le 6 mars 2013 14:58, Tetsuo Shima tets...@gmail.com a écrit : Quand physiquement ce n'est pas la meme chose il est souvent judicieux de ne pas le faire supporter par le meme objet effectivement ca evite des éditions sauvages lorsque qu'un cours d'eau est modifié a priori la limite administrative n'a pas a l’être trivialement. On a le meme souci avec les landuse supporté par des highway ou meme des building! Pour ce qui est d'avoir deux objet superposé et de même géométrie ca génere une alerte certes mais ce n'est pas forcément un doublon. Le 6 mars 2013 14:07, Jo. perche...@gmail.com a écrit : Je ne me rappel plus si c'était un conseil d'édition (sans obligation) mais si possible on ne doit pas fusionner sur le même segment une route ou un cours d'eau avec un frontière. Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et fausser les limites administrative. Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre et je ne pense pas qu'on met à jour le cadastre après chaque hivers. Le 6 mars 2013 13:38, Philippe Verdy verd...@wanadoo.fr a écrit : Justement, des rivières, routes, voies ferrées sont parfois aussi des limites administratives. Et c'est là qu'on trouve le plus des source=inconnue ! Et ça commence à se propager ailleurs sur d'autres objets. Le 6 mars 2013 10:51, Pieren pier...@gmail.com a écrit : 2013/3/6 Philippe Verdy verd...@wanadoo.fr: On dirait que cela a été ajouté uniquement pour faire disparaître le marquage dans Osmose, sans rien corriger du tout. De quelle analyse Osmose parle-t-on ?
Re: [OSM-talk-fr] Bassins versants
Les outils non graphiques que tu cites sont puissants mais mériteraient un peu d'affinage visuel, ainsi que quelques règles complémentaires d'analyse, par exemple pour évacuer des résultats les bras secondaires. Il y a également l'outil d'Arno Renevier, qui reste bloqué en 2012. http://renevier.net/maps/rivers/ J'ai essayé de le faire tourner chez moi sur la base des sources disponibles, et j'ai l'impression qu'il a du mal à digérer les noeuds les plus récents (ceux avec l'id à la limite 32 bit ?). Pas eu le temps de vérifier ça. Le 18 février 2013 17:49, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 18 février 2013 17:33, Ab_fab gamma@gmail.com a écrit : Ou comment _ extraire les données (filaires) relatives aux cours d'eau d'un extrait Geofabrik, _ les analyser https://github.com/skaringa/rivers pour constituer les grands bassins versants, _ et finalement en faire le rendu Il y deux approches : - topologique - relationnelle Les cours d'eau que l'algo n'arrive pas à rattacher à un bassin versant sont affichés en gris. C ela permet de mettre en évidence les défauts de connexion dans le filaire des cours d'eau Ca a l'air sympa, à première vue. Je ne sais pas si ce serait facilement transposable à la France On à déjà deux outil, non graphique pour faire ça, suivant deux approches différentes : - http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html (à la sly) - http://suivi.openstreetmap.fr/cours-eau/suivi-affluents.html (à la fred (moi)) Frédéric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Maperitive + relation
Le message suivant de : ## Bonjour je cherche a faire mon premier rendu avec maperitive mais j'ai quelques soucis et je fais donc appel a vous je n'arrive pas a extraire d'une relation certains éléments contenus dedans ex : la relation Transilien N mais seulement les gares , il me dessine le long de toutes les voies extrait du fichier de règles utilisé [code] lines railway station N : relation[name=Transilien N and type=route and route=train] .../... rules target : railway station N define icon-image : icons/SJJB/png/16px-Logo_Paris_Transilien_ligneN.svg.png min-zoom : 10 icon-width : 32 draw : icon [/code] si vous avez des conseils ... a été posté sur le forum http://forum.openstreetmap.fr/viewtopic.php?f=3t=553 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleures réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Le 6 mars 2013 16:01, Ab_fab gamma@gmail.com a écrit : Les outils non graphiques que tu cites sont puissants mais mériteraient un peu d'affinage visuel, ainsi que quelques règles complémentaires d'analyse, par exemple pour évacuer des résultats les bras secondaires. Les bras secondaires sont normalement tagués avec un rôle side_stream, au lieu du rôle par défaut main_stream, quand les deux types sont présents. Pour les cours d'eau qui forment une seule ligne continue, souvent il n'y a aucun rôle défini, mais c'est à interpréter comme main_stream. Dans certains cas, il n'y a aucun rôle défini mais on déduit le side-stream au fait que ses deux extrémités ne sont les extrémités d'aucun autre chemin, mais seulement des points communs à un même chemin. Des ambiguïtés existent dans des cas comme celui-ci: A---B---C \\ DEF où les deux chemins créés sont ABCE et BDEF : lequel des deux bras BCE ou BDE est le bras principal, l'autre un bras secondaire ? Sans un rôle pour l'indiquer sur chaque chemin dans une même relation, ou sans relation pour les regrouper avec ces rôles ce n'est pas possible de le déterminer géométriquement. Si les chemins ont été créés sous la forme ABCEF et BDE, on pourrait en déduire par défaut que BDE est un bras secondaire ; mais si les chemins sont AB, BCE, BDE et EF, on ne sait pas faire cette déduction; pourtant géométriquement parlant, ces différentes solutions produisent la même chose, et sans indication des débits sur chaque bras, ou sans indication d'un rôle dans une relation-maître, ou sans déduction par observation des largeurs de lits ou des riverbanks quand ils ont été tracés aussi, ou de la dynamique de volumes d'eau en déplacement qui ne peuvent pas changer facilement de direction et privilégieront le chemin le plus en ligne droite et capable d'évacuer en aval la plus grande hauteur d'eau, on ne peut pas toujours réellement décider (cela demande une analyse plus fine que la seule largeur car les hauteurs de fonds en aval jouent aussi un rôle sur les débits que chaque bras peuvent évacuer, sinon ce bras déjà rempli devient un mur d'eau s'opposant au passage et forçant plus d'eau à passer par l'autre bras, même si la lame d'eau doit faire un virage). Cela ne fait en général pas de grosses différences sur le calcul de la longueur totale du cours d'eau (il y a déjà des différences accumulées tout le long du cours par la seule estimation du cours central). Parfois ce choix du bras principal reste arbitraire, sujet à l'interprétation. Par exemple le cours principal d'une rivière reste la partie la plus large supposée écouler le débit d'eau le plus important, même si elle est partiellement fermée par un seuil (pour maintenir un niveau d'eau suffisant en amont) et non franchissable pour la navigation, alors que l'autre est plus étroit, canalisé et fermé par une écluse, mais alors navigable (mais pas adapté pour écouler les volumes d'eau, l'écluse étant destinée à rester toujours fermée au moins sur une des deux portes). Mais il existe aussi des cas où les bras secondaires sont aussi créés uniquement par un seuil à débordement (le bras restant quasiment à sec ou avec une circulation d'eau infime juste destinée à éviter que l'eau n'y croupisse, sauf en cas de crue où le niveau d'eau dépasse la hauteur du seuil), ce seuil pouvant aussi être réglé par la présence de vannes, quitte même à ce que le bras secondaire vienne lui-même inonder certaines terres non construites pour que le bras principal ne provoque pas d'inondations causant des dommages importants. Cela crée donc des bras morts qui sont malgré tout conservés pour cet usage de gestion des crues. Dans des cas comme celui de la Loire à Nantes, il n'est pas possible de décider lequel des deux bras principaux est LE bras principal. Au milieu il y a une île, assez grande d'ailleurs et habitée, les deux bras sont navigables, aucun n'est fermé par un seuil. C'est difficile de dire lequel est le cours principal et d'ailleurs chaque bras a son propre nom, distinct du nom du fleuve entier. Dans des cas comme ça, le choix du bras principal résulte alors d'une simple tradition locale sans tenir compte des débits (un bras considéré comme principal en terme de débit écoulé pendant des périodes normales, pourrait devenir secondaire en période de crue, et suite à une crue la part respective de chaque bras pourrait changer à cause de l'effet de vidange des fonds causés par la crue, ou de comblement au contraire d'un des bras par des charriages alluvionnaires conséquents ayant réhaussé les fonds d'un des bras en aval). Et les travaux humains de curage (ou désensablage) d'un chenal d'écoulement, peuvent aussi changer cette répartition des eaux, sans pourtant rien changer au dessin des rives et de la surface de la nappe d'eau en surface visible en période normale. ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Une tâches est maintenant définie pour la zone de Toliara dans le Gestionnaire de HOT (http://tasks.hotosm.org/job/206). Les images du Disaster Chapter concernent aussi le zones de Sakaraha et Morombe. Nous devrons décider du type de travail carto à effectuer et à partir de quelles images (Bing ou SPOT). En ce qui a trait à l'import de données dans OSM, nous n'avons aucun problème de licence avec Bing, et si nécessaire vous pouver demander à ajouter des tâches pour d'autres zones que Toliara. Par contre, il est nécessaire d'éclaircir la question des licences des images SPOT. Permet-on ou non l'import dans OSM (Licence ODbl incluant à des fins commerciales) dans le contexte de cette urgence humanitaire? Aussi, pour le traitement des infos post-sinistre, immeubles touchés etc., il faudrait décider de ce qui doit être fait. Je fais aussi faire rapport sur la liste de discussion de HOT http://lists.openstreetmap.org/listinfo/hot. Pierre De : Marc SIBERT m...@sibert.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 6 mars 2013 9h36 Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Je viens de contacter M. JF Faudi de Spot Image (rencontré lors du barcamp 2010) pour lui demander les images originales libérées des contraintes de réutilisation. A+ Le 6 mars 2013 14:56, Cédric Moro moro_geogra...@hotmail.com a écrit : Merci de vos réponses. 1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci 2/ Images SPOT/Pléiades : Elles sont dispo à ces adresses : http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434 Nous avons eu un contact téléphonique et fait une demande écrite au SERTIT qui a effectué le traitement des images en télédétection. Nous avions une difficulté à importer leurs images KML dans crowdmap ou même googlemap et nous avons pu les ouvrir seulement dans Googleearth pour les avoir sous une forme géolocalisée. Le problème était que les traitements et légendes étaient incrustés dans le raster de l'image (qui n'est qu'une JPG) et pas sous forme d'objets vecteurs géoloc qui auraient été plus facilement exportables. Pour la région de Tuléar, nous avons donc mis des dizaines d'heures à refaire les polygones et points. On a perdu beaucoup de temps et de la précision, et sur cette zone seulement. Nous avons eu un contact avec le SERTIT hier soir et nous leur avons donc demander de bénéficier des couches de traitement en télédétection au format KML/KMZ pour pouvoir les intégrer à notre crowdmap, surtout pour d'autres régions touchées sur lesquelles nous n'avons pas encore déployé de données spatiales. La demande est en cours d'approbation au siège. Concernant l'utilisation des images satellites en dehors de la catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous rapporte (sans jugement personnel) : Les droits d'auteurs à de fins commerciales et la non réutilisation en dehors de la situation de la catastrophe naturelle et de sa réponse d'urgence. Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique des formats d'échange de données en période de catastrophe pour qu'à l'avenir, on ne perde plus autant de temps. 4/ Ceux qui gèrent la carte, dont moi, ne sommes pas sur le terrain mais en contact avec les acteurs sur place par téléphone et email , surtout avec les Pompiers de l'urgence internationale, et par Réseaux sociaux pour certains habitants sur place. 5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite. 6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais sur place, certains s'intéressent en détail dans la carto libre, je leur montrerai le chemin d'OSM et d'Ushahidi :-) Merci encore à tous et à bientôt, +33 5 35 54 19 27 Skype : roomilissimo Twitter : @Moro_Cedric Coordinateur du VOST Francophone Membre de la communauté MSGU (Médias sociaux en gestion d'urgence) Webmaster des Pompiers de l'urgence internationale www.pompiers-urgence.org www.i-resilience.fr Date: Wed, 6 Mar 2013 14:43:25 +0100 From: j...@arkemie.com To: talk-fr@openstreetmap.org; moro_geogra...@hotmail.com Subject: Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Le mieux est effectivement de récupérer les données directement chez Geofabrik, où elles sont mises à jour quotidiennement. Au cas où cela pourrait être utile, j'ai fait une conversion rapide de leurs shapefiles pour Madagascar en KML, avec ogr2ogr. Le résultat est dans : http://osm.arkemie.org/madagascar/madagascar.kml.zip et les fichiers individuels sont dans le répertoire : http://osm.arkemie.org/madagascar/ (Le fichier LISEZMOI liste les commandes - toutes simples - que j'ai utilisées).
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Concernant les images provenant du Sertit, c'est clairement : non ! Les conditions de réutilisation des images se limitent à l'usage non commercial. Évidemment, il ne s'agit pas ici de réutiliser les images elles-même, mais le produit du travail de vectorisation. Mais AMHA ça ne change rien. D'où ma demande à SpotImage, à la source des images. A+ Le 6 mars 2013 17:06, Pierre Béland pierz...@yahoo.fr a écrit : Une tâches est maintenant définie pour la zone de Toliara dans le Gestionnaire de HOT (http://tasks.hotosm.org/job/206). Les images du Disaster Chapter concernent aussi le zones de Sakaraha et Morombe. Nous devrons décider du type de travail carto à effectuer et à partir de quelles images (Bing ou SPOT). En ce qui a trait à l'import de données dans OSM, nous n'avons aucun problème de licence avec Bing, et si nécessaire vous pouver demander à ajouter des tâches pour d'autres zones que Toliara. Par contre, il est nécessaire d'éclaircir la question des licences des images SPOT. Permet-on ou non l'import dans OSM (Licence ODbl incluant à des fins commerciales) dans le contexte de cette urgence humanitaire? Aussi, pour le traitement des infos post-sinistre, immeubles touchés etc., il faudrait décider de ce qui doit être fait. Je fais aussi faire rapport sur la liste de discussion de HOT http://lists.openstreetmap.org/listinfo/hot. Pierre -- *De :* Marc SIBERT m...@sibert.fr *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Mercredi 6 mars 2013 9h36 *Objet :* Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Je viens de contacter M. JF Faudi de Spot Image (rencontré lors du barcamp 2010) pour lui demander les images originales libérées des contraintes de réutilisation. A+ Le 6 mars 2013 14:56, Cédric Moro moro_geogra...@hotmail.com a écrit : Merci de vos réponses. 1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci 2/ Images SPOT/Pléiades : Elles sont dispo à ces adresses : http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434 Nous avons eu un contact téléphonique et fait une demande écrite au SERTIT qui a effectué le traitement des images en télédétection. Nous avions une difficulté à importer leurs images KML dans crowdmap ou même googlemap et nous avons pu les ouvrir seulement dans Googleearth pour les avoir sous une forme géolocalisée. Le problème était que les traitements et légendes étaient incrustés dans le raster de l'image (qui n'est qu'une JPG) et pas sous forme d'objets vecteurs géoloc qui auraient été plus facilement exportables. Pour la région de Tuléar, nous avons donc mis des dizaines d'heures à refaire les polygones et points. On a perdu beaucoup de temps et de la précision, et sur cette zone seulement. Nous avons eu un contact avec le SERTIT hier soir et nous leur avons donc demander de bénéficier des couches de traitement en télédétection au format KML/KMZ pour pouvoir les intégrer à notre crowdmap, surtout pour d'autres régions touchées sur lesquelles nous n'avons pas encore déployé de données spatiales. La demande est en cours d'approbation au siège. Concernant l'utilisation des images satellites en dehors de la catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous rapporte (sans jugement personnel) : Les droits d'auteurs à de fins commerciales et la non réutilisation en dehors de la situation de la catastrophe naturelle et de sa réponse d'urgence. Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique des formats d'échange de données en période de catastrophe pour qu'à l'avenir, on ne perde plus autant de temps. 4/ Ceux qui gèrent la carte, dont moi, ne sommes pas sur le terrain mais en contact avec les acteurs sur place par téléphone et email , surtout avec les Pompiers de l'urgence internationale, et par Réseaux sociaux pour certains habitants sur place. 5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite. 6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais sur place, certains s'intéressent en détail dans la carto libre, je leur montrerai le chemin d'OSM et d'Ushahidi :-) Merci encore à tous et à bientôt, +33 5 35 54 19 27 Skype : roomilissimo Twitter : @Moro_Cedric Coordinateur du VOST Francophone Membre de la communauté MSGU (Médias sociaux en gestion d'urgence) Webmaster des Pompiers de l'urgence internationale www.pompiers-urgence.org www.i-resilience.fr Date: Wed, 6 Mar 2013 14:43:25 +0100 From: j...@arkemie.com To: talk-fr@openstreetmap.org; moro_geogra...@hotmail.com Subject: Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Le mieux est effectivement de récupérer les données
Re: [OSM-talk-fr] Bassins versants
Ça doit être intéressant, mais c'est vraiment trop long (détaillé). J'aimerais comprendre comment vous tagguez les bras multiples et // tl;dr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Le 6 mars 2013 15:33, Jo. perche...@gmail.com a écrit : Après ce n'est qu'un conseil d'édition, c'est simplement pour éviter de créer/propager une erreur. Séparer les éléments physique des éléments immatériel me semble conseillé pour éviter de nombreuses heures de correction. Tout peut bouger sur une carte au cours du temps, que ce soit les éléments matériels ou les éléments immatériels. Bref on aura toujours des corrections à faire pour tenir compte de ça. Une carte se révise donc dans tous les cas. Mais si dans un état actuel on ne sait pas faire de différence entre deux éléments, la conflation s'impose tant que les différences ne sont pas assez significatives. Car même les frontières administratives ne sont pas encore elles-mêmes en conflation d'une commune à l'autre, ce qui laisse assez d'écart pour que la confusion des deux tracés se confonde aussi avec le tracé de l'élément matériel. Le cadastre est justement un bon exemple puisqu'il est maintenu commune par commune mais quand une commune se limite sur la tracé d'un cours d'eau, il n'y a que le tracé jusqu'aux rives existantes qui soit significatif, le tracé au milieu du cours d'eau est très indicatif et se superpose en fait rarement avec le tracé tout aussi indicatif de la planche cadastrale de la commune voisine. Pour les deux communes pourtant cela ne fait aucune différence, elles sont appelées à gérer en commun le cours d'eau et ses aménagements, et ne peuvent pas intervenir sur le tracé de leurs rives sans impacter l'autre rive. Il me semble même que tous les travaux sur un cours d'eau ou sur ses rives ne peuvent se faire qu'en concertation avec l'agence de bassin car cela peut impacter d'autres communes beaucoup plus loin pour la gestion des crues. Bref la compétence administrative exclusive d'une commune s'arrêtera à sa propre rive, le lit lui-même reste une compétence partagée par toutes les communes traversées ou longeant un cours d'eau. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Dans des cas comme celui de la Loire à Nantes, il n'est pas possible de décider lequel des deux bras principaux est LE bras principal. Au milieu il y a une île, assez grande d'ailleurs et habitée, les deux bras sont navigables, aucun n'est fermé par un seuil. C'est difficile de dire lequel est le cours principal et d'ailleurs chaque bras a son propre nom, distinct du nom du fleuve entier. J'ai grandi à moins de 500 mètres du bras de pirmil, donc je connais bien (et ce n'est pas la première fois que l'on en parle sur cette liste). C'est d'autant plus délicat que la Sèvre Nantaise se jette dans le bras de Pirmil (au sud), et l'Erdre dans le bras de la Madeleine (au nord). C'est un cas particulier, on peut vivre avec, par exemple en y allant de manière arbitraire pour définir le bras principal et le bras secondaire. Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent justement pas compte de ces rôles side_stream ou main_stream. Cela fausse et alourdit les résultats. Ce serait chouette que les résultats de ces analyses puissent être rendus plus clairs sur ces aspects. Cela faciliterait la recherche des zones où il est possible d'améliorer le filaire des cours d'eau et leur continuité Le 6 mars 2013 17:05, Philippe Verdy verd...@wanadoo.fr a écrit : Le 6 mars 2013 16:01, Ab_fab gamma@gmail.com a écrit : Les outils non graphiques que tu cites sont puissants mais mériteraient un peu d'affinage visuel, ainsi que quelques règles complémentaires d'analyse, par exemple pour évacuer des résultats les bras secondaires. Les bras secondaires sont normalement tagués avec un rôle side_stream, au lieu du rôle par défaut main_stream, quand les deux types sont présents. Pour les cours d'eau qui forment une seule ligne continue, souvent il n'y a aucun rôle défini, mais c'est à interpréter comme main_stream. Dans certains cas, il n'y a aucun rôle défini mais on déduit le side-stream au fait que ses deux extrémités ne sont les extrémités d'aucun autre chemin, mais seulement des points communs à un même chemin. Des ambiguïtés existent dans des cas comme celui-ci: A---B---C \\ DEF où les deux chemins créés sont ABCE et BDEF : lequel des deux bras BCE ou BDE est le bras principal, l'autre un bras secondaire ? Sans un rôle pour l'indiquer sur chaque chemin dans une même relation, ou sans relation pour les regrouper avec ces rôles ce n'est pas possible de le déterminer géométriquement. Si les chemins ont été créés sous la forme ABCEF et BDE, on pourrait en déduire par défaut que BDE est un bras secondaire ; mais si les chemins sont AB, BCE, BDE et EF, on ne sait pas faire cette déduction; pourtant géométriquement parlant, ces différentes solutions produisent la même chose, et sans indication des débits sur chaque bras, ou sans indication d'un rôle dans une relation-maître, ou sans déduction par observation des largeurs de lits ou des riverbanks quand ils ont été tracés aussi, ou de la dynamique de volumes d'eau en déplacement qui ne peuvent pas changer facilement de direction et privilégieront le chemin le plus en ligne droite et capable d'évacuer en aval la plus grande hauteur d'eau, on ne peut pas toujours réellement décider (cela demande une analyse plus fine que la seule largeur car les hauteurs de fonds en aval jouent aussi un rôle sur les débits que chaque bras peuvent évacuer, sinon ce bras déjà rempli devient un mur d'eau s'opposant au passage et forçant plus d'eau à passer par l'autre bras, même si la lame d'eau doit faire un virage). Cela ne fait en général pas de grosses différences sur le calcul de la longueur totale du cours d'eau (il y a déjà des différences accumulées tout le long du cours par la seule estimation du cours central). Parfois ce choix du bras principal reste arbitraire, sujet à l'interprétation. Par exemple le cours principal d'une rivière reste la partie la plus large supposée écouler le débit d'eau le plus important, même si elle est partiellement fermée par un seuil (pour maintenir un niveau d'eau suffisant en amont) et non franchissable pour la navigation, alors que l'autre est plus étroit, canalisé et fermé par une écluse, mais alors navigable (mais pas adapté pour écouler les volumes d'eau, l'écluse étant destinée à rester toujours fermée au moins sur une des deux portes). Mais il existe aussi des cas où les bras secondaires sont aussi créés uniquement par un seuil à débordement (le bras restant quasiment à sec ou avec une circulation d'eau infime juste destinée à éviter que l'eau n'y croupisse, sauf en cas de crue où le niveau d'eau dépasse la hauteur du seuil), ce seuil pouvant aussi être réglé par la présence de vannes, quitte même à ce que le bras secondaire vienne lui-même inonder certaines terres non construites pour que le bras principal ne provoque pas d'inondations causant des dommages importants. Cela crée donc des bras morts qui sont malgré
Re: [OSM-talk-fr] Bassins versants
Le 6 mars 2013 17:14, Marc SIBERT m...@sibert.fr a écrit : Ça doit être intéressant, mais c'est vraiment trop long (détaillé). J'aimerais comprendre comment vous tagguez les bras multiples et // Quelle mauvaise foi tu as ! C'était déjà marqué plus court dans un message précédent que tu n'as pas lu non plus ! - le cours principal : rôle main_stream dans la relation du cours d'eau (membres de type way uniquement, avec waterway=river/stream/etc...) - tous les autres bras secondaires : rôle side_stream (membres de type way uniquement, avec waterway=river/stream/etc...) Les riverbanks sont à part, dans des polygones successifs ou dans une relation multipolygone qui les incluent tous sous forme fermée (rôle outer) ou sous forme de série de chemins ouverts formant une boucle fermée (rôle outer), avec parfois des boucles fermées de rôle inner pour les îles créés par les différents bras. En principe si on commence à créer un multipolygone pour une riverbank, on devrait les fusionner dans la même relation sauf pour les sections couvertes taguées en tunnel=yes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Bonjour, J'ai eu à connaitre à titre professionnel un conflit de ce type à l'ONF ou 3 départements et deux régions se disputait 15 hectares de forêts suite à des arrangement cadastraux ( reports des erreurs en limites de communes). J'en ai eu connaissance en 1974. En 1995 une même surface était toujours revendiqué par 2 régions différentes ONF dans les base informatiques. Sur le terrain (source photo aérienne) la limite de plantation, valant limite concrète était éloigné d'une centaine de mètres de la limite légale administrative. Et pourtant, j'ai entendu dire que 3 préfets s'étaient déplacé sur le terrain pour régler ca ... alors, je vous (nous souhaite bien du plaisir pour démerder certaines zones. (Zone : les 3 limites cantal haute-loire Lozère) Bien cordialement -- View this message in context: http://gis.19327.n5.nabble.com/source-inconnue-tp5752013p5752114.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Il est possible d'attribuer dans la relation waterway : _ un rôle main_stream sur le(s) way(s) du bras que l'on définit comme principal, _ un rôle side_stream sur le(s) way(s) du/des bras que l'on détermine comme secondaire(s) Ces règles sont plutôt récentes, et l'usage s'est répandu après que les principaux outils de suivi que l'on connait ont été développés (si ma mémoire est bonne). J'espère qu'un jour il y aura un mashup sympa de tous ces outils permettant d'avoir une bonne vision d'ensemble de l'avancement et des zones à améliorer. Le 6 mars 2013 17:14, Marc SIBERT m...@sibert.fr a écrit : Ça doit être intéressant, mais c'est vraiment trop long (détaillé). J'aimerais comprendre comment vous tagguez les bras multiples et // tl;dr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Le 6 mars 2013 17:29, Ab_fab gamma@gmail.com a écrit : Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent justement pas compte de ces rôles side_stream ou main_stream. Cela fausse et alourdit les résultats. En quoi cela fausse les résultats ? Si tu ne fais pas de différence, la longueur du cours d'eau s'en ressent sensiblement, tu vas cumuler par endroits des longueurs 2 ou 3 fois. Pourtant l'outil doit être capable de déterminer si parmi l'ensemble des chemins main_stream cela forme une ligne continue ou pas. Ensuite s'il reste des segments, l'outil peut signaler que certains devraient passer en side_stream pour former un unique chemin main_stream. Puis si le cours d'eau main_stream n'est toujours pas continu de bout en bout, il peut chercher parmi les sans rôle défini, ou sinon parmi les side_stream ceux qui peuvent combler les trous et les signaler comme des main_stream candidats. Le reste des chemins sans rôle peut enfin être signalé comme devant être des side_stream. Une fois qu'on a un cours d'eau continu, la direction du cours devrait être consistante (on peut signaler alors les sections médianes stipulées dans le sens opposé. Une fois ces ignalement faits, on peut corriger, et finalement obtenir un graphe orienté de main_streams pour les cours d'eau et former les relations tributary des affluents. Là encore l'orientation est vérifiable, un tributary devant avoir un noeud commun avec le cours vers lequel il se termine. Cas particulier: un canal peut avoir une direction changeante : il peut monter et redescendre via des jeux d'écluses (exemple le canal d'Ille-et-Rance qui a son point haut au milieu, aux écluses d'Hédé). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Marc, Compte-tenu que nous avons l'autorisation d'utiliser l'imagerie Bing pour ces zones, j'ai ajouté une tâche pour Sakaraha http://tasks.hotosm.org/job/207. Cependant l'imagerie Bing Haute définition n'est pas disponible pour Morombe. D'où l'importance d'obtenir l'autorisation d'utiliser l'imagerie SPOT ou d'autre. Jean-Guilhem, aurions-nous une chance avec d'autres sources? Pierre De : Marc SIBERT m...@sibert.fr À : Pierre Béland pierz...@yahoo.fr; Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 6 mars 2013 11h10 Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Concernant les images provenant du Sertit, c'est clairement : non ! Les conditions de réutilisation des images se limitent à l'usage non commercial. Évidemment, il ne s'agit pas ici de réutiliser les images elles-même, mais le produit du travail de vectorisation. Mais AMHA ça ne change rien. D'où ma demande à SpotImage, à la source des images. A+ Le 6 mars 2013 17:06, Pierre Béland pierz...@yahoo.fr a écrit : Une tâches est maintenant définie pour la zone de Toliara dans le Gestionnaire de HOT (http://tasks.hotosm.org/job/206). Les images du Disaster Chapter concernent aussi le zones de Sakaraha et Morombe. Nous devrons décider du type de travail carto à effectuer et à partir de quelles images (Bing ou SPOT). En ce qui a trait à l'import de données dans OSM, nous n'avons aucun problème de licence avec Bing, et si nécessaire vous pouver demander à ajouter des tâches pour d'autres zones que Toliara. Par contre, il est nécessaire d'éclaircir la question des licences des images SPOT. Permet-on ou non l'import dans OSM (Licence ODbl incluant à des fins commerciales) dans le contexte de cette urgence humanitaire? Aussi, pour le traitement des infos post-sinistre, immeubles touchés etc., il faudrait décider de ce qui doit être fait. Je fais aussi faire rapport sur la liste de discussion de HOT http://lists.openstreetmap.org/listinfo/hot. Pierre De : Marc SIBERT m...@sibert.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 6 mars 2013 9h36 Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. Bonjour, Je viens de contacter M. JF Faudi de Spot Image (rencontré lors du barcamp 2010) pour lui demander les images originales libérées des contraintes de réutilisation. A+ Le 6 mars 2013 14:56, Cédric Moro moro_geogra...@hotmail.com a écrit : Merci de vos réponses. 1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci 2/ Images SPOT/Pléiades : Elles sont dispo à ces adresses : http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434 Nous avons eu un contact téléphonique et fait une demande écrite au SERTIT qui a effectué le traitement des images en télédétection. Nous avions une difficulté à importer leurs images KML dans crowdmap ou même googlemap et nous avons pu les ouvrir seulement dans Googleearth pour les avoir sous une forme géolocalisée. Le problème était que les traitements et légendes étaient incrustés dans le raster de l'image (qui n'est qu'une JPG) et pas sous forme d'objets vecteurs géoloc qui auraient été plus facilement exportables. Pour la région de Tuléar, nous avons donc mis des dizaines d'heures à refaire les polygones et points. On a perdu beaucoup de temps et de la précision, et sur cette zone seulement. Nous avons eu un contact avec le SERTIT hier soir et nous leur avons donc demander de bénéficier des couches de traitement en télédétection au format KML/KMZ pour pouvoir les intégrer à notre crowdmap, surtout pour d'autres régions touchées sur lesquelles nous n'avons pas encore déployé de données spatiales. La demande est en cours d'approbation au siège. Concernant l'utilisation des images satellites en dehors de la catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous rapporte (sans jugement personnel) : Les droits d'auteurs à de fins commerciales et la non réutilisation en dehors de la situation de la catastrophe naturelle et de sa réponse d'urgence. Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique des formats d'échange de données en période de catastrophe pour qu'à l'avenir, on ne perde plus autant de temps. 4/ Ceux qui gèrent la carte, dont moi, ne sommes pas sur le terrain mais en contact avec les acteurs sur place par téléphone et email , surtout avec les Pompiers de l'urgence internationale, et par Réseaux sociaux pour certains habitants sur place. 5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite. 6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais sur place, certains
[OSM-talk-fr] les POI de Mapnik
Bonjour Existe t-il une liste des POI rendus par Mapnik ? Emilie (la bretonne) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Le 6 mars 2013 17:43, Philippe Verdy verd...@wanadoo.fr a écrit : Le 6 mars 2013 17:29, Ab_fab gamma@gmail.com a écrit : Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent justement pas compte de ces rôles side_stream ou main_stream. Cela fausse et alourdit les résultats. En quoi cela fausse les résultats ? Si tu ne fais pas de différence, la longueur du cours d'eau s'en ressent sensiblement, tu vas cumuler par endroits des longueurs 2 ou 3 fois. Cela fausse les résultats en indiquant que le cours d'eau est en plusieurs segments (et donc implicitement qu'il y a des coupures), alors qu'en réalité tout est ok. Cela ne permet pas de mettre en évidence les cours d'eau pour lesquels il y a vraiment une amélioration à apporter. Voir la Durance, depuis l'outil de Sly : il indique trois tronçons, mais en pratique il y a juste un bras secondaire à Chateau-Arnoux - Saint Auban quand on consulte l'analyseur de relation http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html Pourtant l'outil doit être capable de déterminer si parmi l'ensemble des chemins main_stream cela forme une ligne continue ou pas. Ensuite s'il reste des segments, l'outil peut signaler que certains devraient passer en side_stream pour former un unique chemin main_stream. Il devrait, oui, mais c'est justement pas le cas avec les outils dans leur état actuel. Si j'en étais capable, j'aimerais bien améliorer ce genre de choses. Puis si le cours d'eau main_stream n'est toujours pas continu de bout en bout, il peut chercher parmi les sans rôle défini, ou sinon parmi les side_stream ceux qui peuvent combler les trous et les signaler comme des main_stream candidats. Le reste des chemins sans rôle peut enfin être signalé comme devant être des side_stream. Une fois qu'on a un cours d'eau continu, la direction du cours devrait être consistante (on peut signaler alors les sections médianes stipulées dans le sens opposé. Une fois ces ignalement faits, on peut corriger, et finalement obtenir un graphe orienté de main_streams pour les cours d'eau et former les relations tributary des affluents. Là encore l'orientation est vérifiable, un tributary devant avoir un noeud commun avec le cours vers lequel il se termine. Oui oui Cas particulier: un canal peut avoir une direction changeante : il peut monter et redescendre via des jeux d'écluses (exemple le canal d'Ille-et-Rance qui a son point haut au milieu, aux écluses d'Hédé). C'est un cas particulier, on peut vivre avec ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Si les autorités sont incapables de démerder la situation légalement, je ne vois pas en quoi le fait de créer une conflation nous-même serait plus fausse que les autres solutions théoriquement officielles mais pas d'accord entre elles ! Dans des cas comme ça, on consacre l'usage, donc ici dans le cas de cette forêt, la limite concrète de cette forêt (on reverra ça uniquement le jour où les autorités administratives se mettront d'accord, mais on peut malgré tout marquer notre conflation comme ne correspondant à aucune définition officielle puisque celle-ci tout bonnement... n'existe pas encore !). On résoud comme cela le cas pratique par la règle du terrain, et cela ne sert strictement à rien de multiplier les traits contradictoires selon les sources. Le 6 mars 2013 17:36, PhQ pierre.que...@sfr.fr a écrit : Bonjour, J'ai eu à connaitre à titre professionnel un conflit de ce type à l'ONF ou 3 départements et deux régions se disputait 15 hectares de forêts suite à des arrangement cadastraux ( reports des erreurs en limites de communes). J'en ai eu connaissance en 1974. En 1995 une même surface était toujours revendiqué par 2 régions différentes ONF dans les base informatiques. Sur le terrain (source photo aérienne) la limite de plantation, valant limite concrète était éloigné d'une centaine de mètres de la limite légale administrative. Et pourtant, j'ai entendu dire que 3 préfets s'étaient déplacé sur le terrain pour régler ca ... alors, je vous (nous souhaite bien du plaisir pour démerder certaines zones. (Zone : les 3 limites cantal haute-loire Lozère) Bien cordialement -- View this message in context: http://gis.19327.n5.nabble.com/source-inconnue-tp5752013p5752114.html Sent from the France mailing list archive at Nabble.com. ___ 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] les POI de Mapnik
Pour le rendu Mapnik du site principal openstreetmap.org, tu peux regarder ici : https://github.com/gravitystorm/openstreetmap-carto Et plus particulièrement ici : https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-symbols.mss (...) (sans garantie d'exhaustivité) Le 6 mars 2013 17:48, Emivi cybervaldi...@gmail.com a écrit : Bonjour Existe t-il une liste des POI rendus par Mapnik ? Emilie (la bretonne) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] les POI de Mapnik
Bonjour Émilie, Est-ce que le répertoire des pictos mapnik convient ? http://svn.openstreetmap.org/applications/rendering/mapnik/symbols/ Le 6 mars 2013 18:12, Ab_fab gamma@gmail.com a écrit : Pour le rendu Mapnik du site principal openstreetmap.org, tu peux regarder ici : https://github.com/gravitystorm/openstreetmap-carto Et plus particulièrement ici : https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-symbols.mss (...) (sans garantie d'exhaustivité) Le 6 mars 2013 17:48, Emivi cybervaldi...@gmail.com a écrit : Bonjour Existe t-il une liste des POI rendus par Mapnik ? Emilie (la bretonne) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ 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] Bassins versants
Le 06/03/2013 17:31, Philippe Verdy a écrit : Le 6 mars 2013 17:14, Marc SIBERT m...@sibert.fr a écrit : Ça doit être intéressant, mais c'est vraiment trop long (détaillé). J'aimerais comprendre comment vous tagguez les bras multiples et // Quelle mauvaise foi tu as ! C'était déjà marqué plus court dans un message précédent que tu n'as pas lu non plus ! - le cours principal : rôle main_stream dans la relation du cours d'eau (membres de type way uniquement, avec waterway=river/stream/etc...) - tous les autres bras secondaires : rôle side_stream (membres de type way uniquement, avec waterway=river/stream/etc...) Les riverbanks sont à part, dans des polygones successifs ou dans une relation multipolygone qui les incluent tous sous forme fermée (rôle outer) ou sous forme de série de chemins ouverts formant une boucle fermée (rôle outer), avec parfois des boucles fermées de rôle inner pour les îles créés par les différents bras. En principe si on commence à créer un multipolygone pour une riverbank, on devrait les fusionner dans la même relation sauf pour les sections couvertes taguées en tunnel=yes. Ok, ça ça va. Je parlais du cas des bras symétriques : faites-vous 2 cours // ou un seul arbitraire ? Exemple aussi la mangrove de Mada (justement) ou l'estuaire de la Garonne -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
Salut, J'ai changé les ways constituant la frontière maritime en admin_level=2. Il semble qu'il y ait consensus ! Par contre, arrivé aux ways constituant la frontière Guyane-Brésil, changer l'admin_level de 1 en 2 ne risque-t-il pas de faire doublon avec la relation frontière Guyane-Brésil qui inclut déjà admin_level=2 ? Je supprime carrément l'admin_level sur les ways ? Merci encore ! @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
On peut très bien (et on devrait) dessiner les deux bras (surtout d'ailleurs s'ils séparent une île où il y a des constructions et utilisations diverses du terrain). Mais dans ce cas il faut désigner un des bras comme main_stream et l'autre comme side_stream (classé à part dans la liste des membres). Assez souvent le choix du bras à désigner comme principal est évident (il faut regarder chaque bras dans sa totalité et pas seulement la largeur relative des deux bras à leur séparation), mais pas toujours (cas des deux bras de la Loire à Nantes), et dans ce cas le choix est assez arbitraire. Mais un simple bras canalisé permettant de franchir une écluse reste un bras secondaire, même si le cours principal franchit un seuil construit interdisant la navigation. Cela implique que la longueur navigable d'un cours d'eau est différente de la longueur totale du cours d'eau naturel (c'est de toute façon déjà le cas en amont de tous les fleuves et rivières). Un graphe différent doit donc être calculé pour les bassins versants (qui doivent aussi exclure les canaux mais pas les cours d'eau naturels canalisés) et pour les réseaux navigables (qui incluent les canaux et les bras secondaires créés pour les passages d'écluses). Comme on l'a noté plus haut les affluents ne se connectent pas toujours tous au bras principal, mais tant qu'ils se connectent à un moins un bras déclaré secondaire dans la relation, il n'y a pas d'erreur : Si on dessine un graphe en arbre des affluents en ne tenant compte que des bras principaux, il suffit de prolonger les affluents le long du bras secondaire auquel il se connecte pour le reconnecter au bras principal (en ignorant cette longueur ajoutée dans le calcul de la longueur de l'affluent), l'arbre peut donc continuer à être construit pour calculer les bassins versants. Dernière complication, les embouchures multiples : le choix de l'embouchure principale (main_stream) par rapport aux autres (side_stream) n'est pas toujours évident pour les fleuves terminés en delta (cas du Rhône par exemple), et peut être assez arbitraire. S'il n'est pas évident qu'un bras est beaucoup plus important que les autres, on peut tenter d'utiliser celui le plus central pour le graphe des bassins versants. Sinon le bras qui se connecte le mieux à d'autres canaux (pour le graphe navigable, mais dans ce cas ce graphe n'est pas un arbre de toute façon et n'est pas orienté comme les cours naturels, il forme un réseau maillé qui n'a rien à voir avec les bassins versants mais s'interconnecte d'un bassin à l'autre). Le 6 mars 2013 18:41, Marc Sibert m...@sibert.fr a écrit : Ok, ça ça va. Je parlais du cas des bras symétriques : faites-vous 2 cours // ou un seul arbitraire ? Exemple aussi la mangrove de Mada (justement) ou l'estuaire de la Garonne -- Marc Sibert mailto:m...@sibert.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] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Peut-être qu'une demande à Microsoft/Yahoo/Bing pour obtenir les droits d'usage des images SPOT (pas nécessairement les plus récentes si le CNES tient à garder son exploitation commerciale, ou alors seulement les images après catastrophe) pourrait aider aussi. Mais combien de temps cela prendra-t-il ? Le sponsoring peut marcher aussi si le CNES peut vendre ces images à prix réduit justement du fait de l'urgence humanitaire. La distribution gratuite des images pourrait aussi être temporaire (quelques mois), pour ensuite revenir à une exploitation commerciale des images post-catastrophe montrant l'état des reconstructions et réaménagements (car après une catastrophe, le terrain va évoluer énormément, mais on n'est plus dans le cadre de la gestion humanitaire de la catastrophe elle-même). Le 6 mars 2013 19:09, Jean-Guilhem Cailton j...@arkemie.com a écrit : Cependant l'imagerie Bing Haute définition n'est pas disponible pour Morombe. D'où l'importance d'obtenir l'autorisation d'utiliser l'imagerie SPOT ou d'autre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
Le 6 mars 2013 19:13, Christian Quest cqu...@openstreetmap.fr a écrit : Le rendu mapnik/osm2pgsql utilise bien les relations pour tracer les limites administratives contrairement à ce qu'indique Philippe. Visiblement non ! Il effectue une requête partielle des données et cela se confirme justement par la différence de rendus des traits et leur disparition inattendue si on n'est pas à un niveau de zoom où les chemins sont bien sélectionnés et retournés de la base. Et même quand ils sont retournés et visibles si Mapnik sur OSM.org utilisant toutes les relations dépendantes il ne tiendrait plus compte de l'attribut pour déterminer la nature du trait dessiné et utiliserait la value minimum d'admin_level parmi les relations qu'il a trouvées. Certainement Mapnik sait le faire, mais pour des raisons de performance et de charge des serveurs, des raccourcis ont aussi été faits, justement pour les bas niveaux de zoom où chaque tuile couvre des zones très étendues contenant de très nombreux objets. Tu peux mettre admin_level=2 sur le way de frontière, c'est assez courant même si pas indispensable. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
Un peu de lecture pour confirmer mes dires: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/output-pgsql.c comme ce commentaire fort pertinent: Linear features will end up in the line and roads tables (useful for admin boundaries) -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bassins versants
Le 6 mars 2013 18:09, Ab_fab gamma@gmail.com a écrit : Le 6 mars 2013 17:43, Philippe Verdy verd...@wanadoo.fr a écrit : Le 6 mars 2013 17:29, Ab_fab gamma@gmail.com a écrit : Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent justement pas compte de ces rôles side_stream ou main_stream. Cela fausse et alourdit les résultats. En quoi cela fausse les résultats ? Si tu ne fais pas de différence, la longueur du cours d'eau s'en ressent sensiblement, tu vas cumuler par endroits des longueurs 2 ou 3 fois. Cela fausse les résultats en indiquant que le cours d'eau est en plusieurs segments (et donc implicitement qu'il y a des coupures), alors qu'en réalité tout est ok. Cela ne permet pas de mettre en évidence les cours d'eau pour lesquels il y a vraiment une amélioration à apporter. Voir la Durance, depuis l'outil de Sly : il indique trois tronçons, mais en pratique il y a juste un bras secondaire à Chateau-Arnoux - Saint Auban quand on consulte l'analyseur de relation http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html Justement ce sont les outils d'analyse qui se trompent. La Durance est correctement taguée avec un *unique* segment main_stream de bout en bout et son bras parallèle est bien tagué en side_stream (et listé après tous les autres segments main_stream interconnectés). La liste des tributary est également parfaite. Pourtant l'outil doit être capable de déterminer si parmi l'ensemble des chemins main_stream cela forme une ligne continue ou pas. Ensuite s'il reste des segments, l'outil peut signaler que certains devraient passer en side_stream pour former un unique chemin main_stream. Il devrait, oui, mais c'est justement pas le cas avec les outils dans leur état actuel. Preuve s'il en est qu'on ne doit pas toujours prendre leurs prétendus rapports comme des erreurs. Ce sont des insuffisances de ces outils, mais pas du tout un problème de modélisation dans la base. Et justement les rôles sont là pour confirmer qu'il n'y a pas d'erreurs : pratiquement tous les cours d'eau ont des bras parallèles, et un outil sensé faire le point sur les cours d'eau mais qui ne sait pas prendre en compte ce cas très courant a un problème sérieux à régler. Si j'en étais capable, j'aimerais bien améliorer ce genre de choses. Cas particulier: un canal peut avoir une direction changeante : il peut monter et redescendre via des jeux d'écluses (exemple le canal d'Ille-et-Rance qui a son point haut au milieu, aux écluses d'Hédé). C'est un cas particulier, on peut vivre avec Note : encore : le sens d'écoulement normal dans le canal descend des écluses d'Hédé vers Rennes en rejoignant la partie canalisée de l'Ille. Pourtant, justement par le jeu des écluses, ce sens de circulation peut être inversé temporairement (cela est utilisé en période de crue de la Vilaine, si l'Ille par ailleurs n'est pas en crue et peut être fermée en amont. Cela permet d'évacuer une partie des eaux de la Vilaine vers le canal, pour aller inonder des prairies inondables (il y en a à Rennes même mais plus en amont aussi sur l'Ille à Saint-Grégoire et Betton). Cela permet de limiter les inondations en aval sur la Vilaine, notamment à Redon où il y a un goulet sans grande possibilité d'inonder des terres et où les bassins de rétention sont largement insuffisants. En aval de Rennes il y a aussi des bassins de rétention pour aussi détourner une partie des eaux de la Vilaine. Les modifications de sens de circulation proviennent des équipements construits par l'homme (mais parfois cela se fait avec des erreurs de manipulation: il y a quelques années une écluse en amont du canal a été ouverte sur le cours de l'Ille, en croyant que l'écluse du confluent de l'Ille vers la Vilaine avait été ouverte, mais elle était restée fermée par un bloquage de porte, et cela a inondé durant la nuit tout un quartier au Nord de Rennes qui a été réveillé d'urgence pour évacuer, le temps que les pompiers ne viennent soulever la porte avec une grue de chantier, détruisant la porte au passage... et avant qu'elle soit réparée, il y a eu une inondation importante à Redon du fait que l'eau de l'Ille n'avait pas pu être retenue à Rennes par la même porte). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
Le 6 mars 2013 18:41, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Salut, J'ai changé les ways constituant la frontière maritime en admin_level=2. Il semble qu'il y ait consensus ! Par contre, arrivé aux ways constituant la frontière Guyane-Brésil, changer l'admin_level de 1 en 2 ne risque-t-il pas de faire doublon avec la relation frontière Guyane-Brésil qui inclut déjà admin_level=2 ? Non aucun risque. c'est comme ça partout. mais cela permet d'attribuer un rendu aux frontières justement parce qu'elles sont de plein de types différents selon les relations qui les utilisent (et les moteurs de rendus de carte ne chargent pas toutes les relations dépendantes pour savoir comment afficher le trait, ils se contentent de lire les attributs du chemin pour savoir s'il faut ou non l'afficher selon le niveau de zoom sélectionné). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartopartie des panneaux publicitaires à Paris - samedi 16 mars 2013
C'est sur le site: https://openstreetmap.fr/2013-03-16-cartopartie-paris ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Bonjour, Cette zone est parfaite puisqu'elle tient compte des grosses parties de la ville impactées et toujours sous les eaux à savoir Anketa et Mahavatse II. Si de plus, les autres zones sinistrées relevées par le SERTIT sont intégrées, ce serait mieux pour le terrain. Quant aux images SPOT/Pleiades, c'est super d'avoir le contact. Crowdmap intègre OSM pas de problèmes. Mais il ne peut proposer en même temps d'afficher OSM avec GoogleMap Sattelites. Le problème est que quand il affiche OSM, il ne propose plus la vue images statellites qui peut être importante pour se rendre compte de l'utilisationn du sol, surtout quand la carto n'est pas détaillée. Ce que l'on peut faire par contre, c'est mettre une couche KMZ en bas de légende avec les infos OSM. Dès que la carte OSM est très détaillée, on pourra la mettre en fond de carte par défaut sur crowdmap. Nous avons un chat depuis samedi. Donnez moi votre compte et je vous y fais entrer. Voici mon compte skype @roomilissimo . Merci de votre aide, Cédric From: talk-fr-requ...@openstreetmap.org Subject: Lot Talk-fr, Vol 80, Parution 43 To: talk-fr@openstreetmap.org Date: Wed, 6 Mar 2013 16:47:18 + Envoyez vos messages pour la liste Talk-fr à talk-fr@openstreetmap.org Pour vous (dés)abonner par le web, consultez http://lists.openstreetmap.org/listinfo/talk-fr ou, par email, envoyez un message avec 'help' dans le corps ou dans le sujet à talk-fr-requ...@openstreetmap.org Vous pouvez contacter l'administrateur de la liste à l'adresse talk-fr-ow...@openstreetmap.org Si vous répondez, n'oubliez pas de changer l'objet du message afin qu'il soit plus spécifique que Re: Contenu du digest de Talk-fr... Thèmes du jour : 1. Re: Bassins versants (Ab_fab) 2. Re: Bassins versants (Philippe Verdy) 3. Re: Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar. (Pierre Béland) -- Message: 1 Date: Wed, 6 Mar 2013 17:40:06 +0100 From: Ab_fab gamma@gmail.com To: Discussions sur OSM en français talk-fr@openstreetmap.org Subject: Re: [OSM-talk-fr] Bassins versants Message-ID: cadik2oo4dr_evvcva3vqepzgk7kg9a0cp+7pwh+xntfd4ql...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Il est possible d'attribuer dans la relation waterway : _ un rôle main_stream sur le(s) way(s) du bras que l'on définit comme principal, _ un rôle side_stream sur le(s) way(s) du/des bras que l'on détermine comme secondaire(s) Ces règles sont plutôt récentes, et l'usage s'est répandu après que les principaux outils de suivi que l'on connait ont été développés (si ma mémoire est bonne). J'espère qu'un jour il y aura un mashup sympa de tous ces outils permettant d'avoir une bonne vision d'ensemble de l'avancement et des zones à améliorer. Le 6 mars 2013 17:14, Marc SIBERT m...@sibert.fr a écrit : Ça doit être intéressant, mais c'est vraiment trop long (détaillé). J'aimerais comprendre comment vous tagguez les bras multiples et // tl;dr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja -- section suivante -- Une pièce jointe HTML a été nettoyée... URL: http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130306/1c096ef7/attachment-0001.html -- Message: 2 Date: Wed, 6 Mar 2013 17:43:41 +0100 From: Philippe Verdy verd...@wanadoo.fr To: Discussions sur OSM en français talk-fr@openstreetmap.org Subject: Re: [OSM-talk-fr] Bassins versants Message-ID: CAGa7JC3FO3KS9cA=6=D1c5qHrk9f=+Ote+hZj7R3AZx=oom...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Le 6 mars 2013 17:29, Ab_fab gamma@gmail.com a écrit : Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent justement pas compte de ces rôles side_stream ou main_stream. Cela fausse et alourdit les résultats. En quoi cela fausse les résultats ? Si tu ne fais pas de différence, la longueur du cours d'eau s'en ressent sensiblement, tu vas cumuler par endroits des longueurs 2 ou 3 fois. Pourtant l'outil doit être capable de déterminer si parmi l'ensemble des chemins main_stream cela forme une ligne continue ou pas. Ensuite s'il reste des segments, l'outil peut signaler que certains devraient passer en side_stream pour former un unique chemin main_stream. Puis si le cours d'eau main_stream n'est toujours pas continu de bout en bout, il peut chercher parmi les sans rôle défini, ou sinon parmi les side_stream ceux qui peuvent combler les trous et les signaler comme des main_stream candidats. Le reste des chemins sans rôle peut enfin être signalé comme devant être des side_stream. Une fois
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
C'est la théorie, dans la pratique cela ne marche pas (et cela provient probablement de la requête initiale de sélection de données à traiter). Pour un niveau de zoom données, le moteur de rendu ne charge pas *tous* les objets contenus dans la zone. Il fait une préselection pour ensuite aller chercher juste ce qui semble nécessaire pour compléter le reste. Et le rendu obtenu confirme que cette théorie ne marche pas (ou qu'il y a un bogue dans le code, ce ne serait pas le premier, on a des tas de cas où Mapnik ne tient pas compte de tout ce qui est réellement dans la base, on doit l'aider un peu assez souvent, à commencer par éviter de lui donner des données incorrectes dans les dénormalisations, sinon ces données disparaissent du jeu de données utilisées). 2013/3/6 Christian Quest cqu...@openstreetmap.fr: Un peu de lecture pour confirmer mes dires: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/output-pgsql.c comme ce commentaire fort pertinent: Linear features will end up in the line and roads tables (useful for admin boundaries) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Relation 'waterway'
Bonsoir, Suite à la discussion parlant (initialement) des bassins versants, j'ai découvert l'outil de Sly, et je vois que la relation pour le Golu n'y est pas ! En effet, il n'existe pas de relation mais seulement des ways... Sauf que ledit fleuve passe par le lac de Calacuccia (retenue artificielle, mais cela a-t-il une importance ?). Dois-je donc déclarer dans la relation les ways en amont et en aval dudit lac, et donc créer une coupure ? Inclure le lac ? Dessiner un way au milieu du lac, allant du point d'entrée (amont) au point de sortie (aval) dudit lac ? Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] les POI de Mapnik
Il faut regarder et le fichier .mss et le .mml c'est à dire là où sont les requêtes SQL, car c'est là qu'on sélectionne dans un premier temps les POI à rendre et ensuite on choisit comment ils sont rendus (dans le .mss)... avec ou sans icône présente dans le dossier symbols. Le 6 mars 2013 18:29, Etienne Trimaille etienne.trimai...@gmail.com a écrit : Bonjour Émilie, Est-ce que le répertoire des pictos mapnik convient ? http://svn.openstreetmap.org/applications/rendering/mapnik/symbols/ Le 6 mars 2013 18:12, Ab_fab gamma@gmail.com a écrit : Pour le rendu Mapnik du site principal openstreetmap.org, tu peux regarder ici : https://github.com/gravitystorm/openstreetmap-carto Et plus particulièrement ici : https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-symbols.mss (...) (sans garantie d'exhaustivité) Le 6 mars 2013 17:48, Emivi cybervaldi...@gmail.com a écrit : Bonjour Existe t-il une liste des POI rendus par Mapnik ? Emilie (la bretonne) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab Il n'y a pas de pas perdus, Nadja ___ 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 -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
Le rendu mapnik/osm2pgsql utilise bien les relations pour tracer les limites administratives contrairement à ce qu'indique Philippe. Tu peux mettre admin_level=2 sur le way de frontière, c'est assez courant même si pas indispensable. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
1) le code d'osm2pgsql c'est pas de la théorie, c'est du concret, qui tourne sur les serveurs. Ce code redécoupe clairement les way composant une relation boundary en n objets dans planet_osm_line et planet_osm_roads 2) la feuille de style Mapnik utilise planet_osm_line et planet_osm_roads pour tracer les limites admin, donc les redécoupages des ways membres des relations et c'est bien donc de là que provient le admin_level. Ce sont tes affirmations non étayées qui sont dans la théorie... et l'erreur. Vu que le jour où tu reconnaitra t'être trompé n'est sûrement pas pour aujourd'hui, je passe à autre chose. Dernier message pour moi car perdre mon temps à corriger tes appoximations me lasse... mais je persiste à les corriger pour éviter que trop de monde ne reste sur celles-ci. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation 'waterway'
Dans ces cas, j'ai dessiné un way qui parcoure le lac, un peu comme si le lac était le riverbank de la rivière... Le 6 mars 2013 20:08, Francescu GAROBY f.gar...@gmail.com a écrit : Bonsoir, Suite à la discussion parlant (initialement) des bassins versants, j'ai découvert l'outil de Sly, et je vois que la relation pour le Golu n'y est pas ! En effet, il n'existe pas de relation mais seulement des ways... Sauf que ledit fleuve passe par le lac de Calacuccia (retenue artificielle, mais cela a-t-il une importance ?). Dois-je donc déclarer dans la relation les ways en amont et en aval dudit lac, et donc créer une coupure ? Inclure le lac ? Dessiner un way au milieu du lac, allant du point d'entrée (amont) au point de sortie (aval) dudit lac ? Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation 'waterway'
Donc ma troisième proposition (qui est celle qui avait ma préférence), OK. Francescu Le 6 mars 2013 20:19, Christian Quest cqu...@openstreetmap.fr a écrit : Dans ces cas, j'ai dessiné un way qui parcoure le lac, un peu comme si le lac était le riverbank de la rivière... Le 6 mars 2013 20:08, Francescu GAROBY f.gar...@gmail.com a écrit : Bonsoir, Suite à la discussion parlant (initialement) des bassins versants, j'ai découvert l'outil de Sly, et je vois que la relation pour le Golu n'y est pas ! En effet, il n'existe pas de relation mais seulement des ways... Sauf que ledit fleuve passe par le lac de Calacuccia (retenue artificielle, mais cela a-t-il une importance ?). Dois-je donc déclarer dans la relation les ways en amont et en aval dudit lac, et donc créer une coupure ? Inclure le lac ? Dessiner un way au milieu du lac, allant du point d'entrée (amont) au point de sortie (aval) dudit lac ? Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.
Je viens d'étudier les points de repère que j'ai pris dans la ville. J'en ai 19. J'ai calculé le décalage de Bing avec : En X : 1.91 m (+/-0.57) En Y : -1.76 m (+/-0.64) Autant dire que c'est faible et que je recommande de ne pas appliquer de correction aux images Bing de Tulear. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation 'waterway'
Bonjour Le 06/03/2013 20:08, Francescu GAROBY a écrit : Sauf que ledit fleuve passe par le lac de Calacuccia (retenue artificielle, mais cela a-t-il une importance ?). Dois-je donc déclarer dans la relation les ways en amont et en aval dudit lac, et donc créer une coupure ? Inclure le lac ? Dessiner un way au milieu du lac, allant du point d'entrée (amont) au point de sortie (aval) dudit lac ? Lorsque je rencontre une étendue d'eau sur le parcours d'un cours d'eau, je trace au milieu de cette étendue d'eau un chemin correspondant au même type de chemin que celui d'un cours d'eau. Ainsi cette étendue est un élément tout comme un autre d'un cours d'eau Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation 'waterway'
Comme d'habitude, avec un exemple ce serai plus parlant ;) Merci. Romain Le 6 mars 2013 20:30, David Crochet david.croc...@online.fr a écrit : Bonjour Le 06/03/2013 20:08, Francescu GAROBY a écrit : Sauf que ledit fleuve passe par le lac de Calacuccia (retenue artificielle, mais cela a-t-il une importance ?). Dois-je donc déclarer dans la relation les ways en amont et en aval dudit lac, et donc créer une coupure ? Inclure le lac ? Dessiner un way au milieu du lac, allant du point d'entrée (amont) au point de sortie (aval) dudit lac ? Lorsque je rencontre une étendue d'eau sur le parcours d'un cours d'eau, je trace au milieu de cette étendue d'eau un chemin correspondant au même type de chemin que celui d'un cours d'eau. Ainsi cette étendue est un élément tout comme un autre d'un cours d'eau Cordialement -- David Crochet __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Relation 'waterway'
Bonjour Le 06/03/2013 20:33, Romain MEHUT a écrit : Comme d'habitude, avec un exemple ce serai plus parlant ;) http://www.openstreetmap.org/?lat=48.59035lon=-0.37134zoom=17layers=M -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation 'waterway'
En l'occurrence, il s'agit du Golo (relation fraîchement créée : 2805254http://www.openstreetmap.org/browse/relation/2805254), et du lac de Calacuccia : 28890020http://www.openstreetmap.org/browse/way/28890020, dans lequel j'ai tracé une way au milieu : 208607756http://www.openstreetmap.org/browse/way/208607756 Francescu Le 6 mars 2013 20:33, Romain MEHUT romain.me...@gmail.com a écrit : Comme d'habitude, avec un exemple ce serai plus parlant ;) Merci. Romain Le 6 mars 2013 20:30, David Crochet david.croc...@online.fr a écrit : Bonjour Le 06/03/2013 20:08, Francescu GAROBY a écrit : Sauf que ledit fleuve passe par le lac de Calacuccia (retenue artificielle, mais cela a-t-il une importance ?). Dois-je donc déclarer dans la relation les ways en amont et en aval dudit lac, et donc créer une coupure ? Inclure le lac ? Dessiner un way au milieu du lac, allant du point d'entrée (amont) au point de sortie (aval) dudit lac ? Lorsque je rencontre une étendue d'eau sur le parcours d'un cours d'eau, je trace au milieu de cette étendue d'eau un chemin correspondant au même type de chemin que celui d'un cours d'eau. Ainsi cette étendue est un élément tout comme un autre d'un cours d'eau Cordialement -- David Crochet __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] source=inconnue
Le 06/03/2013 15:33, Jo. a écrit : Pour les cours d'eau, ce sont des éléments physique qui sont mouvant alors que les frontières sont fixée. On peut avoir la même logique avec les routes dont les autorité locale peuvent modifier le tracé sans respecter à la lettre les frontière. Près de chez moi, un cours d'eau change doucement chaque année pourtant il est en plaine et le débit en hivers n'est pas très fort. J'avais par erreur modifier les frontières en suivant le cours d'eau mais le cadastre indiquai autre chose même si les écarts sont de quelques mètres, j'ai du tout séparer et réparer pendant une longue demie journée de perdue : http://osm.org/go/xVlCOin3O- Pareil pour les routes et ponts avec un exemple passant au dessus d'une autoroute : http://osm.org/go/xVlmmAVBA-- Après *ce n'est qu'un conseil d'édition*, c'est simplement pour éviter de créer/propager une erreur. Séparer les éléments physique des éléments immatériel me semble conseillé pour éviter de nombreuses heures de correction. Je suis preneur de la définition légale de la limite d'une commune. Genre article du Code des Collectivités Locales. Perso, je n'ai rien trouvé de convaincant, mais j'ai peut-être pas assez ou mal cherché. Une indication : le cadastre ne définit pas les limites communales (ils seraient bien en peine puisque les limites de 2 cadastres adjacents ne sont pas toujours concordantes). Enfin, OSM n'a pas vocation à être une base d'arbitrage des limites communales. Rappelez-vous : sans garanties. Mais on pourrait dire : OSM a raison, in fine, la limite entre les communes X et Y c'est bien la rivière Z, le chemin d'exploitation AA. La parcelle 1 de la feuille 2 de la section 3 de la commune 4 est bien identifiée comme étant la limite de la commune 4 (selon le cadastre et donc, par dérivation des POS-PLU et autres documents réglementaires, etc.) et participe du faisceau de preuves des revendications territoriales de la commune. Il se pratique régulièrement des échanges de territoires entre communes (et cela change légalement la limite desdites communes car consignée dans le COG -Code Officiel Géographique- publié annuellement au JO). Nos arrangements et règles diverses n'auront aucune influence sur le COG. Je veux dire que le flou légal du juridique ne peut pas être compensé par une confiance aveugle dans les données cadastrales quant aux limites communales et que, de surcroît, ce n'est pas de notre compétence d'interférer dans ce débat. Le jour où OSM sera utilisable (fiable ?), sur l'ensemble du territoire national (pas que métropole) aux échelles cadastrales, il sera temps de recauser de ce débat, avec l'IGN (qui entretemps aura fait la convergence cadastrale -graal des géomaticiens de la grande échelle- et libéré les limites communales de la BD Parcellaire -marge suffisante ?). Denis, ready for the rencontre avec M. DGPiP ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Réunion AFIGEO/OGC à l'IGN
Nous étions (Gaël et moi) à l'IGN pour une réunion de l'Afigéo pour le groupe de travail opendata. Difficile de résumer une journée entière mais voici les grandes lignes. Le matin, réunion avec les CRIGE, où l'on a abordé deux sujets: a- utilisation d'OSM par les CRIGE, en particulier pour la réalisation d'un fond de carte neutre On y a donc parlé de mapnik, de tilemill et comparé l'évolution du style bright de mapbox modifiée par Géopicardie et l'évolution du style osm de mon côté. Les buts sont bien sûr différents, mais nous avons déjà des expérience à partager de part et d'autre. On a aussi abordé les aspects techniques de génération et distribution de tuiles, des volumes en jeu, de la mise à jour, de l'infrastructure matérielle, etc. b- les données dont disposent les CRIGE qui pourraient être mise à disposition pour OSM Le gros morceau ce sont souvent des orthophotos. Une grosse discussion sur la façon de les mettre à disposition: via des services (WMS, TMS) ou en fournissant les données brutes (fichiers .ecw/jpeg2000 voire tiff) ? Nous avons indiqué que nous pouvons tirer partie de l'un comme de l'autre. Il y a assez peu de données vectorielles disponibles actuellement, car peu ont été mises sous licence libre par les membres des CRIGE. La principale toutefois est l'occupation des sols, avec une précision meilleure que CLC (demi Ha). Il y aurait un gros travail de conflation à faire, en croisant aussi avec le registre parcellaire graphique pour les zones cultivées. Cela nécessite une grosse analyse avant de se lancer dans un tel projet, surtout pour ne pas perdre les améliorations de CLC qui ont été faites à de très nombreux endroits. L'après-midi, la réunion Afigéo sur l'opendata. Premier sujet: définir des recommandations sur les données à libérer... fixer un peu des priorités en quelque sorte. Donc toute une discussion sur comment savoir ce qui intéresse les utilisateurs... les compteurs de téléchargement ? un questionnaire à diffuser ? J'avoue ne pas être très chaud pour cette approche. L'opendata est plutôt la simple mise à disposition de données existantes, sans demander un travail particulier sur celles-ci. Faire un tri n'est donc en principe nécessaire que pour éliminer les données non libérables (problème de licence, problème de données personnelles, etc). J'ai rappelé que les compteurs de téléchargement ne pouvaient donner des infos que par rapport aux données disponibles... pas celle qui ne sont pas (encore) en opendata. Un développeur qui télécharge un jeu de données et fait une super appli utilisée par des milliers de personnes compte pareil qu'un curieux qui charge un fichier pour voir et n'en fera jamais rien. Un grosse discussion sur les problèmes de mise à disposition de données très volumineuses (par exemple les orthophotos). Comment gérer ça ? Ensuite, une présentation sur le web sémantique... j'en avais tellement parlé à la précédente réunion ;) Comme souvent les discussion off ont été riches, en particulier avec 2 personnes de l'IGN. Une question sur les calculs d'itinéraires piéton et la possibilité de messages vocaux qui prennent en compte le genre des toponymes... donnée non présente dans OSM, car oui, il s'agit de faire du calcul d'itinéraire piéton avec des données OSM. Donc on a parlé d'OpenTripPlanner et aussi d'OSRM. Pour ce qui est des masculin/féminin/neutre je pense qu'on peut en gérer beaucoup de façon automatique, mais qu'effectivement pour certains cas particuliers l'info a besoin d'être explicitée. L'autre discussion c'est avec un des responsables commerciaux/marketing qu'on croise assez souvent. On a parlé de différence entre gratuit et libre... pour bien être clair: la prison j'y dors gratuitement, mais je ne suis pas libre... ça commence à rentrer ;) Il faut qu'on vérifie par une confirmation écrite la possibilité d'utiliser les ortho IGN pour tracer par dessus, car il m'a encore été dit qu'on pouvait le faire. Autre chose... le GEOFLA non simplifié. Ça peut s'acheter, avec une licence compatible OSM... je demanderai bien un devis par curiosité, juste pour les communes qui nous manque. Dernier point, l'accès à la BDTOPO et au RGE dans le cadre d'une recherche est possible. On pourrait ainsi faire une étude de comparaison des données OSM/IGN, exhaustivité, précision, richesse des détails. Il faut que ce soit dans un cadre universitaire... ça doit pouvoir se trouver, non ? -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réunion AFIGEO/OGC à l'IGN
Merci pour les infos. Deux, trois petites remarques: 2013/3/6 Christian Quest cqu...@openstreetmap.fr: Un grosse discussion sur les problèmes de mise à disposition de données très volumineuses (par exemple les orthophotos). Comment gérer ça ? Pour les gros volumes, on peut envisager de payer les frais de mise à disposition sur DVD/blueray par exemple (à condition de ne pas payer des tarifs prohibitifs comme à la DGFiP). Les ortho ne sont pas actualisées aussi fréquemment que ça. Une question sur les calculs d'itinéraires piéton et la possibilité de messages vocaux qui prennent en compte le genre des toponymes... Intéressant. On pourrait imaginer un tag additionnel pour les cas particuliers. Autre chose... le GEOFLA non simplifié. Ça peut s'acheter, avec une licence compatible OSM... Dès que c'est dans OSM, c'est gratuit. Je voudrais bien voir une licence payante compatible ODbL... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réunion AFIGEO/OGC à l'IGN
On 06/03/2013 22:35, Christian Quest wrote: Nous étions (Gaël et moi) à l'IGN pour une réunion de l'Afigéo pour le groupe de travail opendata. Il faut qu'on vérifie par une confirmation écrite la possibilité d'utiliser les ortho IGN pour tracer par dessus, car il m'a encore été dit qu'on pouvait le faire. Ce serait une excellente nouvelle ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réunion AFIGEO/OGC à l'IGN
Le 6 mars 2013 23:10, Pieren pier...@gmail.com a écrit : Merci pour les infos. Deux, trois petites remarques: 2013/3/6 Christian Quest cqu...@openstreetmap.fr: Un grosse discussion sur les problèmes de mise à disposition de données très volumineuses (par exemple les orthophotos). Comment gérer ça ? Pour les gros volumes, on peut envisager de payer les frais de mise à disposition sur DVD/blueray par exemple (à condition de ne pas payer des tarifs prohibitifs comme à la DGFiP). Les ortho ne sont pas actualisées aussi fréquemment que ça. Pour certains cas, nous avons toujours la possibilité de fournir un disque dur pour y poser plus rapidement les fichier qu'en gravant des DVD ou Bluray... et ça revient souvent moins cher. C'est ce qui est prévu pour PACA. Une question sur les calculs d'itinéraires piéton et la possibilité de messages vocaux qui prennent en compte le genre des toponymes... Intéressant. On pourrait imaginer un tag additionnel pour les cas particuliers. name:gender[:lang] ? Autre chose... le GEOFLA non simplifié. Ça peut s'acheter, avec une licence compatible OSM... Dès que c'est dans OSM, c'est gratuit. Je voudrais bien voir une licence payante compatible ODbL... J'en ai parlé pour l'anecdote... ;) -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Cartopartie à Ercé-près-Liffré (35)
Le message suivant de Gwentux: ## bonjour [url=http://gulliver.eu.org]Gulliver[/url], vous invite à participer à sa prochaine [b]cartopartie[/b] organisée à [b]Ercé-près-Liffré[/b] (au [url=http://www.openstreetmap.org/?mlat=48.2547mlon=-1.5156zoom=12layers=Q]nord-est de Rennes[/url]), en collaboration avec le Groupe Multimédia et l’Association de randonneurs Les Rotes d’Ercé. Date : le [b]samedi 23 mars 2013[/b] à partir de 14h Lieu de rendez-vous : Le Relais des Cultures Place de la Mairie Plus d'info sur notre site : [url]http://gulliver.eu.org/cartopartie_erce-pres-liffre[/url] à bientôt ! a été posté sur le forum http://forum.openstreetmap.fr/viewtopic.php?f=6t=554 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleures réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française
Le 6 mars 2013 20:18, Christian Quest cqu...@openstreetmap.fr a écrit : 1) le code d'osm2pgsql c'est pas de la théorie, c'est du concret, qui tourne sur les serveurs. Ce code redécoupe clairement les way composant une relation boundary en n objets dans planet_osm_line et planet_osm_roads 2) la feuille de style Mapnik utilise planet_osm_line et planet_osm_roads pour tracer les limites admin, donc les redécoupages des ways membres des relations et c'est bien donc de là que provient le admin_level. Ce sont tes affirmations non étayées qui sont dans la théorie... et l'erreur. Vu que le jour où tu reconnaitra t'être trompé n'est sûrement pas pour aujourd'hui, je passe à autre chose. Vu que tu n'as rien prouvé du tout par tes affirmations mais juste énoncé une théorie et que les bogues sont bel et bien visibles, je te laisse à ta conclusion contredite par les résultats obtenus. Tu n'as strictement rien prouvé, je ne juge que sur les résultats obtenus, pas sur un morceau de commentaire dans un code source. Mapnik a des bigues de rendus un peu partout, facile à trouver, et ce ne sera pas le premier. Dernier message pour moi car perdre mon temps à corriger tes appoximations me lasse... mais je persiste à les corriger pour éviter que trop de monde ne reste sur celles-ci. Quelle impolitesse. Même si la théorie dit que 2 et 2 font 4, et qu'on obtient 3, tu vas conclure que la théorie est juste mais même pas te poser la question si les données traitées sont bien 2 et 2 là où le code est sensé agir parce qu'il calcule une addition. On voit pourtant 3, et on sait que les données sources sont justement 2 et 2. Quelque chose t'échappe (à moi aussi d'ailleurs et je n'ais certainement pas envie de regarder et comprendre pourquoi le code rend ce résultat, tout bonnement parce que ce n'est peut-être même pas ce code qui est concerné ici dans le résultat obtenu). Tu fais juste confiance à la théorie et refuse de regarder les résultats tels qu'ils sont. Je ne reproche rien aux concepteurs de ce programme, tous les programmes ont des bogues, des cas particuliers oubliés et non traités ou des conditions initiales non clairement spécifiées et oubliées. Le code est assez complexe pour en avoir des tas. Mais toi tu regarde à un endroit microscopique du code pour conclure que ce code est correct sans même te demander si c'est à cet endroit qu'est l'erreur. Des bigues de rendus il y en a pour différentes raisons, y compris diverses sources de désynchronisations des données entre ce qui est dans la base et ce qui est dans les tables de cache internes. Le problème n'est pas là : si on a des données contradictoires dans la base, la façon dont se débrouille les algos pour lever les ambiguités reste seulement une heuristique qui va juste régler les cas les plus courants. Mais voilà, tu fais partie des personnes qui font une confiance aveugle dans ce que produit un programme, sans doute parce que tu l'as écrit toi-même et que tu penses que c'est déshonorant d'admettre que ton bijou peut avoir des anomalies. Je me fiche totalement de savoir comment fait le programme en interne, et en fait je ne devrais même pas avoir à le savoir. Pour évaluer un programme on regarde ses résultats, rien d'autre. Si le résultat n'est pas celui attendu, on isole le problème en repérant les cas qui ne marchent pas se lon quelques règles simples. Et on commence par d'abord relever les contradictions dans les données sources pour éviter de les mettre. Et c'est en procédant ainsi qu'on arrive à isoler des problèmes en fait dans les données sourves, que l'heuristique du programme ne parbient pas à isoler et corriger lui-même. Et on voit que ces corrections aussitôt faite non seulement résolvent le problème du résultat mais aussi clarifient les données sources (il n'y a pas que Mapnik qui doivent interpréter les données, les contributeurs aussi. Je te laisse donc à ta théorie fumeuse, puisque tu lui fais une confiance aveugle, moi je reste à ma méthode pratique qui est souvent bien plus fiable et permet d'avancer (et surtout ne dépend pas de la seule interprétation faite par Mapnik, mais peut aussi servir à d'autres rendus, sans compter aussi que la version déployée peut aussi être différente de celles qui est dans le code source). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
