Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Bonjour à tous, Pour compléter ta remarque Christian, au niveau international on utilise le codage NUTS ,(Nomenclature of Territorial Units for Statistics) En effet dès que tu dois comparer des régions ou simuler des itinéraires européens les codes INSEE sont insuffisants. D'où ce référentiel NUTS plus global, c'est un complément au code INSEE . Exemple: Lambesc NIVEAU NUTS 0 | 1 | 2 | 3 | 4 | 5 | FR | 8 | 2 | 4 || 050 |où 050 correspond aux 3 derniers caractères du code INSEE. NUTS0 FR FRANCE NUTS1 FR8 ZONE MEDITERRANEE NUTS2 FR82 REGION PACA NUTS3 FR824DEPARTEMENT BOUCHES-DU-RHÔNE NUTS4 -- NUTS5 FR824050 LAMBESC cf: NUTS Internationaux http://web.archive.org/web/2007070457/http://simap.europa.eu/nomen_nuts/7148f4fa-ad24-9e4d-03e427e0aca09bad_en.html cf: Normes ISO des subdivisions administratives http://fr.wikipedia.org/wiki/ISO_3166-2 > From: [EMAIL PROTECTED] > Date: Wed, 26 Nov 2008 01:53:41 +0100 > To: talk-fr@openstreetmap.org > Subject: Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector > > Dans les SIG, c'est le code INSEE des communes (vous avez, si vous > êtes nés en France, celui > de votre commune de naissance dans votre numéro de sécurité > sociale) qui est utilisé comme > jointure entre les tables, dès lors que l'on traite le niveau > administratif. > Les communautés de communes ont un numéro analogue à celui des > entreprises. > Ne serait-il pas logique d'adopter ces numéros normés dans OSM, mais > sans que l'OSMeur de base ait > à s'en préoccuper? > > Christian > > > > > Le 26 nov. 08 à 00:48, Thomas Walraet a écrit : > >> g.d wrote: >>> >>> Pour qu'une lettre arrive, >>> 'faut écrire >>> 20137 Porto-Vecchio >>> Arraggio >>> ! >>> Pourtant, Araghju ne fait pas partie de Porto-Vecchio, rien à voir... >> >> En y réfléchissant, ce n'est pas complètement aberrant que sur une >> lettre distribuée par la Poste il faille mettre les coordonnées du >> bureau qui s'occupe d'un hameau plutôt que celles de la commune à >> laquelle il appartient. >> >> ___ >> 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 _ Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack now. hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Dans les SIG, c'est le code INSEE des communes (vous avez, si vous êtes nés en France, celui de votre commune de naissance dans votre numéro de sécurité sociale) qui est utilisé comme jointure entre les tables, dès lors que l'on traite le niveau administratif. Les communautés de communes ont un numéro analogue à celui des entreprises. Ne serait-il pas logique d'adopter ces numéros normés dans OSM, mais sans que l'OSMeur de base ait à s'en préoccuper? Christian Le 26 nov. 08 à 00:48, Thomas Walraet a écrit : > g.d wrote: >> >> Pour qu'une lettre arrive, >> 'faut écrire >> 20137 Porto-Vecchio >> Arraggio >> ! >> Pourtant, Araghju ne fait pas partie de Porto-Vecchio, rien à voir... > > En y réfléchissant, ce n'est pas complètement aberrant que sur une > lettre distribuée par la Poste il faille mettre les coordonnées du > bureau qui s'occupe d'un hameau plutôt que celles de la commune à > laquelle il appartient. > > ___ > 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] Limites administratives sur la carte OSM Inspector
g.d wrote: > > Pour qu'une lettre arrive, > 'faut écrire > 20137 Porto-Vecchio > Arraggio > ! > Pourtant, Araghju ne fait pas partie de Porto-Vecchio, rien à voir... En y réfléchissant, ce n'est pas complètement aberrant que sur une lettre distribuée par la Poste il faille mettre les coordonnées du bureau qui s'occupe d'un hameau plutôt que celles de la commune à laquelle il appartient. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Le 25 nov. 08 à 19:46, Yannick a écrit : > J'ai même un cas de commune desservie par 2 bureaux distributeurs > différents donc 2 CP différents et ce en fonction de critères > exclusivement postaux. > Je suis quasiment certains que d'autres cas à la noix existent ... > l'exemple de La Grave (dpt > 05) qui est desservie par un bureau distributeur de l'Isère donc cette > commune peut, potentiellement, avoir deux codes postaux 05xxx et > 38xxx. > Ceci a pu être vrai aux origines du système mais je ne pense pas qu'il > soit toujours en vigueur car maintenant la mécanisation permet de > diriger directement les liasses vers le bon bureau distributeur mais > sait-on jamais. J'ai connu le cas de 20170 San Gavino di Carbini en Corse du Sud (San Gavinu di Càrbini, en langue locale) commune qui a un hameau, nommé Araghju par les gens (et par Michelin), nommé Araggio, Arragio, Arraggio ou encore Arraggiu par l'IGN et par différents Cadastres, au choix, mais introuvable sur aucune liste ! :-( Si on écrit une lettre à quelqu'un à 20170 San Gavino di Carbini Hameau d'Arraggio, ça n'arrive pas, Arraggio étant inconnu au régiment chez les postiers du 20170 :-( Car le bureau distributeur pour Araghu est... 20137 ! Mais si on écrit 20137 San Gavino di Carbini Hameau d'Arraggio (ce qui devrait être correct, car même le Cadastre le dit !) la lettre revient quand même, parce que au bureau 20137, ils ne connaissent pas de "San Gavino" ! Pour qu'une lettre arrive, 'faut écrire 20137 Porto-Vecchio Arraggio ! Pourtant, Araghju ne fait pas partie de Porto-Vecchio, rien à voir... Mais ça, on l'apprend seulement, si on demande à la secrétaire de la Maire annexe d'Araghju, ou au café/resto... Ça ne figure sur aucun renseignement ou liste que j'ai pu trouver jusqu'ici. Bref, ça cafouille un max, justement because of the informateschenikke. Gerhard ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
sylvain letuffe a écrit : >> Bonsoir, > Bonne nuit ;-) Bonsoir > >> Le problème des codes postaux multiples dans une commune correspond à la >> délimitation d'une zone susceptible d'évoluer dans le temps. > Argh, merde, ha oui dans ce cas là, ça devient vachement plus chaud alors. Comme quoi on ne pense pas à tout. C'est peut-ere cela l'un des pluis gros avantage de la communauté du libre car il y a toujours une personne qui peut signaler une erreur de raisonnement pouvant obérer ensuite le travail de tous. Il peut même arriver qu'une commune change de bureau distributeur donc changement de code postal. J'ai même un cas de commune desservie par 2 bureaux distributeurs différents donc 2 CP différents et ce en fonction de critères exclusivement postaux. Je suis quasiment certains que d'autres cas à la noix existent > >> Je serais donc assez OK avec toi pour dire non à un codage de la rue >> mais par contre oui à un codage de zone qui sera plus "simple", pas pour >> moi, de modifier ensuite > > Aïe, ce qui reporte le problème à "comment déterminer la zone à codifier" et > si cette zone est décidée "au petit bonheur la chance des registres de la > poste" on est pas sortie de l'auberge. Hé oui on est tributaire d'éléments 'non contrôlés' puisque indépendant de notre volonté. D'un autre coté ce n'est pas tous les jours. Sur le sujet CP bizarroïdes je peux donner l'exemple de La Grave (dpt 05) qui est desservie par un bureau distributeur de l'Isère donc cette commune peut, potentiellement, avoir deux codes postaux 05xxx et 38xxx. Ceci a pu être vrai aux origines du système mais je ne pense pas qu'il soit toujours en vigueur car maintenant la mécanisation permet de diriger directement les liasses vers le bon bureau distributeur mais sait-on jamais. Amitiés -- Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/actes/ Cercle Généalogique (EGE-PTT): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
> Bonsoir, Bonne nuit ;-) > Le problème des codes postaux multiples dans une commune correspond à la > délimitation d'une zone susceptible d'évoluer dans le temps. Argh, merde, ha oui dans ce cas là, ça devient vachement plus chaud alors. > Je serais donc assez OK avec toi pour dire non à un codage de la rue > mais par contre oui à un codage de zone qui sera plus "simple", pas pour > moi, de modifier ensuite Aïe, ce qui reporte le problème à "comment déterminer la zone à codifier" et si cette zone est décidée "au petit bonheur la chance des registres de la poste" on est pas sortie de l'auberge. Tant pis, bien tenté sly ! -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
sylvain letuffe a écrit : > Jamais personne ne me verra ajouter des codes postaux à une rue, car ceux-ci > sont déductibles de la commune dans laquelle ils sont > . > . > . > ou alors j'ai tout faux > Bonsoir, Le problème des codes postaux multiples dans une commune correspond à la délimitation d'une zone susceptible d'évoluer dans le temps. Dans les communes de Paris Lyon et Marseille les codes postaux sont accolés de fait à une entité administrative d'où peu de risque de modifications, quoique. Ailleurs c'est rarement le cas. Le simple fait de déménager physiquement l'établissement postal de tri des facteurs le matin va ipso-facto modifier les codes postaux. La ville de Rennes a 3/4 CP non consécutifs de surcroît. Il se trouve que ma grand-mère a vu changer par au moins 2/3 fois son code postal. Il y a donc un non pérennité de l'information sauf à avoir une personne qui surveille en permanence ce que fait La Poste. Je serais donc assez OK avec toi pour dire non à un codage de la rue mais par contre oui à un codage de zone qui sera plus "simple", pas pour moi, de modifier ensuite Amitiés -- Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/actes/ Cercle Généalogique (EGE-PTT): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
> Je dis simplement que dans > l'état actuel de la base (je ne parle pas de celle que l'un ou l'autre a > pu monter de son côté) ou de l'API, ces informations apportent une > véritable information, pour le moment. Aussi bien l'état peu changer et nous résoudre le problème, aussi bien quelqu'un va nous écrire une logiciel d'exportation qui rajoutera pour "M. Mysql avec machine au rabais" un logiciel de précalcul qui fasse le boulot. Il nous suffira alors de post-traiter la base. "Don't ask a human what a machine can do" > > quand je vois les tags : > > is_in=france ou des trucs comme ça, ça me fout un peu les boules, car > > cette info découle d'une appartenance à un polygone, et me semble être du > > temps perdu. > > C'est un autre problème qui peut être règlé avec des relations > (potentiellement avec une requête spatiale aussi). Tout a fait ! donc autant ne pas perdre du temps à les remplir. Il ne me faudrait pas plus de 10 jours pour remplir tout les is_in de la terre et sortir un fichier osm les contenant > Non, ta position est largement défendable. Je milite juste pour que des > personnes, des applications qui ne peuvent pas (ou ne veulent pas ?) > s'appuyer sur les bases de données spatiales, puissent quand même avoir > des informations sur les relations entre les objets. Alors post-traitons, pour eux, la donnée, mais ne demandons pas à des humains de le faire. J'utilise beaucoup mysql, je veux savoir dans quel département se trouve quel POI, je tiens à disposition de qui veut la fonction php qui pré-calcul tout ça. (et d'après mes bench sur requêtes postGIS, notre vie n'a pas changée, il faut de toute façon le précalculer ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
sylvain letuffe a écrit : > > Je prends un peu en cours et je voudrais juste commenter ça. Je pense qu'il > faut bannir, comme dans toute base de donnée, la redondance. Et si des > relations "commune" voient le jour, il me semble qu'il serait mauvais de s'en > servir pour y inclure tous les éléments contenus dans la commune. exemples de requête sur la base : - quelles sont les communes adjacentes à la commune X ? - combien de communes composent le département Y, la comcom Z (je sais l'INSEE ou d'autress fournissent déjà la réponse, mais l'idée est de vérifier qu'on est aligné) - il y a-t-il une différence significative entre la morphologie des communes du Kochersberg et celles du pays d'Auge ? > > La logique géographique à cet avantage qu'il existe déjà une relation entre > des objets physique (une route) et logique (une commune) : leurs coordonnées. Je suis foncièrement d'accord, j'utilise PostGIS aussi bien au boulot qu'à la maison, je ne suis pas à convaincre. Je dis simplement que dans l'état actuel de la base (je ne parle pas de celle que l'un ou l'autre a pu monter de son côté) ou de l'API, ces informations apportent une véritable information, pour le moment. > > quand je vois les tags : > is_in=france ou des trucs comme ça, ça me fout un peu les boules, car cette > info découle d'une appartenance à un polygone, et me semble être du temps > perdu. C'est un autre problème qui peut être règlé avec des relations (potentiellement avec une requête spatiale aussi). > > Jamais personne ne me verra ajouter des codes postaux à une rue, car ceux-ci > sont déductibles de la commune dans laquelle ils sont > . > . > . > ou alors j'ai tout faux Non, ta position est largement défendable. Je milite juste pour que des personnes, des applications qui ne peuvent pas (ou ne veulent pas ?) s'appuyer sur les bases de données spatiales, puissent quand même avoir des informations sur les relations entre les objets. Dans le même temps, si OSM décidait de basculer l'entrepôt de données dans PostGIS (ou n'importe quel autre soft équivalent), si OSM décidait de s'aligner sur les standards Open GIS Consortium (notamment les web services géographiques), on ferait un grand pas, mais avec des si on mettrait OSM en bouteilles. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
> temps, avoir des relations "commune" avec les tags name=x ou des > relations departements avec name=y. L'information peut paraître > redondante, mais pas tant que cela, sauf à disposer d'outils qui > permettent de retrouver la topologie de l'objet. Je prends un peu en cours et je voudrais juste commenter ça. Je pense qu'il faut bannir, comme dans toute base de donnée, la redondance. Et si des relations "commune" voient le jour, il me semble qu'il serait mauvais de s'en servir pour y inclure tous les éléments contenus dans la commune. La logique géographique à cet avantage qu'il existe déjà une relation entre des objets physique (une route) et logique (une commune) : leurs coordonnées. quand je vois les tags : is_in=france ou des trucs comme ça, ça me fout un peu les boules, car cette info découle d'une appartenance à un polygone, et me semble être du temps perdu. Jamais personne ne me verra ajouter des codes postaux à une rue, car ceux-ci sont déductibles de la commune dans laquelle ils sont . . . ou alors j'ai tout faux -- Sylvain Letuffe [EMAIL PROTECTED] qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
g.d a écrit : > Il me semble, > qu'avec cette nouvelle approche par 'relations', > > on rentrerait dans une nouvelle ère à taguer les propriétés d'un objet, > fondamentalement différente de ce qu'on fait jusque-là... Disons que les relations commencent à prendre leur place et je crois que c'est une bonne pratique et un challenge pour les moteurs de rendu et autres applications connexes. > > Par extension, > ce système de 'relations' devrait s'appliquer > à toute propriété non-physique de tous éléments... (?) Ce serait logique. > > Si on voulait être conséquents, > les "tags traditionnels" resteraient réservés aux propriétés physiques > (classification, largeur, état de la voie, nombre de voies...), > > là où les autres attributs plutôt virtuels, non-physiques, > (name, ref, int_ref d'une voie, > la voie à laquelle appartient l'adresse/n° d'une maison, > ou la ligne de métro à laquelle appartient une station, > devraient faire objet d'une 'relation' ? > > (Voire > une buvette ferait partie d'une relation débits de boisson lic III, > un bar ferait partie d'une relation débits de boisson lic IV, > où tous deux feraient partie de la relation restauration ? > Et ne "reste" dans le node que ce qui n'est pas pris en compte par > une relation, > ici le tag "name : "Chez Bidule" ?) > --- > > Le principe me va, > de regrouper plusieurs ways en une "unité supérieure", > comme plusieurs morcaux de limites communales > en une limite de département, > puis en frontière nationale > (la logique de Jérôme me paraît correcte), Oui. Plus précisément et concernant le cas particulier des limites communales, on peut voir cohabiter des tags, au niveau way, comme left:city=a, right:city:b, right:department=c, etc. et, dans le même temps, avoir des relations "commune" avec les tags name=x ou des relations departements avec name=y. L'information peut paraître redondante, mais pas tant que cela, sauf à disposer d'outils qui permettent de retrouver la topologie de l'objet. > > ou de regrouper plusieurs tronçons de ways en une "route européenne E > machin", > "RCEA", > ou "route des châteaux" ou "route Jacques Cœur", > qui eux-mêmes pourraient être dans une relation parcours touristique. > > ok, même si ça fera du travail en sus, > et obligera à huiler des aiguillages rouillées du cerveau... C'est aussi par ces relations que se créera de la plus value par rapport à un simple dessin de ce que chacun a vu dans son coin. A terme, cela devrait engendrer moins de travail : taguer un itinéraire européen un seule fois (en listant l'ensemble de ses composantes) est moins coûteux que de taguer l'ensemble des ways, et moins source d'erreurs (hors to graphe). > > > mais alors OU est la notion de regroupement en unités supérieures > dans la "Relation:restriction", pourtant dans les "established uses" ? > Ça revient à artificiellement introduire une unité qui n'a pas > d'existence, > pour ensuite dire, qu'elle n'existe pas, > ça me paraît absurde... pas sûr d'avoir compris ta pensée. Pour moi, l'avenir de la relation est aussi dans la factorisation des descriptions. C'est plus simple d'écrire : 4x2 plutôt que 2+2+2+2. Aujourd'hui on n'est pas assuré que les outils d'exploitation de la base en donnent comme seul résultat possible 8. C'est un chantier en cours. Pour les restrictions, les relations sont utiles aussi (no-left-turn) car on met aussi de la logique de circulation et donc forcément des liens entre les objets de base. > > Je suis réfractaire à des fonctionnements > qui nécessitent un élément virtuel extérieur. > Oui, je me sers de tels artifices en mathématiques, > mais je regarde l'usage de ces "parachutes" comme une déclaration > d'échec, > comme quoi je n'ai pas réussi à faire face avec mes outils 'propres'. > --- > > Je n'ai rien contre les 'relations', > mais que cela soit > a) conséquent et partout, > b) simple et compréhensible, > c) expliqué sur le wiki, en mots simples. > (et si possible d), des "presets" en cascade pour ça, dans josm... :-) d'accord pour [a-d]. OSM n'est pas gravé dans le marbre (ou le grès des Vosges), laissons-le poursuivre sa maturation. > > Dans l'attente d'éclaircissement > où s'arrête le tag sur node et way, > et où au juste commence la 'relation', > je continue à l'ancienne. > > Gerhard Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Il me semble, qu'avec cette nouvelle approche par 'relations', on rentrerait dans une nouvelle ère à taguer les propriétés d'un objet, fondamentalement différente de ce qu'on fait jusque-là... Par extension, ce système de 'relations' devrait s'appliquer à toute propriété non-physique de tous éléments... (?) Si on voulait être conséquents, les "tags traditionnels" resteraient réservés aux propriétés physiques (classification, largeur, état de la voie, nombre de voies...), là où les autres attributs plutôt virtuels, non-physiques, (name, ref, int_ref d'une voie, ou la voie à laquelle appartient l'adresse/n° d'une maison, ou la ligne de métro à laquelle appartient une station, devraient faire objet d'une 'relation' ? (Voire une buvette ferait partie d'une relation débits de boisson lic III, un bar ferait partie d'une relation débits de boisson lic IV, où tous deux feraient partie de la relation restauration ? Et ne "reste" dans le node que ce qui n'est pas pris en compte par une relation, ici le tag "name : "Chez Bidule" ?) --- Le principe me va, de regrouper plusieurs ways en une "unité supérieure", comme plusieurs morcaux de limites communales en une limite de département, puis en frontière nationale (la logique de Jérôme me paraît correcte), ou de regrouper plusieurs tronçons de ways en une "route européenne E machin", "RCEA", ou "route des châteaux" ou "route Jacques Cœur", qui eux-mêmes pourraient être dans une relation parcours touristique. ok, même si ça fera du travail en sus, et obligera à huiler des aiguillages rouillées du cerveau... mais alors OU est la notion de regroupement en unités supérieures dans la "Relation:restriction", pourtant dans les "established uses" ? Ça revient à artificiellement introduire une unité qui n'a pas d'existence, pour ensuite dire, qu'elle n'existe pas, ça me paraît absurde... Je suis réfractaire à des fonctionnements qui nécessitent un élément virtuel extérieur. Oui, je me sers de tels artifices en mathématiques, mais je regarde l'usage de ces "parachutes" comme une déclaration d'échec, comme quoi je n'ai pas réussi à faire face avec mes outils 'propres'. --- Je n'ai rien contre les 'relations', mais que cela soit a) conséquent et partout, b) simple et compréhensible, c) expliqué sur le wiki, en mots simples. (et si possible d), des "presets" en cascade pour ça, dans josm... :-) Dans l'attente d'éclaircissement où s'arrête le tag sur node et way, et où au juste commence la 'relation', je continue à l'ancienne. Gerhard --- Le 18 nov. 08 à 20:55, Denis a écrit : > > Jérôme BLUM a écrit : >> Bonsoir, >> >> Bon alors, la plupart des erreurs de boundaries en Île-de-France, >> c'est >> de moi :o) >> http://tools.geofabrik.de/osmi/? >> view=boundaries&baselayer=Mapnik&opacity=0.30&lon=2.16638&lat=48.7543 >> 1&zoom=11&overlays=coastline,boundary_relations_1,boundary_relations_ >> 2,boundary_relations_3,boundary_relations_4,boundary_relations_5,boun >> dary_ways_1,boundary_ways_2,boundary_ways_3,boundary_ways_4,boundary_ >> ways_5,boundary_ways_with_unknown_admlvl,non_simple_boundary_ways >> >> Le truc, c'est que je note les admin_level au niveau des >> relations, et >> pas au niveau des ways directement, car un way peut-être utilisé par >> plusieurs relations avec des admin_level différents. C'est le cas par >> exemple lorsqu'un way correspond à la limite d'une commune, mais >> aussi >> d'un département (voire d'une région). Les ways sont donc juste >> tagués >> boundary=administrative, le reste étant mis dans les relations. >> >> En gros, j'utilise ce qui est décrit dans cette page : >> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries >> >> Si ça vous va pas, vous savez maintenant sur qui taper ! >> >> a+ >> Jérôme > > Merci Jérôme de te dénoncer (nan je déconne, on aurait finit par te > retrouver ;-). En fait, CQFD : les objets immatériels ont besoin d'une > méthodologie pérenne : ton raisonnement tient la route. Un autre > est de > dire : on tague l'objet le plus précis le plus complètement > (normalement > la commune) et les autres objets "supra-communaux" surchargent (à la > manière java) les infos : admin_level=x, name=y, etc. > Dans un raisonnement tautologique, cela s'applique aussi au niveau > communal, mais il reste un way qui n'a plus de sens en soi à part le > fait de dire (ce que tu as fait) qu'il soit une limite administrative. > Je ne souhaite pas lancer le débat ici et maintenant, mais une des > questions est de déterminer s'il faut privilégier uniquement les > relations pour décrire les classes d'objets immatériels ou s'il n'est > pas nécessaire que la brique de base soit porteuse de suffisamment > d'informations pour elle-même. > Personnellement, je voyais la relation "commune" comme étant > l'ordonnancement des ways (dans le sens trigonométrique ?) constituant > la ban communal à partir des limites commune X/commune Y. > A l'assaut du wiki !! > > Denis > > > __
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
2008/11/19 Jérôme BLUM <[EMAIL PROTECTED]>: > Ta troisième solution me semble la meilleure, bien qu'elle ne résolve > pas le problème des noms de différentes limites assignés à un même way. > On pourrait alors proposer pour un même way un "admin_level_6:name = En principe, ce problème est résolu si on respecte la convention actuelle "left:city=", "left:departement=", "left:region=". Je ne me souviens pas ce qu'il y a à ce sujet dans le wiki qui est en rade pour l'instant mais c'est vrai que la relation a été créée justement pour résoudre ces problèmes de nom. En effet, rien ne lie le tag "left:commune" avec "admin_level=8" et le tag "left:departement" avec "admin_level=6" dans la bdd mais uniquement une hypothétique documentation sur le wiki. > ../..j'essaie de me mettre à place > d'un GPS (c'est assez étroit !) ou d'un logiciel : pour trouver la > limite d'un département, lui sera-t-il plus facile, plus rapide ../.. > de chercher tous les ways possédant le tag > "admin_level = 6" et le tag "admin_level_6:name = Pyrénées-Orientales", > ou bien de regarder tous les id des ways contenus dans une relation > "type = boundary", "boundary = administrative", "admin_level = 6" et > "name = Pyrénées-Orientales" ?. Les logiciels disposent rarement des données bruts mais convertissent souvent ces données dans un format qui filtre et organise ces données pour leur besoin propre. Si l'application a besoin de localiser les objets à l'intérieur de polygones comme les régions ou les communes, les développeurs choisiront la solution qui conviendra le mieux à leur besoin et aux capacités de la machine qui accueille le logiciel. Tout ça, c'est assez simple mais ça reste le problème des programmeurs qui ont l'habitude d'en baver. Le modèle des données OSM est volontairement simple et flexible pour les contributeurs. On laisse les trucs compliqués aux machines et aux programmeurs. > > Et puis, au final, il faut regarder vers l'avenir : de nouveaux types de > relations sortent régulièrement. Le fait de découpler certaines > informations des ways dans des relations a deux avantages qui vont > devenir de plus en plus importants : Je suis d'accord. A terme, les tags admin_level et les noms devraient sortir des ways et rester uniquement dans les relations. Mais il y a une certaine réticence à abandonner les attributs des ways parce que les gens sont assez réfractaires aux relations qui sont en général assez difficile à éditer avec les outils actuels. 2008/11/19 Denis <[EMAIL PROTECTED]>: > ... Mieux vaux des infos redondantes (en espérant > une rationalisation à bon escient, qu'une absence d'informations). Pour une fois, je ne suis pas d'accord avec Denis. Si on stocke une information dans deux endroits différents, on est sûr que tôt ou tard, il y a aura des différences. A éviter à tout prix. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Jérôme BLUM a écrit : > Tu veux dire qu'un way appartenant à une commune et à un département > serait uniquement tagué "admin_level=6" par surchargement ?! non, le way "appartenant" à la commune serait tagué admin_level=8, left:city=machin, rigth_city=bidule, comme d'hab. Le département et autres limites supérieures itou, ne serait que des relations se concentrant sur l'ensemble des membres de la relation et les attributs surchargés : admin_level, name, code, etc. > Comment peux-tu retrouver le contour complet de ta commune dans ce cas là ? Une relation pardi ! Celle qui associe l'ensemble des ways commune A/commune B en disant que c'est le ban communal de la commune A (ou B). > Les relations sont en train de prendre de l'importance dans le monde OSM > : voir par exemple la nouvelle façon de taguer les routes > internationales (finies les int_ref)... économies d'énergie -> développement durable ? Pourquoi mettre le même tag sur TOUS les constituants d'un objet ? > Les relations ont été créées en partie pour palier à l'impossibilité > technique d'appliquer plusieurs une même key à un objet, à cause du > format des attributs XML. La solution proposée pour tagguer toutes les > limites administratives avec des relations me semble justement la plus > pérenne, car elle est la plus logique et évolutive dans le temps. J'ai > donc arrêté de taguer avec des right: et des left: à tout-va. Sauf à posséder une base de données spatiale (PostGIS, dans mon cas) qui permet de traiter la question "qu'est ce qu'on a à droite|gauche de l'objet X), je ne crois pas que l'information soit traitable avec les outils classiques (analyse de fichier xml, API, etc.). Est-ce une information importante, je ne sais pas et ce n'est pas à moi d'en décider. Toutefois, si cette connaissance était liée à l'utilisation d'outils particuliers, je militerais pour son maintien comme tag, du moins tant que tout le monde ne bénéficie pas, par ailleurs, du même niveau de connaissance. Mieux vaux des infos redondantes (en espérant une rationalisation à bon escient, qu'une absence d'informations). C'est clair, c'est plus coûteux pour le contributeur et rien ne peut l'y obliger. > Tu connais le coup des 3 engrenages concomitants ? Aucun ne peut tourner > ! Cela serait pareil pour trois communes partageant un coin commun : tu > serais obligé d'avoir au moins une commune avec des ways à contre-sens > de ses autre ways... Donc l'ordonnancement dont tu parles ne peut pas > toujours fonctionner. Une bordure (edge|limite|frontière) ne peut avoir qu'un et un seul côté droit et un et un seul côté gauche. Quant aux relations caractérisant les 2 communes, rien n'empêche que leurs bordures membres soient exprimées dans des sens contraires. A moins que : 1. je me sois mal exprimé dans ma proposition initiale 2. que je n'ai rien compris à la topologie des faces, des edges et des nodes Aucune des 2 hypothèses n'est pas exclure d'emblée vu l'état de fatigue dans lequel je suis actuellement. >> A l'assaut du wiki !! >> > Je t'en prie, après toi... :o) 1:0 ;-) > Jérôme Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Ta troisième solution me semble la meilleure, bien qu'elle ne résolve pas le problème des noms de différentes limites assignés à un même way. On pourrait alors proposer pour un même way un "admin_level_6:name = Pyrénées-Orientales" et un "admin_level_8:name = Rivesaltes" par exemple, mais je trouve ça moche. De plus, j'essaie de me mettre à place d'un GPS (c'est assez étroit !) ou d'un logiciel : pour trouver la limite d'un département, lui sera-t-il plus facile, plus rapide et plus économique en mémoire de chercher tous les ways possédant le tag "admin_level = 6" et le tag "admin_level_6:name = Pyrénées-Orientales", ou bien de regarder tous les id des ways contenus dans une relation "type = boundary", "boundary = administrative", "admin_level = 6" et "name = Pyrénées-Orientales" ?. Et puis, au final, il faut regarder vers l'avenir : de nouveaux types de relations sortent régulièrement. Le fait de découpler certaines informations des ways dans des relations a deux avantages qui vont devenir de plus en plus importants : 1) Cela évitera de placer de plus en plus de tags au niveau des nodes et des ways ayant une représentation physique (routes, waterways...) 2) Par conséquent, cela permettra aux concepteurs de cartes pour GPS de "choisir" le niveau de détail de l'information à embarquer dans l'appareil : s'ils ne veulent pas inclure les limites administratives, il suffira de supprimer toutes les relations "boundary = administrative", sans avoir à modifier les tags des nodes et des ways participant à ces limites-. Jérôme Pieren a écrit : > 2008/11/19 Jérôme BLUM <[EMAIL PROTECTED]>: > > Comme souvent avec OSM, il y a plusieurs solutions: > - créer des ways qui se superposent pour chaque admin_level; mais > comme ça reste du boudary à chaque fois, ça n'aurais pas trop de sens. > Donc mauvaise idée. > - faire comme les hollandais qui ont un tag "admin_level:6=yes" et > "admin_level:8=yes". Je trouve ça pas terrible. En plus, ils gardent > aussi un "admin_level" avec une seule valeur, peut-être pour valider > leur boundary dans l'outil de geofabrik. Encore pire. > - il reste que OSM propose depuis longtemps la possibilité d'avoir une > clé avec plusieurs valeurs, séparées par un point-virgule. Ca donne > "admin_level=4;6;8". C'est simple et c'est valable pour toutes sortes > de clés. > > Pieren > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
2008/11/19 Jérôme BLUM <[EMAIL PROTECTED]>: Comme souvent avec OSM, il y a plusieurs solutions: - créer des ways qui se superposent pour chaque admin_level; mais comme ça reste du boudary à chaque fois, ça n'aurais pas trop de sens. Donc mauvaise idée. - faire comme les hollandais qui ont un tag "admin_level:6=yes" et "admin_level:8=yes". Je trouve ça pas terrible. En plus, ils gardent aussi un "admin_level" avec une seule valeur, peut-être pour valider leur boundary dans l'outil de geofabrik. Encore pire. - il reste que OSM propose depuis longtemps la possibilité d'avoir une clé avec plusieurs valeurs, séparées par un point-virgule. Ca donne "admin_level=4;6;8". C'est simple et c'est valable pour toutes sortes de clés. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
> Merci Jérôme de te dénoncer (nan je déconne, on aurait finit par te > retrouver ;-). En fait, CQFD : les objets immatériels ont besoin d'une > méthodologie pérenne : ton raisonnement tient la route. Un autre est de > dire : on tague l'objet le plus précis le plus complètement (normalement > la commune) et les autres objets "supra-communaux" surchargent (à la > manière java) les infos : admin_level=x, name=y, etc. > Tu veux dire qu'un way appartenant à une commune et à un département serait uniquement tagué "admin_level=6" par surchargement ?! Comment peux-tu retrouver le contour complet de ta commune dans ce cas là ? > Dans un raisonnement tautologique, cela s'applique aussi au niveau > communal, mais il reste un way qui n'a plus de sens en soi à part le > fait de dire (ce que tu as fait) qu'il soit une limite administrative. > > Je ne souhaite pas lancer le débat ici et maintenant, mais une des > questions est de déterminer s'il faut privilégier uniquement les > relations pour décrire les classes d'objets immatériels ou s'il n'est > pas nécessaire que la brique de base soit porteuse de suffisamment > d'informations pour elle-même. > Les relations sont en train de prendre de l'importance dans le monde OSM : voir par exemple la nouvelle façon de taguer les routes internationales (finies les int_ref)... Les relations ont été créées en partie pour palier à l'impossibilité technique d'appliquer plusieurs une même key à un objet, à cause du format des attributs XML. La solution proposée pour tagguer toutes les limites administratives avec des relations me semble justement la plus pérenne, car elle est la plus logique et évolutive dans le temps. J'ai donc arrêté de taguer avec des right: et des left: à tout-va. > Personnellement, je voyais la relation "commune" comme étant > l'ordonnancement des ways (dans le sens trigonométrique ?) constituant > la ban communal à partir des limites commune X/commune Y. > Tu connais le coup des 3 engrenages concomitants ? Aucun ne peut tourner ! Cela serait pareil pour trois communes partageant un coin commun : tu serais obligé d'avoir au moins une commune avec des ways à contre-sens de ses autre ways... Donc l'ordonnancement dont tu parles ne peut pas toujours fonctionner. > A l'assaut du wiki !! > Je t'en prie, après toi... :o) > Denis > Jérôme ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Jérôme BLUM a écrit : > Bonsoir, > > Bon alors, la plupart des erreurs de boundaries en Île-de-France, c'est > de moi :o) > http://tools.geofabrik.de/osmi/?view=boundaries&baselayer=Mapnik&opacity=0.30&lon=2.16638&lat=48.75431&zoom=11&overlays=coastline,boundary_relations_1,boundary_relations_2,boundary_relations_3,boundary_relations_4,boundary_relations_5,boundary_ways_1,boundary_ways_2,boundary_ways_3,boundary_ways_4,boundary_ways_5,boundary_ways_with_unknown_admlvl,non_simple_boundary_ways > > Le truc, c'est que je note les admin_level au niveau des relations, et > pas au niveau des ways directement, car un way peut-être utilisé par > plusieurs relations avec des admin_level différents. C'est le cas par > exemple lorsqu'un way correspond à la limite d'une commune, mais aussi > d'un département (voire d'une région). Les ways sont donc juste tagués > boundary=administrative, le reste étant mis dans les relations. > > En gros, j'utilise ce qui est décrit dans cette page : > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries > > Si ça vous va pas, vous savez maintenant sur qui taper ! > > a+ > Jérôme Merci Jérôme de te dénoncer (nan je déconne, on aurait finit par te retrouver ;-). En fait, CQFD : les objets immatériels ont besoin d'une méthodologie pérenne : ton raisonnement tient la route. Un autre est de dire : on tague l'objet le plus précis le plus complètement (normalement la commune) et les autres objets "supra-communaux" surchargent (à la manière java) les infos : admin_level=x, name=y, etc. Dans un raisonnement tautologique, cela s'applique aussi au niveau communal, mais il reste un way qui n'a plus de sens en soi à part le fait de dire (ce que tu as fait) qu'il soit une limite administrative. Je ne souhaite pas lancer le débat ici et maintenant, mais une des questions est de déterminer s'il faut privilégier uniquement les relations pour décrire les classes d'objets immatériels ou s'il n'est pas nécessaire que la brique de base soit porteuse de suffisamment d'informations pour elle-même. Personnellement, je voyais la relation "commune" comme étant l'ordonnancement des ways (dans le sens trigonométrique ?) constituant la ban communal à partir des limites commune X/commune Y. A l'assaut du wiki !! Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Bonsoir, Bon alors, la plupart des erreurs de boundaries en Île-de-France, c'est de moi :o) http://tools.geofabrik.de/osmi/?view=boundaries&baselayer=Mapnik&opacity=0.30&lon=2.16638&lat=48.75431&zoom=11&overlays=coastline,boundary_relations_1,boundary_relations_2,boundary_relations_3,boundary_relations_4,boundary_relations_5,boundary_ways_1,boundary_ways_2,boundary_ways_3,boundary_ways_4,boundary_ways_5,boundary_ways_with_unknown_admlvl,non_simple_boundary_ways Le truc, c'est que je note les admin_level au niveau des relations, et pas au niveau des ways directement, car un way peut-être utilisé par plusieurs relations avec des admin_level différents. C'est le cas par exemple lorsqu'un way correspond à la limite d'une commune, mais aussi d'un département (voire d'une région). Les ways sont donc juste tagués boundary=administrative, le reste étant mis dans les relations. En gros, j'utilise ce qui est décrit dans cette page : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries Si ça vous va pas, vous savez maintenant sur qui taper ! a+ Jérôme Denis a écrit : > Pieren a écrit : > >> Pour ceux que ça intéresse, il existe une carte en ligne depuis une >> semaine environ qui visualise les limites administratives dans OSM. >> >> http://tools.geofabrik.de/osmi/ >> (choisir "boundaries" dans "view") >> > > merci pour le lien. Bookmarké !!! > Il y a du boulot (et, probablement, une méthodologie à mettre en place) > Demain, j'ai une formation sur Openlayers. Youpi !!! > Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Pieren a écrit : > Pour ceux que ça intéresse, il existe une carte en ligne depuis une > semaine environ qui visualise les limites administratives dans OSM. > > http://tools.geofabrik.de/osmi/ > (choisir "boundaries" dans "view") merci pour le lien. Bookmarké !!! Il y a du boulot (et, probablement, une méthodologie à mettre en place) Demain, j'ai une formation sur Openlayers. Youpi !!! Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
2008/11/18 Robin Prest <[EMAIL PROTECTED]>: > Je serais intéressé de connaître la source, mais comment remonter cette > information ? Il suffit d'aller sur la carte principale d'OSM et de sélectionner le layer "data" et cliquer sur l'objet : http://www.openstreetmap.org/browse/way/27285683 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
>> Inutile de préciser que ces données sont extrêmement importantes pour le >> projet OSM car elles permettront à terme de localiser tous les objets >> jusqu'à un niveau communal, ce qui ouvre de belles perspectives pour de >> nombreuses applications à venir. Je suis surpris de constater que certaines limites communales semblent déjà exister, notamment en région parisienne, comme celle ci : layer:boundary_relations_5 id:989 rel_id:34076 name:Marcoussis admlvltxt:8 admlvl:8 label:Marcoussis (8) lastchange:2008-09-26 13:28:23 Je serais intéressé de connaître la source, mais comment remonter cette information ? Robin, curieux. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
