Re: [OSM-talk-fr] Frontière Guyane-Brésil
Superbe boulot ! Ça me fait me remémorer un super reportage sur la recherche de la tri-frontières entre la guyane Française, le Suriname et le Brésil ! Sur quelles données se baser sur des frontières aussi difficiles ? -- View this message in context: http://gis.19327.n5.nabble.com/Frontiere-Guyane-Bresil-tp5729676p5729711.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] Alignement cadastre
Bonjour Vincent, Le 09/10/2012 22:26, Vincent de Chateau-Thierry a écrit : La vectorisation est autant que je sache manuelle, elle s'appuie bien sûr sur le calage préalable des planches raster. Et ça peut déraper à toutes les étapes : - les planches peuvent être à la base mal foutues (le nord pas au nord, etc.), - le calage peut à son tour être approximatif, - et le re-dessin itou. Sans parler de la dextérité des exécutants : la vectorisation est faite par tant d'opérateurs différents (cabinets de géomètres, CDIF) qu'au final on est vraiment face à une source hétérogène. Je pensais que la vectorisation était mieux gérée qu'elle n'apparaît. Bah, faut pas l'enterrer trop vite non plus :-). En combinant bing et cadastre, on est quand même assez vernis en France. Entièrement d'accord. Mais, justement, la qualité de ce que l'on trouve dans les grosses agglomérations (ex : Bordeaux) donne de mauvaises habitudes et inspire une confiance qui ne doit en aucun cas être généralisée. Quelles sont vos expériences ? Comment gérez-vous la rotation sous JOSM ? Heu... je ne sais pas. Et pourtant elle tourne :-p Pour la rotation, avec un way selectionné : Ctrl+Shift puis bouger la souris. Magie :-) \o/ Super ! Merci ! -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alignement cadastre
Le 09/10/2012 23:01, Pieren a écrit : Il faudrait signaler ce problème soit à la DGFiP, soit au CDIF local pour que ce soit corrigé. En même temps, il est probable qu'ils soient déjà au courant (les géomètres experts devraient s'en rendre compte avant nous) mais qu'il n'y ait pas de budget pour refaire le plan... je m'interroge sur les éventuels conflits de voisinage lorsque, pour les résoudre, il faut faire appel au Cadastre... -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose a changé de peau
Le 09/10/2012 21:20, Etienne Trimaille a écrit : Le 9 octobre 2012 21:01, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net mailto:jean-francois.nifenec...@laposte.net a écrit : l'interface d'OsmOse a changé : précédemment en regard de chaque type d'erreur figurait son niveau (1, 2 ou 3). Cette information a disparu. C'est dommage car je la trouvais très intéressante. J'ai loupé qqch ou bien ? C'est la gravité des erreurs. Rouge, niveau 1 orange, niveau 2 et jaune le niveau 3. Ahah ! Sauf que, sur mon poste et par défaut, la langue est en et que, en habitué de la langue de Guillaume Hochepoire, je n'avais pas changé. Dans mon cas, pas de points de couleur : suite à ton message je les ai cherchés un bon moment ces %$§ points... Lorsque l'on choisi FR, alors plusieurs nouveautés : la fenêtre Osmose est par dessus la carte glissante et les merveilleux points sont là (suggestion : mettre le niveau en clair car la relation couleur-niveau n'est pas implicite). - Il semble que, lors de la transition de mode d'affichage entre l'ancien mode (sans les points) et le nouveau (avec), mon Firefox n'ait pas mis à jour son cache. Qu'on se le dise ! Note : je rejoins l'avis de Francescu. Lorsque l'on choisi rien, eh bien c'est qu'on ne veut *rien* et non les erreurs par défaut. C'est assez perturbant au début. Bon, après, on s'y fait. En matière d'usage je verrais : -- choix d'un niveau - les erreurs pour ce niveau -- rien - aucune erreur -- tout - toutes les erreurs pour le niveau sélectionné Merci Étienne ! -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alignement cadastre
Mappant principalement en zone rurale, la plupart du temps, je pars du principe que le cadastre est décalé... Mais... je suis impatient de voir ce que va donner le remaniement cadastrale dans les communes que je connais. je m'interroge sur les éventuels conflits de voisinage lorsque, pour les résoudre, il faut faire appel au Cadastre... Il n'est pas fait pour ça, et n'a pas de valeur légale dans ce genre de situation. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose a changé de peau
Je rejoins les autres avis, si rien c'est tout alors autant supprimer le bouton rien puisque sa fonction est identique à tout. Dommage qu'il n'y ait pas le petit champs de recherche de lieu qu'on a sur openlayer. A ce propos, quel est l'intérêt d'openlayer puisqu'on retrouve les même infos dans osmose ? Est-ce que ce ne serait pas plus judicieux de fusionner les 2 services ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose a changé de peau
Sur mon ordi, avec firefox, le lien permalink est superposé aux infos de coordonnées. Je suis le seul dans ce cas ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alignement cadastre
Le 9 octobre 2012 20:51, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonsoir, au cours de mes pérégrinations correctrices, j'ai rencontré un cas de bâti mal calé. [...] Ma confiance dans le Cadastre s'émousse très fortement... Quelles sont vos expériences ? J'ai de moins en moins confiance dans le cadastre en Haute-Garonne. j'ai rencontré ce genre de décalage à Merville (au nord de Toulouse) et dans une commune au sud-est (Je ne sais plus laquelle. Péchabou ?). Bruno. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière Guyane-Brésil
2012/10/10 partir-en-vtt ad...@partir-en-vtt.com: Sur quelles données se baser sur des frontières aussi difficiles ? Pour la partie terrestre, je me souviens d'un reportage sur un groupe de légionnaires qui partaient en expédition pour dégager de grosses bornes en béton qui marquaient la frontière au milieu de la forêt vierge. Mais ça n'est pas le cadastre, hein, c'est genre une borne tous les 30 kms. Leurs coordonnées GPS doivent être connues et on pourrait peut-être même les repérer sur les images aériennes si la résolution est suffisante. Sinon, les frontières sont définies par des traités internationaux et utilisent souvent un cour d'eau comme repère simple. Donc les tracer depuis l'imagerie aérienne a du sens sauf qu'il faut faire une confiance toute relative au positionnement des images (mais c'est déjà mieux que le tracé grossier de l'import CIA World Database actuel). La difficulté peut aussi venir sur les îlots et branches multiples du fleuve. Il est possible qu'il reste encore des désaccords sur la position exacte de la frontière au mètre près et donc de l'appartenance de tel ou tel îlot. Le mieux serait de comparer les cartes officielles françaises et brésiliennes. D'après ce que j'ai compris, seule la frontière sur le Rhin avec l'Allemagne a été très précisement définie pour des raisons de droit et de recherche de responsabilités en cas d'accident, et ce, dans un traité signé très récemment (début des années 2000). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alignement cadastre
Il ne faut pas non plus exagérer ni généraliser, tant dans un sens (le cadastre est LA référence) que dans l'autre (le cadastre est vraiment mal calé). C'est du cas par cas et c'est une des raisons pour lesquelles on l'intègre après un contrôle/travail que seul un humain peut faire en recoupant les sources. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] IGN et data.ign.fr
Bonjour, Extract: Data.ign.fr est un site expérimental pour la diffusion de données de l'IGN au format des Linked data. Il est mis en place dans le contexte du projet collaboratif Datalift financé par l'Agence Nationale de la Recherche (CONTINT 2010). L'objectif de ce projet est de mettre au point une plate-forme pour la publication et l'interconnexion de contenu selon le modèle des Linked data (formats RDF, OWL, SPARQL). http://data.ign.fr/ Pour l'instant c'est pauvre en données : Ontologie topographique : topo.owl Données administratives : SPARQL Endpoint -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment décrire une borne qui rentre dans le sol?
2012/9/20 Jean-Marc Liotier j...@liotier.org: Nan, liftgate c'est http://www.securityproductsolutions.com/Images/traffic-gate-3.jpg La borne au sol genre bite d'amarrage c'est bollard - et rentrant dans le sol ce serait donc barrier=rising_bollard J'ai trouvé dans le wiki barrier=bollard + bollard=rising avec 291 occurences dans taginfo (http://wiki.openstreetmap.org/wiki/Key:bollard). Donc beaucoup plus que le barrier=rising_bollard qui, lui, n'est pas documenté. Les hollandais proposent même un automatic=yes (http://wiki.openstreetmap.org/wiki/NL:Tag:barrier%3Dbollard#Automatische.2C_.22Rising.22_Pollers) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] IGN et data.ign.fr
En gros... GEOFLA en SPARQL ;) Je suis à Etalab pour la journée à propos de Datalift, le projet de web sémantique (voir sur http://datalift.org/fr ). Le 10 octobre 2012 10:44, Cyrille Giquello cyrill...@gmail.com a écrit : Bonjour, Extract: Data.ign.fr est un site expérimental pour la diffusion de données de l'IGN au format des Linked data. Il est mis en place dans le contexte du projet collaboratif Datalift financé par l'Agence Nationale de la Recherche (CONTINT 2010). L'objectif de ce projet est de mettre au point une plate-forme pour la publication et l'interconnexion de contenu selon le modèle des Linked data (formats RDF, OWL, SPARQL). http://data.ign.fr/ Pour l'instant c'est pauvre en données : Ontologie topographique : topo.owl Données administratives : SPARQL Endpoint -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] IGN et data.ign.fr
Le 10/10/2012 11:03, Christian Quest a écrit : En gros... GEOFLA en SPARQL ;) OKI mais comment on filtre les information ? Quels sont les resources RDF que l'on peut utiliser pour filtrer les données ? ça manque d'info quoi ;-) Je suis à Etalab pour la journée à propos de Datalift, le projet de web sémantique (voir sur http://datalift.org/fr ). Le 10 octobre 2012 10:44, Cyrille Giquello cyrill...@gmail.com a écrit : Bonjour, Extract: Data.ign.fr est un site expérimental pour la diffusion de données de l'IGN au format des Linked data. Il est mis en place dans le contexte du projet collaboratif Datalift financé par l'Agence Nationale de la Recherche (CONTINT 2010). L'objectif de ce projet est de mettre au point une plate-forme pour la publication et l'interconnexion de contenu selon le modèle des Linked data (formats RDF, OWL, SPARQL). http://data.ign.fr/ Pour l'instant c'est pauvre en données : Ontologie topographique : topo.owl Données administratives : SPARQL Endpoint -- Cyrille. ___ 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] Tuteurs pour volontaires européens ?
Bonjour, Je up le sujet et j'en profite pour répondre positivement à cette demande de support à distance. Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire sur le forum. A+ Marc Le 4 octobre 2012 18:32, Christian Quest cqu...@openstreetmap.fr a écrit : Demain se termine la formation EUROSHA de volontaires européens à laquelle je participe depuis le début de la semaine. De quoi s'agit-il ? Un vingtaine de volontaires ont suivit une formation de 3 semaines avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad et Centrafrique) dans les semaines qui vont venir pour y faire de la cartographie à visée humanitaire sur OpenStreetMap. La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a été très dense car elle couvrait: la présentation du projet avec le concept de licence libre de logiciels libres, de crowdsourcing, puis un aperçu des outils de contributions de l'imagerie aérienne, de la préparation d'une collecte sur le terrain, une cartopartie avec relevés par GPS, logger, walking papers et photos géotaguées, puis saisie dans JOSM, puis les outils de contrôle de qualité, les outils de coordination (OSM Task Manager d'HOT), et on va attaquer la partie exploitation des données. Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à digérer... et qu'il va falloir consolider tout ça. Ils partent en mission dans les semaines à venir, et vont donc rapidement avoir à mettre les mains dans le cambouis et besoin d'être aidés. Je propose donc à ceux qui le souhaite et qui se sentent capable de prendre par la main des débutants d'avoir un rôle de tuteur et j'ai invité les volontaires francophones à venir sur http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur puisse les suivre. Dans un premier temps, il s'agit essentiellement d'aider à prendre en main JOSM et de gagner en efficacité ainsi que de suivre les tracés de routes et de bâtiments faits sur les images bing dans leur zone de déploiement. Les règles de tagging seront à voir dans un deuxième temps, et elles sont un peu spécifiques à l'humanitaires et parfois différentes par rapport à nos habitudes. Plus d'infos: - http://hot.openstreetmap.org/projects/eurosha_0 - http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alignement cadastre
Le 10/10/2012 10:28, Christian Quest a écrit : Il ne faut pas non plus exagérer ni généraliser, tant dans un sens (le cadastre est LA référence) que dans l'autre (le cadastre est vraiment mal calé). C'est du cas par cas et c'est une des raisons pour lesquelles on l'intègre après un contrôle/travail que seul un humain peut faire en recoupant les sources. D'où l'intérêt immense qu'il y a de bien prévenir lors de l'intégration du bâti (voir autres discussions sur ce sujet). Lorsque j'ai débuté cette intégration, il y a bien longtemps, j'ai commis moult erreurs involontaires (pas vrai Fred ?) sans bien mesurer toutes les particularités qui se rattachent au bâti intégré (bref, j'ai fait un peu bourrin). Tout particulièrement les décalages, quasi inexistants dans les zones urbaines que j'ai d'abord traitées. C'est aujourd'hui que j'aborde les zones rurales par le petit bout de la lorgnette (Osmose) que je vois qu'il y a Cadastre et Cadastre. D'autres problèmes comme les bâtiments se recouvrant et les interstices entre bâtiments (points de jonction non déclarés) montrent que l'intégration devrait se faire groupe de maisons par groupe de maisons tant les détails sont infimes (et pas toujours relevés par le validateur JOSM). Ce qui montre l'importance de vérifier avec *très* grand soin avant l'intégration. Celle-ci ne peut donc pas être rapide, il faut que les contributeurs en aient conscience. Quoi qu'il en soit, oui, le Cadastre est une bonne source de données, oui Bing est une bonne source de données et *grand merci* à tous ceux qui ont créé les outils permettant de les exploiter et de vérifier la qualité des données. C'est sur ce dernier terrain que nous serons j(a)ugés et c'est celui-là que nous devons améliorer. Amicalement, -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?
Ca va venir, j'attendais d'avoir quelques tuteurs en stock pour leur refaire signe... Le 10 octobre 2012 11:14, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Je up le sujet et j'en profite pour répondre positivement à cette demande de support à distance. Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire sur le forum. A+ Marc Le 4 octobre 2012 18:32, Christian Quest cqu...@openstreetmap.fr a écrit : Demain se termine la formation EUROSHA de volontaires européens à laquelle je participe depuis le début de la semaine. De quoi s'agit-il ? Un vingtaine de volontaires ont suivit une formation de 3 semaines avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad et Centrafrique) dans les semaines qui vont venir pour y faire de la cartographie à visée humanitaire sur OpenStreetMap. La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a été très dense car elle couvrait: la présentation du projet avec le concept de licence libre de logiciels libres, de crowdsourcing, puis un aperçu des outils de contributions de l'imagerie aérienne, de la préparation d'une collecte sur le terrain, une cartopartie avec relevés par GPS, logger, walking papers et photos géotaguées, puis saisie dans JOSM, puis les outils de contrôle de qualité, les outils de coordination (OSM Task Manager d'HOT), et on va attaquer la partie exploitation des données. Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à digérer... et qu'il va falloir consolider tout ça. Ils partent en mission dans les semaines à venir, et vont donc rapidement avoir à mettre les mains dans le cambouis et besoin d'être aidés. Je propose donc à ceux qui le souhaite et qui se sentent capable de prendre par la main des débutants d'avoir un rôle de tuteur et j'ai invité les volontaires francophones à venir sur http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur puisse les suivre. Dans un premier temps, il s'agit essentiellement d'aider à prendre en main JOSM et de gagner en efficacité ainsi que de suivre les tracés de routes et de bâtiments faits sur les images bing dans leur zone de déploiement. Les règles de tagging seront à voir dans un deuxième temps, et elles sont un peu spécifiques à l'humanitaires et parfois différentes par rapport à nos habitudes. Plus d'infos: - http://hot.openstreetmap.org/projects/eurosha_0 - http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] IGN et data.ign.fr
Peace and LOV ! http://lov.okfn.org/dataset/lov/details/vocabularySpace_Space.html Les vocabulaires (ontology) liés aux données géographiques... Le 10 octobre 2012 11:06, rldhont rldh...@gmail.com a écrit : Le 10/10/2012 11:03, Christian Quest a écrit : En gros... GEOFLA en SPARQL ;) OKI mais comment on filtre les information ? Quels sont les resources RDF que l'on peut utiliser pour filtrer les données ? ça manque d'info quoi ;-) Je suis à Etalab pour la journée à propos de Datalift, le projet de web sémantique (voir sur http://datalift.org/fr ). Le 10 octobre 2012 10:44, Cyrille Giquello cyrill...@gmail.com a écrit : Bonjour, Extract: Data.ign.fr est un site expérimental pour la diffusion de données de l'IGN au format des Linked data. Il est mis en place dans le contexte du projet collaboratif Datalift financé par l'Agence Nationale de la Recherche (CONTINT 2010). L'objectif de ce projet est de mettre au point une plate-forme pour la publication et l'interconnexion de contenu selon le modèle des Linked data (formats RDF, OWL, SPARQL). http://data.ign.fr/ Pour l'instant c'est pauvre en données : Ontologie topographique : topo.owl Données administratives : SPARQL Endpoint -- Cyrille. ___ 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 - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alignement cadastre
Est-ce qu'il serait possible de faire une visualisation combinant : _ Les limites communales osm (on peut prendre celle de layers.openstreetmap.fr) _ Les limites communales geofla (ça doit pouvoir se trouver quelque part) _ les limites communales individuelles des communes, provenant du dépôt cadastre Pour ce dernier point, on pourrait avoir une couche de tuiles, ou bien générer les contours à la volée d'une commune à étudier et de celles de ses voisines. Pour le peu d'import de bâti que j'ai fait, j'ai constaté un décalage pour la commune de Lassouts (12)http://www.openstreetmap.fr/outils/etat-commune?insee=12124alors que les communes alentours semblaient cohérentes entre elles, au moins au niveau des limites admin. L'outil état-communes (cf. lien pour lassouts) donnant les communes limitrophes, je me dis que cela ne doit pas hors de portée. Si on a de plus la possibilité d'afficher la couche d'imagerie Bing et les points géodésiques, ça pourrait faire un bon outil de vérif par croisement des sources à disposition Le 10 octobre 2012 11:26, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 10/10/2012 10:28, Christian Quest a écrit : Il ne faut pas non plus exagérer ni généraliser, tant dans un sens (le cadastre est LA référence) que dans l'autre (le cadastre est vraiment mal calé). C'est du cas par cas et c'est une des raisons pour lesquelles on l'intègre après un contrôle/travail que seul un humain peut faire en recoupant les sources. D'où l'intérêt immense qu'il y a de bien prévenir lors de l'intégration du bâti (voir autres discussions sur ce sujet). Lorsque j'ai débuté cette intégration, il y a bien longtemps, j'ai commis moult erreurs involontaires (pas vrai Fred ?) sans bien mesurer toutes les particularités qui se rattachent au bâti intégré (bref, j'ai fait un peu bourrin). Tout particulièrement les décalages, quasi inexistants dans les zones urbaines que j'ai d'abord traitées. C'est aujourd'hui que j'aborde les zones rurales par le petit bout de la lorgnette (Osmose) que je vois qu'il y a Cadastre et Cadastre. D'autres problèmes comme les bâtiments se recouvrant et les interstices entre bâtiments (points de jonction non déclarés) montrent que l'intégration devrait se faire groupe de maisons par groupe de maisons tant les détails sont infimes (et pas toujours relevés par le validateur JOSM). Ce qui montre l'importance de vérifier avec *très* grand soin avant l'intégration. Celle-ci ne peut donc pas être rapide, il faut que les contributeurs en aient conscience. Quoi qu'il en soit, oui, le Cadastre est une bonne source de données, oui Bing est une bonne source de données et *grand merci* à tous ceux qui ont créé les outils permettant de les exploiter et de vérifier la qualité des données. C'est sur ce dernier terrain que nous serons j(a)ugés et c'est celui-là que nous devons améliorer. Amicalement, -- 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 -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose a changé de peau
Rien, c'est différent de Tout car cela permet de ne sélectionner ensuite qu'un seul type d'erreur, en ne cochant que celle-ci dans la liste plutôt que décocher toutes les autres... Mika Le mercredi 10 octobre 2012 à 09:32 +0200, Stéphane Péneau a écrit : Je rejoins les autres avis, si rien c'est tout alors autant supprimer le bouton rien puisque sa fonction est identique à tout. Dommage qu'il n'y ait pas le petit champs de recherche de lieu qu'on a sur openlayer. A ce propos, quel est l'intérêt d'openlayer puisqu'on retrouve les même infos dans osmose ? Est-ce que ce ne serait pas plus judicieux de fusionner les 2 services ? ___ 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] Alignement cadastre
Une couche GEOFLA sur layers.openstreetmap.fr pourrait être facilement ajoutée et utile. Pour une couche de limites administratives directement issues du cadastre, il faudrait toutes les extraire sur les communes en cadastre vecteur et en faire une couche à part... rien d'insurmontable, je pense même en avoir une copie historique de juin 2010 où j'avais fait une extraction globale du cadastre. Pour les communes limitrophes, j'utilise GEOFLA sur l'outil etat-commune avec un peu de PostGIS. Le 10 octobre 2012 11:41, Ab_fab gamma@gmail.com a écrit : Est-ce qu'il serait possible de faire une visualisation combinant : _ Les limites communales osm (on peut prendre celle de layers.openstreetmap.fr) _ Les limites communales geofla (ça doit pouvoir se trouver quelque part) _ les limites communales individuelles des communes, provenant du dépôt cadastre Pour ce dernier point, on pourrait avoir une couche de tuiles, ou bien générer les contours à la volée d'une commune à étudier et de celles de ses voisines. Pour le peu d'import de bâti que j'ai fait, j'ai constaté un décalage pour la commune de Lassouts (12) alors que les communes alentours semblaient cohérentes entre elles, au moins au niveau des limites admin. L'outil état-communes (cf. lien pour lassouts) donnant les communes limitrophes, je me dis que cela ne doit pas hors de portée. Si on a de plus la possibilité d'afficher la couche d'imagerie Bing et les points géodésiques, ça pourrait faire un bon outil de vérif par croisement des sources à disposition Le 10 octobre 2012 11:26, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 10/10/2012 10:28, Christian Quest a écrit : Il ne faut pas non plus exagérer ni généraliser, tant dans un sens (le cadastre est LA référence) que dans l'autre (le cadastre est vraiment mal calé). C'est du cas par cas et c'est une des raisons pour lesquelles on l'intègre après un contrôle/travail que seul un humain peut faire en recoupant les sources. D'où l'intérêt immense qu'il y a de bien prévenir lors de l'intégration du bâti (voir autres discussions sur ce sujet). Lorsque j'ai débuté cette intégration, il y a bien longtemps, j'ai commis moult erreurs involontaires (pas vrai Fred ?) sans bien mesurer toutes les particularités qui se rattachent au bâti intégré (bref, j'ai fait un peu bourrin). Tout particulièrement les décalages, quasi inexistants dans les zones urbaines que j'ai d'abord traitées. C'est aujourd'hui que j'aborde les zones rurales par le petit bout de la lorgnette (Osmose) que je vois qu'il y a Cadastre et Cadastre. D'autres problèmes comme les bâtiments se recouvrant et les interstices entre bâtiments (points de jonction non déclarés) montrent que l'intégration devrait se faire groupe de maisons par groupe de maisons tant les détails sont infimes (et pas toujours relevés par le validateur JOSM). Ce qui montre l'importance de vérifier avec *très* grand soin avant l'intégration. Celle-ci ne peut donc pas être rapide, il faut que les contributeurs en aient conscience. Quoi qu'il en soit, oui, le Cadastre est une bonne source de données, oui Bing est une bonne source de données et *grand merci* à tous ceux qui ont créé les outils permettant de les exploiter et de vérifier la qualité des données. C'est sur ce dernier terrain que nous serons j(a)ugés et c'est celui-là que nous devons améliorer. Amicalement, -- Jean-Francois Nifenecker, Bordeaux ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?
Moi aussi je suis dispo pour ça, en Français ou en Anglais. Le 10/10/2012 11:27, Christian Quest a écrit : Ca va venir, j'attendais d'avoir quelques tuteurs en stock pour leur refaire signe... Le 10 octobre 2012 11:14, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Je up le sujet et j'en profite pour répondre positivement à cette demande de support à distance. Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire sur le forum. A+ Marc Le 4 octobre 2012 18:32, Christian Quest cqu...@openstreetmap.fr a écrit : Demain se termine la formation EUROSHA de volontaires européens à laquelle je participe depuis le début de la semaine. De quoi s'agit-il ? Un vingtaine de volontaires ont suivit une formation de 3 semaines avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad et Centrafrique) dans les semaines qui vont venir pour y faire de la cartographie à visée humanitaire sur OpenStreetMap. La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a été très dense car elle couvrait: la présentation du projet avec le concept de licence libre de logiciels libres, de crowdsourcing, puis un aperçu des outils de contributions de l'imagerie aérienne, de la préparation d'une collecte sur le terrain, une cartopartie avec relevés par GPS, logger, walking papers et photos géotaguées, puis saisie dans JOSM, puis les outils de contrôle de qualité, les outils de coordination (OSM Task Manager d'HOT), et on va attaquer la partie exploitation des données. Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à digérer... et qu'il va falloir consolider tout ça. Ils partent en mission dans les semaines à venir, et vont donc rapidement avoir à mettre les mains dans le cambouis et besoin d'être aidés. Je propose donc à ceux qui le souhaite et qui se sentent capable de prendre par la main des débutants d'avoir un rôle de tuteur et j'ai invité les volontaires francophones à venir sur http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur puisse les suivre. Dans un premier temps, il s'agit essentiellement d'aider à prendre en main JOSM et de gagner en efficacité ainsi que de suivre les tracés de routes et de bâtiments faits sur les images bing dans leur zone de déploiement. Les règles de tagging seront à voir dans un deuxième temps, et elles sont un peu spécifiques à l'humanitaires et parfois différentes par rapport à nos habitudes. Plus d'infos: - http://hot.openstreetmap.org/projects/eurosha_0 - http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] tag name avec double nom (Osmose)
Le 09/10/2012 16:02, Cyrille Giquello a écrit : Salut, Comment taguer name=Commissariat de Secteur de Tours Nord/St Cyr sur Loire ? Osmose dit Le tag name contient deux noms (http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#5030) Laisse Osmose dire ce qu'il veut ! Tu le marque en faux positif si tu veux et puis c'est tout. Par contre Osmose va aussi signaler le St. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?
Je suis aussi disponible. Pierre De : Marc SIBERT m...@sibert.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Cc : Severin Menard severin.men...@hotosm.org; nicolas chavent nicolas.chav...@hotosm.org Envoyé le : Mercredi 10 octobre 2012 5h14 Objet : Re: [OSM-talk-fr] Tuteurs pour volontaires européens ? Bonjour, Je up le sujet et j'en profite pour répondre positivement à cette demande de support à distance. Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire sur le forum. A+ Marc Le 4 octobre 2012 18:32, Christian Quest cqu...@openstreetmap.fr a écrit : Demain se termine la formation EUROSHA de volontaires européens à laquelle je participe depuis le début de la semaine. De quoi s'agit-il ? Un vingtaine de volontaires ont suivit une formation de 3 semaines avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad et Centrafrique) dans les semaines qui vont venir pour y faire de la cartographie à visée humanitaire sur OpenStreetMap. La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a été très dense car elle couvrait: la présentation du projet avec le concept de licence libre de logiciels libres, de crowdsourcing, puis un aperçu des outils de contributions de l'imagerie aérienne, de la préparation d'une collecte sur le terrain, une cartopartie avec relevés par GPS, logger, walking papers et photos géotaguées, puis saisie dans JOSM, puis les outils de contrôle de qualité, les outils de coordination (OSM Task Manager d'HOT), et on va attaquer la partie exploitation des données. Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à digérer... et qu'il va falloir consolider tout ça. Ils partent en mission dans les semaines à venir, et vont donc rapidement avoir à mettre les mains dans le cambouis et besoin d'être aidés. Je propose donc à ceux qui le souhaite et qui se sentent capable de prendre par la main des débutants d'avoir un rôle de tuteur et j'ai invité les volontaires francophones à venir sur http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur puisse les suivre. Dans un premier temps, il s'agit essentiellement d'aider à prendre en main JOSM et de gagner en efficacité ainsi que de suivre les tracés de routes et de bâtiments faits sur les images bing dans leur zone de déploiement. Les règles de tagging seront à voir dans un deuxième temps, et elles sont un peu spécifiques à l'humanitaires et parfois différentes par rapport à nos habitudes. Plus d'infos: - http://hot.openstreetmap.org/projects/eurosha_0 - http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Chef-lieu de commune...
is_in pour dire dans quel district et région se trouve la place (point-virgule comme séparateur) Ah non, pas le is_in, vade retro stanas ;-) Éventuellement, pourquoi pas. Néanmoins, je trouve que le is_in ne permet pas de bien de hiérarchiser l'information. Comment on fait pour savoir à quels niveaux administratifs correspondent les valeurs successives du is_in? Ou alors comme c'est proposé dans le wiki is_in:municipality, is_in:district, is_region. M'enfin, dans tous les cas, on n'a pas d'objet dans OSM en relation de l'entité administrative sur le terrain, pour indiquer par exemple les noms malgache et français de l'entité. admin_centre=yes par exemple sur le chef-lieu (facile à transposer lorsque les limites apparaitront) Là, on ne sait pas à quel niveau administratif ça se réfère. En plus admin_centre est presque exclusivement utilisé comme de la relation boundary. Il y a aussi la proposition de Vincent d'utiliser capital=(admin_level). Ou d'autres variantes comme admin_centre=(admin_level). Ou rajouter séparément admin_level=* au noeud place=* en complément de admin_centre=yes. Il reste à traiter le cas où le nom du chef-lieu de commune est différent du nom de la commune. Franchement, il n'y aurait pas de modèle avec relation? mais autre que boundary? Ca me rappelle les discussions sur les modèles linéaires vs. surfaciques pour les empilements de structures administratives. Il n'y a pas de pays qui ait adopté le modèle surfacique, c'est-à-dire une relation département qui contienne juste la liste des communes le constituant (+ admin_centre=* ;-) )? Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chef-lieu de commune...
Bonjour, De : Eric Sibert is_in pour dire dans quel district et région se trouve la place (point-virgule comme séparateur) Ah non, pas le is_in, vade retro stanas ;-) Franchement, il n'y aurait pas de modèle avec relation? mais autre que boundary? Ca me rappelle les discussions sur les modèles linéaires vs. surfaciques pour les empilements de structures administratives. Il n'y a pas de pays qui ait adopté le modèle surfacique, c'est-à-dire une relation département qui contienne juste la liste des communes le constituant (+ admin_centre=* ;-) )? Le rôle subarea ? Vade retro satanas :-) Plus sérieusement, tu voudrais composer un arbre administratif malgache via une / des relations qui agrégeraient les différents nodes place=*, la subtilité étant dans le rôle de chacun ? (Je ne suis pas bien sûr d'avoir compris ton besoin en fait). 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] tag name avec double nom (Osmose)
Le 10 octobre 2012 12:07, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 09/10/2012 16:02, Cyrille Giquello a écrit : Salut, Comment taguer name=Commissariat de Secteur de Tours Nord/St Cyr sur Loire ? Osmose dit Le tag name contient deux noms (http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#5030) Laisse Osmose dire ce qu'il veut ! Tu le marque en faux positif si tu veux et puis c'est tout. Ah bon ?! Mais pour moi Osmose était le maître de la perfitude d'osm. Tu me détruis un graal ! ;-) Mais si je le marque faux-positif, il va revenir un jour, non ? Par contre Osmose va aussi signaler le St. Ok, ça je peux le faire :-) Merci Fred. Frédéric. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name avec double nom (Osmose)
Le 10 octobre 2012 15:26, Cyrille Giquello cyrill...@gmail.com a écrit : Le 10 octobre 2012 12:07, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 09/10/2012 16:02, Cyrille Giquello a écrit : Salut, Comment taguer name=Commissariat de Secteur de Tours Nord/St Cyr sur Loire ? Osmose dit Le tag name contient deux noms (http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#5030) Laisse Osmose dire ce qu'il veut ! Tu le marque en faux positif si tu veux et puis c'est tout. Ah bon ?! Mais pour moi Osmose était le maître de la perfitude d'osm. Tu me détruis un graal ! ;-) Mais si je le marque faux-positif, il va revenir un jour, non ? Par contre Osmose va aussi signaler le St. Ok, ça je peux le faire :-) Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut c'est pas osmose qui doit dicter sa loi ! Exemple : http://osmose.openstreetmap.fr/map/?zoom=18lat=43.31694lon=5.4065layers=B000FFTitem=3010,3020,3030,3031,3032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060level=1,2,3 C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas modifier. Tant pis si l'orthographe est foireuse faut se plaindre à ceux qui font les panneaux :) Fabien Merci Fred. Frédéric. -- Cyrille. ___ 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] [Presse] Microsoft et OpenStreetMap
Extract: Microsoft a compris depuis longtemps que sa solution maison - Bing Maps - ne permettrait pas de concurrencer le leader du secteur. La marque a donc choisi une autre option en se rapprochant, fin 2010, du projet collaboratif OpenStreetMap. http://www.liberation.fr/medias/2012/10/08/smartphones-les-gros-sous-des-cartes_851826 -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name avec double nom (Osmose)
De : Fabien Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut c'est pas osmose qui doit dicter sa loi ! Exemple : http://osmose.openstreetmap.fr/map/? zoom=18lat=43.31694lon=5.4065layers=B000FFTitem=3010,3020,3030,3031,3 032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060level=1,2, 3 C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas modifier. Tant pis si l'orthographe est foireuse faut se plaindre à ceux qui font les panneaux :) À te suivre, en voyant une plaque de rue Rue du Gal Laclerc tu taggues : name=Rue du Gal Leclerc ? Voir : http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 En substance : lorsqu'on connaît la signification d'une abréviation, on ne taggue pas l’abréviation mais le mot complet. 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] tag name avec double nom (Osmose)
Le 10 octobre 2012 16:36, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Fabien Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut c'est pas osmose qui doit dicter sa loi ! Exemple : http://osmose.openstreetmap.fr/map/? zoom=18lat=43.31694lon=5.4065layers=B000FFTitem=3010,3020,3030,3031,3 032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060level=1,2, 3 C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas modifier. Tant pis si l'orthographe est foireuse faut se plaindre à ceux qui font les panneaux :) À te suivre, en voyant une plaque de rue Rue du Gal Laclerc tu taggues : name=Rue du Gal Leclerc ? Oui Voir : http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 En substance : lorsqu'on connaît la signification d'une abréviation, on ne taggue pas l’abréviation mais le mot complet. C'est même indiqué ici : Apart from following the above rules, you should always enter the full name as it appears on the street name signs. En substance : vous devez toujours écrire le nom comme il apparaît sur les panneaux. Leur partie qui dit de ne pas faire d'abbréviation c'est par exemple la «CAF des Bouches-du-Rhônes» doit être taggée : Caisse d'Allocation Familiale des Bouches-du-Rhône On n'est pas sensé forcément savoir que CAF c'est ça. Fabien 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name avec double nom (Osmose)
Le 10/10/2012 16:47, Fabien a écrit : À te suivre, en voyant une plaque de rue Rue du Gal Laclerc tu taggues : name=Rue du Gal Leclerc ? Oui Et tu fais comment quand le panneau à l'entrée de la rue indique Rue du Gal Leclerc et de l'autre côté Rue du Général Leclerc ? Jean signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name avec double nom (Osmose)
Le 10 octobre 2012 16:47, Fabien marbolan...@gmail.com a écrit : Le 10 octobre 2012 16:36, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Fabien Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut c'est pas osmose qui doit dicter sa loi ! Exemple : http://osmose.openstreetmap.fr/map/? zoom=18lat=43.31694lon=5.4065layers=B000FFTitem=3010,3020,3030,3031,3 032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060level=1,2, 3 C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas modifier. Tant pis si l'orthographe est foireuse faut se plaindre à ceux qui font les panneaux :) À te suivre, en voyant une plaque de rue Rue du Gal Laclerc tu taggues : name=Rue du Gal Leclerc ? Oui Voir : http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 En substance : lorsqu'on connaît la signification d'une abréviation, on ne taggue pas l’abréviation mais le mot complet. C'est même indiqué ici : Apart from following the above rules, you should always enter the full name as it appears on the street name signs. En substance : vous devez toujours écrire le nom comme il apparaît sur les panneaux. Leur partie qui dit de ne pas faire d'abbréviation c'est par exemple la «CAF des Bouches-du-Rhônes» doit être taggée : Caisse d'Allocation Familiale des Bouches-du-Rhône On n'est pas sensé forcément savoir que CAF c'est ça. Ceci dit, il y a des noms de rues abrégés, pour lesquels il est parfois difficile de retrouver le nom exact. Je pense à toutes les rues portant le nom d'un régiment militaire, cas assez fréquents en Basse-Normandie. La solution, indiquée sur le wikhttp://wiki.openstreetmap.org/wiki/FR:Key:namei, est de faire un mix : le tag 'name' porte le nom complet et on rajoute un tag 'short_name' avec le nom abrégé. Francescu Fabien 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 ___ 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] tag name avec double nom (Osmose)
Le 10 octobre 2012 16:54, Jean Couteau cout...@codelutin.com a écrit : Le 10/10/2012 16:47, Fabien a écrit : À te suivre, en voyant une plaque de rue Rue du Gal Laclerc tu taggues : name=Rue du Gal Leclerc ? Oui Et tu fais comment quand le panneau à l'entrée de la rue indique Rue du Gal Leclerc et de l'autre côté Rue du Général Leclerc ? Pas sûr : alt_name ? Jean ___ 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] tag name avec double nom (Osmose)
Le 10/10/2012 16:36, Vincent de Chateau-Thierry a écrit : À te suivre, en voyant une plaque de rue Rue du Gal Laclerc tu taggues : name=Rue du Gal Leclerc ? Voir : http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 En substance : lorsqu'on connaît la signification d'une abréviation, on ne taggue pas l’abréviation mais le mot complet. Attention, ça peut conduire à des dérives. Par exemple, la Rue de la Colle d'Artaud, à Six-Fours : - les plaques portent le nom incorrect de Rue du Col d'Artaud. - Google Maps (ou son fournisseur) a cru que col était l'abbréviation de colonel, et donc cette rue s'appelle désormais Rue du Colonel d'Artaud sur les cartes Google. Rien à voir avec le nom d'origine ! Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] écoles et osmose
bonjour à tous dans osmose, il y a a mapper- école non intégrée mais aussi intégration- école cela parle semble-il des mêmes écoles restant à intégrer mais pourtant lorsque l'on corrige l'un il ne corrige pas automatiquement autre ? djo_man ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Presse] Microsoft et OpenStreetMap
Oui enfin c'est quand meme un peu incorrect. A ma connaissance, Bing n'a pas fait le moindre bruit pour utiliser OSM a part fournir la carto aerienne et un fond OSM quelque part (meme pas genere eux meme). Bing Map de toute facon c'est base quasi entierement sur les produits de Nokia (NavTeq) sur pas mal de points (geocodeur, cartographie, etc...). S'ils gardent OSM pret quelque part, il le cache tres bien. Emilie Laffray 2012/10/10 Cyrille Giquello cyrill...@gmail.com Extract: Microsoft a compris depuis longtemps que sa solution maison - Bing Maps - ne permettrait pas de concurrencer le leader du secteur. La marque a donc choisi une autre option en se rapprochant, fin 2010, du projet collaboratif OpenStreetMap. http://www.liberation.fr/medias/2012/10/08/smartphones-les-gros-sous-des-cartes_851826 -- Cyrille. ___ 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] [Presse] Microsoft et OpenStreetMap
2012/10/10 Emilie Laffray emilie.laff...@gmail.com: Bing Map de toute facon c'est base quasi entierement sur les produits de Nokia (NavTeq) sur pas mal de points (geocodeur, cartographie, etc...). S'ils gardent OSM pret quelque part, il le cache tres bien. Les choses vont peut-être changer. On s'interroge quand on voit ce genre d'application: http://frontdoor.cloudapp.net/ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name avec double nom (Osmose)
2012/10/10 Jean-Claude Repetto jrepe...@free.fr: Par exemple, la Rue de la Colle d'Artaud, à Six-Fours : - les plaques portent le nom incorrect de Rue du Col d'Artaud. - Google Maps (ou son fournisseur) a cru que col était l'abbréviation de colonel, et donc cette rue s'appelle désormais Rue du Colonel d'Artaud sur les cartes Google. Rien à voir avec le nom d'origine ! C'est un cas intéressant. - les plaques comme le plan de ville officiel ([1]) et le cadastre indiquent tous Rue du Col d'Artaud. - google comme le géoportail de l'IGN se trompent et utilisent Rue du Colonel d'Artaud Je ne sais pas d'où tu sors le nom Rue de la Colle d'Artaud mais d'après ce document ([2]), c'est une colline qui se dirait colo en provençal et qui a donné la colle d'Artaud, déformé ensuite en col d'Artaud. Mais la dénomination courante reste col d'Artaud. De toute façon, comme le panneau correspond au plan de ville, il n'y a pas matière à discuter (en tout cas, pour nous, parce que Google semble pomper sur le géoportail ou inversement). Pieren [1] http://www.mairie-six-fours.fr/plans/plan2011recto.pdf [2] http://marius.autran.pagesperso-orange.fr/rues/lexique_rues_a.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name avec double nom (Osmose)
Le 10 oct. 2012 à 18:39, Pieren a écrit : Je ne sais pas d'où tu sors le nom Rue de la Colle d'Artaud mais d'après ce document ([2]), c'est une colline qui se dirait colo en provençal et qui a donné la colle d'Artaud, déformé ensuite en col d'Artaud. Mais la dénomination courante reste col d'Artaud. De toute façon, comme le panneau correspond au plan de ville, il n'y a pas matière à discuter (en tout cas, pour nous, parce que Google semble pomper sur le géoportail ou inversement). Ce qui serait intéressant, ce seraitde retrouver la délibération municipale (si c'est possible, car les appellations les plus anciennes n'ont pas toujours été décidées en CM). Christian Rogel___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] écoles et osmose
Le 10/10/2012 17:03, djo_man a écrit : bonjour à tous dans osmose, il y a a mapper- école non intégrée mais aussi intégration- école cela parle semble-il des mêmes écoles restant à intégrer C'est bien ça. mais pourtant lorsque l'on corrige l'un il ne corrige pas automatiquement autre ? Si, c'est automatique, le délai est juste de 6h. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tram T4 Bondy-Aulnay : railway=light_rail ou railway=tram ?
Bonjour, Question de tag : réutilisant l'infrastructure ferroviaire de l'ancienne ligne SNCF Bondy-Aulnay dite des Coquetiers, le tram-train T4 devrait-il plutôt être marqué comme light_rail ou comme tram ? Actuellement selon qu'on soit plus proche de Bondy ou d'Aulnay-sous-Bois, l'un ou l'autre des tags est utilisé. Les autres trams de la région parisienne (T1, T2, T3) sont marqués railway=tram. Merci pour votre avis, Teuxe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name avec double nom (Osmose)
C'est sûr qu'on voit rarement sur les plaques de rues l'expansion complète de l'abréviation Boulevard du 3e RPIMa (Régiment parachutiste d'infanterie de la Marine)... On doit modérer un peu quand c'est l'abréviation qui est plus connue que le nom complet (qui a pu même changer de signification sans changer le sigle ou l'acronyme qu'on continu de prononcer comme un sigle ou acronyme). Mais pour une abréviation à peine moins longue que le nom complet et qui mentionne la prononciation correcte comme St ou Ste au lieu de Saint(e), qu'on ne prononce jamais lettre à lettre, et qui est évidente pour un humain francophone, la question ne se pose pas : on n'abrège pas (les logiciels abrégeront eux-mêmes si-nécessaire pour faire tenir le texte dans un espace limité). Autre exemple: les mots -sur- ou -sous- sont fréquemment abrégés par exemple / ou s/s sur les plaques d'entrée d'agglomération ou les panneaux indicateurs directionnels. Certaines communes à noms long peuvent y avoir des parties abrégées aussi (exemple : Frontenay-Rohan-Rohan dans le 79, qu'on trouve affiché sur certains panneaux en Frontenay-R.-R., mais pas tous les panneaux, pas plus que dans les annuaires ou les bulletins municipaux, ni les publications de la communauté de communes et des autres collectivités locales, ou dans la base INSEE ; personne n'épelle ces R isolément, sauf ceux qui tombent sur ces panneaux et ne savent pas les lire, mais ce n'est pas gênant car cela ne donne aucune ambiguïté selon le lieu où on les voit, l'association avec le nom complet qu'on pourrait avoir étant aussi évidente même si l'abréviation est inattendue). Ces abréviations sont juste contextuelles, juste adaptées au support physique limité où on les trouve spécifiquement pour un usage très local. Le 10 octobre 2012 16:55, Francescu GAROBY windu...@gmail.com a écrit : Le 10 octobre 2012 16:47, Fabien marbolan...@gmail.com a écrit : Le 10 octobre 2012 16:36, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Fabien Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut c'est pas osmose qui doit dicter sa loi ! Exemple : http://osmose.openstreetmap.fr/map/? zoom=18lat=43.31694lon=5.4065layers=B000FFTitem=3010,3020,3030,3031,3 032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060level=1,2, 3 C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas modifier. Tant pis si l'orthographe est foireuse faut se plaindre à ceux qui font les panneaux :) À te suivre, en voyant une plaque de rue Rue du Gal Laclerc tu taggues : name=Rue du Gal Leclerc ? Oui Voir : http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 En substance : lorsqu'on connaît la signification d'une abréviation, on ne taggue pas l’abréviation mais le mot complet. C'est même indiqué ici : Apart from following the above rules, you should always enter the full name as it appears on the street name signs. En substance : vous devez toujours écrire le nom comme il apparaît sur les panneaux. Leur partie qui dit de ne pas faire d'abbréviation c'est par exemple la «CAF des Bouches-du-Rhônes» doit être taggée : Caisse d'Allocation Familiale des Bouches-du-Rhône On n'est pas sensé forcément savoir que CAF c'est ça. Ceci dit, il y a des noms de rues abrégés, pour lesquels il est parfois difficile de retrouver le nom exact. Je pense à toutes les rues portant le nom d'un régiment militaire, cas assez fréquents en Basse-Normandie. La solution, indiquée sur le wiki, est de faire un mix : le tag 'name' porte le nom complet et on rajoute un tag 'short_name' avec le nom abrégé. Francescu Fabien 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 ___ 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] tag name avec double nom (Osmose)
Le 10 octobre 2012 16:47, Fabien marbolan...@gmail.com a écrit : Leur partie qui dit de ne pas faire d'abbréviation c'est par exemple la «CAF des Bouches-du-Rhônes» doit être taggée : Caisse d'Allocation Familiale des Bouches-du-Rhône On n'est pas sensé forcément savoir que CAF c'est ça. Je suis d'accord, mais c'est alors faire une enquête sur un terrain sans rien savoir sur lui ni apprendre à le connaître. Bref même raisonnement que pour ceux qui cartographient des terres inconnues d'eux depuis leur chaise : ce n'est plus une enquête de terrain, c'est du tourisme ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tram T4 Bondy-Aulnay : railway=light_rail ou railway=tram ?
Et l'espacement des rails comparé au chemin de fer classique et aux autres lignes de tram? A Baltimore, il y a un truc qui s'appelle le light_rail, qui est d'ailleurs taggué comme tel. En centre-ville, ça ressemble à du tram qui roule au milieu de la chaussée. Quand on part en banlieue, c'est en site propre qui fait plus penser au RER. L'espacement est celui des trains: 1435 mm. http://osm.org/go/ZZfUD8nPo-- Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chef-lieu de commune...
Le 10 octobre 2012 15:09, Eric Sibert courr...@eric.sibert.fr a écrit : Là, on ne sait pas à quel niveau administratif ça se réfère. En plus admin_centre est presque exclusivement utilisé comme de la relation boundary. Il y a aussi la proposition de Vincent d'utiliser capital=(admin_level). Ou d'autres variantes comme admin_centre=(admin_level). Ou rajouter séparément admin_level=* au noeud place=* en complément de admin_centre=yes. C'est bien pour ça que le modèle utilisé en Espagne (dont les communes comptent de nombreuses petites localités avec chacune leur nom spécifique, souvent différent de la commune elle-même) marche bien : capital = 8 pour les localités qui sont chef-lieu de la commune (ou municipio en espagnol), c'est-à-dire sont là où siège la mairie (ou ajuntamento en espagnol) ; mais le nom de la localité n'indique pas forcément le nom réel de la commune elle-même, qui est précisé dans la relation communale, capital=7 pour les chef-lieu de comarques, capital=6 pour les capitales de province, capital=4 pour les capitales de communauté autonome, capital=2 pour la capitale du pays.. Noter que certaines zones (par exemple certaines provinces, mais aussi certaines communes) ont deux capitales officielles (donc deux noeuds membres admin_centre dans leur relation), chacun des noeud portant alors la même valeur capital=n, mais ayant chacun leur propre nom qui n'impacte le nom donné aux zones dont elle est capitale. Noter aussi que la capitale d'une communauté autonome (capital=4) n'est pas nécessairement non plus capitale de la province (niveau 6) où elle se situe (son admin_centre mentionne un autre point que la capitale de communauté, et sur ce noeud on a capital=6). Aucun problème donc en Espagne, ça marche très bien ! Même avec la réforme en cours des comarques et les nouvelles organisations administratives propres à chaque communauté autonome (qui ne tiennent pas compte du découpage administratif national des communautés en provinces, et qui créent des nouveaux regroupements de comarques en régions et sous-régions, ou en districts, ou en conseils insulaires, ou qui effacent complètement les anciennes comarques, et parfois aussi annulent le découpage national des communes, au delà de la réforme aussi de leur propre toponymie dans la langue régionale officielle) : le découpage administratif national (avec des admin_level numériques) ne sert plus alors que pour l'organisation des services nationaux de l'Etat non transférés dans la compétence des communautés autonomes, ou pour les circonscriptions électorales pour les députés au parlement national. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites communales dans les DOM
Bonsoir à tous, Quel dommage que l'on ne puisse pas trouver ici (http://export.openstreetmap.fr/contours-administratifs/export-communes/) les limites communales sur les DOM... Il manque : 971 : Guadeloupe (cadastre entièrement vectorisé) 972 : Martinique (cadastre entièrement vectorisé) 973 : Guyane (cadastre récemment entièrement vectorisé mais pas diffusé sur cadastre.gouv.fr) 974 : Réunion (cadastre entièrement vectorisé) 976 : Mayotte (cadastre entièrement vectorisé mais pas diffusé sur cadastre.gouv.fr) Quelqu'un a-t-il une méthode pour récupérer facilement les contours des communes sur ces départements ? Pierre T. -- View this message in context: http://gis.19327.n5.nabble.com/Limites-communales-dans-les-DOM-tp5729803.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] Alignement cadastre
Sur l'indre et loire, certaines communes contenait quelques planches mal géoréférencées mais depuis quelques semaines on a des mis a jours qui semble parfaites vis a vis des images de Bing et des repères géodésiques. Le 09/10/2012 20:51, Jean-Francois Nifenecker a écrit : Bonsoir, au cours de mes pérégrinations correctrices, j'ai rencontré un cas de bâti mal calé. Et, curieusement, mappant en extérieur aujourd'hui, voilà-t-y pas que je tombe sur un deuxième cas de l'espèce. Moi qui n'avais jamais rencontré de commune dont le bâti était mal placé, me voilà verni. Le premier cas : commune de Launac en Haute-Garonne. J'ai constaté un décalage du bâti par rapport à l'imagerie Bing. La position de deux points géodésiques distants sur la commune (église du village, église d'un hameau à l'ouest) confirme que c'est le Cadastre qui est dans les choux et l'imagerie Bing qui est correcte. - j'ai recalé tout ce beau monde a-la-mano (vivent les filtres JOSM !). Et puis recalé le reste (les %$§@ piscines) et les highways puisque les contributeurs, sagement, avaient décalé leurs positions en proportion du bâti. Pfff... 4 heures de boulot. Par chance, le bâti y est facilement sélectionnable par groupe si bien que le travail a avancé assez rapidement. Ce qui me surprend le plus sur cette commune c'est que (1) elle n'est pas spécialement située en montagne mais au contraire dans une plaine à l'ouest de Toulouse et (2) que le décalage (LES décalages devrais-je dire) n'était pas régulier, c'est le moins que l'on puisse dire. J'ai trouvé des différences en moyenne de 15 mètres mais allant dans certains cas jusqu'à 25 mètres ! Et le secteur le plus à l'Est était correctement calé. En outre, des bâtiments proches (une maison et un appentis sur son terrain) pouvaient être décalés différemment. Enfin, certains décalages étaient en rotation, certes légère mais suffisamment importante pour être remarquée (et ça, j'ai pas corrigé). Le second cas : commune de Saint-Amant de Boixe (Charente) où j'ai passé la journée. Décalage très visible sur le fond Bing. La position du point géodésique sur le clocher de l'abbatiale confirme l'erreur cadastrale. Ici, le décalage est moins important qu'à Launac et sans doute beaucoup plus régulier (majoritairement vers le Nord). Ici non plus, le relief ne peut être mis en cause, la Charente n'étant pas réputée pour ses cols de haute montagne. Je m'attends à un peu plus de boulot de recalage qu'à Launac car le bâti y est plus dense, il va donc être plus difficile de sélectionner des groupes de bâtiments peu étendus. Ma confiance dans le Cadastre s'émousse très fortement... Quelles sont vos expériences ? Comment gérez-vous la rotation sous JOSM ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chef-lieu de commune...
C'est bien pour ça que le modèle utilisé en Espagne (dont les communes comptent de nombreuses petites localités avec chacune leur nom spécifique, souvent différent de la commune elle-même) marche bien : Je viens de jeter un coup d’œil au modèle espagnol: Il y a des relations de type=boundary. Un exemple: admin_level = 6 place = county rank= county is_in = Comunidad Valenciana, Spain is_in:country = Spain is_in:region = Comunidad Valenciana ine:provincia = 03 rôles outer : les limites rôles subarea : la liste des municipalités rôle admin_centre : le(s) chef-lieu(x) Et quand je vais sur le nœud place du chef-lieu, je trouve: admin_level = 6 capital = 6 is_in = Alicante, Comunidad Valenciana, Spain is_in:continent= Europe is_in:municipality = Alacant/Alicante is_in:province_code = 03 place = city De mon point de vue, c'est ce que j'appelle bétonner. En poussant plus loin, les nombreuses informations redondantes peuvent poser problème pour la maintenance de la base. Et comme je l'ai déjà expliqué, faute de limites communales, mettre en place des relations type=boundary paraît capilotracté. Sans relation, juste capital=(admin_level) ne permet pas de couvrir tous les cas. Il faut au moins compléter avec des is_in:*=. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose a changé de peau
Le 10 octobre 2012 09:32, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Je rejoins les autres avis, si rien c'est tout alors autant supprimer le bouton rien puisque sa fonction est identique à tout. Cela affiche la même chose que tout mais la fonction reste différente puisque ça décoche toutes les cases, ce qui permet d'en cocher une seule d'un seul clic pour ne plus voir qu'un seul type d'alerte/ Maintenant je pense que rien ne devrait aussi rien afficher du tout, d'une part c'est perturbant au début, d'autre part on peut très bien vouloir temporairement ne rien afficher du tout, soit parce qu'eon avait sélectionné une case et que pour éviter de zoomer sur une zone pour l'identifier sur la carte en arrière-plan on souhaute cacher les bulles, soit parce qu'on veut arrêter d'arrêter d'interroger dynamiquement le serveur, afin de se déplacer plus rapidement sur la carte (avec un minimum de requêtes) et zoomer sur une zone d'intérêt donnée où on va aller chercher un ou plusieurs types d'alertes (voire toutes). Nouveauté de cette version d'Osmose : les remplissages en couleur des zones par niveau administratif ou politique/électoral faits jusqu'à présent sur Layers sont disponibles aussi sur Osmose dans le menu de droite. Un regret (sous Osmose NG, comme déjà avant sur Layers): toujours pas de séparation des zones boundary=political selon leur sous-type political_subdivision=* (surtout gênant actuellement en France où cela concerne déjà la distinction, impossible à voir séparément, des cantons et des circonscriptions législatives qui sont mélangés dans la sélection et provoquent des anomalies de fermeture de polygones ou des superpositions de polygones de la même couleur avec seulement un changement du niveau d'intensité de la transparence, et la superposition excessive des libellés). Pas même les régions NUTS-2 pour la France (même si ce ne sont pas 'stricto sensu' des découpages administratifs mais des découpages économiques d'aménagement du territoire national, qui iraient pourtant créer un admin_level=3 en France (sans chef-lieu donc sans membre admin_centre dans leur relation, est-ce un vrai problème puisque on a des tas de communes aussi sans admin_centre désigné, voire plusieurs dans niveaux admin d'autres pays européens ?). Alors qur tout est en place pour les afficher correctement. Alors qu'on a une séparation des EPCI à fiscalité propre pour la France (boundary=local_authority utilisé différemment au moins en Angletere), mais pas de distinction possibles des autres EPCI sans fiscalité propre (comme les SIVU et SIVOM qui existent encore et manquent dans la base OSM, voire aussi les les pays et pays Loi Voynet qui regroupent ces EPCI sans tenir compte nécessairement des frontières administratives des régions ou départements puisque les EPCI peuvent être à cheval). Et rien en place n'est prévu pour visualiser d'autres limites : les structures européennes de coopération régionale transfrontalière, les circonscriptions électorales au parlement européen, les adadémies, les zones de défense et régions militaires, les régions de police nationale ou gendarmerie, les zones de police municipale, les régions judiciaires, les régions hospitalières et de couverture médicale, les étendues des charges notariales, des agences de bassin, des régions maritimes... Pas plus que le découpage « administratif religieux » (c'est à dire des paroisses, unités paroissiales, évêchés ou arhevêchés...) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chef-lieu de commune...
Le rôle subarea ? Vade retro satanas :-) Plus sérieusement, tu voudrais composer un arbre administratif malgache via une / des relations qui agrégeraient les différents nodes place=*, la subtilité étant dans le rôle de chacun ? Oui, c'est bien ça. J'ai juste du mal à construire des relations type=boundary en l'absence de frontière. Ça me paraît contre nature. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière Guyane-Brésil
Dans cette zone très densément irriguée, et où la végétation noie tout et change les écoulements des cours d'eau, et où les zones inondées bougent sans arrêt je me demande l'intérêt de l'acuité visuelle des images Bing haute résolution de la Guyane (pas sûr d'ailleurs que Bing soit la source la plus récente ni la plus précise). Ok les bornes plantées en terre ne devraient pas bouger de si tôt (sauf si des garinperos les déplacent exprès pour implanter un site d'orpaillage clandestin), ce qui risque dene pas être repérés avant un bon moment quand même l'armée française a du mal à s'y rendre et les retrouver dans la végétation ou sur une terre désormais inondée. Hormi la région côtière qui est plus peuplée et mieux équipée, les limites intérieures dans la forêt, où les communes couvrent des zones gigantesques quasiment vides de population résidente (les populations amérindiennes y sont aussi nomades que les sites d'orpaillage légaux ou non), sont très relatives. Même sur les cours d'eaux servant de frontière naturelle avec les pays voisins. Au mieux on repérera les villages et leur petit aérodrome dans certaines clairières hors d'eau, et avant que l'armée revienne, les pistes de terre qui les relient difficilement (encore moins bien que les cours d'eau) auront eu le temps de bouger selon les aléas naturels ou l'exploitation forestière ou agricole. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pushpin: nouvelle appli iOS pour contribuer
Le 10/10/2012 07:55, Christian Quest a écrit : C'est une première version... je pense qu'il faut faire remonter un max de remarques et de suggestion d'améliorations pour la faire évoluer dans le bon sens. Ayé c'est fait... -- Marc http://www.openstreetmap.org/user/plonk/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le rendu est-il un tabou ?
Pontifier ? parler en odeur de sainteté ? Alors qu'on me fait dire ce que je ne pense pas? Je ne bulle pas. Les noms des lignes frontières ont toujours été indicatifs et pas prescriptifs, utilisés d'abord par et pour les éditeurs, pas pour le rendu (c'est vrai partout dans le monde). On me fait dire que c'est là pour taguer pour le rendu alors que jamais ils n'ont été sensés apparaître et que de toute façon ils n'apparaissent pas sur les lignes de frontières rendues ; ou pas mieux en tout cas ni plus souvent que les noms prescriptifs donnés aux relations (ceux-là sont affichés sans aucun critère significatifs de toute façon, et peuvent par exemple masquer totalement le nom d'une rue pour afficher un des noms des relations, même si pourtant ce sont des objets différents non liés). Si on tagait réellement les noms pour le rendu, on ne donnerait plus aucun nom, même aux relations, pour s'assurer que le nom de la rue sera là, ou pour éviter de voir le nom d'une commune deux fois (un nom au centroïde du polygone ou à la position de son membre de rôle label, et autant de noms que les noeuds des localités membres de la relation avec le rôle admin_centre, même si ces noms sont les mêmes très souvent pour les communes en France). Comme il n'y a strictement aucune règle définie clairement là-dessus, aucun rendu ne peut être correct et cohérent et ce n'est pas un tag à ce niveau qui changera quelquechose puisque le résultat n'est pas stable du tout et dépend du rendu ou non des noms d'autres objets dans le voisinage. Le 9 octobre 2012 21:36, Hélène PETIT h...@free.fr a écrit : Le 07/10/2012 22:58, Philippe Verdy a écrit : Non ce n'est pas délibérément pour le rendu. Rien à voir, tu te trompes. Philippe, si tu pouvais arrêter de pontifier, s'te plait. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un peu d'opendata... sur mp2013.fr
Le 9 octobre 2012 16:03, Sylvain Maillard sylvain.maill...@gmail.com a écrit : au début j'ai pensé n'avoir rien compris à ce fichier xml, mais dans l'exemple que j'ai donné le point est clairement situé dans la mer (enfin, dans le port) et non pas en pleine ville, et il doit bien y avoir 2 km de décalage ! Si c'est déjà dans le port c'est déjà dans une commune, et c'est sans soute suffisant à l'échelle du secteur couvert par eux dans leur asso. Bref ils n'ont pas eu à géolocaliser la ville, il ont fait comme sur une carte de France affiché au mur avec des punaises et ça leur suffit, ils n'ont pas été plus loin. 2 km d'écart c'est pas si mal pour la couverture locale d'une asso dont la portée est souvent bien plus grande que ça. J'en reviens donc à ma solution proposée de qualifier les points importés avec une distance maximale d'imprécision, comme si on importait non pas des points mais des cercles du rayon donné, dans lequel le point réel est localisé, pour assurer le suivi de ce qui n'a pas été rellement intégré avec une meilleure précision. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chef-lieu de commune...
Le 10/10/2012 21:07, Eric SIBERT a écrit : Le rôle subarea ? Vade retro satanas :-) Plus sérieusement, tu voudrais composer un arbre administratif malgache via une / des relations qui agrégeraient les différents nodes place=*, la subtilité étant dans le rôle de chacun ? Oui, c'est bien ça. J'ai juste du mal à construire des relations type=boundary en l'absence de frontière. Ça me paraît contre nature. Je ne sais pas si tu as un usage en tête pour ce que tu vas modéliser ? Si c'est juste pour fixer l'organisation administrative et organiser des relations d'inclusions sans géométrie, personnellement je pencherais plus pour des relations imbriquées que pour le recours au tag is_in et à ses déclinaisons, pour plusieurs raisons : - la relation lie des IDs d'objets (plus fiable) - le is_in donne comme clé de rattachement du texte, plus ambigü (fautes de frappe possibles, divergences sur l'orthographe) - la relation donne une vue synthétique, ne serait-ce que par la capacité à lister les membres d'une même relation - le is_in ne met en relation que des couples d'objets : celui qui porte le tag, et celui référencé dans la valeur du tag. On ne voit pas facilement ensemble plusieurs objets ayant le même tag is_in. Concrètement, j'imagine par exemple : - pour chaque commune, une relation de type commune avec comme membres tous les nodes place=* dont tu sais qu'ils sont dans le périmètre de la commune. La relation a pour valeur de tag name le nom (administratif) de la commune, qui peut être distinct de chacun des noms de lieux place. Un des nodes place porte le rôle admin_centre, les autres ont un rôle à définir (place, village, hameau, etc.) ou pas de rôle du tout. - pour chaque district, une relation de type district, avec comme membres les relations de type commune des communes formant le district. On peut éventuellement coller à chacune un rôle, par exemple commune. - idem un niveau au dessus avec pour chaque région, une relation de type region regroupant ses districts, sauf à utiliser les limites actuelles (admin_level=4) pour composer directement des relations de type boundary. L'idée est de permettre temporairement la description de la hiérarchie administrative sans géométrie surfacique, pour au moins les districts et communes. On remplace l'inclusion spatiale (celle dont on bénéficie en France avec nos niveaux région et département complets) par l'inclusion dans des relations. Le jour où tu disposes des limites de districts, tu peux remplacer les relations district par des relations boundary avec admin_level=6. Idem pour les communes. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag name avec double nom (Osmose)
Le 10/10/2012 16:47, Fabien a écrit : Le 10 octobre 2012 16:36, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Fabien Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut c'est pas osmose qui doit dicter sa loi ! Exemple : http://osmose.openstreetmap.fr/map/? zoom=18lat=43.31694lon=5.4065layers=B000FFTitem=3010,3020,3030,3031,3 032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060level=1,2, 3 C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas modifier. Tant pis si l'orthographe est foireuse faut se plaindre à ceux qui font les panneaux :) À te suivre, en voyant une plaque de rue Rue du Gal Laclerc tu taggues : name=Rue du Gal Leclerc ? Oui Voir : http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 En substance : lorsqu'on connaît la signification d'une abréviation, on ne taggue pas l’abréviation mais le mot complet. C'est même indiqué ici : Apart from following the above rules, you should always enter the full name as it appears on the street name signs. En substance : vous devez toujours écrire le nom comme il apparaît sur les panneaux. Sur la même page du wiki mais quelques lignes au dessus, tu liras : Si une plaque de rue contient des abréviations dont vous ne connaissez pas le développement, tagguez avec l'abréviation en attendant que quelqu'un d'autre place le nom complet. Ça fait vraiment partie des valeurs ajoutées de nos contributions que de pouvoir décrire le terrain sans le photocopier lettre à lettre. Le projet s'appelle bien OSM, pas OCR :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chef-lieu de commune...
Le 10 octobre 2012 20:59, Eric SIBERT courr...@eric.sibert.fr a écrit : C'est bien pour ça que le modèle utilisé en Espagne (dont les communes comptent de nombreuses petites localités avec chacune leur nom spécifique, souvent différent de la commune elle-même) marche bien : Je viens de jeter un coup d’œil au modèle espagnol: Il y a des relations de type=boundary. Un exemple: admin_level = 6 place = county dans la relation le place=* ici inutile, a priori, place c'est plutôt pour les noeuds, bien que place soit associé à la population du lieu et que cette population ne se définit pas au noeud (dont on ne sait pas quelle étendue in concerne, mais sur la surface entière donc bien sur la relation. rank= county doublon inutile à priori de admin_level=6. Sauf que justement en Espagne le découpage administratif est en pleine mutation et la hiérarchie des niveaux va être profondément modifiée. Je pense que ce rank permet de conserver une trace du type d'entité que cela désigne, avant que la structure hiérarchique soit modifiée (donc aussi les numéros assignés en valeur d'admin_level. is_in = Comunidad Valenciana, Spain is_in:country = Spain is_in:region = Comunidad Valenciana Les is-in là sont tous documentaires, pas forcément nécessaires. C'est déjà blindé autrement de façon nettement plus pratique par les relations parent/enfant de rôle subarea. ine:provincia = 03 Comme nos références INSEE en France. rôles outer : les limites Comme en France, mais aussi facilement cassé qu'en France (heureusement les suareas aident à restaurer les ambiguités. rôles subarea : la liste des municipalités Liste qui doit rester exhaustive de toutes les communes (au niveau suivant) couvertes. Cela ne détermine PAS les contours qui peuvent être plus larges que ces communes. rôle admin_centre : le(s) chef-lieu(x) Tout à fait : un ou plusieurs chef-lieux en admin_center Les subarea sont pour assurer l'exhausitivité de la liste des communes membres Et quand je vais sur le nœud place du chef-lieu, je trouve: admin_level = 6 Sauf là c'est une erreur, ce devrait rester admin_level=8 (voire 9) car le noeud n'est pas celui de la province mais celui de la municipalité (voire même de la localité). capital = 6 Ça c'est bon is_in = Alicante, Comunidad Valenciana, Spain is_in:continent= Europe is_in:municipality = Alacant/Alicante is_in:province_code = 03 Là aussi uniquement documentaire, car totalement blindé par les relations parent/enfant de rôle subarea (indépendamment des chemins frontières listés dans la relation) place = city C'est comme en France ici, mais c'est en fait pas l'endroit idéal pour mettre ça puisque ça dépend de la population. Hors les localités en Espagne ont des noms et des couvertures plus petites que la municipalité, qui n'est correctement décrite dans sa surface comme dans son nom QUE dans la relation (laquelle est l'endroit idéal pour importer les chiffres de population, ainsi que toutes les traductions). De mon point de vue, c'est ce que j'appelle bétonner. En poussant plus loin, les nombreuses informations redondantes peuvent poser problème pour la maintenance de la base. Du point de vue espagnol, non, car ce qui est bétonné ce sont les relations parent/enfant entre les relations, et leurs tags donnant les noms, traductions, classifications hiérarchiques, populations. Ce sont les contours indiqués en chemins membres qui ne sont pas stables mais peuvent être régénérés récursivement. Toutes les autres données sur les chemins et les noeuds sont alors redondantes. Et comme je l'ai déjà expliqué, faute de limites communales, mettre en place des relations type=boundary paraît capilotracté. Sans relation, juste capital=(admin_level) ne permet pas de couvrir tous les cas. Il faut au moins compléter avec des is_in:*=. Si on n'a pas encore de limites communales, on peut déjà créer les relations pour y mettre en membre non pas des frontières internes et externes, mais au moins tous les noeuds de localités ou lieux-dits inclus dedans, ou pas loin de cette frontière. On distinguera le rôle 'admin_center pour la localité chef-lieu, et pour les autres localités on pourrait utiliser en attendant un rôle place (qui deviendront inutiles si on a pu fermer toutes les frontières autour des localités (de rôles admin_center et place). Le modèle hiérarchique se construit quand même, on peut commencer avec des frontières grossières soit au niveau le plus grand du pays et ses provinces ou régions, soit au niveau le plus fin des localités les plus petites ou des quartiers, ou dans un ordre quelconque. On n'a aucune contrainte dans l'ordre de travail, et il est possible de dresser rapidement des listes exhaustives de toutes les relations administratives nécessaires et leur hiérarchie, même sans aucune frontière (qui viennent après et qu'on sait construire alors en analyse montante comme descendante). Les subarea évitent également les oublis
Re: [OSM-talk-fr] Chef-lieu de commune...
Sinon tu peux regarder aussi la république tchèque, totalement achevée et blindée elle aussi par des subareas. Encore tant pis pour la France qui s'y refuse pour des mauvaises raisons ou des incompréhensions qui n'ont pas lieu sur le prétendu modèle surfacique alors que les relations parent/enfant ne déterminent PAS les surfaces totales, juste une couverture complète ou partielle de la surface d'une relation enfant, représentée par ses frontières, par la surface de son/ses parents qu divent être le plus exhaustif possible mais peuvent ne pas couvrir QUE leurs seuls enfants). Les subareas sont là pour l'exhaustivité du modèle hiérarchique et recouvre une relation de dépendance, partielle ou totale, même lorsque des morceaux de surface du parent ne sont inclus dans AUCUNE des relations enfants, puisque le parent peut être plus grand que l'union de ses enfants, et puisque leurs enfants peuvent aussi avoir des intersections de surface non nulle. Le 10 octobre 2012 23:20, Philippe Verdy verd...@wanadoo.fr a écrit : Le 10 octobre 2012 20:59, Eric SIBERT courr...@eric.sibert.fr a écrit : C'est bien pour ça que le modèle utilisé en Espagne (dont les communes comptent de nombreuses petites localités avec chacune leur nom spécifique, souvent différent de la commune elle-même) marche bien : Je viens de jeter un coup d’œil au modèle espagnol: Il y a des relations de type=boundary. Un exemple: admin_level = 6 place = county dans la relation le place=* ici inutile, a priori, place c'est plutôt pour les noeuds, bien que place soit associé à la population du lieu et que cette population ne se définit pas au noeud (dont on ne sait pas quelle étendue in concerne, mais sur la surface entière donc bien sur la relation. rank= county doublon inutile à priori de admin_level=6. Sauf que justement en Espagne le découpage administratif est en pleine mutation et la hiérarchie des niveaux va être profondément modifiée. Je pense que ce rank permet de conserver une trace du type d'entité que cela désigne, avant que la structure hiérarchique soit modifiée (donc aussi les numéros assignés en valeur d'admin_level. is_in = Comunidad Valenciana, Spain is_in:country = Spain is_in:region = Comunidad Valenciana Les is-in là sont tous documentaires, pas forcément nécessaires. C'est déjà blindé autrement de façon nettement plus pratique par les relations parent/enfant de rôle subarea. ine:provincia = 03 Comme nos références INSEE en France. rôles outer : les limites Comme en France, mais aussi facilement cassé qu'en France (heureusement les suareas aident à restaurer les ambiguités. rôles subarea : la liste des municipalités Liste qui doit rester exhaustive de toutes les communes (au niveau suivant) couvertes. Cela ne détermine PAS les contours qui peuvent être plus larges que ces communes. rôle admin_centre : le(s) chef-lieu(x) Tout à fait : un ou plusieurs chef-lieux en admin_center Les subarea sont pour assurer l'exhausitivité de la liste des communes membres Et quand je vais sur le nœud place du chef-lieu, je trouve: admin_level = 6 Sauf là c'est une erreur, ce devrait rester admin_level=8 (voire 9) car le noeud n'est pas celui de la province mais celui de la municipalité (voire même de la localité). capital = 6 Ça c'est bon is_in = Alicante, Comunidad Valenciana, Spain is_in:continent= Europe is_in:municipality = Alacant/Alicante is_in:province_code = 03 Là aussi uniquement documentaire, car totalement blindé par les relations parent/enfant de rôle subarea (indépendamment des chemins frontières listés dans la relation) place = city C'est comme en France ici, mais c'est en fait pas l'endroit idéal pour mettre ça puisque ça dépend de la population. Hors les localités en Espagne ont des noms et des couvertures plus petites que la municipalité, qui n'est correctement décrite dans sa surface comme dans son nom QUE dans la relation (laquelle est l'endroit idéal pour importer les chiffres de population, ainsi que toutes les traductions). De mon point de vue, c'est ce que j'appelle bétonner. En poussant plus loin, les nombreuses informations redondantes peuvent poser problème pour la maintenance de la base. Du point de vue espagnol, non, car ce qui est bétonné ce sont les relations parent/enfant entre les relations, et leurs tags donnant les noms, traductions, classifications hiérarchiques, populations. Ce sont les contours indiqués en chemins membres qui ne sont pas stables mais peuvent être régénérés récursivement. Toutes les autres données sur les chemins et les noeuds sont alors redondantes. Et comme je l'ai déjà expliqué, faute de limites communales, mettre en place des relations type=boundary paraît capilotracté. Sans relation, juste capital=(admin_level) ne permet pas de couvrir tous les cas. Il faut au moins compléter avec des is_in:*=. Si on n'a pas encore de limites communales, on peut
Re: [OSM-talk-fr] Chef-lieu de commune...
Dernier intérêt du modèle parent/enfant à subarea : le cas où les enfants ont des intersections de surface non nulle concerne les territoires qui se partagent pacifiquement l'administration conjointe d'une même portion de territoire, ou bien qui se disputent un même territoire (contestation de leur limites territoriales). On peut le faire théoriquement aussi uniquement avec les chemins de rôles outer/inner mais on ne dispose d'aucun outil permettant d'en vérifier la validité, pusique la requête sera purement géométrique (laquelle ne marche pas du tout avec les frontières incomplètes). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chef-lieu de commune...
Autre intérêt du modèle à subarea : le cas où le modèle hiérarchique théorique n'est pas complet pour chaque niveau. Prenons le cas de la Belgique, elle est divisée en 3 régions (admin_level=4) elles même divisées en provinces (admin_level=6) et arrondissements (admin_level=7). Pourtant une des trois régions (niveau 3), celle de Bruxelles-Capitale, n'est divisée en AUCUNE province (niveau 6), bien que la région soit elle-même un arrondissement unique (niveau 7). De fait la Belgique n'est pas totalement couverte par la liste de ses provinces (cas similaire aussi en Allemagne avec les statuts différents des Villes-Etats) Si on faut une requête seulement géométrique, on va détecter un trou dans la couverture au niveau 6, et rien n'indiquera qu'il faut aussi inclure l'arrondissement de niveau 7. Avec les subareas, on n'indique explcitement : les enfants subarea de la région de Bruxelles-Capitale (niveau 4) sont son unique arrondissement au niveau 7 (tel qu'indiqué dans la définition de sa relation), et non une province de niveau 6. En Espagne, où chaque communauté autonome va pouvoir disposer de sa propre organisation administrative, les niveaux ne seront pas équivalents d'une communauté autonome à l'autre, et pourtant il faut un modèle pour synthétiser la définition admministrative de chacune. De plus, si on revient en Belgique, celle-ci dispose de deux types de divisions indépendantes au niveau en dessous : - les 3 régions (avec pour chacune un parlement compétent) qui couvrent toute la Belgique - les 3 communautés lingusitiques (avec aussi pour chacune un parlement compétent), différentes des régions, mais qui recouvre également la Belgique en totalité. La Belgique dispose donc dans sa définition de 6 membres subarea. bien que distingués par leur type (indiqué dans les attributs propres aux relations enfants). Le parcours exhaustif selon un type de division ou l'autre reste possible. Mais impossible à certifier avec un modèle ayant juste des frontières externes non réellement qualifiées. Le modèle sans subarea utilisé en France ne fonctionne bien (avec beaucoup de difficultés) QUE parce qu'il forme une hiérarchie administrative uniforme à tous les niveaux, et offrant une couverture totale formant une partition de l'espace national (ce n'est déjà plus vrai pour la France avec les collectivités uniques ou fusionnées dans les DOM et COM, ou avec les EPCI...) Il ne marche pas plus avec les frontières floues (pas de ligne administrative claire entre deux territoires enfants, qui se recouvrent alors partiellement dans la zone frontalière plus ou moins partagée autour de leurs contours flous, et délimitée par les frontières d'extension *maximales* de chaque territoire enfant. Même en France où des petites zones de gestion conjointe existent aussi pour des territoires partagés (y compris avec des pays voisins : on a le cas en métropole avec la Suisse à l'aéroport de Mulhouse-Bâle : souveraineté française de jure, mais administration suisse ; on a le cas avec l'Espagne pour une partie des eaux territoriales dans le Golfe de Gascogne). Les admin_level du modèle hiérarchique complet et uniforme, et partitionné (sans superpositions) basé uniquement sur les contours externes ont du plomb dans l'aile... Et la France fait cavalier seul dans OSM en voulant imposer aux autres pays un modèle basé uniquement sur des frontières étanches et exclusives, et difficiles à maintenir cohérentes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tram T4 Bondy-Aulnay : railway=light_rail ou railway=tram ?
Les wikis anglophones et allemands ont l'air de considérer que le critère principal est une plateforme séparée de la circulation routière sur la majorité du parcours pour le light_rail, alors que le tram est mêlé à la circulation. Ce qui voudrait dire que pour Paris, T1 et T3 sont tram, T4 est light_rail et T2 est un OVNI (les sections actuellement ouvertes sont clairement du type light_rail, mais le nouveau prolongement à Pont de Bezons est plutôt tram il me semble). Les lignes françaises les plus semblables au T4 parisien sont le T3 lyonnais et le tram-train Mulhouse - Vallée de la Thur, qui sont toutes deux railway=tram. Du coup, j'ai l'impression que l'usage francais est assez différent de ce qui se fait à l'étranger... faudrait-il corriger ça ? 2012/10/10 Eric SIBERT courr...@eric.sibert.fr Et l'espacement des rails comparé au chemin de fer classique et aux autres lignes de tram? A Baltimore, il y a un truc qui s'appelle le light_rail, qui est d'ailleurs taggué comme tel. En centre-ville, ça ressemble à du tram qui roule au milieu de la chaussée. Quand on part en banlieue, c'est en site propre qui fait plus penser au RER. L'espacement est celui des trains: 1435 mm. http://osm.org/go/ZZfUD8nPo-- Éric __**_ 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
[OSM-talk-fr] Séparation commune et Landuse : demande vérification.
Bonjour, Ayant le sentiment que les limites administratives sont des trucs fragiles, je viens demander une vérification sur ma séparation du Landuse residential de la limite administrative. La frontière entre Médan et Villenes était intégrée au multipolygone de zone résidentiel de Villenes. J'ai - dupliqué les points à chaque extrémité (obtenu trois points) et deplacé ceux des ways dédié landuse, - prolongé le way landuse pour fermer le multipolygone, - refusionnés les points dupliqués (ceux resté en double sur les ways limite administrative) - supprimé de la relation landuse les ways de la limite administrative. Le changeset correspondant est là: http://www.openstreetmap.org/browse/changeset/13449892 Ai-je merdé ? Cordialement. -- Marc http://www.openstreetmap.org/user/plonk/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Ç'ui-la, je l'comprends pas…
OSRM m'y a fait regarder de plus prêt, il évite un passage de cette route principale pour passer par le petit village voisin (tiens, le bouton permalink a disparu ? Chez vous aussi ?). Un coup d'œil sous JOSM, je vois rien qui ne va pas, ni sur le way, ni sur les nodes, mais OSMI indique bien un « small component », que je ne trouve pas non-plus sous JOSM : http://tools.geofabrik.de/osmi/?view=routinglon=5.59845lat=44.83161zoom=18 Le way : 164407528, au niveau de la frontière Clelles-St-Martin de Clelles. La dernière modification de la voie date du 12 septembre, les small-components ont-ils été compilés avant ? OSRM utilise des données OSM à jour, il me semble ? Rondoudjou, qu'est-ce qui empêche OSRM de faire passer des voitures par là ? JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
