Re: [OSM-talk-fr] La corée du nord sur gmaps
Vous pouviez déjà réagir dans les commentaires directement sous l'article. Le 31 janvier 2013 02:41, Severin MENARD severin.men...@gmail.com a écrit : Et tous les médias suivent, Le Monde pompant allègrement les mêmes andouilleries : http://www.lemonde.fr/technologies/article/2013/01/29/google-rend-la-coree-du-nord-plus-transparente_1823754_651865.html On devrait peut-être contacter le journaliste ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données BRGM
La non modifiabilité est une clause rédibitoire qui en fait une source non libre (même si OSM permet de consulter les versions historiques). Cette clause n'a même aucun sens pour des données géographiques qui sont nécessairement vivantes (on ne peut pas admettre que ces données ne soient ensuite modifiables QUE depuis une source de mise à jour IGN, ce qui en ferait une source unique. Il n'est pas admissible de restreindre le nombre de sources. l'IGN devrait se contenter d'être seulement cité comme UNE des sources utilisées (en autorisant aussi des importations partielles, modifiées, simplifiées dans une préparation permettant la fusion avec l'existant). OSM n'est pas destiné à être une autre base de l'IGN, avec des ressources tehcniques mises gratuitement à sa seule disposition et où il serait les seuls à disposer des droits de modification. Bref dans l'état actuel cette source n'est pas encore libre et il va falloir mieux négocier avec l'IGN pour qu'il se contentent de la mention de la source (comme le fait le cadastre). L'IGN ne répond clairement pas à l'initiative OpenData européenne. On ne lui demande pas de libérer TOUTES ses données, mais d'en mettre à disposition un certain nombre (à lui de le décider en concertation avec ses partenaires et clients, et en fonction de l'évolution de sa stratégie commerciale pour que l'IGN considère qu'il sera plus économique pour lui de ne plus garder l'exclusivité sur cette partie des données, et de faire confiance à une gestion plus communautaire). L'IGN gardera son expertise dans bien d'autres domaines, notamment pour des études poussées de certains territoires afin de créer de nouveaux jeux de données répondant à la demande de ses clients qui ne seraient pas couverts par un jeu de données libéralisé et communautaire. L'IGN peut aussi proposer à ses clients une version expurgée et nettoyée de la base OSM ou d'autres bases ouvertes, là où il pense que ces données entrent dans des conditions de fiabilité et de fraicheur suffisantes pour l'objectif fixé. L'IGN pourra aussi proposer un service de qualification et certification des données (sans que cela remette en cause les attributions des sources). Le service consistera justement à faire des extractions fines et bien qualifiées, et ensuite de boucher les trous existants en utilisant d'autres données (mais que l'IGN devra aussi ouvrir si ces autres données viennent combler les trous restant dans l'extraction OSM ou l'extraction d'autres sources ouvertes conformes à OpenData). L'IGN pourra encore proposer des services connexes : géolocaliser de gros fichiers d'adresses, faire des croisements avec d'autres données propriétaires comme les antennes relais GPS, les réseaux de communication privés, les réseaux de transports et de gestion de chalandise et logistiques, l'expertise environnementale avec des données confidentielles ou restreintes par la loi (secteur de la défense, énergie nucléaire, exploitation des forages miniers ou gaziers, études géologiques pour certaines constructions ou ouvrages d'arts) ou pour des raisons commerciales (gestion des réseaux d'autoroutes), ou des données plus publiques (implantation des radars de contrôle routier... surveillance des aqueducs et gazoducs, réseaux câblés ou fibrés...). L'iGN ne manque pas de travail et de compétence à revendre, même s'il libéralise des données publiques concernant plein de monde, où il est plus rentable et plus simple de faire confiance à une gestion plus communautaire (qui sera aussi plus réactive et pouura assurer aussi un service largement gratuit et offert et partagé à tous, pour tous les usages privés ou publics, commerciaux ou pas). L'iGN peut aussi travailler dans le développement des normes OpenGIS Le modèle actuel du profil simple ne répond pas à tout, c'est pourtant celui qu'on utilise dans OSM, il vit assez mal déjà avec la 3e dimension qu'on gère très mal ou de façon très ambigue, et OSM est limité par sa projection WGS84 qui couvre très mal les pôles et supporte de grosses aberrations à proximité des pôles, au point qu'on n'est pas capable de produire des tuiles correctes utilisant une autre projection plus pratique comme peut le faire Google avec Google Earth, en passant à la vraie 3D cartésienne, indépendante du géoïde utilisé ; Google supporte maintenact avec la 3D la modélisation multiniveau (on a les plans des étages des immeubles et la possibilité de voir les véritables profils altimétriques du terrain et le profil des tunnels ou des ponts, dans OSM on n'a que les layers qui ne sont en rien une dimension homogène, pas plus que les tags alt où on ne sait pas quel est le point de référence pour l'altitude zéro !) Pour rien que la 3D fait partie du profil OpenGIS simple (mais il faut définir pour cela ce qu'on appelle la verticale : est-ce la direction vers le centre du géoïde terrestre, très proche de la verticale de pesanteur? ou la direction de la normale à la surface du géoïde ?). On en reparlera quand on devrait modéliser aussi
Re: [OSM-talk-fr] La corée du nord sur gmaps
Bonjour, Le 03/02/2013 10:04, Philippe Verdy a écrit : Vous pouviez déjà réagir dans les commentaires directement sous l'article. Pas forcément. Sur lemonde.fr, les commentaires ne sont pas ouvert à tous. Pour réagir, il faut être abonné. Le 31 janvier 2013 02:41, Severin MENARD severin.men...@gmail.com a écrit : Et tous les médias suivent, Le Monde pompant allègrement les mêmes andouilleries : http://www.lemonde.fr/technologies/article/2013/01/29/google-rend-la-coree-du-nord-plus-transparente_1823754_651865.html On devrait peut-être contacter le journaliste ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] repère de crues - zone inondables
Le 29 janvier 2013 12:46, ades_...@orange.fr ades_...@orange.fr a écrit : Pour les pays de Loire c'est téléchargeable (mif-mid et shp) ; je crois que c'est libre mais faudrait vérifier : L'accès aux informations mises à disposition sur un site internet d'un service du ministère chargé de l'environnement et leur réutilisation sont régis par les dispositions générales de la loi n° 78-753 du 17 juillet 1978 portant diverses mesures d'amélioration des relations entre l'administration et le public et diverses dispositions d'ordre administratif social et fiscal, modifiée en dernier lieu par l'ordonnance n° 2005-650 du 6 juin 2005, du décret d'application n° 2005-1755 du 30 décembre 2005 relatif à la liberté d'accès aux documents administratifs et à la réutilisation des informations publiques ainsi que par le chapitre IV du titre II du livre Ier du Code de l'environnement (articles L. 124-1 à L. 124-8 et R. 124-1 à R. 124-5). ; je ne suis pas trop juriste ;-). Bigre ! C'est quoi ce jargon incompréhensible ? Ne peuvent-ils pas pondre eux-même une licence en langage clair conforme à ces lois et règlements, et recensant clairement les droits et obligations et les limites d'utilisation imposées s'il y en a, ainsi que les clauses de responsabilité ou dénis de responsabilité ? Car faire dépendre cela de diverses dispositions d'ordre administratif social et fiscal et de décrets en fait une source absolument instable. Que ceux qui ont pondu ces lois et règlements se concertent pour accepter une licence conforme à leurs exigences, mais *non répudiable* à loisir et à tout moment à la faveur d'un obscur arrêté ou décret dont la validité est très éphémère et les changements très mal connus (ce sera encore modifiable par la loi, mais c'est une limite connue de toutes les licences, libres ou pas). Il me semblait pourtant qu'on avait en France une licence OpenData libre créée exprès pour être utilisée par les administrations. Que les Pays de Loire s'y mettent et arrêtent de publier ce jargon légal, dont ils ne sont pas l'auteur, alors que c'est la licence publique qui prend en compte déjà les contraintes légales ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Kort... un jeu pour corriger des erreurs OSM
Noter quand même que l'API de géolocalisation permet aux utilisateurs du navigateur de soit la bloquer (par une demande d'autorisation préalable) ou de se choisir eux-même une géolocalisation (c'est le cas dans Internet Explorer sous Windows, Windows permettant de paramétrer un lieu assez vague sous la forme de seulement un nom de pays, ou nom de ville, ou une adresse complète, à charge pour les sites de convertir cela en géolocalisant les adresses fournies). La disponibilité d'un GPS ou d'une antenne GSM pour récupérer les signaux d'une antenne relai n'est pas obligatoire. Je pense même qu'à l'avenir la demande de géolocalisation effectuée par un site web permettra à l'utilisateur de choisir lui-même son lieu de géolocalisation sur une carte (OSM ou Google Map) affichée non pas par le site mais par le navigateur web (la première utilisation sera pour les sites de rencontre et les réseaux sociaux, pour protéger la vie privée... les sites pourront aussi proposer leur propre carte permettant à l'utilisateur de choisir son lieu de recherche ou de modifier son profil sur le comtpe en ligne à loisir, indépendamment du lieu vrai où il se trouve, mais si les navigateurs supportent cette fonction, ils ne le feront plus et utiliseront l'API de géolocalisation laquelle pourra être librement renseignée par l'utilisateur, soit en cliquant une carte soit en utilisant la position relevée sur un GPS si elle est disponible). La géolocalisation par IP est utilisée aussi sur certains sites mais elle n'est pas fiable du tout (je me suis déjà retrouvé aux Pays-Bas ou au Royaume-Uni ou au Canada, parce que pour accéder à certains sites en IPv6 j'utilise un VPN d'accès mondial qui détermine automatiquement le hotspot à utiliser pour q'y connecter via IPv4, avec un client local effectuant la passerelle et le routage via ce VPN, comme la passerelle véhicule *aussi* les adresses IPv4, ou les adresses IPv4 mappées en IPv6 selon divers méthodes, le serveur de VPN réachemine alors depuis son propre réseau situé n'importe où les accès ; selon les temps de réponse cela permet aussi d'accéder à des sites très difficiles à joindre depuis la France en utilisant les routeurs de son propre FAI, par exemple ceux à Taiwan, ou d'avoir une alternative de routage quand il y a une difficulté ou une panne sur un routeur du FAI ou sur les liens de peering du backbone IPv4 mondial, ce qui arrive assez fréquemment en fait). Le 29 janvier 2013 18:27, Pierre-Alain Dorange pdora...@mac.com a écrit : Philippe Verdy verd...@wanadoo.fr wrote: Si, Safari Mobile est le navigateur d'iOS. Je n'ai pas dit le contraire, mais Kort ne semble pas supporter l'API de géolocalisation de Safari sur iPhone. Ce doit certainement être un problème de validation des clés de sécurité, ou un bogue dans le Javascript de Kort pour utiliser cette API. Ou alors l'utilisateur de l'iPhone a bloqué les autorisations de géolocalisation sur son iPhone venant de Kort, ou bien le GPS est désactivé sur l'iPhone qui ne retourne pas non plsu la dernière position ni une géolocalisation basée sur l'antenne GSM ou sur l'IP du hotspot public utilisé (via un webservice de géolocalisation des IPs connues des hotspots)... Sur iPad (iOS) avec la géolocalisation qui marche bien (ailleurs), Kort ne fait rien du tout... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
Le samedi 02 février 2013 à 23:02 +0100, Vincent de Chateau-Thierry a écrit : En bref : tout ça concerne le moteur qui exploite les données (Nominatim) et pas la donnée elle-même. Ne faisons pas assumer à la donnée ce qui relève du logiciel. Bon, ok, tu as gagné, je laisse tomber (pour cette manche ;-))... Mais il faut quand même laisser un ticket sur trac.openstreetmap.org du coup... Je veux bien m'en charger mais mon anglais est...usé..., enfin, voilà... Si je résume, Nominatim devrait : - Compléter le nom des relations de limites administratives de niveau 7 en Arrondissement de %name% dans le contexte français. - de même, il faudrait compléter le nom des relations de limites politiques de type canton par Canton de %name% - Ne pas retourner ce niveau (7) dans le résultat détaillé. ex : [1] , countyArrondissement de Rennes/county), en France on attendrait plutôt countyIlle-et-Vilaine/county, soit le niveau 6. - Et pour être encore plus précis (je ne sais pas ce que cela implique ??) : department au lieu de county et pendant qu'on y est region à la place de state, pour mieux coller au contexte français... J'ai bien résumé ? Mika_Gueret ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
Non, à mon avis Nominatim n'a pas besoin de changer les noms. En revanche oui il devrait pouvoir ne pas afficher county comme type pour le niveau 7 mais bien utiliser le terme arrondissement. Cela se fait déjà dans un champ de résultat séparé du nom, ce qui rend inutile d'ajouter Arrondissement de (sans compter les problème des apostrophes ou de contraction du mot de qu'il sera trop compliqué de gérer). Bref cela me parait suffisant d'afficher Le Mans (arrondissement) mais déjà on a Le Mans (county) et ce n'est pas ambigu (si on sait que county est déduit pour le niveau 7 et correspond aux arrondissements). Pour le niveau 8 Nominatim affiche la valeur du tag place=* et on a Le Mans (city). Là encore pas d'ambiguïté. La seule chose à demander à Nominatim c'est qu'il suive les règles de désignation de nos subdivisions administratives selon le niveau (à mon avis il devrait aussi afficher le mot commune pour tout le niveau 8, même s'il affiche encore la classification du tag place=*, qui me semble redondante dès que la relation mentionne déjà la population en clair. Mais on n'a pas besoin de mettre cette précision dans le tag name=*. (Je serait même d'avis de supprimer la précision générique Communauté de communes du/des dans nos relations des EPCI. Sachant qu'on a déjà un tag séparé pour préciser le type d'EPCI, que ce soit une CC, une CA, une CU, un SAN, ou une métropole), car aucun moteur de rendu de carte ne peut le faire intelligemment (supprimer des infos automatiquement dans un nom est bien plus difficile que d'ajouter une précision venant d'un autre champ car on ne connait pas les règles applicables car parfois une précision s'avère pertinente). Le 3 février 2013 12:16, Mickaël Guéret m.gue...@free.fr a écrit : Le samedi 02 février 2013 à 23:02 +0100, Vincent de Chateau-Thierry a écrit : En bref : tout ça concerne le moteur qui exploite les données (Nominatim) et pas la donnée elle-même. Ne faisons pas assumer à la donnée ce qui relève du logiciel. Bon, ok, tu as gagné, je laisse tomber (pour cette manche ;-))... Mais il faut quand même laisser un ticket sur trac.openstreetmap.org du coup... Je veux bien m'en charger mais mon anglais est...usé..., enfin, voilà... Si je résume, Nominatim devrait : - Compléter le nom des relations de limites administratives de niveau 7 en Arrondissement de %name% dans le contexte français. - de même, il faudrait compléter le nom des relations de limites politiques de type canton par Canton de %name% - Ne pas retourner ce niveau (7) dans le résultat détaillé. ex : [1] , countyArrondissement de Rennes/county), en France on attendrait plutôt countyIlle-et-Vilaine/county, soit le niveau 6. - Et pour être encore plus précis (je ne sais pas ce que cela implique ??) : department au lieu de county et pendant qu'on y est region à la place de state, pour mieux coller au contexte français... J'ai bien résumé ? Mika_Gueret ___ 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] repère de crues - zone inondables
Le 3 févr. 2013 à 11:23, Philippe Verdy a écrit : Le 29 janvier 2013 12:46, ades_...@orange.fr ades_...@orange.fr a écrit : Pour les pays de Loire c'est téléchargeable (mif-mid et shp) ; je crois que c'est libre mais faudrait vérifier : L'accès aux informations mises à disposition sur un site internet d'un service du ministère chargé de l'environnement et leur réutilisation sont régis par les dispositions générales de la loi n° 78-753 du 17 juillet 1978 portant diverses mesures d'amélioration des relations entre l'administration et le public et diverses dispositions d'ordre administratif social et fiscal, modifiée en dernier lieu par l'ordonnance n° 2005-650 du 6 juin 2005, du décret d'application n° 2005-1755 du 30 décembre 2005 relatif à la liberté d'accès aux documents administratifs et à la réutilisation des informations publiques ainsi que par le chapitre IV du titre II du livre Ier du Code de l'environnement (articles L. 124-1 à L. 124-8 et R. 124-1 à R. 124-5). ; je ne suis pas trop juriste ;-). Bigre ! C'est quoi ce jargon incompréhensible ? Ne peuvent-ils pas pondre eux-même une licence en langage clair conforme à ces lois et règlements, et recensant clairement les droits et obligations et les limites d'utilisation imposées s'il y en a, ainsi que les clauses de responsabilité ou dénis de responsabilité ? Car faire dépendre cela de diverses dispositions d'ordre administratif social et fiscal et de décrets en fait une source absolument instable. Que ceux qui ont pondu ces lois et règlements se concertent pour accepter une licence conforme à leurs exigences, mais *non répudiable* à loisir et à tout moment à la faveur d'un obscur arrêté ou décret dont la validité est très éphémère et les changements très mal connus (ce sera encore modifiable par la loi, mais c'est une limite connue de toutes les licences, libres ou pas). Il me semblait pourtant qu'on avait en France une licence OpenData libre créée exprès pour être utilisée par les administrations. Que les Pays de Loire s'y mettent et arrêtent de publier ce jargon légal, dont ils ne sont pas l'auteur, alors que c'est la licence publique qui prend en compte déjà les contraintes légales ! certe ! ;-) je ne vais pas défendre les Pays de la Loire, mais dans ce cas je crois que c'est l'Etat, serveur carmen (équipement, écologie, je ne sais plus comment ça s'appelle maintenant). Pour la licence, j'espérais que ça éclairerait ;-). Reste à appeler une Dréal, à moins qu'un lecteur de la liste soit dans la maison, et qu'il puisse avoir la réponse plus facilement. Je pense que ce sont des données libres puisque simplement collectées auprès des communes (obligation réglementaire) et que pour certains bassins de crue il est même fait appel à la collaboration du public (la Seine je crois). Reste que je posais aussi la question de l'intérêt que ça pourrait avoir pour OSM. Et si oui, comment ça se passe pour en faire la publicité, je crois que ça devient intéressant que si les contributeurs renseignent ces repères (date, hauteur d'eau). Facile à faire lorsque l'on en voit un, encore plus facile si l'on sait d'avance où il se trouve, à condition de savoir que ça peut-être à reporter. J'avais lancé la question suite à des éléments de débat concernant la carto des zones inondables dans OSM. Cartographier les repères de crue me semblait plus intéressant que l'import zones telles que définies dans les Plan de prévention des risques d'inondations. Des points encombrent moins la base que des surfaces, en plus même si ça n'a pas complètement été tranché il ne semble pas qu'OSM doivent devenir le support de données réglementaires de l'Etat ou des Collectivités. En plus par rapport à une cartographie des zones inondables(si ce n'est pas le PPRI qui est reporté) ces points ont une existence historique, ils constatent juste l'existence d'une certaine hauteur d'eau en un point à une certaine date ; alors que dans la création de zones inondables il y a toujours une part d'interprétation. Sur le terrain je pense que l'indication d'une hauteur de crue en un point donnée renseigne, de facto, de l'inondabilité de l'endroit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] repère de crues - zone inondables
Le 3 février 2013 12:41, ades_...@orange.fr ades_...@orange.fr a écrit : je ne vais pas défendre les Pays de la Loire, mais dans ce cas je crois que c'est l'Etat, serveur carmen (équipement, écologie, je ne sais plus comment ça s'appelle maintenant). Pour la licence, j'espérais que ça éclairerait ;-). Reste à appeler une Dréal, à moins qu'un lecteur de la liste soit dans la maison, et qu'il puisse avoir la réponse plus facilement. Je pense que ce sont des données libres puisque simplement collectées auprès des communes (obligation réglementaire) et que pour certains bassins de crue il est même fait appel à la collaboration du public (la Seine je crois). Penser que... cela ne fait pas une licence claire. Rien ne vaut une licence en bonne et due forme. Qui ne s'oppose pas non pus à l'application de la loi ou d'une décision judiciaire : si tel était le cas, on pourra encore supprimer certaines données et appliquer la loi ou la décision judiciaire, et OSM dispose publiquement de tels recours. Après ce n'est pas parce qu'on réutilise légalement les données libres selon la licence que le réutilisateur n'est pas lui même à l'abri de la loi ou d'une décision judiciaire, la licence ne peut pas être une garantie juridique (et donc doit inclure une clause de non-garantie face à la loi ou une décision judiciaire exécutée en bonne et due forme). OSM le fera savoir quand il exécute une telle décision ou met des restrictions nouvelles suite à certaines lois (toutefois il faudra modérer cela par le territoire d'applicabilité de la loi qui peut ne pas inclure la totalité du projet OSM ou ses serveurs soumis déjà à la loi britannique et directives européennes transcrites dans la loi britannique, et aux traités internationaux eux aussi ratifiés par le Royaume-Uni et transcrits par la loi britannique). Dans certains cas il n'est pas inenvisageable que pour se conformer à une loi, OSM impose des restrictions d'accès selon les visiteurs mais seulement si ils sont soumis à cette loi ou sont exposés à des risques légaux inexistants au Royaume-Uni. Si cela permet de préserver le reste des données accessibles partout ailleurs cela vaut le coup de mettre ne place ces filtres (mais la dificulté est alors une question de cohérence du reste du schéma des données si des infos sont masquées à certains : le système doit être assez résistant pour que cela n'invalide pas trop d'éléments). Il me semble tout de même qu'entre le droit britannique et le droit français il y a une reconnaissance mutuelle des décisions judiciaires en vertu des traités de coopération judiciaire. De fait il y a peu de risque qu'on voit des filtres spécifiques pour l'accès aux données depuis la France (de tels risques existent en revanche avec la Chine qui a mis en place des filtres d'usage obligatoire pouvant aller très loin jusqu'à interdire d'accéder à un domaine Internet tout entier du fait de la seule présence de quelques données que contestent la Chine : le prix à payer est trop élevé si on ne met pas en place un filtrage permettant d'éviter la censure totale). Bref rien ne vaut une bonne licence. En plus cela évite à la collectivité de devoir se soumettre elle-même à des décisions : les contestations au sujet de cette licence seront traitées en commun par les initiateurs (publics) de cette licence, qui le feront savoir à ceux qui les utilisent par des révisions éventuelles du texte : alors seulement viendra la question pour la collectivité d'adopter ou non le nouveau texte. Mais bon nombre de procédures judiciaires ou de recours très chers à des avocats seront évités : une bonne licence c'est une bonne source d'économies futures car les litiges sont réglés en commun par tous ses utilisateurs et initiateurs ou défenseurs ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
2013/2/2 Vincent de Chateau-Thierry v...@laposte.net: Et surtout, la règle que tu énonces (homonymie avec l'admin_centre) n'en est pas une. Euh, pour Rennes, un peu quand même, non ? JOSM indique [7] en face de ces relations, comme indicateur du niveau administratif. Il ne faut pas voir les données qu'à travers la lorgnette de JOSM. Concernant Nominatim, tu mets le doigt sur le fond du problème, à mon avis. Nominatim fait des choix, et c'est en fait eux qui sont le sujet. En dehors de nominatim qui peut sans doute être amélioré, il faut surtout appeler un canard un canard. Je dis ça par ce qu'il faut parfois revenir à des notions simples comme énoncé sur ce wiki: http://wiki.openstreetmap.org/wiki/Duck_tagging If it looks like a duck and quacks like a duck, tag it as a duck si ça ressemble à un canard et que ça cancane comme un canard, tag le comme un canard. Si on te montre une carte qui souligne les coutours de l'arrondissement de Rennes, tu ne vas pas dire hé, mais c'est Rennes mais plutôt hé ben, ça, c'est l'arrondissement de la sous-préfecture de Rennes ? Autre choix : faire tout rentrer dans un même moule. Par simplicité, la structure des données de Nominatim range nos régions dans un niveau state, les arrondissements dans county comme tu le soulignes. En France ça ne veux rien dire, mais j'imagine que ça facilite la gestion des réponses de Mouais. 1er exemple pris au hasard, le comté de Los Angeles, USA: http://www.openstreetmap.org/browse/relation/396479 avec le tag name=Los Angeles County Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
2013/2/2 Vincent de Chateau-Thierry v...@laposte.net: En bref : tout ça concerne le moteur qui exploite les données (Nominatim) et pas la donnée elle-même. Ne faisons pas assumer à la donnée ce qui relève du logiciel. Si on part du principe que tout se déduit de la combinaison des tags, alors plus besoin de mettre Mairie de Rennes sur un amenity=townhall mais seulement Rennes (puisque la mairie se déduit du amenity). Ou École de Triffouilly-les-oies puisqu'il y a un amenity=school. etc Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
Le 03/02/2013 13:36, Pieren a écrit : 2013/2/2 Vincent de Chateau-Thierry v...@laposte.net: Et surtout, la règle que tu énonces (homonymie avec l'admin_centre) n'en est pas une. Euh, pour Rennes, un peu quand même, non ? Pour Rennes si tu veux. Je te laisse l'appliquer à Strasbourg (bon courage) : http://layers.openstreetmap.fr/?layers=BFFFTzoom=10lat=48.61899lon=7.2 JOSM indique [7] en face de ces relations, comme indicateur du niveau administratif. Il ne faut pas voir les données qu'à travers la lorgnette de JOSM. Je parlais de JOSM tout simplement en réponse à la remarque de Mickaël : pour l'édition, on voit tout de suite à quel genre de relation on a faire dans JOSM Concernant Nominatim, tu mets le doigt sur le fond du problème, à mon avis. Nominatim fait des choix, et c'est en fait eux qui sont le sujet. En dehors de nominatim qui peut sans doute être amélioré, il faut surtout appeler un canard un canard. Je dis ça par ce qu'il faut parfois revenir à des notions simples comme énoncé sur ce wiki: http://wiki.openstreetmap.org/wiki/Duck_tagging If it looks like a duck and quacks like a duck, tag it as a duck si ça ressemble à un canard et que ça cancane comme un canard, tag le comme un canard. Si on te montre une carte qui souligne les coutours de l'arrondissement de Rennes, tu ne vas pas dire hé, mais c'est Rennes mais plutôt hé ben, ça, c'est l'arrondissement de la sous-préfecture de Rennes ? Non. Si c'est sur une carte des arrondissements, on va dire : hé, mais c'est Rennes. Bref, on peut continuer longtemps comme ça, hein :-) Autre choix : faire tout rentrer dans un même moule. Par simplicité, la structure des données de Nominatim range nos régions dans un niveau state, les arrondissements dans county comme tu le soulignes. En France ça ne veux rien dire, mais j'imagine que ça facilite la gestion des réponses de Mouais. 1er exemple pris au hasard, le comté de Los Angeles, USA: http://www.openstreetmap.org/browse/relation/396479 avec le tag name=Los Angeles County En prenant un exemple aux US pour argumenter sur une situation française on ne risque pas d'aller bien loin. Je te rappelle ce que je mentionnais vendredi, issu du COG : http://insee.fr/fr/methodes/nomenclatures/cog/arrdep.asp?codedep=35 = on n'a pas arrondissement de devant chaque nom d'arrondissement, pas plus pas moins qu'on a commune de dans cet autre tableau : http://insee.fr/fr/methodes/nomenclatures/cog/comcan.asp?codedep=35codecan=47 issu du même. Et il ne faut pas mélanger le nom des tags de Nominatim (county,country) et le nom du niveau de découpage qui y est rangé (arrondissement,Bezirk,district, etc.). C'est ce dernier qui doit être adapté selon le pays. Le 03/02/2013 13:43, Pieren a écrit : Si on part du principe que tout se déduit de la combinaison des tags, alors plus besoin de mettre Mairie de Rennes sur un amenity=townhall mais seulement Rennes (puisque la mairie se déduit du amenity). Ou École de Triffouilly-les-oies puisqu'il y a un amenity=school. etc Pour les écoles on a la chance d'avoir le terrain pour constater les noms. Pour les limites admins c'est déjà moins facile, surtout pour des niveaux peu utilisés au quotidien comme les arrondissements. Mais il ne s'agit pas de faire de ce qu'on discute pour les arrondissements (et plus généralement les découpages admins) un principe pour les écoles ou les jardins publics. À tout amalgamer on ne ressort rien de bon. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
Le 03/02/2013 12:16, Mickaël Guéret a écrit : Si je résume, Nominatim devrait : - Compléter le nom des relations de limites administratives de niveau 7 en Arrondissement de %name% dans le contexte français. S'il tient à les montrer dans ses résultats, oui. Ou en plus simple : %name% (Arrondissement). - de même, il faudrait compléter le nom des relations de limites politiques de type canton par Canton de %name% Idem. - Ne pas retourner ce niveau (7) dans le résultat détaillé. ex : [1] , countyArrondissement de Rennes/county), en France on attendrait plutôt countyIlle-et-Vilaine/county, soit le niveau 6. Le niveau 6 devrait être une constante des réponses en France. Aujourd'hui il est masqué par le 7 quand le 7 existe. Pour une réponse détaillée, pourquoi pas ajouter le 7. Mais pour une réponse synthétique, présentable au grand public et sans ambiguïté, le 7 est superflu. - Et pour être encore plus précis (je ne sais pas ce que cela implique ??) : department au lieu de county et pendant qu'on y est region à la place de state, pour mieux coller au contexte français... Le nom des balises importe peu, dès lors qu'on comprend bien ce qui est mis dedans. Et là, c'est pays par pays que le sens diffère. J'ai du mal à imaginer qu'un xml change de noms de balises pays par pays. En revanche, ajouter dans la réponse une balise telle que : county_level_nameDépartement/county_level_name apporterait un vrai plus, pour adapter le vocabulaire au contexte du pays. J'ai bien résumé ? yep :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Stationnement interdit / accès pompiers
2013/2/3 Nicolas Pieuchot nls@gmail.com: Je cherche comment intégrer une zone de stationnement interdit pour accès pompier, j'ai pensé à une zone de stationnement avec access à no en fasse d'une en barrier gate avec motocar access à no. Qu'en pensez-vous ? Du peu qu'on peut en voir sur la photo, je dirais que c'est d'abord une voie de service. Perso, je tracerais la voie de service (ou son début au moins) avec un noeud pour la barrière et le tout avec un access=emergency (ou access=no + emergency=yes). Pas besoin de parler de stationnement dans ce cas, comme pour n'importe quelle intersection. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire
Et voilà, dernière erreur de migration ODbL éliminée sur le Val de Marne :) J'ai atteint mon petit objectif local. Ces erreurs signalées par osmose sont de moins en moins nombreuses, mais il ne faut pas hésiter à parcourir les alentours, surtout en repérant les nœuds orphelins qui sont souvent laissés suite à la suppression d'une route/rue par le bot de migration. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire
Le 03/02/2013 16:13, Christian Quest a écrit : Et voilà, dernière erreur de migration ODbL éliminée sur le Val de Marne :) J'ai atteint mon petit objectif local. Ces erreurs signalées par osmose sont de moins en moins nombreuses, mais il ne faut pas hésiter à parcourir les alentours, surtout en repérant les nœuds orphelins qui sont souvent laissés suite à la suppression d'une route/rue par le bot de migration. Pour les noeuds orphelins, y a déjà eu le bot jfnif ;) -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire
Dites, pour les outils et stats qui pourraient etre utile pour le projet de la semaine, Osmose vous suffit pas? Vu le nombre d'analyse osmose, il y a largement de quoi faire un projet par quinzaine? -- View this message in context: http://gis.19327.n5.nabble.com/Un-groupe-de-coordination-etait-Support-publicitaire-tp5747518p5747888.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] Stationnement interdit / accès pompiers
Merci ! 2013/2/3 Pieren pier...@gmail.com 2013/2/3 Nicolas Pieuchot nls@gmail.com: Je cherche comment intégrer une zone de stationnement interdit pour accès pompier, j'ai pensé à une zone de stationnement avec access à no en fasse d'une en barrier gate avec motocar access à no. Qu'en pensez-vous ? Du peu qu'on peut en voir sur la photo, je dirais que c'est d'abord une voie de service. Perso, je tracerais la voie de service (ou son début au moins) avec un noeud pour la barrière et le tout avec un access=emergency (ou access=no + emergency=yes). Pas besoin de parler de stationnement dans ce cas, comme pour n'importe quelle intersection. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire
Les restes du passage du bot, sont: - des noeuds/way avec comme OSM Redaction comme dernier modificateur - des noeuds orphelins avec la plupart du temps un autre compte comme dernier modificateur, car ils appartenaient à un way supprimé par le bot (ou ne passant plus par ces noeuds)... ils restent utile pour trouver les endroits où des données ont été perdues. Que fait le bot jfnif au juste ? Le 3 février 2013 16:42, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 03/02/2013 16:13, Christian Quest a écrit : Et voilà, dernière erreur de migration ODbL éliminée sur le Val de Marne :) J'ai atteint mon petit objectif local. Ces erreurs signalées par osmose sont de moins en moins nombreuses, mais il ne faut pas hésiter à parcourir les alentours, surtout en repérant les nœuds orphelins qui sont souvent laissés suite à la suppression d'une route/rue par le bot de migration. Pour les noeuds orphelins, y a déjà eu le bot jfnif ;) -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire
Le 03/02/2013 17:32, Christian Quest a écrit : Que fait le bot jfnif au juste ? ben... euh... le bot c'est moi :) Et j'ai supprimé des noeuds orphelins. Fallait pas apparemment. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire
Le 3 février 2013 17:57, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 03/02/2013 17:32, Christian Quest a écrit : Que fait le bot jfnif au juste ? ben... euh... le bot c'est moi :) Et j'ai supprimé des noeuds orphelins. Fallait pas apparemment. Si tu n'a pas fait les réparations nécessaire autour c'est dommage, mais si elles sont faites, ça ne sert à rien de les garder et tu as bien fait, enfin, il me semble ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] repère de crues - zone inondables
Le 03/02/2013 13:11, Philippe Verdy a écrit : Le 3 février 2013 12:41, ades_...@orange.fr ades_...@orange.fr a écrit : je ne vais pas défendre les Pays de la Loire, mais dans ce cas je crois que c'est l'Etat, serveur carmen (équipement, écologie, je ne sais plus comment ça s'appelle maintenant). Pour la licence, j'espérais que ça éclairerait ;-). Reste à appeler une Dréal, à moins qu'un lecteur de la liste soit dans la maison, et qu'il puisse avoir la réponse plus facilement. Je pense que ce sont des données libres puisque simplement collectées auprès des communes (obligation réglementaire) et que pour certains bassins de crue il est même fait appel à la collaboration du public (la Seine je crois). Penser que... cela ne fait pas une licence claire. Rien ne vaut une licence en bonne et due forme. Qui ne s'oppose pas non pus à l'application de la loi ou d'une décision judiciaire : si tel était le cas, on pourra encore supprimer certaines données et appliquer la loi ou la décision judiciaire, et OSM dispose publiquement de tels recours. Tu dis à la fois que cela n'est pas un licence libre mais que Bigre ! C'est quoi ce jargon incompréhensible ?. L'administration française n'est pas tenue de fournir les données sous une licence OL/LO (même si c'est plus confortable pour tous les réutilisateurs), mais est tenue à respecter la Loi française (et d'en faire un rappel -comme l'a fait en son temps la Direction Générale des Finances Publiques pour nous signifier clairement que nous avions à faire face à de l'information publique légalement réutilisable-). Comprendre la convention d'Aarhus, la directive européenne INSPIRE, la politique et la stratégie de l'État français n'est pas une tâche simple, mais nous ne sommes pas les seuls à investir ce maquis juridique. L'Open Data jette un trouble dans un monde où l'eau claire distillée par les sources officielles ne gênait personne. Les temps ont changé et il faut accepter que tous les acteurs se donnent le temps de s'adapter à cette nouvelle donne. Pour en revenir aux données environnementales, la seule tache qui pourrait empêcher une pleine réutilisation est le fait que les données produites l'aient été à partir de données IGN sans que ces services de l'État bénéficient alors de la licence étendue permettant de s'approprier (au sens droit d'auteur et droits voisins) les données dérivées. On entre ici dans le dur de la stratégie de l'État vis à vis de lui-même ou de ses émanations (s'agissant plus particulièrement de la partie de la mission de service public de l'IGN (Référentiel à Grande Échelle -RGE) théoriquement entièrement subventionné. En résumé, utiliser des données DREAL, aucun doute sur la légalité. Télécharger des données DREAL, nécessité de verrouiller la clause IGN. Denis, ex-voisin de la maison ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire
Le 03/02/2013 20:42, Christian Quest a écrit : Si tu n'a pas fait les réparations nécessaire autour c'est dommage /o\ Je n'avais pas réalisé que les points provenaient du bot rédacteur. Je pensais à des imports foirés. Dans cette situation, un nettoyage avant de reprendre est nécessaire. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de localisation de Rennes
Le 03/02/2013 18:11, Pieren a écrit : Moi, j'essaie de parler de ce qu'on met dans le tag name d'une relation administrative. Nominatim a juste permis de révéler que plusieurs entités administratives portent exactement le même tag name, ce qui prête à confusion. J'ai aussi dit que nominatim pouvait sans doute être amélioré mais cela n'enlève rien au problème original sur le tag name. Si tous les outils affichant les données OSM doivent être modifiés pour éviter ces subtilités franco-françaises, il y a un problème, non ? Pour moi il n'y a pas de problème sur le tag name, mais des problèmes sur la manière d'appréhender sa valeur dans des applications, d'où les disgressions sur Nominatim. Partir du principe que la valeur du name est auto-suffisante pour délivrer un résultat non ambigü, quand on parle des noms de lieux, c'est une erreur. Et ça n'a rien de franco-français. Certes, on a nos Saint-Nicolas ou Saint-Martin, mais pour qui aime les exemples aux USA :-), combien de Paris là-bas ? Une floppée : http://en.wikipedia.org/wiki/Paris_%28disambiguation%29 De Bagdad ? Quelques uns : http://en.wikipedia.org/wiki/Bagdad_%28disambiguation%29 etc. Je ne dis pas autre choses pour les arrondissements. Pour reformuler (après, promis, j'arrête) : Je préfère en base un tag name avec strictement le nom, et pas un nom aménagé qui viserait à désambiguïser par lui-même. On a d'autres moyens que le tag name pour éviter les confusions, et la combinaison de tags est un levier à actionner : qui par le code postal, qui par le niveau administratif de l'objet, qui par un niveau administratif (ou postal) dans lequel est inclus l'objet. À tout amalgamer on ne ressort rien de bon. Il ne s'agissait pas d'amalgame mais d'illuster les limites de l'argument l'identification se déduit du nom complété par d'autres tags par des contre-exemples simples. vincent (convaincu que ça n'est pas simple) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthophotoplans de Toulouse
Génial.
Les utilisateurs de Viking peuvent aussi en profiter en rajoutant les
lignes suivantes dans ~/.viking/maps.xml :
object class=VikSlippyMapSource
property name=labelOrthophotoplans Toulouse 2011/property
property name=hostnamewms.openstreetmap.fr/property
property name=url/tms/1.0.0/toulouse_ortho2011/%d/%d/%d.png/property
property name=id510/property
/object
object class=VikSlippyMapSource
property name=labelOrthophotoplans Toulouse 2007/property
property name=hostnamewms.openstreetmap.fr/property
property name=url/tms/1.0.0/toulouse_ortho2007/%d/%d/%d.png/property
property name=id511/property
/object
Je suis toutefois surpris que le format des fichiers soit en .png pour
des photos.
Le 2 février 2013 12:28, Jean-Guilhem Cailton j...@arkemie.com a écrit :
Bonjour,
Les orthophotoplans de Toulouse, réalisés à partir de prises de vue
aériennes de juillet 2011 et 2007, avec une taille de pixel de 12,5 cm,
et libérés par Toulouse Métropole, sont disponibles en TMS sur
wms.openstreetmap.fr.
Vous pouvez les visualiser dans votre navigateur à partir de :
http://wms.openstreetmap.fr/toulouse
(qui inclut aussi quelques cartes OSM, dont le rendu en occitan de PauLLA).
Ces images sont intégrées dans les fournisseurs d'imagerie de JOSM,
accessibles dans l'onglet WMS-TMS des préférences (mettez la liste à
jour, et activez-les pour les faire apparaître dans votre menu imagerie).
Vous pouvez aussi ajouter à la main ces URL TMS pour JOSM :
tms[22]:
http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2011/{zoom}/{x}/{y}
tms[22]:
http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2007/{zoom}/{x}/{y}
Pour Potlatch2, ajoutez ces URL dans les arrières-plans :
http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2011/$z/$x/$y
http://wms.openstreetmap.fr/tms/1.0.0/toulouse_ortho2007/$z/$x/$y
Voyez https://wiki.openstreetmap.org/wiki/Toulouse/ToulouseMetropoleData
pour la source à citer.
Bien cordialement,
Jean-Guilhem
--
gpg 0x5939EAE2
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
--
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire
Je suis complètement pour. Toutefois il me semble que ceux qui lancent ces projets devraient être attentif à la question de la validation de la donnée entrée. Par validation, je ne veux pas dire de prouver à 100% que la donnée entrée est vrai, mais qu'il existe une règle, dans le cadre du projet, que l'on considère validante. Et placer cette règle dans les paramètres de la donnée. Par exemple, j'ai remarqué qu'on considérait quelque fois l'imagerie bing comme validante. On dit Je le vois dans Bing, et je le vois dans OSM, donc OSM est bon ! Alors on devrait placer dans les paramètres de ce que l'on voit un truc style Bing OK. Autre exemple, on dit quelques fois que telle cartopartie a fait tel parcours, et comme les cartoparties c'est du vu et du vécu, alors c'est bon. Et on devrait, je pense, placer dans les paramètres des données Vu et Vécu au cours de la cartopartie machin du truc. maiscestcommechacun y penseetcestpasgravesivouspensezautrement jepeuxmetromper. Le 1 février 2013 10:47, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Je forke une discussion en cours (jointe) pour lever le point de la coordination. J'ai bien conscience qu'OSM est basé sur le volontaria et la liberté de contribution et je ne remets pas en cause cette vision. Je reste convaincu que la mise en place d'un groupe de travail pourrait se mettre en place pour faire des propositions de taches à réaliser sur le territoire français (au sens large), comme cela a pu se faire ponctuellement sur le Nord avec le remplacement des données supprimées. Je vous propose de lancer le sujet pour en débattre et voir l'intérêt qu'y la communauté porte. A+ -- Marc Sibert m...@sibert.fr -- Message transféré -- De : Pierre-Alain Dorange pdora...@mac.com Date : 31 janvier 2013 20:01 Objet : Re: [OSM-talk-fr] Support publicitaire À : talk-fr@openstreetmap.org Michel michel.descou...@gmail.com wrote: quand je tombe sur des zones de ce type, une question me vient à l'esprit : le devenir d'OSM est il de servir, entre autres, de support publicitaire pour des structures à but lucratif ? http://www.openstreetmap.org/?lat=43.610584lon=3.876857zoom=18layers=M C'est le Sentier ? Je suis aussi assez dubitatif sur ce genre de rendu qui peut avoir certains intérêts (on a tous des centres d'intérêts différents et un rendu généraliste ne pourra pas satisfaire tout le monde) mais un tel niveau de détail me perturbe quand on trouve a quelques kilomètres de là des zone ou il manque de la voirie... Mais c'est aussi le propre d'un projet comme le notre. Il est contributif, chacun y contribu a sa manière, sur les zones qui l'intéresse et aussi sur les sujets qui l'intéresse. Toutefois il manquerait peut être une coordination pour rendre nos cartes plus homogène (des task-forces de vétérans qui s'occuperaient sur bien commun et s'organiserait pour cartographier les bases sur l'ensemble d'un territoire). Après l'autre soucis que je vois avec le tag de toutes ces boutiques, ce sont les mises à jour. Car dans certains coins ça change souvent d'enseigne et là on est carrément pas équipé pour assurer un suvi et on va vite se retrouver avec des trucs obsolètes... Mais là encore c'est compliqué, chacun fait comme il a envie. Par exemple lors des carto-parties que j'organise localement j'ai une participantes qui note tout, pour une boutique elle va noter le nom, les horaires d'ouvertures, le téléphone, etc... et veut renseigner ça dans OSM. Je lui ait bien sur montrer comment faire, mais j'y ait mis des bémoles persos sur le fiabilité et longévités des données. On cartographie des bourges ruraux et ces infos ne me semble pas assez fixe pour être intégrer à OSM avec le niveai d'organisation qui existe. Mais en même temps, je peux pas lui interdire de s'amuser en notant tout, elle a parfaitement le droit de la faire... -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ 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
