Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
2012/1/27 Philippe Verdy verd...@wanadoo.fr: Tes messages sont trop longs et abordent trop de sujets différents. Essaie de créer un fil de discussion par thème. On a alors alt_name pour référencer le nom officiel même si ce n'est pas celui qu'on affiche sur la carte. Pour les communes, le nom officiel est généralement aussi celui en usage. Les cas où ça diverge sont heureusement extrêmement rares (on en a cité un seul à ma connaissance sur cette liste). On peut aussi envisager le tag official_name parce que alt_name, c'est plus lorsqu'on a deux versions du nom avec une important égale (alt pour alternative). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Le 27/01/2012 02:34, Philippe Verdy a écrit : L'admin_level de la polyligne indique aussi au moteur de rendu ... trollJe tague PAS pour le rendu ; c'est pas bien de taguer pour le rendu ; on ne doit PAS taguer pour le rendu/ troll Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait ce pour quoi il a été conçu au départ ; comme je préfère cartographier que mettre la main dans le code (pour l'instant) je n'ai pas pris le temps d'aller lire la descro du schéma de la base et de ses abatis. Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? AC) pas particulièrement référence au schéma actuel de la base, je me demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre le système de catégories utilisé par le wiki :( Pendant que j'y suis : À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée boundary=administrative, vu que de toutes façons, c'est la relation boundary qui dira le admin_level ? Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Le 26 janvier 2012 14:30, Hélène PETIT h...@free.fr a écrit : Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. Il y a sûrement un équilibre à trouver entre une base avec uniquement des relations spatiales et l'ajout d'un peu de relationnel non spatial pour des objets spatialement très complexes à manipuler. Le volume de données à manipuler n'allant qu'en grandissant, ces informations non spatiales risques d'être de plus en plus utiles et nombreuses. Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait ce pour quoi il a été conçu au départ ; comme je préfère cartographier que mettre la main dans le code (pour l'instant) je n'ai pas pris le temps d'aller lire la descro du schéma de la base et de ses abatis. Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? AC) pas particulièrement référence au schéma actuel de la base, je me demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre le système de catégories utilisé par le wiki :( Pendant que j'y suis : À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? Tu veux parler d'un node avec le rôle label dans une relation d'admin_level=8 ? - à indiquer une position pour le nom de la commune sur le rendu des cartes À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée boundary=administrative, vu que de toutes façons, c'est la relation boundary qui dira le admin_level ? Je ne vois pas trop l'intérêt moi non plus. En théorie, les tags d'une relation s'appliquent à ses membres, enfin c'est comme que je vois les choses. Même le boundary=administrative est redondant avec cette approche ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
2012/1/26 Hélène PETIT h...@free.fr: À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? Le tag 'label' se retrouve dans plusieurs types de relations mais n'est pas encore exploité (à ma connaissance). L'idée, c'est pour résoudre des problèmes de rendu en forçant le placement du label (le texte name). Sinon, il arrive que ce label s'affiche dans des endroits incorrects (par exemple, lorsque la relation contient des exclaves et que le centroide se trouve à l'extérieur du multipolygone). À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée boundary=administrative, vu que de toutes façons, c'est la relation boundary qui dira le admin_level ? Pour des raisons de retro-compatibilité, je suppose. C'est vrai qu'on pourrait s'en passer mais le logiciel de rendu - par exemple - devrait scanner l'ensemble des relations avant de pouvoir déterminer l'admin_level le plus haut (et donc le style à appliquer). En revanche, comme on le sait déjà, je ne suis pas partisan de mettre TOUS les tags dans les relations, pour des raisons de facilité de lecture pour un humain comme moi. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Une réponse sur un point de détail. Un way peut *n'être qu'une* limite administrative, auquel cas un tag boundary=administrative est le bienvenue . Si d'aventure on utilise une rivière ou une chemin/piste/route comme limite , seule la relation indiquera cet état de fait. ... mais il y a (ou il y a eu) des problèmes de rendu. -- View this message in context: http://gis.19327.n5.nabble.com/Modele-surface-Modele-frontiere-Bilan-tp5430900p5432929.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
2012/1/26 PhQ pierre.que...@sfr.fr: Si d'aventure on utilise une rivière ou une chemin/piste/route comme limite , seule la relation indiquera cet état de fait. ... mais il y a (ou il y a eu) des problèmes de rendu. A mettre en perspective avec la proposition multilinestring de Sly (http://wiki.openstreetmap.org/wiki/Relation:multilinestring) Alors le tag boundary, il est mis sur la relation multilinestring ou sur la relation boundary qui contient le multilinestring ? Dans le 2e cas, il devient encore plus difficile de voir que le way est aussi une frontière. A force de multiplier les relations et les structures pyramidales, il deviendra très difficile d'interpréter les données, surtout pour les non-experts. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Pour des raisons de retro-compatibilité, je suppose. C'est vrai qu'on pourrait s'en passer mais le logiciel de rendu - par exemple - devrait scanner l'ensemble des relations avant de pouvoir déterminer l'admin_level le plus haut (et donc le style à appliquer). Sauf erreur, C'est déjà ce qui se passe pour map...@osm.org ;-) d'une manière peu élégante d'ailleurs. Ce rendu réalise un rendu du chemin de frontière pour chaque relation dont il est membre, et en plus pour ces propres tags. Ce qui donne une infame couche très ampilée de tracés et le style a été fait pour que, par exemple, admin_level=2 fasse un rendu plus gros que tout les autres pour cache la misère. Exemples : http://www.openstreetmap.org/?lat=-79.863lon=-160.7434zoom=13layers=M En revanche, comme on le sait déjà, je ne suis pas partisan de mettre TOUS les tags dans les relations, pour des raisons de facilité de lecture pour un humain comme moi. à part pour le tag source=* moi c'est l'inverse, mais le sait aussi déjà ;-) D'autant que les progrès de josm sur la gestion des relations ont été énorme ces 2 dernières années -- 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] Modèle surface Modèle frontière : Bilan
Le 26 janvier 2012 14:30, Hélène PETIT h...@free.fr a écrit : Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait ce pour quoi il a été conçu au départ ; comme je préfère cartographier que mettre la main dans le code (pour l'instant) je n'ai pas pris le temps d'aller lire la descro du schéma de la base et de ses abatis. Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? AC) pas particulièrement référence au schéma actuel de la base, je me demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre le système de catégories utilisé par le wiki :( Pendant que j'y suis : À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? Pour une commune dont la forme fait que son centroïde calculé tombe en dehors de ses frontières et le label par défaut semble indiquer le nom d'une autre commune. Regarde les boucles de la Seine dans le 92 pour comprendre... À quoi ça sert de mettre admin_level=n sur une polyligne déjà étiquetée boundary=administrative, vu que de toutes façons, c'est la relation boundary qui dira le admin_level ? Non ! L'admin_level de la polyligne peut être de niveau inférieur au niveau 8 de la relation communale. Regarde donc les communes en frontière d'arrondissement, de département, de région ou de pays: les polylignes des contours sont de niveau différents. L'admin_level de la polyligne indique aussi au moteur de rendu des tuiles comment dessiner (quel style de ligne, quelle épaisseur, quelle couleur) sur ce contour partiel. Un moteur de rendu de tuile ne charge pas nécessairement la totalité de la commune ou des communes environnantes, ni toutes les relations de niveau inférieur qui contiennent cette polyligne. Il se contente de regarder l'admin_level qu'on lui a assigné localement, et ça suffit car il ne voudra pas charger tous les noeuds et toutes les polylignes de la relation parente qui sortent de son rectangle de tracé, cela prendrait trop de temps et trop de données. Il demande au serveur les objets contenus dans un rectangle et le serveur ne lui retourne que les noeuds dans ce rectangle, les polylignes qui ont une intersection dans ce rectangle. En fait parfois il en oublie si la polyligne n'a pour seule interection qu'un seule segment de droite entre deux noeuds qui ne sont pas dans le rectangle d'intérêt, ce qui parfois aboutit à des morceaux oubliés de lignes dessinées d'une tuile à l'autre; pour régler cela, si plus tard une autre tuile est analysée contenant un noeud dont un trait sort du cadre, il marque les tuiles extérieures comme étant à revisiter plus tard en tenant compte de nœuds trouvés dans une autre tuile; de ce fait il peut aussi oublier des relations contenant des polylignes avec ces segments oubliés; je pense, sans l'affirmer, que cela marche avec des listes d'attentes marquant chaque tuile à redessiner avec les numéros de tuiles voisines contenant des noeuds de la base ou des noeuds calculés sur des rendus de lignes épaisses, mais dont les données ont été mises à jour et sont à charger depuis la base OSM en plus de celles des noeuds tombant dans la tuile à redessiner, afin d'avoir des données suffisantes pour ne rien oublier). En conséquence, les tuiles se mettent à jour avec des décalages dans le temps, en plusieurs passes successives selon la longueur des files d'attentes de tuiles à redessiner. Mais on doit encore lui mâcher le travail trait par trait, pour minimiser le nombre de ces oublis. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Le 27 janvier 2012 02:34, Philippe Verdy verd...@wanadoo.fr a écrit : Le 26 janvier 2012 14:30, Hélène PETIT h...@free.fr a écrit : Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit : Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait ce pour quoi il a été conçu au départ ; comme je préfère cartographier que mettre la main dans le code (pour l'instant) je n'ai pas pris le temps d'aller lire la descro du schéma de la base et de ses abatis. Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ? AC) pas particulièrement référence au schéma actuel de la base, je me demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre le système de catégories utilisé par le wiki :( Pendant que j'y suis : À quoi pourrait bien servir le tag label dans une relation frontière administrative de niveau 8 ? Pour une commune dont la forme fait que son centroïde calculé tombe en dehors de ses frontières et le label par défaut semble indiquer le nom d'une autre commune. Regarde les boucles de la Seine dans le 92 pour comprendre... Si on ne tague que la relation avec son nom, comme la relation n'a pas de position bien définie pour le label, celui-ci sera par défaut positionné sur le centroïde. La relation contient en général un admin_center pour positionner son centre administratif (en principe à la Mairie). Mais des communes ont des contours tels que la mairie est très excentrée; bien que ce contour soit fortement convexe, le centroïde marche bien en général pour le positionner, mais il peut y avoir une position plus adaptée pour positionner le label sans recouvrir d'autres éléments importants. Le nom présent dans la relation peut aussi ne désigner qu'une partie de la commune pour celles qui sont éclatées en plusieurs exclaves, chacune pouvant avoir un nom distinct qu'il est plus adéquat d'afficher sur la carte en tant que lieu. La relation donne le nom de la commune elle-même, pas celui de ses parties. Hors seule une de ses parties contient un centre administratif (la mairie), l'autre partie se retrouverait sans noeud membre admin_center. Il faut alors positionner un label même sans admin_center pour nommer cette partie de façon visible sur la carte. Cependant ces parties définies dans des relations séparées ne sont en principe pas ce qui définit la relation de niveau 8, et pas forcément non plus un niveau 9 (arrondissement communal) ou supérieur (quartiers, pôle de proximité). Pourtant il y a bien une frontière admnistrative définie par cette relation à laquelle on souhaite donner un nom distinctif sur la carte (en général un toponyme géographique plus qu'un lieu place).. On a donc à régler ce genre de détails localement selon l'importance qu'on donne à ces noms. Par défaut une relation communale sera affichée avec le nom de la relation affiché le long de ses bordures tracées, ou sinon positionné sur le centroïde. Si la résolution est suffisante pour afficher un label à l'intérieur, le moteur cherchera à utiliser la position de l'admin_center (cependant pas son nom car le nom pourrait être celui du centre adminitratif tel que Hôtel de Ville, qui n'est pas suffisant pour nommer la commune sur la carte. Il reste alors le label pour aussi donner le nom à afficher sur la carte (qui lui apparait dans sa forme normale sans qualificatif de désambiguation, car certaines relations éloignées les unes des autres sont distinguées en ayant des noms qualifiés, facilitant les recherches par nom... On ne voudrait pas voir par exemple Paris (Texas) sur la carte du Texas, même si sa relation s'appelle ainsi, on préfère avoir juste Paris. Le rôle label est alors utilisé à la fois pour positionner le label à afficher sur la carte, et ce qu'il faut afficher. Si un label est présent, il est préférable au nom et la position d'un admin_center, et si ce dernier n'est pas présent non plus, par défaut on utilise sur la carte dessinée le nom de la relation positionné sur le centroïde de la relation. C'est comme ça que je vois les choses. Note: l'IGN utilise des centroïdes modifiés : en général il est positionné à la position du centroïde calculée, mais si cette position tombe hors de toute zone habitée de la zone, il le modifie en la position de la mairie sur l'entrée de son bâtiment principal. Parfois il le mettra sur la place centrale (Place de la Mairie, Place de l'Hôtel de Ville, dans les communes où la Mairie consiste en un ensemble de bâtiments administratifs sans qu'on puisse déterminer réellement lequel de ces bâtiments est le principal. si la mairie officielle est en fait construite dans un hameau séparé de l'agglomération principale (ça arrive dans les communes rurales), il peut garder la position de l'ancienne mairie
[OSM-talk-fr] Modèle surface Modèle frontière : Bilan
Comme ce débat revient souvent, je propose d'en faire une page sur le wiki, qui tente de présenter objectivement avantages et inconvénients de manière résumé http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Modèle_somme_de_surface_ou_modèle_frontière Si des motivés se sentent d'ajouter des points de comparaisons, vous êtes les bienvenus. Tentons de rester objectif, et de mettre des peut-être quand ça reste une supposition plutôt que les superlatifs récemment lu du genre : C'est 1 fois plus rapide. -- 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
