Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
2012/11/9 sly (sylvain letuffe) li...@letuffe.org: (Avec JOSM, quand je dois tricotter/réparer une bordure de région ça devient de plus en plus une calamité) Ce qui devient difficile pour toi avec 6 relations, l'est pour un débutant avec 1 ou 2 relations. Encore un ptit effort et tu admetteras que les relations, c'est pas une si bonne chose que ça ;-) - flemme, soyons honnête Mais le non support par osm2pgsql qui reste l'un des outils les plus utilisés pour le rendu de carte osm est un vrai frein. Si j'étais meilleur en C, je coderais le truc, et mon avis pencherais alors en faveur du non entassement. Mais en attendant, je suis aussi d'accord avec Vincent. L'uniformité est plus importante pour que ce soit exploitable tout de suite. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Ce qui devient difficile pour toi avec 6 relations, l'est pour un débutant avec 1 ou 2 relations. Encore un ptit effort et tu admetteras que les relations, c'est pas une si bonne chose que ça ;-) Mais quelle entassement de mauvaise foi ! A mon tour : Je dirais que ce qui est dur pour un débutant, c'est de débuter, et ça, on n'y peut pas grand chose. Ensuite, j'admet bien évidement que les relations sont difficiles à utiliser (surtout en l'état actuel) et j'écoute volontiers les idées pour s'en passer. or, dans le cas qui nous occupe des relations administratives, sans relations, la solution c'est d'entasser des ways fermés. Et je doute que ça puisse être défendable donc : relations. La question étant donc : comment, en utilisant les relations, trouver un modèle plus simple que celui actuel, dont les données seraient utilisables et l'édition simplifiée. De même qu'entasser des ways est trop difficile à gérer, entasser des relations, bien que plus simple, me semble encore insuffisant. D'où ma proposition de longue date des relations de relations permettant de limiter l'entassement à 1. (avec d'autres défauts que l'on connait, mais qui me semblent moins nombreux que les défauts du modèle actuel) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Bonsoir, Le 09/11/2012 23:54, sly (sylvain letuffe) a écrit : Le vendredi 09 novembre 2012 22:22:13, Vincent de Chateau-Thierry a écrit : J'ai un bémol Je m'y attendais ;-) Voyou ! :-) Fais, les 2 se valent à l'heure actuelle à mon avis. Chose faite, pour chacun des DOMs : http://www.openstreetmap.org/browse/changeset/13825643 (Guadeloupe) http://www.openstreetmap.org/browse/changeset/13825698 (Martinique) http://www.openstreetmap.org/browse/changeset/13825728 (Guyane) http://www.openstreetmap.org/browse/changeset/13825760 (Réunion) J'ai choisi mon option pour 2 raisons : - Car sans utiliser cette méthode, on ne pousse pas les outils à l'évolution et donc les contributeurs continuerons à entasser toujours plus des relations les unes sur les autres. L'arrivée des cantons, des epci, des réserves naturelles, des diocèses,... ajoutant encore à cette complexité. (Avec JOSM, quand je dois tricotter/réparer une bordure de région ça devient de plus en plus une calamité) - flemme, soyons honnête Mais le non support par osm2pgsql qui reste l'un des outils les plus utilisés pour le rendu de carte osm est un vrai frein. Si j'étais meilleur en C, je coderais le truc, et mon avis pencherais alors en faveur du non entassement. L'absence de support par osm2pgsql est aussi un argument pour moi, même si ça ne me plaît pas : ça revient à contraindre la donnée pour l'adapter aux outils, bref, c'est un mauvais argument, opportunistico-pragmatique en fonction du paysage logiciel actuel. Le 10/11/2012 12:41, Pieren a écrit : 2012/11/9 sly (sylvain letuffe) li...@letuffe.org: (Avec JOSM, quand je dois tricotter/réparer une bordure de région ça devient de plus en plus une calamité) Ce qui devient difficile pour toi avec 6 relations, l'est pour un débutant avec 1 ou 2 relations. Encore un ptit effort et tu admetteras que les relations, c'est pas une si bonne chose que ça ;-) Une bonne chose je ne sais pas, mais la moins pire pour l'instant, non ? Avec l'API actuelle, la limite de 2000 points par way nous oblige à passer aux relations pour décrire les polygones de + de 2000 points, ce qui se rencontre à coup sûr aux niveau des arrondissements et au dessus. Donc en l'état, qu'on aime ou pas, je ne vois pas trop d'alternative. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le samedi 10 novembre 2012 22:25:43, Vincent de Chateau-Thierry a écrit : Chose faite, pour chacun des DOMs : (...) L'absence de support par osm2pgsql est aussi un argument pour moi (...) Donc en l'état, qu'on aime ou pas, je ne vois pas trop d'alternative. vincent Pensée sage et pragmatique à laquelle j'adhère. Demain étant un autre jour, nous pourrons toujours changer si les choses évolues. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
On peut aussi taguer à la fois: - pour ce que les outils actuels (malgré leurs défauts) savent faire et interpréter, tout en sachant que ce n'est pas encore l'idéal et que cela devient de plus en plus lourd ou ambigu à interpréter. - ET en même temps commencer à taguer pour ce que les outils devraient savoir gérer et interpréter de façon moins ambiguë (ces nouveaux tags apportant une sémantique plus précise tout en étant à la fois moins lourde à gérer. Tant que les tags sont différents on s'en sort. Mais au moins cela permet déjà d'avancer sur ce que devraient être les outils à l'avenir et qui vont progressivement apprendre à reconnaitre les nouvelles sémantiques. Sinon on tombe systématiquement dans le piège de l'œuf et de la poule (lequel vient en premier ?). À vouloir toujours ménager à la fois la chèvre et le chou on reste sur la mauvaise rive, on ne franchit pas le fleuve, et on regarde les autres avancer plus facilement que nous et plus vite parce qu'ils ont inventé l'enclos pour garder la chèvre, et engagé un pilote pour faire traverser le chou sur la barque (autrement dit, séparation des tâches par un travail séparable en équipes) tandis que pendant ce temps là les fermiers sont déjà avec les clients pour leur vendre et la chèvre, et le chou, et qu'ils ont déjà commandé un nouveau bateau plus grand pour transporter le tout, tout en ayant prévu la construction d'un pont qui réconciliera tout le monde et rendra obsolète l'ancienne barque tout en permettant d'étendre les élevages et les cultures, et diversifier les espèces produites. ;- Il faut aussi savoir regarder à côté de nous ce qui marche bien et vite et ne pas rester sur nos seules solutions franco-centrées, voire aussi OSM-centrées (là je parle des autres systèmes SIG, et aussi des systèmes cartographiques concurrents (commerciaux comme Google, ou pas comme les projets forks d'OSM): il me parait clair qu'on évoluera à terme non pas vers une base unique contenant tout, mais vers une galaxie de bases de données permettant des recherches croisées et générant leurs propres couches éditables plus simplement et séparément, et plus facile aussi à vérifier et à conserver dans un étant homogène. Avec une galaxie de bases, les expérimentations comme les migrations vers un schéma plus pratique et plus précis seront aussi bien plus faciles, et il sera plus facile aux nouveaux contributeurs de s'intéresser à une partie des données sans casser le reste qu'il ne maîtrisent pas. Dès lors on ne parlera plus d'imports massifs, les intégrations demanderont moins de travail (au lieu de fusionner les objets, on les rapprochera plus ou moins par des références relationelles interbases seulement là où ces rapprochements seront pertinents. Et dans de nombreux cas, nombre d'attributs actuellement ajoutés directement aux objets géographiques n'auront même plus besoin d'y être puisque pour la plupart ils seront remplacés par des identifiants de référence qu'on pourra lier à des bases de données relationnelles externes (par exemple pour les différentes traductions, ou la tonomymie officielle, ou des données statistiques): les objets actuels de type relation pourront encore servir, mais à terme des primitives plus orientées OpenGIS standard feront partie de l'arsenal (sans nécessiter de coûteuses et constantes réparations de géométries ni de conversions complexes à cause des différentes interprétations). OSM en est encore à son enfance et manque de maturité, il y a plein de choses qui vont évoluer dans le schéma et peut être qu'à terme on travaillera directement dans un schéma OpenGIS (sans conversion intermédiaire pour les réimports vers pgSQL), même s'il restera éventuellement encore un serveur proposant une vue (dynamique) permettant de voir le schéma actuel pendant un certain temps pour conserver les outils actuels utilisables. Même nos éditeurs vont faire vite pâle figure à côté de ce qui se fait dans le monde SIG où des normes sont développées (et qui constituent déjà des volumes de données bien plus importants que la totalité d'OSM actuel). Même en France, les outils développés par SANDRE ou l'IGN ou par d'autres bases européennes, sont Open Source (tout en étant beaucoup moins lourds à utiliser et plus productifs et efficaces qu'OSM). Aussi je regrette qu'on en reste encore à ne vouloir pas faire évoluer nos schémas vers une logique d'avantage orientée avec les normes. OSM souffre de gros défauts un peu partout à cause du fait qu'il est trop permissif (juste pour permettre une évolutivité qui en pratique n'a pas lieu car on se noie d'abord dans les problèmes d'évolutivité et de cohérence des données : on ne profite pas du fait qu'au départ c'est une base de données, et donc qu'elle doit pouvoir effectuer des contrôles d'intégrité, des ordonnancements et clasements automatiques, et de la possibilité d'être autoorganisée avec des structures de données mieux adaptées et moins redondantes: le modèle des relations qui ne contiennent QUE des chemins simples
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le 8 novembre 2012 13:51, Vincent de Chateau-Thierry v...@laposte.net a écrit : Ça semble un débat sans fin, entre : - oui vu qu'il y a pour la Guadeloupe un code ISO 3166-1 (GP) Un code ISO 3166-1 n'a aucune signification politique ou administrative de classification d'un territoire comme un pays. C''est juste un code de classification géographique. Ce n'est même pas un indicateur de l'indépendance ou l'autonomie reliative du territoire, car sinon il en manquerait plein d'autres ! La raison d'être de ces codes est leur besoin dans des bases de données de classification pour divers usages pratiques (zones detélécommunications, zones postales, zones de gestion des droits de propriété intellectuelle, zones de transport...). - non vu que ça n'est qu'une région de la France En revanche les frontières maritimes territoriales ne sont PAS des lignes naturelles, ces chemins devraient être tagués comme des frontières internationales (admin_level=2) tout autour de la Guadeloupe, car ce sont des frontières de la France (et non pas parce que ce sont des frontières de la Guadeloupe qui n'est encore qu'un département ou une région), afin de préciser la nature de cette frontière virtuelle (ISO 3166-1 n'a rien à voir là dedans). Sans aucun doûte admin_level est défini dans OSM pour reproduire la classification admonistrative officielle de chaque pays. Mais encore une fois la ligne de côte n'est pas la frontière adminsitrative, on ne l'utilise que pour approximer la ligne de base dans la définition des relations (qui, elles, **doivent** respecter la définition des admin_level). Bref je redemande que les admin_level soient TOUS les chemins des lignes de côtes (chemins de type natural=coastline) qui en elles mêmes ne sont QUE des lignes naturelles physiques et pas des frontières. - la construction pyramidale est nouvelle pour les départements, doit elle être conservée telle que, ou passer au mode chemin pour être en cohérence avec les autres départements ? Ce sont des éléments utiles pour la construction. Si les chemins sont complets, stables et vérifiés ils pourraient être vus comme des doublons mais ils ne codent en fait pas la même chose: pour OSM il est encore nécessaire, afin de représenter une surface, que les polygones soient fermés soit dans un seul chemin, soit en groupant les chemins dans une relation fermés. Et reste en suspend le détail local du découpage des deux grandes îles par rivière salée C'est une frontière naturelle et géographique. On peut toujours définir une relation (non administrative) permettant de fermer et nommer le contenu de chaque partie. Il manque de toute façon la définition en tant que région (admin_level=4). Tout à fait car il y a des attributs différents à noter, et les deux noveaux existent bel et bien un noveau administratif (que ces deux entités soient gérées par une collectivité territoriale unique ou non). Noter alors que Saint-Martin et Saint-Barthélemy sont à considérer chacun comme une région administrative (admin_level=4), un département (6), un arrondissement (7) et une commune (8) même si là encore il n'y a qu'une seule collectivité cumulant les compétences: autant de relations, mais là encore pas besoin d'admin_level sur les chemins de leur côte (d'ailleurs pour Saint-Martin on a des frontières internationales terrestres (niveau 2 sur le chemin, mais nulle part dans ses relations, sauf pour celle concernant la France elle-même). Je verrais bien : - conservation de l'admin_level=2 pour la relation http://www.openstreetmap.org/browse/relation/1047206 Moi pas du tout ! Cette relation ne définit pas un pays. C'est la relation de la France qu'il faut étendre pour inclure ses outre-mer. - modification de sa liste de membres pour passer à un mode chemin, au moins pour la cohérence avec le reste des découpages admin de France pour l'instant, Pas forcément un problème, et pas urgent du tout, cela ne gène absolument pas et n'est pas une erreur en tant que tel (je pense même que c'est à étendre à toute la France opur solidifier le modèle, le stabiliser, et le rendre plus facile à maintenir, comme cela a été fait dans les autres pays). - duplication du résultat sous forme d'une relation admin_level=4 pour définir la région oui - duplication du résultat sous forme d'une relation admin_level=6 pour définir le département oui mais une relation existe déjà, ce n'est pas une duplication - suppression des actuelles relations admin_level=6 Basse Terre et Grande Terre qui s'appuient plutôt sur des limites d'arrondissement. Pour Basse Terre voir plus haut, pour Grande Terre c'est concurrent de l'arrondissement Pointe-à-Pitre, contrairement à ce que je disais hier soir. Je penche juste pour la suppression des attributs boundary=adminsitrative et admin_level=* afin de garder uniquement le ou les champs de noms. On pourrait aussi en faire une relation de type natural=island (la rivière salée crée bien deux îles au plan physique). Tout ça
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le 8 novembre 2012 14:44, sly (sylvain letuffe) li...@letuffe.org a écrit : On jeudi 8 novembre 2012, Vincent de Chateau-Thierry wrote: De : Pieren boundary=administrative + admin_level=2 définit les limites d'un pays. On ne peut avoir qu'une relation admin_level=2 pour la France (une 2e à la rigueur pour les versions coastlines/12miles marins). Le code ISO 3166-1 ne désigne pas que des pays autonomes ! En gros : +1 avec tout ce qu'a dit pieren (être d'accord sur des relations, ça doit pas arriver plus d'une fois par siècle) Pas d'accord ici : s'il y a deux relations pour la France, une est de nature adminsitrative et inclut les eaux territoriales et c'est alors la seule à avoir boundary=adminitrative et admin_level=2. La seconde relation limitée aux terres doit être différente et être taguée boundary=land_area même si on y met admi_level=2 aussi pour le rapprochement logique de dépendance de la relation land_area en tant que restriction de la relation boundary=administrative. Mais concernant ISO 3166-1, ne pas en tenir compte pour le découpage administratif ou territorial et politique, même si on infique un attribut ISO 3166-1 sur certaines relations administratives (de niveaux admin_level différents selon les endroits du monde, et qui peuvent aussi se recouvrir, car le code ISO 3166-1 FR est à mettre sur la relation de la France entière et qui inclue tous les outre-mers : métropole + les 5 DOM + les COM + la NC ; noter qu'il n'y a plus aucun territoire d'outre-mer légalement en France, hormi la NC et les 5 DOM, tout les autres sont maintenant des COM, y compris Clipperton ou les TAAF, même si ces derniers sont gérés par l'Etat, mais il y a un des régularitions législatives pour fixer les attributions, autorités, compétences judiciaires, comptes publics, et la désignation là encore d'une assemblée décisionnaire compétente : l'Assemblée nationale, et d'un conseil consultatif aussi, en plus du système exécutif constitué par le gouvernement du premier ministre qui a délégué au ministre de l'outre-mer...). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le vendredi 09 novembre 2012 16:38:54, Philippe Verdy a écrit : - non vu que ça n'est qu'une région de la France En revanche les frontières maritimes territoriales ne sont PAS des lignes naturelles ha bon ? , ces chemins devraient être tagués comme des frontières internationales (admin_level=2) tout autour de la Guadeloupe, car ce sont des frontières de la France On pourrait aussi ne pas les tagguer du tout, cette information étant portée par la relation. Bref je redemande que les admin_level soient TOUS les chemins des lignes de côtes (chemins de type natural=coastline) qui en elles mêmes ne sont QUE des lignes naturelles physiques et pas des frontières. En général, au mieux, on propose, ça permet d'éviter de croire que osm c'est toi. C'est juste une question de forme, mais ça à l'avantage d'ouvrir le dialogue et permettre aux lecteurs qui te lisent (encore) d'en déduire le statu d'une telle proposition. Passé ce détail de forme tu demandes quoi exactement ? Je ne comprends pas ce que tu veux dire : admin_level c'est un tag, c'est pas un chemin. Ta phrase est-elle : Tous les chemins portant un admin_level devraient tous être un chemin représentant la côte J'imagine que non, sinon on est mal barrée car la côte n'arrive pas encore jusqu'en Savoie. A la devinette, j'imagine que tu proposes donc que tous les chemins portant natural=coastline ne soient pas porteur d'un tag admin_level ni boundary ? ça me va, et ça tombe bien, c'est indiqué ici : http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Les_limites_administratives_c.C3.B4ti.C3.A8res - la construction pyramidale est nouvelle pour les départements, doit elle être conservée telle que, ou passer au mode chemin pour être en cohérence avec les autres départements ? Ce sont des éléments utiles pour la construction. Si les chemins sont complets, stables et vérifiés ils pourraient être vus comme des doublons mais ils ne codent en fait pas la même chose: pour OSM il est encore nécessaire, afin de représenter une surface, que les polygones soient fermés soit dans un seul chemin, soit en groupant les chemins dans une relation fermés. Je n'ai pas compris, on ne devait pas parler de la même chose. C'est une frontière naturelle et géographique. On peut toujours définir une relation (non administrative) permettant de fermer et nommer le contenu de chaque partie. C'est ce que j'ai fais, comme précisé dans mon mail d'avant. Pas forcément un problème, et pas urgent du tout, cela ne gène absolument pas et n'est pas une erreur en tant que tel (je pense même que c'est à étendre à toute la France opur solidifier le modèle, le stabiliser, et le rendre plus facile à maintenir, comme cela a été fait dans les autres pays). Le débat ayant déjà eu lieu (et avec toi d'ailleurs) je propose de maintenir pour l'instant le statu quo en ce qui concerne tous les admin_level2 Pour des raisons de manque d'outils le gérant et de cohérence avec l'existant. Je viens de répondre à ce bémol, et entre place=island ou natural=island, je ne sais lequel convient le mieux pour moi c'est équivalent, on trouve l'un ou l'autre dans la base. Je vais rester sur place=island puisque le wiki ne parle pas de natural=island et je n'ai pas l'impression que c'est beaucoup utilisé le natural=island -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le vendredi 09 novembre 2012 16:50:55, Philippe Verdy a écrit : Pas d'accord ici : s'il y a deux relations pour la France, une est de nature adminsitrative et inclut les eaux territoriales et c'est alors la seule à avoir boundary=adminitrative et admin_level=2. La seconde relation limitée aux terres doit être différente et être taguée boundary=land_area même si on y met admi_level=2 aussi pour le rapprochement logique de dépendance de la relation land_area en tant que restriction de la relation boundary=administrative. Pour l'instant, c'est l'approche inverse qui a été mise en place : boundary=adminitrative et admin_level=2 pour les deux. maritime=yes pour celle qui contient la ligne au delà des eaux territoriales histoire de la distinguer. ça se rapproche de cette proposition : http://wiki.openstreetmap.org/wiki/Proposed_features/Maritime_borders mais en contenant les frontières terrestre pour former un polygone fermé. Pour la frontière contenant la base line, ça peut se discuter, mais notre manière de tagguer diffère de cette proposition et apporte, selon moi plusieurs avantages. Tout ça pouvant se discuter si on le veut. Je suis prèt à accepter de changer les tags (si mal ranger, pas cohérent avec les autres pays), mais pas le contenu de ces deux relations. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Bonsoir, Le 08/11/2012 14:22, sly (sylvain letuffe) a écrit : On jeudi 8 novembre 2012, Vincent de Chateau-Thierry wrote: Il manque de toute façon la définition en tant que région (admin_level=4). Oui, je vais l'ajouter. Je verrais bien : - conservation de l'admin_level=2 pour la relation http://www.openstreetmap.org/browse/relation/1047206 Moi plutôt pas. (voir ci-dessus) - modification de sa liste de membres pour passer à un mode chemin, au moins pour la cohérence avec le reste des découpages admin de France pour l'instant, ça me va aussi, on reste dans une logique uniformité et pragmatisme bien que je continue à dire qu'il faudrait continuer à avancer vers un support des 2 approches, mais on va pas tout changer tout de suite. - duplication du résultat sous forme d'une relation admin_level=4 pour définir la région Pour les autres DOM, j'ai opté pour une solution hybride pour l'instant : Je créer la relation région, qui contient comme membre la relation département. D'abord parce que c'est plus simple, ensuite parce que comme aucun de ces départements n'a de frontières avec un autre département, ça ne rend pas le multipolygon invalide au sens osm (rien à voir avec les subareas dans la logique) Reste donc que pour exploiter cette construction, il faut disposer d'outil à gestion pyramidale. - duplication du résultat sous forme d'une relation admin_level=6 pour définir le département Je vois l'idée je pense, mais je trouve que ça allourdit pas mal si on entasse des relations dont les membres (ways) sont identiques. Je vois ce soir que tu as pu appliquer tout ce qu'on disait hier, merci pour ça. J'ai un bémol (que j'aurais dû formuler hier, désolé), c'est sur la définition du niveau région des DOMs (admin_level=4). Tu parles ci-dessus, à juste titre, d'uniformité et de pragmatisme, mais du coup c'est contredit, pour moi, par le choix de définir les régions comme relations ayant comme membre une relation (plutôt que des chemins). Ça n'est pas uniforme (les régions de métropole sont définies par des chemins), et pas pragmatique vu que les outils courants (au moins osm2pgsql) ne savent pas s'en sortir avec cette modélisation en relations imbriquées. Résultat, on ne peut pas simplement disposer d'un export de la couche complète des régions admin françaises, car les régions des DOMs passent à la trappe. Quant à l'économie que ça représente, je la trouve anecdotique vu la taille des 4 territoires. Et pour ce qui est de contours admins dont les membres sont identiques, ben, on a déjà Paris dans ce cas : admin_level 6/7/8 à lui tout seul :-) En résumé : je souhaiterais pour l'instant convertir les relations région des DOMs en mode chemin. Si pas d'avis contraires à Chambéry ou ailleurs :-) je m'en occuperai ce week-end. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le vendredi 09 novembre 2012 22:22:13, Vincent de Chateau-Thierry a écrit : J'ai un bémol Je m'y attendais ;-) Fais, les 2 se valent à l'heure actuelle à mon avis. J'ai choisi mon option pour 2 raisons : - Car sans utiliser cette méthode, on ne pousse pas les outils à l'évolution et donc les contributeurs continuerons à entasser toujours plus des relations les unes sur les autres. L'arrivée des cantons, des epci, des réserves naturelles, des diocèses,... ajoutant encore à cette complexité. (Avec JOSM, quand je dois tricotter/réparer une bordure de région ça devient de plus en plus une calamité) - flemme, soyons honnête Mais le non support par osm2pgsql qui reste l'un des outils les plus utilisés pour le rendu de carte osm est un vrai frein. Si j'étais meilleur en C, je coderais le truc, et mon avis pencherais alors en faveur du non entassement. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le 9 novembre 2012 17:29, sly (sylvain letuffe) li...@letuffe.org a écrit : Le vendredi 09 novembre 2012 16:38:54, Philippe Verdy a écrit : - non vu que ça n'est qu'une région de la France En revanche les frontières maritimes territoriales ne sont PAS des lignes naturelles ha bon ? Je parle bien des frontières en mer (par exemple celle des 12 miles) : il n'y a rien pour les marquer naturellement. Je maintiens donc ce que j'ai écrit. , ces chemins devraient être tagués comme des frontières internationales (admin_level=2) tout autour de la Guadeloupe, car ce sont des frontières de la France On pourrait aussi ne pas les tagguer du tout, cette information étant portée par la relation. Peut-être, mais quand la relation n'est pas chargée, on ne voit pas ce qui la définit comme étant une ligne adminsitrative, on voit juste un trait anonyme sans aucun attribut. Je pense quand même que chaque trait devrait avoir un rôle défini caractérisant sa nature: ligne naturelle ou construite ou virtuelle. Surtout si on ne voit rien sur une photo. Bref je redemande que les admin_level soient TOUS les chemins des lignes de côtes (chemins de type natural=coastline) qui en elles mêmes ne sont QUE des lignes naturelles physiques et pas des frontières. En général, au mieux, on propose, ça permet d'éviter de croire que osm c'est toi. C'est juste une question de forme, mais ça à l'avantage d'ouvrir le dialogue et permettre aux lecteurs qui te lisent (encore) d'en déduire le statu d'une telle proposition. Je ne fais pas que le proposer car c'est justifié : les lignes naturelles de côtes ne sont pas les frontières administratives. Nulle part en France. Même quand c'est un axe de route ou de rivière/fleuve, on ne voit pas que ce sont des frontières. Les vraies frontières ont une autre définition délimitée par soit un bornage (qu'il faut chercher sur le terrain car impossible de le voir sur une orthophoto, soit par les plans et relevés cadastraux, soit dans des textes légaux et traités internationaux avec des coordonnées, parfois seulement matérialiées (en mer) uniquement par le croisement de deux lignes de repérages depuis des points très éloignés. Dans des cas assez rares on trouvera des bouées ou balises flottantes ancrées ou des mats scellés au fond (mais qui sont souvent abîmés et pas remplacés). Passé ce détail de forme tu demandes quoi exactement ? Je ne comprends pas ce que tu veux dire : admin_level c'est un tag, c'est pas un chemin. Que les chemins (ways) de type natural=coastline ne portent peut-même aucun attribut boundary=* ni admin_level=*. Ta phrase est-elle : Tous les chemins portant un admin_level devraient tous être un chemin représentant la côte J'imagine que non, sinon on est mal barrée car la côte n'arrive pas encore jusqu'en Savoie. A la devinette, j'imagine que tu proposes donc que tous les chemins portant natural=coastline ne soient pas porteur d'un tag admin_level ni boundary ? ça me va, et ça tombe bien, c'est indiqué ici : http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Les_limites_administratives_c.C3.B4ti.C3.A8res C'est pourtant bien ce que j'ai écrit, je ne vois pas comment tu peux l'interpréter autrement. - la construction pyramidale est nouvelle pour les départements, doit elle être conservée telle que, ou passer au mode chemin pour être en cohérence avec les autres départements ? Ce sont des éléments utiles pour la construction. Si les chemins sont complets, stables et vérifiés ils pourraient être vus comme des doublons mais ils ne codent en fait pas la même chose: pour OSM il est encore nécessaire, afin de représenter une surface, que les polygones soient fermés soit dans un seul chemin, soit en groupant les chemins dans une relation fermés. Je n'ai pas compris, on ne devait pas parler de la même chose. Peut-être mais de toute façon ce n'est pas une erreur même si on ne parle pas de la même chose. C'est une frontière naturelle et géographique. On peut toujours définir une relation (non administrative) permettant de fermer et nommer le contenu de chaque partie. C'est ce que j'ai fais, comme précisé dans mon mail d'avant. Pas forcément un problème, et pas urgent du tout, cela ne gène absolument pas et n'est pas une erreur en tant que tel (je pense même que c'est à étendre à toute la France opur solidifier le modèle, le stabiliser, et le rendre plus facile à maintenir, comme cela a été fait dans les autres pays). Le débat ayant déjà eu lieu (et avec toi d'ailleurs) je propose de maintenir pour l'instant le statu quo en ce qui concerne tous les admin_level2 Pour des raisons de manque d'outils le gérant et de cohérence avec l'existant. P... parce que vous pensez que ça ne sert à rien alors qu'on passe un temps considérable à essayer de réparer les trous. Dans les pays où les deux modèles sont utilisés simultanément, il y a beaucoup moins d'erreurs de frontières,
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le 9 novembre 2012 23:54, sly (sylvain letuffe) li...@letuffe.org a écrit : Le vendredi 09 novembre 2012 22:22:13, Vincent de Chateau-Thierry a écrit : J'ai un bémol Je m'y attendais ;-) Fais, les 2 se valent à l'heure actuelle à mon avis. J'ai choisi mon option pour 2 raisons : - Car sans utiliser cette méthode, on ne pousse pas les outils à l'évolution et donc les contributeurs continuerons à entasser toujours plus des relations les unes sur les autres. L'arrivée des cantons, des epci, des réserves naturelles, des diocèses,... ajoutant encore à cette complexité. (Avec JOSM, quand je dois tricotter/réparer une bordure de région ça devient de plus en plus une calamité) Eh oui, toi aussi tu l'admets que détricoter un ensemble de relations qui n'ont QUE des définitions de frontières devient un enfer. Alors que les relations sont faites nativement pour supporter un modèles relationnel très facile à comprendre et faire sans erreurs. Ce qui faciltite énormément les reconstructions de frontières manquantes (ce qui arrivent en fait extrêmement rarement car l'inclusion des liens relationnels (parent/enfant) assure que les relations parentes seront bien toutes chargées dans tous les éditeurs avant même qu'on puisse modifier une relation enfant. Le modèle n'est pas compliqué, il marche très bien. Regarde la république thèque : il est parfait et complet. Regarde la Slovénie (même chose). Regarde l'Allemagne (pas complet mais ils ont compris l'intérêt et arrivent à gérer bien plus d'entités et de niveaux adminsitratifs que nous. Ils gèrent aussi les zones postales. Et aussi les différents statuts de villes (et les nombreux cas de niveaux administratifs fusionnés dans la même collectivité, ce qui commence à se développer aussi en France et va certainement s'accélérer). Regarde l'Espagne il est presque complet sauf pour les comarques dont il faut encore en ajouter pas mal, mais avec des exceptions à gérer sur des inclusions partielles de comarques à cheval sur plusieurs provinces (ce qui existe aussi en France pour les cantons qui ont de telles exceptions dans un certain nombre de communes découpées en plusieurs fractions dont certaines fractions recouvrent aussi des communes voisines : on est amené à définir, pour une représentation relationnelle un niveai intermétiaire formant une fraction administrative et non une entité administrative complète, avec un type différent de bounday=administrative pour cette fraction.. Cela pourrait aussi être fait pour les fractions cantonales en France. Egalement pour les EPCI pour définir des listes d'EPCI par département (donc avec des fractions d'EPCI. Egalement pour les zones judiciaires ou de police. Avec la réforme administrative en cours en Espagne, ils arrivent à suivre ! même auand chaque communauté autonome développe son propre découpage administratif indépendant du découpage national en provinces et communes (qui devient de moins en moins pertinent, les comarques n'avaient plus d'utilité dans l'ancien système adminsitratif espagnol, depuis les communautés les font revivre et leur donne une identité propre un peu à la façon de nos communautés de communes, quitte à les redécouper, comme si on passait de nos cantons actuels aux EPCI sans changer les noms en France). On a plein d'autres relations à mettre dans la base pour la France, mais là je trouve qu'on s'enlise en ne regardant pas ce qui marche bien mieux ailleurs (on n'arrive plus à suivre la plus petite évolution et on se bloque pour rien en n'osant pas ajouter d'autres données pourtant pertinentes en cartographie. Continuer sur une logique purement géométrique (que ce soit avec celle des ways polygones fermés uniquement ou avec des relations qui n'ont que des chemins membres) n'est plus viable du tout: il conduit à beaucoup trop d'erreurs et une complexité gigantesque pour réparer. Je milite donc pour des polygones représentés par des relations, avec SANS AUCUN chemin superposé (même partiellement) et aussi pour ajouter aux relations non seulement leurs limites externes avec des listes de chemins, complexes à éditer, mais aussi avec des membres relationnels qui aident à consolider le tout et sont très stables, et bien plus faciles à comprendre pour les contributeurs et à vérifier ensuite. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
On mercredi 7 novembre 2012, Vincent de Chateau-Thierry wrote: Ça a en effet tout l'air d'être la limite de l'arrondissement de Basse-Terre : OSM : http://www.openstreetmap.org/browse/relation/531250 Oui, mais cette relation porte un admin_level=6 Sauf... que l'admin_level 7 existe par ailleurs, plus récent (je plaide coupable) : http://www.openstreetmap.org/browse/relation/1694553 en incluant Les Saintes, au sud. Donc plutôt du ménage à faire que du changement de valeur de tag. En gros, on vire http://www.openstreetmap.org/browse/relation/531250 c'est ça ? Concernant donc la relation guadeloupe : http://www.openstreetmap.org/browse/relation/1047206 se pose 2 questions : - l'admin_level=2 est-il pertinent ? - la construction pyramidale est nouvelle pour les départements, doit elle être conservée telle que, ou passer au mode chemin pour être en cohérence avec les autres départements ? Et reste en suspend le détail local du découpage des deux grandes îles par rivière salée -- 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
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Bonjour, De : sly (sylvain letuffe) A : Discussions sur OSM en français Sauf... que l'admin_level 7 existe par ailleurs, plus récent (je plaide coupable) : http://www.openstreetmap.org/browse/relation/1694553 en incluant Les Saintes, au sud. Donc plutôt du ménage à faire que du changement de valeur de tag. En gros, on vire http://www.openstreetmap.org/browse/relation/531250 c'est ça ? Pour moi oui c'est bien ça. Concernant donc la relation guadeloupe : http://www.openstreetmap.org/browse/relation/1047206 se pose 2 questions : - l'admin_level=2 est-il pertinent ? Ça semble un débat sans fin, entre : - oui vu qu'il y a pour la Guadeloupe un code ISO 3166-1 (GP) - non vu que ça n'est qu'une région de la France - la construction pyramidale est nouvelle pour les départements, doit elle être conservée telle que, ou passer au mode chemin pour être en cohérence avec les autres départements ? Et reste en suspend le détail local du découpage des deux grandes îles par rivière salée Il manque de toute façon la définition en tant que région (admin_level=4). Je verrais bien : - conservation de l'admin_level=2 pour la relation http://www.openstreetmap.org/browse/relation/1047206 - modification de sa liste de membres pour passer à un mode chemin, au moins pour la cohérence avec le reste des découpages admin de France pour l'instant, - duplication du résultat sous forme d'une relation admin_level=4 pour définir la région - duplication du résultat sous forme d'une relation admin_level=6 pour définir le département - suppression des actuelles relations admin_level=6 Basse Terre et Grande Terre qui s'appuient plutôt sur des limites d'arrondissement. Pour Basse Terre voir plus haut, pour Grande Terre c'est concurrent de l'arrondissement Pointe-à-Pitre, contrairement à ce que je disais hier soir. Tout ça devrait mettre l'organisation en conformité avec celle des autres départements, mais il y a (au moins) un bémol : par quels tags désigner les emprises Basse Terre et Grande Terre pour refléter que ces noms sont utilisés dans la vie courante ? Est-ce que pour chacune, une surface s'appuyant sur les ways natural=coastline, et tagguée avec place=island serait pertinente ? 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] Limites communales dans les DOM - Construction de la limite de guadeloupe
2012/11/8 Vincent de Chateau-Thierry v...@laposte.net: Ça semble un débat sans fin, entre : - oui vu qu'il y a pour la Guadeloupe un code ISO 3166-1 (GP) - non vu que ça n'est qu'une région de la France boundary=administrative + admin_level=2 définit les limites d'un pays. On ne peut avoir qu'une relation admin_level=2 pour la France (une 2e à la rigueur pour les versions coastlines/12miles marins). Le code ISO 3166-1 ne désigne pas que des pays autonomes ! Je verrais bien : - conservation de l'admin_level=2 pour la relation http://www.openstreetmap.org/browse/relation/1047206 - modification de sa liste de membres pour passer à un mode chemin, au moins pour la cohérence avec le reste des découpages admin de France pour l'instant, - duplication du résultat sous forme d'une relation admin_level=4 pour définir la région Plutôt : - conversion de la relation actuelle 1047206 de admin_level=2 en admin_level=4 (avec une note pour expliquer la présence du code ISO à ce niveau) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
De : Pieren 2012/11/8 Vincent de Chateau-Thierry : Ça semble un débat sans fin, entre : - oui vu qu'il y a pour la Guadeloupe un code ISO 3166-1 (GP) - non vu que ça n'est qu'une région de la France boundary=administrative + admin_level=2 définit les limites d'un pays. On ne peut avoir qu'une relation admin_level=2 pour la France (une 2e à la rigueur pour les versions coastlines/12miles marins). Le code ISO 3166-1 ne désigne pas que des pays autonomes ! Ça m'irait bien mais c'est bien moins clair sur le wiki (d'où ma non proposition) : http://wiki.openstreetmap.org/wiki/Admin_level#National Pour ce qui est des relations de niveau 2, on a tout ça aujourd'hui : http://www.openstreetmap.org/browse/relation/2202162 (France, eaux territoriales) http://www.openstreetmap.org/browse/relation/2202120 (DOM, eaux territoriales) http://www.openstreetmap.org/browse/relation/79981 (France metro, eaux territoriales) http://www.openstreetmap.org/browse/relation/1362232 (France metro pyramidale) http://www.openstreetmap.org/browse/relation/1403916 (France metro mode chemin) et j'en passe. Autant dire un sujet (un marronnier ?) qui mérite une discussion en propre. Je verrais bien : - conservation de l'admin_level=2 pour la relation http://www.openstreetmap.org/browse/relation/1047206 - modification de sa liste de membres pour passer à un mode chemin, au moins pour la cohérence avec le reste des découpages admin de France pour l'instant, - duplication du résultat sous forme d'une relation admin_level=4 pour définir la région Plutôt : - conversion de la relation actuelle 1047206 de admin_level=2 en admin_level=4 (avec une note pour expliquer la présence du code ISO à ce niveau) D'accord là-dessus mais sans oublier le niveau 6 à définir, et surtout le sujet des noms d'usage sur Basse Terre et Grande Terre. 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] Limites communales dans les DOM - Construction de la limite de guadeloupe
On jeudi 8 novembre 2012, Vincent de Chateau-Thierry wrote: En gros, on vire http://www.openstreetmap.org/browse/relation/531250 c'est ça ? Pour moi oui c'est bien ça. On est 2, ça fait donc une majorité, je m'en occupe. - l'admin_level=2 est-il pertinent ? Ça semble un débat sans fin, entre : - oui vu qu'il y a pour la Guadeloupe un code ISO 3166-1 (GP) J'ignorais ça, bonne info. Toutefois, si j'en crois wikipedia : http://en.wikipedia.org/wiki/ISO_3166-1 defines codes for the names of countries, dependent territories, and special areas of geographical interest. Ce qui ne veut pas dire uniquement pays, or le admin_level=2 est plus classiquement utilisé pour les pays dans osm, et en France, c'est comme ça qu'on fonctionne (à moins qu'une exception ait été formulée pour les DOM/TOM). On peut toutefois noter a juste titre, que les bordures du département guadeloupe forment aussi les frontières de la france, mais ça, on peut le gérer avec des relations, la relation de la guadeloupe étant membre de la relation France qui elle est bien admin_level=2 Il manque de toute façon la définition en tant que région (admin_level=4). Oui, je vais l'ajouter. Je verrais bien : - conservation de l'admin_level=2 pour la relation http://www.openstreetmap.org/browse/relation/1047206 Moi plutôt pas. (voir ci-dessus) - modification de sa liste de membres pour passer à un mode chemin, au moins pour la cohérence avec le reste des découpages admin de France pour l'instant, ça me va aussi, on reste dans une logique uniformité et pragmatisme bien que je continue à dire qu'il faudrait continuer à avancer vers un support des 2 approches, mais on va pas tout changer tout de suite. - duplication du résultat sous forme d'une relation admin_level=4 pour définir la région Pour les autres DOM, j'ai opté pour une solution hybride pour l'instant : Je créer la relation région, qui contient comme membre la relation département. D'abord parce que c'est plus simple, ensuite parce que comme aucun de ces départements n'a de frontières avec un autre département, ça ne rend pas le multipolygon invalide au sens osm (rien à voir avec les subareas dans la logique) Reste donc que pour exploiter cette construction, il faut disposer d'outil à gestion pyramidale. - duplication du résultat sous forme d'une relation admin_level=6 pour définir le département Je vois l'idée je pense, mais je trouve que ça allourdit pas mal si on entasse des relations dont les membres (ways) sont identiques. - suppression des actuelles relations admin_level=6 Basse Terre et Grande Terre qui s'appuient plutôt sur des limites d'arrondissement. Pour Basse Terre voir plus haut, pour Grande Terre c'est concurrent de l'arrondissement Pointe-à-Pitre, contrairement à ce que je disais hier soir. Tu veux dire que grande terre ne correspond à aucune entité administrative ? Tout ça devrait mettre l'organisation en conformité avec celle des autres départements, mais il y a (au moins) un bémol : par quels tags désigner les emprises Basse Terre et Grande Terre pour refléter que ces noms sont utilisés dans la vie courante ? Est-ce que pour chacune, une surface s'appuyant sur les ways natural=coastline, et tagguée avec place=island serait pertinente ? Je ne connais pas assez la guadeloupe, mais s'il est confirmé que les appelations Basse Terre et Grande Terre ne correspondent à aucune entité administrative, alors oui, ta proposition d'utiliser place=island fait sens (pour moi), d'ailleurs, elle fait sens qu'il y est ou pas d'entité admin. -- 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
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
On jeudi 8 novembre 2012, Vincent de Chateau-Thierry wrote: De : Pieren boundary=administrative + admin_level=2 définit les limites d'un pays. On ne peut avoir qu'une relation admin_level=2 pour la France (une 2e à la rigueur pour les versions coastlines/12miles marins). Le code ISO 3166-1 ne désigne pas que des pays autonomes ! En gros : +1 avec tout ce qu'a dit pieren (être d'accord sur des relations, ça doit pas arriver plus d'une fois par siècle) Ça m'irait bien mais c'est bien moins clair sur le wiki (d'où ma non proposition) : http://wiki.openstreetmap.org/wiki/Admin_level#National Ok, c'est pas hyper clair, ça dit : For the sake of clarity, only political entities listed on the ISO 3166 standard are to be considered countries. Toutefois, on peut le comprendre comme une implication, c'est à dire que pour être admin_level=2 dans osm, une entité doit être listée par ISO 3166. Toutefois, l'inverse n'est pas nécessairement vrai, toute entité listée n'a pas forcément besoin d'être admin_level=2. Pour ce qui est des relations de niveau 2, on a tout ça aujourd'hui : (...) et j'en passe. Autant dire un sujet (un marronnier ?) qui mérite une discussion en propre. Oui, je suis dispo pour faire tomber les marrons ;-) Ton et j'en passe : je ne suis pas sûr qu'il y est tant que ça de relation admin_level=2, mais je suis d'accord avec pieren il ne devrait y en avoir que 1. Ou en fait 2 (si on veut gérer les frontières maritimes, mais ce n'est pas tout à fait un admin_level=2 puisque c'est un admin_level = 2 + border_type = territorial ) Ensuite, pour la france métropole, il y a là un peu de pragmatisme, j'entends souvent des reproches sur la manière atypique de construire les frontières de la France et nombre de ceux qui veulent les frontières ne sont parfois même pas au courant des détails du passé colonial de la france, (style la france dispose de points dans l'hémisphère sud). Leur fournir alors une version light de la France connue d'eux apaise un peu. Mais je suis favorable au retrait des admin_level=2 là ou l'élément (en général relation) n'ait qu'un élément de géométrie et ne représente pas, à lui seul, une entité administrative. (style une ile en bordure atlantique, ou même la corse) D'accord là-dessus mais sans oublier le niveau 6 à définir, et surtout le sujet des noms d'usage sur Basse Terre et Grande Terre. Je vais faire, en cohérence avec ce que j'ai fais ailleurs, ça n'est pas idéalement comme vous l'avez proposé entre admin_level 4 et/ou 6 mais ça répond à un pragmatisme (à nouveau) et ça sera très simple à changer quand on n'impliquera pas trop de perturbations -- 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
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
De : sly (sylvain letuffe) On jeudi 8 novembre 2012, Vincent de Chateau-Thierry wrote: De : Pieren boundary=administrative + admin_level=2 définit les limites d'un pays. On ne peut avoir qu'une relation admin_level=2 pour la France (une 2e à la rigueur pour les versions coastlines/12miles marins). Le code ISO 3166-1 ne désigne pas que des pays autonomes ! En gros : +1 avec tout ce qu'a dit pieren (être d'accord sur des relations, ça doit pas arriver plus d'une fois par siècle) Ça m'irait bien mais c'est bien moins clair sur le wiki (d'où ma non proposition) : http://wiki.openstreetmap.org/wiki/Admin_level#National Ok, c'est pas hyper clair, ça dit : For the sake of clarity, only political entities listed on the ISO 3166 standard are to be considered countries. Toutefois, on peut le comprendre comme une implication, c'est à dire que pour être admin_level=2 dans osm, une entité doit être listée par ISO 3166. Toutefois, l'inverse n'est pas nécessairement vrai, toute entité listée n'a pas forcément besoin d'être admin_level=2. En effet, en relisant le wiki, c'est bien dans le sens que tu indiques. Du coup admin_level=4 pour tout le monde. Pour ce qui est des relations de niveau 2, on a tout ça aujourd'hui : (...) et j'en passe. Autant dire un sujet (un marronnier ?) qui mérite une discussion en propre. Oui, je suis dispo pour faire tomber les marrons ;-) Ton et j'en passe : je ne suis pas sûr qu'il y est tant que ça de relation admin_level=2, mais je suis d'accord avec pieren il ne devrait y en avoir que 1. Ou en fait 2 (si on veut gérer les frontières maritimes, mais ce n'est pas tout à fait un admin_level=2 puisque c'est un admin_level = 2 + border_type = territorial ) Ensuite, pour la france métropole, il y a là un peu de pragmatisme, j'entends souvent des reproches sur la manière atypique de construire les frontières de la France et nombre de ceux qui veulent les frontières ne sont parfois même pas au courant des détails du passé colonial de la france, (style la france dispose de points dans l'hémisphère sud). Leur fournir alors une version light de la France connue d'eux apaise un peu. Mais je suis favorable au retrait des admin_level=2 là ou l'élément (en général relation) n'ait qu'un élément de géométrie et ne représente pas, à lui seul, une entité administrative. (style une ile en bordure atlantique, ou même la corse) En gros, il faudrait, sans forcément s'appuyer sur les limites admins, des définitions géométriques bêtement techniques pour dire : quand je veux la France métropolitaine, je prends ce qui tombe dans le polygone de la relation xxx, quand je veux la Corse, c'est telle autre emprise, etc. On n'est sûrement pas très loin d'un besoin, hors base OSM, couvert chez Geofabrik par les polygones d'extraction. Je vais faire, en cohérence avec ce que j'ai fais ailleurs, ça n'est pas idéalement comme vous l'avez proposé entre admin_level 4 et/ou 6 mais ça répond à un pragmatisme (à nouveau) et ça sera très simple à changer quand on n'impliquera pas trop de perturbations Pour moi ça marche. 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] Limites communales dans les DOM - Construction de la limite de guadeloupe
On jeudi 8 novembre 2012, Vincent de Chateau-Thierry wrote: En gros, il faudrait, sans forcément s'appuyer sur les limites admins, des définitions géométriques bêtement techniques pour dire : quand je veux la France métropolitaine, je prends ce qui tombe dans le polygone de la relation xxx, quand je veux la Corse, c'est telle autre emprise, etc. On n'est sûrement pas très loin d'un besoin, hors base OSM, couvert chez Geofabrik par les polygones d'extraction. En tout cas, moi, ce n'est pas de ça que je parle. L'aspect technique je veux télécharger une zone est une autre problématique que chacun peut gérer comme il l'entend. Géofabrik fait ce qu'il veut, les autres aussi. (Qu'ils s'appuyent ou pas sur les relations dans OSM) Je réfléchis donc plus dans un sens un objet = une entité administrative (ou une entité portant un nom) et ce n'est qu'un bénéfice collatéral si ça peut être utiliser plus facilement pour des raisons techniques. Bénéfice que j'ai bien à l'esprit, mais qui n'est pas uniquement la raison de faire. -- 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
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le mercredi 07 novembre 2012 17:13:08, Pierre Touzard a écrit : Il manque deux départements : la Guadeloupe (971) et Mayotte (976). La guadeloupe y est, mais par contre le département n'est pas correct (correct au sens de l'outil dont il est question), mais mon contact avec Ratzilla, auteur de la construction de la limite n'a pas obtenu de réponse. Ci-après, je recopie mon message si quelqu'un veut bien en causer avec moi (Mayotte n'est pas au cadastre donc mon outil ne peut pas traiter) Salut n'importe qui, Je te contact en tant qu'unique contributeur sur cette relation : http://www.openstreetmap.org/browse/relation/531250 (Basse-Terre en guadeloupe) J'étais en train de réfléchir (en partie avec quelques rares motivés de la liste) à la manière de tagguer les frontières des DOM. Tu as choisi de mettre admin_level=6 sur la relation basse-Terre, mais je me demande si c'est bien adapté, car (enfin, sauf erreur je ne connais pas bien la guadeloupe) Basse-Terre n'est pas un département. Mon avis est que : http://www.openstreetmap.org/browse/relation/1047206 devrait être admin_level=6 Et que Basse-Terre devrait être soit rien, soit 7 ? 8 ? si Basse-Terre est en effet une limite administrative de ce niveau. Il y a aussi la question grande/basse terre pour lesquelles je suis un peu perdu : Ce sont deux entité administratives ? je vois qu'il y a des îles sur rivière salée, et je ne sais pas si elles appartiennent à l'une ou l'autre des entité admin et si on devrait pas les inclure dans l'une ou l'autre plutôt que de faire un trait un peu au milieu ( vue : http://osm.org/go/YzUOyPMo ) Que penses-tu de tout ça ? as-tu un peu de temps pour en causer sur la liste ? -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Tu ne sais pas que Ratzilla$ = Gaël ? Romain Le 7 novembre 2012 18:58, sly (sylvain letuffe) li...@letuffe.org a écrit : Le mercredi 07 novembre 2012 17:13:08, Pierre Touzard a écrit : Il manque deux départements : la Guadeloupe (971) et Mayotte (976). La guadeloupe y est, mais par contre le département n'est pas correct (correct au sens de l'outil dont il est question), mais mon contact avec Ratzilla, auteur de la construction de la limite n'a pas obtenu de réponse. Ci-après, je recopie mon message si quelqu'un veut bien en causer avec moi (Mayotte n'est pas au cadastre donc mon outil ne peut pas traiter) Salut n'importe qui, Je te contact en tant qu'unique contributeur sur cette relation : http://www.openstreetmap.org/browse/relation/531250 (Basse-Terre en guadeloupe) J'étais en train de réfléchir (en partie avec quelques rares motivés de la liste) à la manière de tagguer les frontières des DOM. Tu as choisi de mettre admin_level=6 sur la relation basse-Terre, mais je me demande si c'est bien adapté, car (enfin, sauf erreur je ne connais pas bien la guadeloupe) Basse-Terre n'est pas un département. Mon avis est que : http://www.openstreetmap.org/browse/relation/1047206 devrait être admin_level=6 Et que Basse-Terre devrait être soit rien, soit 7 ? 8 ? si Basse-Terre est en effet une limite administrative de ce niveau. Il y a aussi la question grande/basse terre pour lesquelles je suis un peu perdu : Ce sont deux entité administratives ? je vois qu'il y a des îles sur rivière salée, et je ne sais pas si elles appartiennent à l'une ou l'autre des entité admin et si on devrait pas les inclure dans l'une ou l'autre plutôt que de faire un trait un peu au milieu ( vue : http://osm.org/go/YzUOyPMo ) Que penses-tu de tout ça ? as-tu un peu de temps pour en causer sur la liste ? -- sly (sylvain letuffe) ___ 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 communales dans les DOM - Construction de la limite de guadeloupe
Le mercredi 07 novembre 2012 19:02:37, Romain MEHUT a écrit : Tu ne sais pas que Ratzilla$ = Gaël ? si -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le mercredi 07 novembre 2012 19:19:47, sly (sylvain letuffe) a écrit : Le mercredi 07 novembre 2012 19:02:37, Romain MEHUT a écrit : Tu ne sais pas que Ratzilla$ = Gaël ? si Et je voulais ajouter : il y a quelque chose que j'ignore à son propos ? -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le 7 novembre 2012 19:28, sly (sylvain letuffe) li...@letuffe.org a écrit : Le mercredi 07 novembre 2012 19:19:47, sly (sylvain letuffe) a écrit : Le mercredi 07 novembre 2012 19:02:37, Romain MEHUT a écrit : Tu ne sais pas que Ratzilla$ = Gaël ? si Et je voulais ajouter : il y a quelque chose que j'ignore à son propos ? Je trouvais bizarre que tu commences par *Salut n'importe qui*. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
A ce sujet, c'est simple de corriger admin_level=7 sur la relation. En revanche on ne met AUCUN admin_level sur les chemins membres définissant la ligne de côte On ne le fait que sur les lignes administratives virtuelles (maritimes ou terrestres). La ligne de côte n'est PAS la limite administrative légale, juste une limite de son extension territoriale **terrestre**, autrement dit ce qu'on définirait sur une relation type=land_area. A défaut d'avoir une définition exacte des frontières d'extension administrative d'une collectivité territoriale (selon les niveaux ce peut être légalement la ligne de base pour laquelle on manque sincèrement de sources pour la définir correctement, même souvent dans le cadastre), on a seulement utilisé la ligne de côte. Puisqu'on ne peut pas distinguer les deux surfaces (administratives et terrestres), on n'a défini qu'une seule relation (de type=boundary) pour la plupart des collectivités. Seuls les ways membres tracés virtuellement au travers des terres (parfois attachés à l'axe d'une route ou l'axe central d'un cours d'eau, ou à travers une petite baie ou estuaire sur moins de 100 mètres) sont munis d'un attribut admin_level=* correspondant à la plus petite valeur dparmi les admin_level=* des relations qui l'utilisent. Si jamais on a une définition exacte de la ligne de base, on changera la relation frontalière (de type=boundary, avec boundary=administrative ou sinon boundary=political) pour suivre ces chemins de frontière (qui alors porteront un attribut admin_level=* ou sinon political_division=*), mais on gardera une seconde relation (de type=land_area) dont les ways membres seront réduits pour suivre la ligne de côte actuelle (et qui là encore ne contiendront pas non plus admin_level). Supprimez donc les attributs admin_level=* de TOUS les ways qui définissent les lignes de côtes (natural=coastline) françaises, ils sont ABSOLUMENT TOUS faux. C'est même le cas pour la plupart des lignes de côtes européennes et de bon nombre d'autres pays. Les attributs admin_level=* ou political_division=* des relations de type=boundary sont suffisants et seuls utiles dans ce cas. Et une carte qui serait rendue ne devrait afficher aucun trait superposé de frontière sur ces lignes de côtes, mais devrait se contenter de n'afficher que le trait de la ligne naturelle. MÊME si la carte affiche (comme dans le rendu Mapnik utilisé par le site OSM) le long de ce trait un libellé correspondant au nom du/des relation(s) qui utilisent ce trait, la même carte ne devrait ajouter aucun pointillé de frontière administrative (ou politique) par dessus. Le 7 novembre 2012 18:58, sly (sylvain letuffe) li...@letuffe.org a écrit : Le mercredi 07 novembre 2012 17:13:08, Pierre Touzard a écrit : Il manque deux départements : la Guadeloupe (971) et Mayotte (976). La guadeloupe y est, mais par contre le département n'est pas correct (correct au sens de l'outil dont il est question), mais mon contact avec Ratzilla, auteur de la construction de la limite n'a pas obtenu de réponse. Ci-après, je recopie mon message si quelqu'un veut bien en causer avec moi (Mayotte n'est pas au cadastre donc mon outil ne peut pas traiter) Salut n'importe qui, Je te contact en tant qu'unique contributeur sur cette relation : http://www.openstreetmap.org/browse/relation/531250 (Basse-Terre en guadeloupe) J'étais en train de réfléchir (en partie avec quelques rares motivés de la liste) à la manière de tagguer les frontières des DOM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le mercredi 07 novembre 2012 19:33:44, Romain MEHUT a écrit : Je trouvais bizarre que tu commences par *Salut n'importe qui*. ;-) !!! Tu crois vraiment que je me permettrait d'aborder quelqu'un, en privé par un salut n'importe qui ?? Non, pas de panique Le message que je lui ais envoyé commençait par : titre : Salut président ! (Odeurs des îles et frontières de guadeloupe) Message : Salut Gaël, (...) Le n'importe qui, c'était la redaction ajouté avant de l'envoyer sur cette liste, pour interpeler n'importe qui qui voudrait en causer avec moi -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe
Le 07/11/2012 19:42, Philippe Verdy a écrit : A ce sujet, c'est simple de corriger admin_level=7 sur la relation. Ça a en effet tout l'air d'être la limite de l'arrondissement de Basse-Terre : OSM : http://www.openstreetmap.org/browse/relation/531250 INSEE COG : http://insee.fr/fr/methodes/nomenclatures/cog/carte_canarr.asp?codearr=9711 Sauf... que l'admin_level 7 existe par ailleurs, plus récent (je plaide coupable) : http://www.openstreetmap.org/browse/relation/1694553 en incluant Les Saintes, au sud. Donc plutôt du ménage à faire que du changement de valeur de tag. Pas de doublon en revanche sur l'autre arrondissement : http://www.openstreetmap.org/browse/relation/1047199 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
