Re: [OSM-talk-fr] circonscriptions legislatives : trouver les limites
Les SVG que j'ai générés sont fait en semi-automatique. 1) une requête SQL me sort des path SVG bruts, 2) je colle ça dans un fichier SVG "vide" que je vérifie dans Illustrator Je peux sortir des cartes SVG des circonscriptions législatives métropolitaines, dès qu'on a une bonne couverture. Le 24 mai 2012 16:36, Christian Quest a écrit : > Les SVG que j'ai générés sont fait en semi-automatique. > > 1) une requête SQL me sort des path SVG bruts, > 2) je colle ça dans un fichier SVG "vide" que je vérifie dans Illustrator > > Je peux sortir des cartes SVG des circonscriptions législatives > métropolitaines, dès qu'on a une bonne couverture. > > > Le 18 mai 2012 14:18, Christophe Augier a écrit > : >> Bonjour, >> >> J'aimerai générer des cartes de France des régions, départements, >> communes et pourquoi pas cantons et circonscriptions législatives au >> format SVG. >> >> Je viens de visiter le lien de ComCom Maker en mode web et je vois que >> ces informations sont disponibles il ne resterait donc plus qu'à les >> extraire. Mais voilà le hic, c'est que je n'ai aucune idée de comment >> faire. >> >> Pourriez vous m'orienter vers des tutoriels ou de la documentation >> avec les bonnes explications pour faire cela ? >> >> Merci, >> >> - Christophe >> >> 2012/5/16 Frédéric Rodrigo : >>> Suite à une discution sur IRC j'ai généré les relations des circonscriptions >>> avec ComCom Maker (en ligne de commande, si, si, c'est possible). >>> (ComCom makee en mode web : >>> http://osm7.pole-aquinetic.fr/~vincentpottier/comcom/ ) >>> >>> Il en résulte une relation par circonscriptions construite uniquement avec >>> les communes présentes dans OSM et qui ne sont pas découpées dans plusieurs >>> circonscriptions. >>> >>> Les relations de circonscriptions : >>> http://osm7.pole-aquinetic.fr/~fred/circo/ >>> >>> Les circonscriptions pour les quelles il manque des communes dans OSM (128): >>> http://osm7.pole-aquinetic.fr/~fred/circo/circo-missing-com.txt >>> >>> Donc tous les circonscriptions qui ne sont pas dans la liste pourraient être >>> importées, modulo les 88 communes découpés. Soit 449 sur 577. De plus il y >>> sûrement des circonscriptions faisables même sans avoir toutes les communes >>> dans OSM, comme pour les ComCom. >>> >>> La même chose dans un (joli?) paquet : >>> http://osm7.pole-aquinetic.fr/~fred/circo.tar.bz2 >>> >>> La liste des 88 communes découpés sur plusieurs circonscriptions est là : >>> https://github.com/Icephale/constituency-fr-NG/blob/master/circos/doubles.txt >>> >>> C'est faisable, si on le veut. Il y a quand même un réelle attende sur ces >>> données. >>> >>> Il y en a déjà dans OSM : >>> http://layers.openstreetmap.fr/?zoom=9&lat=46.89719&lon=6.10539&layers=BFT >>> >>> Frédéric. >>> >>> >>> Le 16/05/2012 15:31, Benjamin Bohard a écrit : >>> Bonjour, Avec l'arrivée imminente des élections législatives, Regards Citoyens a besoin de disposer des limites de circonscriptions électorales. Avec les données GEOFLA (libérées récemment par l'IGN), nous avons entrepris de les reconstruire à partir de limites communales et d'une liste de correspondance (data.gouv.fr) entre communes et circonscriptions (qui donne un meilleur résultat qu'une correspondance entre cantons électoraux et circonscriptions). Cette démarche permet d'automatiser la construction de la majeure partie des circonscriptions (331 sur 577). Le cas des limites infra-communales est à faire à la main dans 88 communes. Un fichier shapefile par département (60 sont concernés) à été généré et on aurait besoin de cartographes inspirés afin de pouvoir intégrer les dernières limites des circonscriptions. Nous sommes partis de ces données (GEOFLA) car elles étaient tout simplement plus faciles à prendre en main rapidement, le but étant de proposer une première version libre des circonscriptions pour le mois de juin. Dans un avenir proche, nous pensions toutefois faire un travail équivalent à partir des données OSM. Sans forcément chercher à intégrer le résultat dans la base de données OSM, ne sachant pour l'instant pas sous quelle structure nous pourrions le faire. La structure actuelle de notre essai est donc une collection de polygones, créés par agrégation de communes dans le cas des circonscriptions "simples" et de fragments de communes dans les cas plus complexes. Dans le cadre d'OSM, nous imaginons plutôt une relation portant sur des limites administratives communales et des voies (chemin de fer, rue, cours d'eau). Définir les circonscriptions comme un ensemble de cantons ou même de communes ne nous semble pas correct. Si le projet vous intéresse, nous utilisons le canal IRC #OpenDataBourgogne sur freenode pour échanger. Benjamin ___ Talk-fr mailing l
[OSM-talk-fr] ville d'Orange : livraison du plan en 4000 exemplaires
L'attente était longue; voici le lien vers la photo prise avec l'Iphone. http://www.flickr.com/photos/jeanlouis_zimmermann/7266888544/in/photostream/lightbox/ Une partie va pour l'office de tourisme, une autre pour les services municipaux et enfin une autre pour l'association des entreprises du sud d'Orange. Bonne fête de la Pentecôte à chacun !!! - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/ville-d-Orange-livraison-du-plan-en-4000-exemplaires-tp5710123.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] ville d'Orange : livraison du plan en 4000 exemplaires
Bonjour Jean-Louis, Félicitations à vous pour ce magnifique travail. C'est ce genre d'initiatives qui donne envie de contribuer encore et toujours plus à OSM ! Tu m'avais laissé la maquette de votre plan quand on s'est rencontré à Paris, mais je suis intéressé pour avoir quelques exemplaires de la version finale. Sur les stands OSM que j'anime, ce sera du plus bel effet. :-) A bientôt et bonne pentecôte à toi aussi, Nicolas Le 25/05/2012 12:42, ZIMMY a écrit : L'attente était longue; voici le lien vers la photo prise avec l'Iphone. http://www.flickr.com/photos/jeanlouis_zimmermann/7266888544/in/photostream/lightbox/ Une partie va pour l'office de tourisme, une autre pour les services municipaux et enfin une autre pour l'association des entreprises du sud d'Orange. Bonne fête de la Pentecôte à chacun !!! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ville d'Orange : livraison du plan en 4000 exemplaires
Bonjour Jean-Louis et bravo, Je crois que l'on va être nombreux à vouloir un exemplaire du plan. De quoi montrer quand on parle d'OSM autour de nous que ce n'est pas que virtuel mais bien réel... Romain Le 25/05/2012 12:42, ZIMMY a écrit : > > L'attente était longue; voici le lien vers la photo prise avec > l'Iphone.http://www.flickr.com/photos/jeanlouis_zimmermann/7266888544/in/photostream/lightbox/ > > Une partie va pour l'office de tourisme, une autre pour les services > municipaux et enfin une autre pour l'association des entreprises du sud > d'Orange. > > > Bonne fête de la Pentecôte à chacun !!! > ___ > > 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] Absence de landuse: residential
Bonjour à tous, Je suis nouveau sur la liste, dans le cadre de limport de données OSM pour une exploitation par un système de navigation, je suis amené à utiliser les surfaciques portant le tag landuse = residential, cela permet de pénaliser les voies traversant les agglomérations lors des calculs ditinéraire ou des calculs de temps de parcours. Visiblement ces données sont présentes pour la plupart des communes en France et semblent issues dun import automatique, cependant certaines sont absentes comme pour Aix en Provence, Salon, Marseille, Lambesc Quelquun a-t-il une explication sur labsence de ces données (problème dimport, source absente ou corrompue, suppression par utilisateur) et le moyen des les rajouter. Cordialement Jean-Christophe Montero ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Absence de landuse: residential
Bonjour, Ces donnes proviennent de Corine Land Cover. http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover Les données en conflit avec l'existant n'ont pas été importé. Ce qui c'est produit plus facilement dans les grande villes. Les polygones non importées sont visible là : http://clc.openstreetmap.fr/cgi-bin/index.py Tu peux chercher à les importer. Mais ce n'est pas un travail simple dans ce type de zone, ou simplement chercher à les créer à la main. Il s'agit de zones denses et étendues, souvent avec l'import du bâtit. Frédéric. Le 25 mai 2012 13:10, Montero JC a écrit : > Bonjour à tous, > > Je suis nouveau sur la liste, > dans le cadre de l’import de données OSM pour une exploitation par un > système de navigation, je suis amené à utiliser les surfaciques portant le > tag landuse = residential, cela permet de pénaliser les voies traversant les > agglomérations lors des calculs d’itinéraire ou des calculs de temps de > parcours. > > Visiblement ces données sont présentes pour la plupart des communes en > France et semblent issues d’un import automatique, cependant certaines sont > absentes comme pour Aix en Provence, Salon, Marseille, Lambesc… > > Quelqu’un a-t-il une explication sur l’absence de ces données (problème > d’import, source absente ou corrompue, suppression par utilisateur) et le > moyen des les rajouter. > > Cordialement > > Jean-Christophe Montero ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ville d'Orange : livraison du plan en 4000 exemplaires
Le ven. 25 mai 2012 à 03:42 -0700, ZIMMY a ecrit : > L'attente était longue; voici le lien vers la photo prise avec l'Iphone. > http://www.flickr.com/photos/jeanlouis_zimmermann/7266888544/in/photostream/lightbox/ > > Une partie va pour l'office de tourisme, une autre pour les services > municipaux et enfin une autre pour l'association des entreprises du sud > d'Orange. Félicitations pour avoir mené à bien cette v.2. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ville d'Orange : livraison du plan en 4000 exemplaires
Ça a l'air vraiment chouette ! bravo ! Sylvain Le 25 mai 2012 12:42, ZIMMY a écrit : > L'attente était longue; voici le lien vers la photo prise avec l'Iphone. > > http://www.flickr.com/photos/jeanlouis_zimmermann/7266888544/in/photostream/lightbox/ > > Une partie va pour l'office de tourisme, une autre pour les services > municipaux et enfin une autre pour l'association des entreprises du sud > d'Orange. > > > Bonne fête de la Pentecôte à chacun !!! > > - > Cordialement, > ZIMMY > Jean-Louis ZIMMERMANN > Développeur territorial (ville d'Orange,FR84) > Mandataire OSM-France sur le Grand-Sud-est > -- > View this message in context: > http://gis.19327.n5.nabble.com/ville-d-Orange-livraison-du-plan-en-4000-exemplaires-tp5710123.html > Sent from the France mailing list archive at Nabble.com. > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ville d'Orange : livraison du plan en 4000 exemplaires
superbe ! félicitations :) Le 25 mai 2012 14:28, Guillaume Allegre a écrit : > Le ven. 25 mai 2012 à 03:42 -0700, ZIMMY a ecrit : > > L'attente était longue; voici le lien vers la photo prise avec l'Iphone. > > > http://www.flickr.com/photos/jeanlouis_zimmermann/7266888544/in/photostream/lightbox/ > > > > Une partie va pour l'office de tourisme, une autre pour les services > > municipaux et enfin une autre pour l'association des entreprises du sud > > d'Orange. > > Félicitations pour avoir mené à bien cette v.2. > > > -- > ° /\Guillaume AllègreOpenStreetMap France > /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative > / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
On jeudi 24 mai 2012, Balaitous wrote: > Bonjour, Bonjour, > Pour mon premier message, je voudrais poser une question que je me pose > depuis un moment. > Est-ce que les tags d'une relation sont héréditaires ? > En d'autre terme lorsque je mets un tag dans une relation celui-ci > est-il transmis aux enfants de la relation (lorsque ceux-ci ne > redéfinissent pas le tag en question) ? Il n'y a pas "une" mais plusieurs réponses à ta question, principalement car l'éco-système OSM (la base, les utilisations, les éditeurs, le wiki) sont très souples et disons, un peu anarchique parfois et pas toujours cohérent et pas imposé par quoi que ce soit. (Je ne commenterais pas les défauts et avantages) Donc la réponse à ta question va dépendre de quelle partie de cet éco-système elle concerne. Dans la base OSM (celle qu'on édite avec JOSM/potlatch/...) il n'y a pas de notion d'hérédité, une relation a ses tags, un way les siens, un noeud les sien, et rien n'est recopié nulle part de manière automatique. Exemple, si tu places le tag landuse=forest sur une relation multipolygon, ce tag ne se retrouvera pas sur les ways membres de la relation. L'hérédité, si elle existe quelque part, sera dans la manière d'utiliser les données OSM, c'est à dire les logiciels de rendu, l'impression d'une carte, ... Et ça, c'est laissé complètement libre à celui qui veut se servir des données OSM, et donc au logiciel qu'il va utiliser pour s'occuper de la conversion du format .osm vers un format exploitable pour son besoin. Le logiciel osm2pgsql par exemple qui est célèbre car étant utilisé par la majorité des rendus sous forme de carte des données OSM (dont le rendu proposé en page d'accueil du site www.osm.org) dispose de quelque traitement de l'hérédité au niveau de certaines relations seulement (type=route, type=boundary et type=multipolygon) et pour certains tags seulement défini dans par liste blanche ou noire Il n'y a rien de systématique donc, et tout est fait au cas par cas, selon le besoin et le logiciel utilisé. Et enfin, il y a le wiki, qui va décrire l'utilisation de relation, et pour lesquelles il va (ou non) explicitement indiquer que toute utilisation de cette relation "devrait" considérer l'hérédité. Mais le wiki n'est qu'une description, la décision finale revenant à l'utilisation qui sera faite des dites relations et qui dépendra, certes de la description faite du wiki, mais aussi de la manière réél et majoritaire dont les contributeurs OSM auront rentré dans la base de donnée Exemple, si 1% seulement des routes nationales de france disposent d'une relation avec nom+ref alors que tout le reste c'est de la réplication des tags sur chacun des composants, alors je suppose que quelqu'un souhaitant faire un rendu des routes nationales de france va simplement laisser tomber l'hérédité car ça ne gérera que trop peu de cas. A l'inverse, si ce chiffre passe à 99% ça va commencer à intéresser du monde, et les choses évoluerons. Tout ça est donc un salmigondi s'entre-influençant fait de la manière d'éditer, du nombre d'utilisation qui en est faite, de documentation wiki qui en parle et du support plus au moins aisé/influencé par les éditeurs OSM. Une sorte de progression anarchique par essai/erreur qui entraîne sans doute de la perte de temps, de création d'algorithme plus compliqué mais aussi de plus de flexibilité. Mon pronostic c'est qu'on devrait ré-avancer vers la normalisation (factorisation des tags par les relations) et la multiplication des relations dans l'avenir car le découpage des routes, des cours d'eau, des frontières de manière quasi-arbitraire (restriction de vitesse, pont, tunnel, chevauchement) augmenterons et avec eux la difficulté d'éditer, donc un besoin grandissant d'outil pour les gérer. > Plus généralement, depuis quelques temps que je m'intéresse à OSM, je > trouve un manque de séparation des aspects géométriques (point, > ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes > de cohérence pour le nommage des routes, de plus en plus fragmentées. Beaucoup en sont conscient, et des solutions arrivent petit à petit qui tente de garder la compatibilité (les relations sont l'exemple le plus typique) sinon les réflexions depuis quelques années pour gérer d'une manière unique et cohérente les surface : http://wiki.openstreetmap.org/wiki/The_Future_of_Areas Mais il est devenu presque impensable de dire : bon, on casse tout et on repart de zéro avec les géométries d'un coté, la sémantique de l'autre. > En gros, généraliser les relations, faire du multipolygon un élément > géométrique à part entière. J'en suis partisan, d'autres voudraient l'abandonner et le substituer par un nouvel objet "area" au même niveau que "way", "node" et "relation" qui reprendrait grosso modo l'idée du multipolygon mais imposerait des contraintes d'intégrité -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___
Re: [OSM-talk-fr] ville d'Orange : livraison du plan en 4000 exemplaires
Bravo à vous. Maintenant c'est l'occasion pour la ville de nouer une jumelage avec une ville grecque ou portugaise qui aurait sérieusemnt besoin d'aide pour leur cartographie, et à qui vous apporteriez vos solutions avec votre association ! D'ailleurs ce serait bien de mobiliser les groupes qui ont déjà bien avancé dans leur ville pour aider ces deux pays en difficulté. Surtout que c'est aussi l'occasion de préparer ses vacances là-bas cet été, et que ce sont deux pays où le français est facilement compris (encore plus facilement au Portugal). L'occasion d'aller faire quelques rencontre sur place, puis commencer un projet commun de collaboration pour la rentrée. Le 25 mai 2012 12:42, ZIMMY a écrit : > L'attente était longue; voici le lien vers la photo prise avec l'Iphone. > http://www.flickr.com/photos/jeanlouis_zimmermann/7266888544/in/photostream/lightbox/ > > Une partie va pour l'office de tourisme, une autre pour les services > municipaux et enfin une autre pour l'association des entreprises du sud > d'Orange. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Merci pour ces réponses qui me permettent d'y voir un peu plus clair. Le vendredi 25 mai 2012 à 14:39 +0200, sly (sylvain letuffe) a écrit : > On jeudi 24 mai 2012, Balaitous wrote: > > Bonjour, > > Bonjour, > > > Pour mon premier message, je voudrais poser une question que je me pose > > depuis un moment. > > Est-ce que les tags d'une relation sont héréditaires ? > > En d'autre terme lorsque je mets un tag dans une relation celui-ci > > est-il transmis aux enfants de la relation (lorsque ceux-ci ne > > redéfinissent pas le tag en question) ? > > Il n'y a pas "une" mais plusieurs réponses à ta question, principalement car > l'éco-système OSM (la base, les utilisations, les éditeurs, le wiki) sont > très souples et disons, un peu anarchique parfois et pas toujours cohérent et > pas imposé par quoi que ce soit. (Je ne commenterais pas les défauts et > avantages) > > Donc la réponse à ta question va dépendre de quelle partie de cet éco-système > elle concerne. > > Dans la base OSM (celle qu'on édite avec JOSM/potlatch/...) il n'y a pas de > notion d'hérédité, une relation a ses tags, un way les siens, un noeud les > sien, et rien n'est recopié nulle part de manière automatique. > Exemple, si tu places le tag landuse=forest sur une relation multipolygon, ce > tag ne se retrouvera pas sur les ways membres de la relation. > > L'hérédité, si elle existe quelque part, sera dans la manière d'utiliser les > données OSM, c'est à dire les logiciels de rendu, l'impression d'une > carte, ... > Et ça, c'est laissé complètement libre à celui qui veut se servir des données > OSM, et donc au logiciel qu'il va utiliser pour s'occuper de la conversion du > format .osm vers un format exploitable pour son besoin. > > Le logiciel osm2pgsql par exemple qui est célèbre car étant utilisé par la > majorité des rendus sous forme de carte des données OSM (dont le rendu > proposé en page d'accueil du site www.osm.org) dispose de quelque traitement > de l'hérédité au niveau de certaines relations seulement (type=route, > type=boundary et type=multipolygon) et pour certains tags seulement défini > dans par liste blanche ou noire > Il n'y a rien de systématique donc, et tout est fait au cas par cas, selon le > besoin et le logiciel utilisé. > Et enfin, il y a le wiki, qui va décrire l'utilisation de relation, et pour > lesquelles il va (ou non) explicitement indiquer que toute utilisation de > cette relation "devrait" considérer l'hérédité. Mais le wiki n'est qu'une > description, la décision finale revenant à l'utilisation qui sera faite des > dites relations et qui dépendra, certes de la description faite du wiki, mais > aussi de la manière réél et majoritaire dont les contributeurs OSM auront > rentré dans la base de donnée Côté wiki il ne me parait pas à jour. Par quel processus une relation passe du stade de proposé à officiel ? Sur la base des statistiques d'utilisation ? Quand j'aurais plus de temps, j'irais faire un tour de ce côté là aussi. > Exemple, si 1% seulement des routes nationales de france disposent d'une > relation avec nom+ref alors que tout le reste c'est de la réplication des > tags sur chacun des composants, alors je suppose que quelqu'un souhaitant > faire un rendu des routes nationales de france va simplement laisser tomber > l'hérédité car ça ne gérera que trop peu de cas. > A l'inverse, si ce chiffre passe à 99% ça va commencer à intéresser du monde, > et les choses évoluerons. Pour le projet qui m'intéresse, je compte pourtant m’appuyer sur les relations quand elles existent, et faire de l'empirique ailleurs (2 ways avec un certain nombres d'attribut communs = 1 route) (2 ways // avec même catégorie de route = probablement 1 route a chaussée séparée) Pour ma part hier j'ai ajouté 2 ou 3 routes, dès qu'elles sont coupées en 2 je les encapsules dans une "street", et je ne met plus le nom dans tous les tronçons. Aux éditeurs de se débrouiller comme cela m'a été dit dans certaines réponses. > Tout ça est donc un salmigondi s'entre-influençant fait de la manière > d'éditer, du nombre d'utilisation qui en est faite, de documentation wiki qui > en parle et du support plus au moins aisé/influencé par les éditeurs OSM. Une > sorte de progression anarchique par essai/erreur qui entraîne sans doute de > la perte de temps, de création d'algorithme plus compliqué mais aussi de plus > de flexibilité. > > Mon pronostic c'est qu'on devrait ré-avancer vers la normalisation > (factorisation des tags par les relations) et la multiplication des relations > dans l'avenir car le découpage des routes, des cours d'eau, des frontières de > manière quasi-arbitraire (restriction de vitesse, pont, tunnel, > chevauchement) augmenterons et avec eux la difficulté d'éditer, donc un > besoin grandissant d'outil pour les gérer. Effectivement, quand les gens aurons fait l'expérience de modifier 10 ou 20 tag pour ajouter UNE ref sur UNE rue, il trouverons plus d’intérêt aux relations. > > Pl
Re: [OSM-talk-fr] Héritage et relation
> Côté wiki il ne me parait pas à jour. C'est souvent le cas, sur certaines pages soit il est en avance dans le sens où il propose de tagguer tel truc de tel manière alors que ça n'est pas encore utilisé dans la base. Soit des gens finirons par l'utiliser de cette manière car elle "ressort" comme mieux, soit cette page tombera dans l'oubli. A l'inverse des pratiques existent qui ne sont pas ou mal documentées, et là, il est préférable de venir compléter le wiki (tout le monde le peux), et indiquer par des pages que "voilà ce qui se fait à tel endroit, pour tel et tel raison avec tel et tel avantage sur telle autre méthode qui lui ressemble" et en parler sur la liste anglaise tagging pour présenter son existence aux autres, en discuter et l'améliorer et espérer que son usage va se démocratiser pour qu'elle finisse par obtenir le "droit" de figurer dans la liste des "Established Relations" : http://wiki.openstreetmap.org/wiki/Types_of_relation Ce qui d'ailleurs et un peu fumeux car la notion de "Established Relations" est bien vague, et certains ne lui reconnaissent pas de valeur. Mais on peut dire que des relations très utilisées par les contributeurs et très utilisées par les consommateurs sont en bonne voie pour figurer dans cette liste. > Par quel processus une relation > passe du stade de proposé à officiel ? J'ai envie de dire "aucun" ;-) Contrairement a beaucoup d'autres tags pour lequel une procédure de discussion+vote a lieu, aucune relation, à ma connaissance, n'est passée par un tel système, sans doute car beaucoup trouve cette méthode de validation comme merdique. > Sur la base des statistiques > d'utilisation ? y'a pas mal de ça. Plus une relation est utilisée, plus elle a de chance de finir dans la liste des "Established Relations" En même temps, c'est un wiki, donc n'importe qui peut ajouter à la liste, tout comme n'importe qui peut l'enlever ensuite > Je pense que je vais en laisser trainer quelques une dans la base (avec > un tag comment expliquant le pourquoi) C'est à mon avis la bonne solution, et je le fais régulièrement, voire en laisser "beaucoup" dans la base -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tag Access
Bonjour, Je suis en discussion avec l'auter de l'outil de routing OSRM à propos du tag access sur les barrières et autres éléments de restriction d'accés. J'ai l'impression que l'on ne comprends pas de la même façon cette clé. J'espère être dans le faux sinon cela impliquerait que l'outil de routing ne va pas donner de bon résultats. Si l'un de vous a une vision claire de cette entrée de tag je l'invite à participer à https://github.com/DennisOSRM/Project-OSRM/issues/276 et à m'expliquer en quoi je comprends mal ce point. Merci et bon WE -- Rodolphe Quiédeville - Artisan Logiciel Libre http://cartosm.eu - Intégration de carte libre sur site web Blog : http://blog.rodolphe.quiedeville.org/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag Access
On vendredi 25 mai 2012, Rodolphe Quiedeville wrote: > Si l'un de vous a une vision claire de cette entrée de tag je l'invite à > participer à > https://github.com/DennisOSRM/Project-OSRM/issues/276 > > et à m'expliquer en quoi je comprends mal ce point. Concernant le cas la barrière, c'est discutable. En effet, si il y a une barrière, ça peut se comprendre qu'elle n'est pas traversable dans certains cas, donc prise en compte par le logiciel de routage comme non traversable. Maintenant, ce que je suppose, c'est que si tu veux embarquer ta voiture sur le ferry, alors cette barrière doit être amovible afin justement de permettre le passage, auquel cas, il faudrait indiquer un truc genre access=destination pour dire que si la destination c'est justement le ferry, alors elle pourra être passée (à condition d'acheter son billet !) Concernant son access=motorcar, c'est bien toi qui a raison, access ne s'utilise pas comme ça mais : access=no motorcar=yes (si on veut dire que seules les voitures sont autorisés, mais ni les piétons, ni les cyclistes, ni tout le reste) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
