[OSM-talk-fr] Evaluer les kms de voies cyclables
Bonjour, je fais partie de vélocité de l'Angoumois et depuis 1 an nous contribuons à OSM pour répertorier les équipements cyclables de l'agglo, rajouter les rues manquantes ... Nous aimerions avoir une idée du kilométrage de voies cyclables de l'agglomération d'Angoulême Est- ce qu'il y a une méthode pour cela ? Merci d'avance Dominique ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Sur le modèle des adresses (était Rendu BANO)
2014-05-24 15:04 GMT+02:00 DH dhel...@free.fr: Ainsi, par exemple, je n'avais pas assimilé l'intérêt des relations AssociatedStreet, maintenant si. Au risque de me répéter, il y aurait un grand danger à vouloir généraliser les relations associatedStreet dans OSM pour des raisons que j'ai déjà expliqué par ailleurs mais que je vais résumer ici: - c'est plus difficile à modifier. Ceux qui les ajoutent utilisent josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je les défie de modifier ces relations avec iD ou P2, ne serait-ce que de déplacer un numéro d'une rue à sa voisine. C'est très difficile et chia.. même pour les habitués. Et ne parlons pas des nouveaux contributeurs ou irréguliers. - l'argument sur l'intégrité est correct dans l'immédiat mais ne tient pas au long cours. On le voit avec toutes les relations comme les limites administratives, toutes les relations de type route ou même les multipolygones (pensez landuse corine), elles sont plus difficiles à maintenir parce qu'elles sont souvent cassées par les néophites. Ou pire, si l'éditeur est préventif à l'égard de toute modification comme dans JOSM, elle bloquera la bonne volonté du débutant. - nous serions le seul pays à utiliser à une telle échelle une relation par rue dans OSM. Si aucun autre pays n'a fait ce choix, il faudrait au moins se demander pourquoi (alors qu'ils sont nombreux à faire des imports du même type et à se poser les mêmes questions que nous). L'habitude du village gaullois qui a raison seul contre tous ? - l'argument d'éviter les redondances ne tient pas. C'est même le contraire. Faute de support dans les outils externes autres que nominatim, les noms de rues sont de toute façon répétés sur la rue et la relation, si ce n'est pire, sur la rue et chaque numéro. Sans parler de l'internationalisation, des alt_name ou autres liens externes, on verra au final tous les tags doublonner. Certains ici prônent même la redondance comme solution à leurs problèmes lorsqu'ils doivent rédiger des règles de rendu pour mapnik et qu'ils trouvent au final la gestion des relations bien lourdes au niveau logiciel. - sur la modélisation elle-même, tout ce qui peut s'identifier par une relation peut se faire sans elle. Des solutions existent déjà pour les name, ref ou ref:FR:FANTOIR, même pour des rues appartenant à deux communes. - l'argument du changement de nom de rue qui serait plus facile est, là encore, discutable. Comme on l'a vu, les noms sont déjà répétés et il y faudra de toute façon surveiller la cohérence entre noms et numéros avec des outils QA (ce que fait déjà l'outil de geofabrik, par exemple). Et de toute façon, les changements de noms sont assez rares et on sera d'avantage confronté à du vandalisme ou des interprétations orthographiques divergentes. - finalement, le principal avantage des relations se trouve du côté des utilisateurs des données. Pour eux, il est effectivement plus facile de travailler avec une relation par rue que de chercher à assembler des morceaux de rues pas toujours attachés entre eux avec des noeuds ou des polygones éparses. Mais dans OSM, il y a une règle de base : c'est le terrain qui prime, et 90% des contributeurs sont des contributeurs uniques ou de très faible niveau. Même si ça n'est pas eux qui produisent le plus de données en quantité, ce sont eux qui sont les plus proches du terrain et qui fournissent les meilleures données en qualité. S'il faut donc choisir entre faciliter la vie des consommateurs des données OSM (les développeurs) et celle des contributeurs néophites, il faudra toujours essayer de priviligier autant que possible les seconds, quitte à donner un peu plus de travail aux premiers. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sur le modèle des adresses (était Rendu BANO)
Le 26/05/2014 11:27, Pieren a écrit : 2014-05-24 15:04 GMT+02:00 DH dhel...@free.fr: Ainsi, par exemple, je n'avais pas assimilé l'intérêt des relations AssociatedStreet, maintenant si. Au risque de me répéter, il y aurait un grand danger à vouloir généraliser les relations associatedStreet dans OSM pour des raisons que j'ai déjà expliqué par ailleurs mais que je vais résumer ici: - c'est plus difficile à modifier. Ceux qui les ajoutent utilisent josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je les défie de modifier ces relations avec iD ou P2, ne serait-ce que de déplacer un numéro d'une rue à sa voisine. C'est très difficile et chia.. même pour les habitués. Et ne parlons pas des nouveaux contributeurs ou irréguliers. Généraliser les associatedStreet ne rend pas obsolètes les autres manières de tagguer les adresses. OpenStreetMap fonctionne ne manière itérative. Le neocontributeur ira au plus simple avec un simple noeud qui sera ensuite intégré a la relation idoine par un contributeur plus expérimenté. - l'argument sur l'intégrité est correct dans l'immédiat mais ne tient pas au long cours. On le voit avec toutes les relations comme les limites administratives, toutes les relations de type route ou même les multipolygones (pensez landuse corine), elles sont plus difficiles à maintenir parce qu'elles sont souvent cassées par les néophites. Ou pire, si l'éditeur est préventif à l'égard de toute modification comme dans JOSM, elle bloquera la bonne volonté du débutant. Chaque type de relation a son propre cycle de vie. Les relations adresses ne dérogeront pas à la règle. Il n'y a aucune raison qu'elles soient plus cassées que les autres, bien au contraire à mon avis dans la mesure ou elles ont une emprise beaucoup plus petite. - nous serions le seul pays à utiliser à une telle échelle une relation par rue dans OSM. Si aucun autre pays n'a fait ce choix, il faudrait au moins se demander pourquoi (alors qu'ils sont nombreux à faire des imports du même type et à se poser les mêmes questions que nous). L'habitude du village gaullois qui a raison seul contre tous ? Les autres pays ont ils un ref:FANTOIR ? Les autres pays cherchent t'ils simplement à afficher un numéro de rue sur un fond de carte ou a travailler efficacement avec leurs collectivités territoriales ? - l'argument d'éviter les redondances ne tient pas. C'est même le contraire. Faute de support dans les outils externes autres que nominatim, les noms de rues sont de toute façon répétés sur la rue et la relation, si ce n'est pire, sur la rue et chaque numéro. Sans parler de l'internationalisation, des alt_name ou autres liens externes, on verra au final tous les tags doublonner. Certains ici prônent même la redondance comme solution à leurs problèmes lorsqu'ils doivent rédiger des règles de rendu pour mapnik et qu'ils trouvent au final la gestion des relations bien lourdes au niveau logiciel. Heu, sur les doublons je ne te suis pas, il y en a beaucoup moins avec les relations qu'a répéter un addr:street pour chaque addr:housenumber Cela permet d'éviter de multiplier les erreurs de toponymes et d'augmenter la qualité des données. On peut associer un code FANTOIR unique à une seule relation plutôt qu'a chaque tronçon de la même voie. - sur la modélisation elle-même, tout ce qui peut s'identifier par une relation peut se faire sans elle. Des solutions existent déjà pour les name, ref ou ref:FR:FANTOIR, même pour des rues appartenant à deux communes. Avec les relation on factorise les redondance d'informations. c'est bénéfique pour la base. - l'argument du changement de nom de rue qui serait plus facile est, là encore, discutable. Comme on l'a vu, les noms sont déjà répétés et il y faudra de toute façon surveiller la cohérence entre noms et numéros avec des outils QA (ce que fait déjà l'outil de geofabrik, par exemple). Et de toute façon, les changements de noms sont assez rares et on sera d'avantage confronté à du vandalisme ou des interprétations orthographiques divergentes. - finalement, le principal avantage des relations se trouve du côté des utilisateurs des données. Pour eux, il est effectivement plus facile de travailler avec une relation par rue que de chercher à assembler des morceaux de rues pas toujours attachés entre eux avec des noeuds ou des polygones éparses. Mais dans OSM, il y a une règle de base : c'est le terrain qui prime, et 90% des contributeurs sont des contributeurs uniques ou de très faible niveau. Même si ça n'est pas eux qui produisent le plus de données en quantité, ce sont eux qui sont les plus proches du terrain et qui fournissent les meilleures données en qualité. S'il faut donc choisir entre faciliter la vie des consommateurs des données OSM (les développeurs) et celle des contributeurs néophites, il faudra toujours essayer de priviligier autant que possible les seconds, quitte à donner un peu plus de travail aux premiers.
Re: [OSM-talk-fr] Sur le modèle des adresses (était Rendu BANO)
2014-05-26 11:57 GMT+02:00 Christophe Merlet red...@redfoxcenter.org: OpenStreetMap fonctionne ne manière itérative. Le neocontributeur ira au plus simple avec un simple noeud qui sera ensuite intégré a la relation idoine par un contributeur plus expérimenté. Ou l'inverse... Chaque type de relation a son propre cycle de vie. Les relations adresses ne dérogeront pas à la règle. Il n'y a aucune raison qu'elles soient plus cassées que les autres, bien au contraire à mon avis dans la mesure ou elles ont une emprise beaucoup plus petite. La raison en serait leur nombre. Même plus petites, si elles sont systématiques, elles seront plus souvent cassée... Les autres pays ont ils un ref:FANTOIR ? Les autres pays cherchent t'ils simplement à afficher un numéro de rue sur un fond de carte ou a travailler efficacement avec leurs collectivités territoriales ? Le ref:FANTOIR ne peut, ne doit pas être la raison de créer des relations associatedStreet. Les autres pays peuvent avoir leurs refs ou même leurs wikidata. Concernant le travail avec les collectivités locales, c'est bien entendu un sujet partagé. La discussion sur le share alike de la license et les CT est directement inspirée d'une collaboration avec des collectivités locales. Partout, on voit bien que l'ajout des adresses par des contributeurs isolés prendrait de nombreuses années voir décennies et que si l'import d'une base publique est possible, il sera systématiquement préféré. Heu, sur les doublons je ne te suis pas, il y en a beaucoup moins avec les relations qu'a répéter un addr:street pour chaque addr:housenumber Cela permet d'éviter de multiplier les erreurs de toponymes et d'augmenter la qualité des données. Sauf que comme des appli genre OsmAnd ne reconnaissent pas ces relations, on voit fleurir ici et là des rues tagguées avec les deux modèles. Sauf que même avec une relation, le toponyme reste sur le highway parce que mapnik ne connait pas cette relation. Sauf que certains ont une interprétation différente du tag name sur la relation et mettent déjà un nom différent de la rue. Sauf que certains font deux ou plus relations par rues. Sauf que rien n'empêche quelqu'un de mettre la rue dans plusieurs relations... On peut associer un code FANTOIR unique à une seule relation plutôt qu'a chaque tronçon de la même voie. Comme le tag 'ref' ou le tag 'name' qu'il est bien plus simple de retrouver sur le way lui-même. On peut aussi décider de tout déplacer dans des relations : une pour le nom, une pour le 'ref', une pour le maxspeed, etc... Avec les relation on factorise les redondance d'informations. c'est bénéfique pour la base. Alors il faut pousser la logique jusqu'au bout et tout mettre dans des relations. Bizarre de ne pas vouloir faire évoluer les pratiques d'OSM vers un niveau plus industriels. Le but c'est de voir les données réutilisé le plus massivement possible, pour cela il faut un certain formalisme, même si cela augmente un peu le niveau de compétences requis pour contribuer. Encore que dans le même temps, les outils de contribution vont masquer cette difficulté dans des cliquodromes appropriés. C'est l'autre risque du projet, le syndrome wikipedia qui fait que seuls des experts pourront modifier la carte. Et après ils viendront pleurer qu'il n'y a pas assez de contributeurs locaux pour actualiser les données. Quant à l'éditeur qui modifie les relations discrètement et en toute facilité, on le cherche encore... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sur le modèle des adresses (était Rendu BANO)
Dans ce cas, ne serait-il pas intéressant d'aplatir les données des relations lors de l'édition, et de refactoriser le tout lors de l'enregistrement dans la base de données ? Je ne sais pas s'il faudrait mieux faire ça du côté des clients ou du serveur, mais la saisie reste simple car la complexité des relation est masquée par l'absence d'édition directe desdites relations. Je ne pense pas que ce système peut fonctionner pour tout (multipolygones), mais je ne vois pas de problèmes pour les lignes de bus ou pour les adresses. Greg 2014-05-26 12:57 GMT+02:00 Pieren pier...@gmail.com: 2014-05-26 11:57 GMT+02:00 Christophe Merlet red...@redfoxcenter.org: OpenStreetMap fonctionne ne manière itérative. Le neocontributeur ira au plus simple avec un simple noeud qui sera ensuite intégré a la relation idoine par un contributeur plus expérimenté. Ou l'inverse... Chaque type de relation a son propre cycle de vie. Les relations adresses ne dérogeront pas à la règle. Il n'y a aucune raison qu'elles soient plus cassées que les autres, bien au contraire à mon avis dans la mesure ou elles ont une emprise beaucoup plus petite. La raison en serait leur nombre. Même plus petites, si elles sont systématiques, elles seront plus souvent cassée... Les autres pays ont ils un ref:FANTOIR ? Les autres pays cherchent t'ils simplement à afficher un numéro de rue sur un fond de carte ou a travailler efficacement avec leurs collectivités territoriales ? Le ref:FANTOIR ne peut, ne doit pas être la raison de créer des relations associatedStreet. Les autres pays peuvent avoir leurs refs ou même leurs wikidata. Concernant le travail avec les collectivités locales, c'est bien entendu un sujet partagé. La discussion sur le share alike de la license et les CT est directement inspirée d'une collaboration avec des collectivités locales. Partout, on voit bien que l'ajout des adresses par des contributeurs isolés prendrait de nombreuses années voir décennies et que si l'import d'une base publique est possible, il sera systématiquement préféré. Heu, sur les doublons je ne te suis pas, il y en a beaucoup moins avec les relations qu'a répéter un addr:street pour chaque addr:housenumber Cela permet d'éviter de multiplier les erreurs de toponymes et d'augmenter la qualité des données. Sauf que comme des appli genre OsmAnd ne reconnaissent pas ces relations, on voit fleurir ici et là des rues tagguées avec les deux modèles. Sauf que même avec une relation, le toponyme reste sur le highway parce que mapnik ne connait pas cette relation. Sauf que certains ont une interprétation différente du tag name sur la relation et mettent déjà un nom différent de la rue. Sauf que certains font deux ou plus relations par rues. Sauf que rien n'empêche quelqu'un de mettre la rue dans plusieurs relations... On peut associer un code FANTOIR unique à une seule relation plutôt qu'a chaque tronçon de la même voie. Comme le tag 'ref' ou le tag 'name' qu'il est bien plus simple de retrouver sur le way lui-même. On peut aussi décider de tout déplacer dans des relations : une pour le nom, une pour le 'ref', une pour le maxspeed, etc... Avec les relation on factorise les redondance d'informations. c'est bénéfique pour la base. Alors il faut pousser la logique jusqu'au bout et tout mettre dans des relations. Bizarre de ne pas vouloir faire évoluer les pratiques d'OSM vers un niveau plus industriels. Le but c'est de voir les données réutilisé le plus massivement possible, pour cela il faut un certain formalisme, même si cela augmente un peu le niveau de compétences requis pour contribuer. Encore que dans le même temps, les outils de contribution vont masquer cette difficulté dans des cliquodromes appropriés. C'est l'autre risque du projet, le syndrome wikipedia qui fait que seuls des experts pourront modifier la carte. Et après ils viendront pleurer qu'il n'y a pas assez de contributeurs locaux pour actualiser les données. Quant à l'éditeur qui modifie les relations discrètement et en toute facilité, on le cherche encore... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Feuilleton sur la carto
Salut ! Je suis tombé en cours de route sur un reportage du journal 13h de F2 sur la carto. Comme c'est un feuilleton du journal, ca doit etre diffusé en 5 épisodes sur la semaine. J'y ai croisé rapidement un logo OSM mais pas de mention explicite, que de l'IGN. Esperons que ca sera le cas sur les 4 autres épisodes de la semaine... A revoir sur PLUZZ [1] Eric [Blueberry] [1] http://pluzz.francetv.fr/france2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Feuilleton sur la carto
À 32 minutes et 45 secondes sur : http://www.francetvinfo.fr/replay-jt/france-2/13-heures/jt-de-13h-du-lundi-26-mai-2014_603905.html Par contre je n'ai pas vu d'osm, ou alors je suis passé à côté ... -- Jean-Baptiste Holcroft Le 26 mai 2014 13:43, Eric eric...@sfr.fr a écrit : Salut ! Je suis tombé en cours de route sur un reportage du journal 13h de F2 sur la carto. Comme c'est un feuilleton du journal, ca doit etre diffusé en 5 épisodes sur la semaine. J'y ai croisé rapidement un logo OSM mais pas de mention explicite, que de l'IGN. Esperons que ca sera le cas sur les 4 autres épisodes de la semaine... A revoir sur PLUZZ [1] Eric [Blueberry] [1] http://pluzz.francetv.fr/france2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO: 100% des départements traités !
Ou encore les lettres majuscules accentuées : Erable - Érable http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/48.753964/7.853557 -- Jean-Baptiste Holcroft Le 25 mai 2014 02:56, Pierre Knobel pierr...@gmail.com a écrit : Je ne crois pas que cela ait déjà été signalé, pour le rapprochement : oe et œ (exemple : sœur). Peut-être aussi ae et ä (exemple http://www.openstreetmap.org/way/41940309). Pour le problème des communes fusionnées avec le nom de l'ancienne commune rajouté après le nom des rues, on doit aussi pouvoir faire quelque chose. On pourrait compter le nombre d'occurences pour le dernier mot de chaque nom de voie qui n'a pas pu être rapprochée, et pour ceux qui apparaissent plusieurs fois retenter le rapprochement après avoir supprimé ce dernier mot. Si ça marche, rajouter un addr:place=dernier mot et un fixme:vérifier addr:place dans le résultat de l'outil d'intégration. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Feuilleton sur la carto
Bonjour À 36mn 10s, un morceau d'écran avec bing et une route qui coupe une pelouse ou je ne sais quoi, pas forcément une bonne pub :-D Cordialement Le 26/05/2014 14:50, Jean-Baptiste Holcroft a écrit : À 32 minutes et 45 secondes sur : http://www.francetvinfo.fr/replay-jt/france-2/13-heures/jt-de-13h-du-lundi-26-mai-2014_603905.html Par contre je n'ai pas vu d'osm, ou alors je suis passé à côté ... -- Jean-Baptiste Holcroft Le 26 mai 2014 13:43, Eric eric...@sfr.fr mailto:eric...@sfr.fr a écrit : Salut ! Je suis tombé en cours de route sur un reportage du journal 13h de F2 sur la carto. Comme c'est un feuilleton du journal, ca doit etre diffusé en 5 épisodes sur la semaine. J'y ai croisé rapidement un logo OSM mais pas de mention explicite, que de l'IGN. Esperons que ca sera le cas sur les 4 autres épisodes de la semaine... A revoir sur PLUZZ [1] Eric [Blueberry] [1] http://pluzz.francetv.fr/france2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Première rencontre mensuelle OpenStreetMap à la Cantine
*Rencontres mensuelles OpenStreetMap à Brest, rejoignez-nous !* Depuis 2009, une belle dynamique s'est installé au Pays de Brest autour des cartes collaboratives OpenStreetMap avec des réalisations comme les plans de Plouarzel, Plouider, le développement de Chimère, le groupe cartes ouvertes et des ateliers à Plabennec, Plouzané, Guilers... Pour découvrir le projet OpenStreetMap et ses enjeux du moment, faire le point sur les projets en cours en France et autour de Brest, rencontrer la communauté de contributeurs, nous vous invitons à une première rencontre mensuelle : le mardi 03 juin 2014 à la Cantine brestoise à partir de 18h. Au menu de la soirée en fonction des appétits : - Présentation générale OSM et OSM France - Les projets nationaux - Les projets au Pays de Brest (accessibilité de BMO, hackathon, carto-Afrique, Chimère...) - et tout ce que vous souhaitez partager, grignoter, décortiquer ensemble autour des cartes... Et bien sûr repas partagé... Au plaisir de se (re)-croiser... - Lien pour accéder à la Cantine : http://osm.org/go/erDxrP8jf?m=node=2261538499 - Contact : Louis-Julien de la Bouëre, ljbou...@openstreetmap.fr , 06 58 79 80 56 /Message envoyé aux listes OSM-fr, OSM-bzh, cartes ouvertes pays de Brest, centre de ressources et wiki-brest/ -- Louis-Julien de la Bouëre Association Tiriad ljbou...@tiriad.org www.tiriad.org Portable : 06 58 79 80 56 Twitter : @assotiriad Skype : tiloul29 Instagram : ljbouere29 TumblR : http://ljbouere.tumblr.com/ attachment: ljbouere.vcf___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Evaluer les kms de voies cyclables
On 26.05.2014 10:28, domi wrote: je fais partie de vélocité de l'Angoumois et depuis 1 an nous contribuons à OSM pour répertorier les équipements cyclables de l'agglo, rajouter les rues manquantes ... Nous aimerions avoir une idée du kilométrage de voies cyclables de l'agglomération d'Angoulême Est- ce qu'il y a une méthode pour cela ? Je vois deux méthodes pour le faire. On peut importer les données OSM dans une base PostGis et faire une ou plusieurs requêtes spatiales du genre : select sum(st_length(l.way)) from planet_osm_line l, planet_osm_polygon p where l.highway='cycleway' and p.osm_id=-18000 and st_intersects(l.way,p.way) où 18000 est l'id de la relation boundary. Ou bien on utilise overpass / overpass-turbo pour selectionner les voies en question, puis on les eporte au format GPX, par exemple, et on aura la longueur avec un outil d'analyse GPX. Avec Overpass Turbo on obtient par exemple les pistes cyclables pour la ville de Perpignan avec http://overpass-turbo.eu/s/3xL Il suffit de remplacer 18000 par l'id de la relation boundary de ton agglo. Je préfére la méthode PostGis car elle permet un filtrage plus complexe et fournit directement la longueur. La méthode overpass a l'avantage de marcher sans base PostGis. Et il doit y avoir d'autres methodes. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Utilisation d'une carte OSM pour suivre une course par relais
Depuis samedi dernier se court la « Redadeg », autrement dit une course de 1500 km dans toute la Bretagne pour collecter de l’argent afin de soutenir l’enseignement du breton, sa production audiovisuelle et l’initiation des adultes. Pour ceux que cela intéresse, j’ai résumé les buts et l’organisation, ici : http://www.agencebretagnepresse.com/fetch.php?id=33879 Le point intéressant est que cette course peut être suivie sur un site Internet avec un pointage satellite qui montre que les coureurs arrivent à Nantes en ce moment et la carte est basée sur MapQuest ouverte. http://www.ar-redadeg.org (cliquez sur la version française ou anglaise, au choix) J’avais écrit (en breton) )à l’organisation pour signaler que les cartes n’avaient pas la bonne attribution. Là, c’est quasi parfait (il me semble que le CC-By-SA n’est pas nécessaire). Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Feuilleton sur la carto
Sue un coin de carte affiché sur un écran on lisait parfaitement OpenStreetmap dans cet épisode. Mais c'est vrai que seul l'IGN a été mentionné... Pas grand chose de très convaincant dans ce premier épisode sur la naissance d'une carte, et même sur ce qui devrait nous intéresser tous : quelles sont les missions publiques de l'IGN et comment cette mission peut évoluer dans un contexte de concurrence internationale avec toutes sortes de projets et d'offres, ouvertes ou commerciales. Si l'IGN doit se réformer c'est en tant que prestataire conseil pour aider les collectivités et le développement d'applications intéessantes pour le public dans des usages très différents. Aussi dans une démarche de supervision qualité: la quantité des données disponibles ne va aller qu'en croissant, il se pose déjà la question de la qualification des données, leur suivi, leur intégration, la gestion des historiques, les méthodes d'accès et de sélection des données selon les usages, l'identification des besoins, l'évaluation de l'efficacité des méthodes, la gestion des coûts, les économies possibles par des coopérations. Le temps des cartes avec une seule source est fini : le reportage le dit bien: la 4e génération des cartes IGN a encore un cycle de développement de 6 ans, c'est peut-être 10 fois plus rapide que la génération précédente mais c'est encore beaucoup trop long pour les usages actuels et ce n'est pas avec 240 personnes à l'IGN pour préparer un carroyage de 400km2 revu tous les 6 ans que l'IGN pourra suivre seule la demande et les besoins. Même Google avec des outils automatiques et une équipe de 600 personnes ne pourra pas suivre. Plus que jamais les collaborations sont nécessaires et seule la voie des données ouvertes permettra d'aller plus vite, personne ne pourra suivre avec une solution propriétaire où les trous de couverture seront de plus en plus flagrants et de moins en moins acceptable. L'IGN ne doit plus se positionner en tant que fournisseur de données mais en tant que fournisseur de solutions qualité et expert pour rendre les processus de mises à jour plus efficaces et avec une meilleure qualité finale. Même sur OSM, on doit aller non plus sur la seule accumulation de données mais aller vers une démarche qualitative utilisant des outils de plus en plus automatiques pour effectuer des rapprochements et détecter rapidement les différences, par une meilleure classification plus systématique des données où la contribution humaine individuelle des fourmis (toujours indispensable) sera mieux exploitée, que pour des tâches de plus en plus répétitives n'apportant rien en terme de réutilisabilité et de valeur ajoutée (si on n'est pas capable de faire des rapprochements avec des sources de plus en plus nombreuses d'informations nécessaires pour les besoins. Le 26 mai 2014 14:50, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : À 32 minutes et 45 secondes sur : http://www.francetvinfo.fr/replay-jt/france-2/13-heures/jt-de-13h-du-lundi-26-mai-2014_603905.html Par contre je n'ai pas vu d'osm, ou alors je suis passé à côté ... -- Jean-Baptiste Holcroft Le 26 mai 2014 13:43, Eric eric...@sfr.fr a écrit : Salut ! Je suis tombé en cours de route sur un reportage du journal 13h de F2 sur la carto. Comme c'est un feuilleton du journal, ca doit etre diffusé en 5 épisodes sur la semaine. J'y ai croisé rapidement un logo OSM mais pas de mention explicite, que de l'IGN. Esperons que ca sera le cas sur les 4 autres épisodes de la semaine... A revoir sur PLUZZ [1] Eric [Blueberry] [1] http://pluzz.francetv.fr/france2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sur le modèle des adresses (était Rendu BANO)
Le 26 mai 2014 11:27, Pieren pier...@gmail.com a écrit : 2014-05-24 15:04 GMT+02:00 DH dhel...@free.fr: Ainsi, par exemple, je n'avais pas assimilé l'intérêt des relations AssociatedStreet, maintenant si. Au risque de me répéter, il y aurait un grand danger à vouloir généraliser les relations associatedStreet dans OSM pour des raisons que j'ai déjà expliqué par ailleurs mais que je vais résumer ici: - c'est plus difficile à modifier. Ceux qui les ajoutent utilisent josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je les défie de modifier ces relations avec iD ou P2, ne serait-ce que de déplacer un numéro d'une rue à sa voisine. C'est très difficile et chia.. même pour les habitués. Et ne parlons pas des nouveaux contributeurs ou irréguliers. - l'argument sur l'intégrité est correct dans l'immédiat mais ne tient pas au long cours. On le voit avec toutes les relations comme les limites administratives, toutes les relations de type route ou même les multipolygones (pensez landuse corine), elles sont plus difficiles à maintenir parce qu'elles sont souvent cassées par les néophites. Ou pire, si l'éditeur est préventif à l'égard de toute modification comme dans JOSM, elle bloquera la bonne volonté du débutant. Contrairement à toi je pense qu'il faut aller vers ce modèle même s'il est plus complexe pour le débutant. Mais cette complexité vient des défauts des outils en question qui ne font pas assez de validation, pas du modèle lui-même. Je n'aime pas du tout iD à cause de ça: on lui en demande trop, il présente aux débutants une idée fausse de ce qu'est la cartographie. Si on veut utiliser iD, à mon avis il ne devrait même pas être utilisé pour alimenter directement la base OSM principale mais alimenter une autre base plus simple pouvant ensuite servir de source d'intégration. Le modèle de la base unique dans OSM a vécu il va falloir qu'OSM s'ouvre à des bases multiples plus spécialisées, plus faciles à maintenir et plus facile à rapprocher et intégrer avec de plus en plus d'outils d'intégration multiniveau. Et sans doute la base OSM principale devra ne plus être que le produit de l'intégration d'un certain nombre de couches maintenues séparément. Et à terme ne sera plus qu'une API présentant l'union de plusieurs sources qualifiées. L'intégration devra être de plus en plus automatique pour que le contributeur humain, lui s'occupe de ce qui est le plus intéressant: travailler sur des sous-bases plus homogènes, plus cohérentes, plus faciles à maintenir. On peut même aller vers des intégrations bidirectionnelles. Pour ça on peut développer des tas de sites ou d'applis et militer pour que toutes ces solutions puissent coexister et faire des échanges et comparaisons b Je pense qu'ID est trop mal fichu pour notre base commune et devra aller vers un travail sur une base séparée utilisant un jeu réduit de données et une modélisation plus spécifique. L'utilisateur lambda est trop noyé sous des tas d'infos qu'il ne peut plus maitriser et qui rendent ses contributions de pus en plus difficile. Je pense même qu'à terme OSM devrait aller vers un modèle GIS natif et abandonner son modèle qui ne sera plus que virtuel dans une API d'interrogation destiné aux rendus et analyses mais plus du tout en mode écriture: l'utilisateur lui pourra tout voir dans des claques transparents, mais travaillera sur des sous-calques spécialisés. Et OSM devra supporte un système de versionnement collaboratif, façon Git, permettant aussi des innovations par l'expérimentation sans casser le reste. Et on pourrait s'épargner totalement les imports en permettant d'accéder directement aux bases sources et à leur propre API de contribution collaborative, même si on utilise un même outil visuel où on aura choisi les couches qui nous intéressent et qu'on peu maitriser. Très vite, plus personne ne sera en mesure de tout maitriser dans ces données et cela devient de plus en plus complqué de maintenir la cohérence et gérer les mises à jour car on manque d'états de synthèse. Alors que faire ? En finir avec l'id d'objet unique et passer aux objets liés par des URNs, autrement dit des ids spécialisés par source, et vers une solution où OSM au lieu de stocker les objets deviendra plutôt un résolveur permettant de référencer des tas de bases ouvertes, ou un moteur de recherche permettant de les découvrir. C'est tout le modèle de données d'OSM qui est à revoir, il montre aujourd'hui clairement ses limites et coûte trop cher à maintenir (tant en moyens nécessaires qu'en terme de moyens humains), cette base étnt de plus en plus compliquée à aborder par des humains, même experts dans leurs domaines de compétence. OSM pourrait s'inspirer des projets comme Wikidata (qui commence à devenir aussi une base de données cartographiques en tant que tel tout en étant ouvert à plus d'utilisations). Le gros du travail de Wikidata est encore fait par des bots d'import, mais cela va se tarir et c'est vers de nouvelles interfaces
Re: [OSM-talk-fr] Evaluer les kms de voies cyclables
Merci pour ces informations. J'ai testé la seconde méthode qui me semble plus simple pour moi. En exécutant la requête donnée en exemple, j'ai réussi effectivement à exporter les gpx et à obtenir la distance totale de Perpignan. Comme j'exécute bêtement j'ai remplacé le 18000 par 2177407 car dans le wiki d'OSM j'ai trouvé ce qui me semble être l'id du grand Angoulême mais là cela ne retourne rien. Relation : Grand Angoulème (2177407) Bref, merci de tes lumières. Dominique Lachgar Le 26/05/2014 17:26, rainerU a écrit : On 26.05.2014 10:28, domi wrote: je fais partie de vélocité de l'Angoumois et depuis 1 an nous contribuons à OSM pour répertorier les équipements cyclables de l'agglo, rajouter les rues manquantes ... Nous aimerions avoir une idée du kilométrage de voies cyclables de l'agglomération d'Angoulême Est- ce qu'il y a une méthode pour cela ? Je vois deux méthodes pour le faire. On peut importer les données OSM dans une base PostGis et faire une ou plusieurs requêtes spatiales du genre : select sum(st_length(l.way)) from planet_osm_line l, planet_osm_polygon p where l.highway='cycleway' and p.osm_id=-18000 and st_intersects(l.way,p.way) où 18000 est l'id de la relation boundary. Ou bien on utilise overpass / overpass-turbo pour selectionner les voies en question, puis on les eporte au format GPX, par exemple, et on aura la longueur avec un outil d'analyse GPX. Avec Overpass Turbo on obtient par exemple les pistes cyclables pour la ville de Perpignan avec http://overpass-turbo.eu/s/3xL Il suffit de remplacer 18000 par l'id de la relation boundary de ton agglo. Je préfére la méthode PostGis car elle permet un filtrage plus complexe et fournit directement la longueur. La méthode overpass a l'avantage de marcher sans base PostGis. Et il doit y avoir d'autres methodes. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Evaluer les kms de voies cyclables
Bonsoir Le 26/05/2014 22:01, domi a écrit : Merci pour ces informations. J'ai testé la seconde méthode qui me semble plus simple pour moi. En exécutant la requête donnée en exemple, j'ai réussi effectivement à exporter les gpx et à obtenir la distance totale de Perpignan. Comme j'exécute bêtement j'ai remplacé le 18000 par 2177407 car dans le wiki d'OSM j'ai trouvé ce qui me semble être l'id du grand Angoulême mais là cela ne retourne rien. Relation : Grand Angoulème (2177407) Il faut remplacer en soustrayant 18000 puis additionnant 2177407 = avec 3602177407 on a bien au final des données sur le Grand Angoulême. Bons tests, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tile.openstreetmap.fr en pause
layers est en cours de ré-importation de sa base monde Le 25 mai 2014 08:44, Philippe Verdy verd...@wanadoo.fr a écrit : Le 25 mai 2014 07:51, Christian Quest cqu...@openstreetmap.fr a écrit : Ne vous étonnez pas si c'est pas à jour ;) Problème aussi sur layers... mais qui est moins critique en terme d'usage que tile (rendu FR+HOT) Au fait sur les couches de layers, c'est volontaires qu'on n'y voit plus que les découpages admin et politiques QUE sur la France métropolitaine et plus les pays voisins (Royaume-Uni, Belgique, Luxembourg, Allemagne, Suisse, Italie, Espagne) ni au delà Afrique, Amérique, Asie et même notre outre-mer ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Evaluer les kms de voies cyclables
Bonsoir, Pouvez-vous expliquer pourquoi il faut faire ces calculs sur l'id de la relation ? Merci 2014-05-26 22:16 GMT+02:00 Vincent de Château-Thierry v...@laposte.net: Bonsoir Le 26/05/2014 22:01, domi a écrit : Merci pour ces informations. J'ai testé la seconde méthode qui me semble plus simple pour moi. En exécutant la requête donnée en exemple, j'ai réussi effectivement à exporter les gpx et à obtenir la distance totale de Perpignan. Comme j'exécute bêtement j'ai remplacé le 18000 par 2177407 car dans le wiki d'OSM j'ai trouvé ce qui me semble être l'id du grand Angoulême mais là cela ne retourne rien. Relation : Grand Angoulème (2177407) Il faut remplacer en soustrayant 18000 puis additionnant 2177407 = avec 3602177407 on a bien au final des données sur le Grand Angoulême. Bons tests, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Evaluer les kms de voies cyclables
Le 26/05/2014 22:22, Éric Gillet a écrit : Bonsoir, Pouvez-vous expliquer pourquoi il faut faire ces calculs sur l'id de la relation ? Le mécanisme est évoqué ici : http://api.openstreetmap.fr/#section.download_area L'exemple est celui d'une ville, mais (de mémoire) la possibilité a été étendue aux relations des communautés de communes. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Lot Talk-fr, Vol 94, Parution 99
Le 19 mai 2014 23:28, dom bertho new-...@hotmail.fr a écrit : Je voudrais ajouter le cas des parcelles et des adresses avec 2 accès. Un sur une rue et l' autre de l' autre coté donnant sur une autre rue. L'adressage ne correspond pas a une logique définie mais parfois a des choix de propriétaires... De nombreux cas prouvent que s'il semble avoir des règles permettant cette systématisation de nombreux cas particuliers existent.. D'ou l'idée d' une certification datée par exemple. Certification ? Par qui ? La source BANO est-elle plus officielle que tout autre chose pour déterminer laquelle parmi deux adresses possibles est la bonne ? Les cas de double adresse sont légions, et même dans la même rue avec des adresses incluant plusieurs numéros associés (par ex., 10-12 rue Xyz). L'entrée depuis la voie publique en fin de compte pourrait ne plus exister que depuis un des numéros et plus l'autre, ou le propriétaire peut avoir gardé deux entrées mais changé celle qui est principale selon lui (par exemple en fermant celle traversant un jardin par une porte fermée et utilisée uniquement par le propriétaire qui en garde la clé, alors qu'il a déplacé sa boite près de l'autre entrée qu'il garde fermée et ne franchit pas lui-même. Dans les peties villes portuaires, il est courant que les maisons soient assez serrées entre elles avec des passages où elles ont des accès sur plusieurs façades. Il n'y a pourtant pas plusieurs propriétés, mais l'enregistrement initial de l'adresse peut ne plus correspondre à l'accès utilisé aujourd'hui. Les boites à lettres peuvent être déplacées aussi. Une entrée de garage peut avoir été aménagée sur un accès plus pratique pour le véhicule de l'occupant. Le numéro de l'ancien accès peut être resté affiché en façade même s'il ne sert plus, l'aute accès n'ayant pas de numéro toujours visible mais pourtant bien réel. En fin de compte c'est l'occupant qui détermine lui-même (ou sa copropriété) quel accès privilégier. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
