Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
2012/5/29 Emilie Laffray emilie.laff...@gmail.com: Je pense que la solution est d'utiliser un double niveau de lecture: - International: place=* + population=* - National: place:fr etc Je ne crois pas qu'un nouveau tag place:fr soit la bonne solution. Le tag place uniquement basé sur la population a toujours posé problème un peu partout dans le monde. C'est toute la difficulté de définir l' importance d'un endroit par rapport aux autres. Le critère de la population en est un (population=*). On pourrait aussi privilégier l'importance administrative (admin_centre - préfectures/sous-préfectures) ou même culturelle, pourquoi pas. C'est au final un choix à faire dans les styles de rendu. Pour l'instant, ceux-ci se contentent du tag place uniquement. Mais adapter sa valeur pour être plus visible sur le rendu openmapquest est évidemment une erreur qu'il faut corriger aussi vite que possible. Pour l'instant, nous avons une définition qui est celle du wiki et qu'il faut garder cohérente sur l'ensemble du territoire français. Il faut aussi ajouter le tag population lorsque c'est possible (pas évident pour les communes composées) car les chiffres qui fixent les limites entre catégories pourraient, elles, changer un jour ou l'autre (un autre fil de discussion rappelait les définitions de l'insee par exemple). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Le 5 juin 2012 11:44, Pieren pier...@gmail.com a écrit : Je ne crois pas qu'un nouveau tag place:fr soit la bonne solution. Moi non plus. Les communes ont le même statut de commune... sauf le cas des rares communes associées qui existent encore (qui ont un statut plus léger et où l'essentiel des responsabilités est pris dans un conseil intercommunal commun ou délégué à une autre commune). La plupart des communes associées ont soit décidé de fusionner complètement avec une autre commune, soit sont redevenues complètement indépendantes en faisant le partage de leurs missions dans le cadre plus actuel et plus pratique (aussi plus avantageux vis-à-vis des dotations et reversements de l'Etat) des EPCI où elles ont décidé d'adhérer pour des objectifs finalement similaires d'économie de moyens et d'échelle. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Malgré ces avantages a fort zoom, OpenMapQuest a un gros inconvénient a zoom moyen : on y voit fort peu de commune ce qui rend l'interprétation de certaines cartes très difficile pour l'utilisateur... Aujourd'hui je m'y penche un peu et je m'aperçois qua priori dans mon coin en tout cas, MapQuest n'affiche que les place=town pas les place=village (il ne semble pas tenir compte de la population)... [...] Bon je reste zen et j'essaye un feedback a openmapquest (sans trop y croire), mais bon c'est pas un bug, c'est juste un problème de rendu... Je suis d'accord avec toi, la sélection des étiquettes est le gros point noir des rendus actuels avec des tuiles complètement muettes à zoom moyen en milieu rural où tout est place=village. Le critère de population est un critère quantitatif insuffisant car les communes française sont petites et la population de la commune centre ne représente pas la population de l'agglomération et donc son importance réelle. Il y a une sorte de tabou sur l'ajout d'un critère qualitatif pour les agglomérations qui permettraient aux moteurs de rendu ou à d'autres de faire un tri sur une base autre que le seule population. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
la sélection des étiquettes est le gros point noir des rendus actuels avec des tuiles complètement muettes à zoom moyen en milieu rural où tout est place=village. Le critère de population est un critère quantitatif insuffisant Je suis d'accord car les communes française sont petites et la population de la commune centre ne représente pas la population de l'agglomération et donc son importance réelle. C'est quoi la commune centre ? Il y a une sorte de tabou sur l'ajout d'un critère qualitatif pour les agglomérations qui permettraient aux moteurs de rendu ou à d'autres de faire un tri sur une base autre que le seule population. Un tabou je ne pense pas, plus un refus sans doute, car cette solution n'est pas forcément la meilleure car elle inclurait dans le tagging une notion bien subjective d'importance. Alors qu'il existe peut être d'autre informations objectives (à définir) que l'on pourrait renseigner, qui permettrait peut-être ensuite d'avoir des rendus de meilleure qualité, ou, tout du moins, plus adaptés à ce que l'on veut en faire. Perso en tout cas, je ne suis pas contre un débat sur cette question d'importance et discuter pour savoir si le problème ne serait pas ailleurs. J'aurais tendance à penser que le tagging des noeuds place=* a tellement été fait, au fil des années, dans le but de faire un joli rendu de map...@osm.org qu'on en arrive à un point où si on touche à un paramètre de rendu de style (zzom, condition, nouvelle manière de concevoir le positionnement), le château de carte s'effondre. Mon sentiment est en partie liée à une méthode de tagging pas/peu homogène à l'échelle du globe qui amène un rendu couvrant le monde à toujours merder quelque part. ps: je n'ai pas dis que j'avais une solution -- 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] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Justement le tag capital=* permettrait de cartographier en plus de façon plus qualitative (mais basée tout de même sur un critère objectif et facilement vérifiable et stable) bon nombre de chef-lieux d'entités administratives plus petites. Parce que ce tag peut se mettre directement un nœud (comme aussi le tag place=*) dans devoir aller chercher dans quelle relation ce nœud est mentionné comme admin_centre (OpenMapQuest ne semble pas en tenir compte). En ayant les deux tags au même endroit (place=* et capital=*) au niveau du noeud central d'une ville, on a un second critère pour faire apparaître plus de choses et savoir (en cas de multiplicité de choix et d'impossibilité d'afficher tout le monde en même temps sans superposition des libellés) quelle ville il vaut mieux conserver affichée. Comme je l'ai dit, ça marche très bien en Espagne ! Aussi bien pour OpenMapquest que pour Mapnik d'ailleurs ! La France étant très similaire à l'Espagne dans on organisation administrative, on pourrait s'en inspirer car cela n'a pas nécessité en Espagne de réellement taguer pour le rendu, puisque ce qui est mis est quelquechose d'objectif et utile, facile à sélectionner et trouver pour de nombreux types de d'extractions et filtrages de données depuis la base de données (nettement plus facile qu'une requête purement géométrique, bien plus compliquée à réaliser à cause (1) du volume de données à traiter et de nombreuses ambiguïtés d'interprétation et d'oublis soit dans la base soit dans la requête, et (2) dont les résultats sont très souvent instables, et hasardeux au gré des modifications et ajouts de données successifs). On peut noter aussi que des choix de dénormalisation ont été faits déjà dans la base (qui consiste à multiplier des tags sur des niveaux de représentation différents entre les briques géométriques de base, nœuds et ways, et les relations) pour faciliter des traitements mais aussi à cause de l'instabilité des données et de leur incomplétude (qui n'est jamais garantie nulle part). On a donc différentes façons d'utiliser les données, avec des axes de recherche différents. Ajouter un petit tag capital=* sur les nœuds des communes chef-lieux ne coûterait pas grand chose : c'est simple à faire, peu volumineux, facile à vérifier, et cela renforce les possibilités de maintien de la cohérence, et facilite énormément la restauration de ce qui aurait pu être brisé par une modification ou un ajout incomplet (rappelons que la base OSM ne sera jamais complète), ou d'une modification faite par erreur quelquepart, sans avoir à fouiller dans des données pas facilement géolocalisables (les nœuds centraux de communes n'ont pas de matérialité sur le terrain, on ne sait donc pas réellement où les trouver s'ils ne sont pas associés à un élément plus large, avec un critère simple pour discriminer facilement parmi des milliers d’autres nœuds dans la même zone). Le 29 mai 2012 16:26, Vincent Calame vincent.cal...@exemole.fr a écrit : Je suis d'accord avec toi, la sélection des étiquettes est le gros point noir des rendus actuels avec des tuiles complètement muettes à zoom moyen en milieu rural où tout est place=village. Le critère de population est un critère quantitatif insuffisant car les communes française sont petites et la population de la commune centre ne représente pas la population de l'agglomération et donc son importance réelle. Il y a une sorte de tabou sur l'ajout d'un critère qualitatif pour les agglomérations qui permettraient aux moteurs de rendu ou à d'autres de faire un tri sur une base autre que le seule population. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Le mardi 29 mai 2012 16:55:23 Philippe Verdy a écrit : Justement le tag capital=* permettrait de cartographier en plus de façon plus qualitative (mais basée tout de même sur un critère objectif et facilement vérifiable et stable) bon nombre de chef-lieux d'entités administratives plus petites. Bonjour, Oui, effectivement, l'information objective du chef-lieu administratif serait pertinent pour trier les place=* à afficher. Par contre, je ne crois pas que le capital=* soit nécessaire pour les communes, puisque nous avons déjà le rôle admin_centre sur les relations administratives. Je comprends tout à fait qu'il peut apparaître plus pratique de retirer l'information sur un nœud sans avoir à prendre en compte d'autres objets de la base. Je comprends aussi que l'utilisation du tag capital ait un effet bénéfique dans d'autres contrées. Mais il apparaît évident que l'on parle là de modifier le « modèle » accepté par la communauté pour que les moteurs de rendu actuel ait un comportement désiré. Pour un moteur de rendu manipulant la base de données complète, il ne m'apparaît pas très compliqué de rendre en priorité les chefs-lieux administratifs. Je fais d'ailleurs noter au passage, que « chef-lieu » s'accorde « chefs-lieux » au pluriel. En fait, j'aurai pu faire la même erreur, mais c'est en relisant la citation que j'ai eu un doute. Donc voilà, c'est fait. Par ailleurs, quand je parle de chefs-lieux, je veux surtout parler des chefs- lieux de communes et de département. Quoiqu'il serait probablement intéressant aussi d'intégrer le niveau cantonal, je pense que ces deux niveaux permettrait de régler bon nombre de désagréments visuels. Maintenant, je ne connais pas tous les détails … doit-on modifier le script d'import des données OSM dans la base postgis pour faciliter l'accès à l'information admin_centre ? Pour mettre en priorité les nœuds portant cette information dans la feuille de style mapnik, j'imagine qu'il faille modifier les requêtes SQL des couches appropriées. Mais j'avoue ne pas y avoir regarder de plus près. Au final, je ne sais pas si mon message est pertinent, mais je tenais à donner mon avis sur la question. Et il est vrai que ce soucis de rendu est un peu ennuyeux dans les zones rurales qui sont pourtant si importantes (et si étendues). On pourrait encore parler de la sous-évaluation des territoires ruraux par les populations urbaines, mais je dois y aller, on verra une autre fois. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Bonjour à tous, C'est peut être aussi une des limites des méthodes collaboratives et mondiales. Comment en effet avoir un rendu pertinent pour des régions aussi disparates ? Je prêche pour ma paroisse, mais une solution serait (peut être) de penser à une modélisation logique des informations. Cela permettrait de réduire les problèmes d'hétérogénéité sémantiques rencontrés. Un exemple serait la base geonames dont les informations peuvent être obtenues sous une forme ontologique (RDF) : http://www.geonames.org/ Arnaud 2012/5/29 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net Le mardi 29 mai 2012 16:55:23 Philippe Verdy a écrit : Justement le tag capital=* permettrait de cartographier en plus de façon plus qualitative (mais basée tout de même sur un critère objectif et facilement vérifiable et stable) bon nombre de chef-lieux d'entités administratives plus petites. Bonjour, Oui, effectivement, l'information objective du chef-lieu administratif serait pertinent pour trier les place=* à afficher. Par contre, je ne crois pas que le capital=* soit nécessaire pour les communes, puisque nous avons déjà le rôle admin_centre sur les relations administratives. Je comprends tout à fait qu'il peut apparaître plus pratique de retirer l'information sur un nœud sans avoir à prendre en compte d'autres objets de la base. Je comprends aussi que l'utilisation du tag capital ait un effet bénéfique dans d'autres contrées. Mais il apparaît évident que l'on parle là de modifier le « modèle » accepté par la communauté pour que les moteurs de rendu actuel ait un comportement désiré. Pour un moteur de rendu manipulant la base de données complète, il ne m'apparaît pas très compliqué de rendre en priorité les chefs-lieux administratifs. Je fais d'ailleurs noter au passage, que « chef-lieu » s'accorde « chefs-lieux » au pluriel. En fait, j'aurai pu faire la même erreur, mais c'est en relisant la citation que j'ai eu un doute. Donc voilà, c'est fait. Par ailleurs, quand je parle de chefs-lieux, je veux surtout parler des chefs- lieux de communes et de département. Quoiqu'il serait probablement intéressant aussi d'intégrer le niveau cantonal, je pense que ces deux niveaux permettrait de régler bon nombre de désagréments visuels. Maintenant, je ne connais pas tous les détails … doit-on modifier le script d'import des données OSM dans la base postgis pour faciliter l'accès à l'information admin_centre ? Pour mettre en priorité les nœuds portant cette information dans la feuille de style mapnik, j'imagine qu'il faille modifier les requêtes SQL des couches appropriées. Mais j'avoue ne pas y avoir regarder de plus près. Au final, je ne sais pas si mon message est pertinent, mais je tenais à donner mon avis sur la question. Et il est vrai que ce soucis de rendu est un peu ennuyeux dans les zones rurales qui sont pourtant si importantes (et si étendues). On pourrait encore parler de la sous-évaluation des territoires ruraux par les populations urbaines, mais je dois y aller, on verra une autre fois. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Le mardi 29 mai 2012 à 17:25 +0200, Nicolas Dumoulin a écrit : Le mardi 29 mai 2012 16:55:23 Philippe Verdy a écrit : Justement le tag capital=* permettrait de cartographier en plus de façon plus qualitative (mais basée tout de même sur un critère objectif et facilement vérifiable et stable) bon nombre de chef-lieux d'entités administratives plus petites. Bonjour, Oui, effectivement, l'information objective du chef-lieu administratif serait pertinent pour trier les place=* à afficher. Par contre, je ne crois pas que le capital=* soit nécessaire pour les communes, puisque nous avons déjà le rôle admin_centre sur les relations administratives. Je comprends tout à fait qu'il peut apparaître plus pratique de retirer l'information sur un nœud sans avoir à prendre en compte d'autres objets de la base. Je comprends aussi que l'utilisation du tag capital ait un effet bénéfique dans d'autres contrées. Mais il apparaît évident que l'on parle là de modifier le « modèle » accepté par la communauté pour que les moteurs de rendu actuel ait un comportement désiré. Pour un moteur de rendu manipulant la base de données complète, il ne m'apparaît pas très compliqué de rendre en priorité les chefs-lieux administratifs. Je fais d'ailleurs noter au passage, que « chef-lieu » s'accorde « chefs-lieux » au pluriel. En fait, j'aurai pu faire la même erreur, mais c'est en relisant la citation que j'ai eu un doute. Donc voilà, c'est fait. Par ailleurs, quand je parle de chefs-lieux, je veux surtout parler des chefs- lieux de communes et de département. Quoiqu'il serait probablement intéressant aussi d'intégrer le niveau cantonal, je pense que ces deux niveaux permettrait de régler bon nombre de désagréments visuels. Maintenant, je ne connais pas tous les détails … doit-on modifier le script d'import des données OSM dans la base postgis pour faciliter l'accès à l'information admin_centre ? Pour mettre en priorité les nœuds portant cette information dans la feuille de style mapnik, j'imagine qu'il faille modifier les requêtes SQL des couches appropriées. Mais j'avoue ne pas y avoir regarder de plus près. Au final, je ne sais pas si mon message est pertinent, mais je tenais à donner mon avis sur la question. Et il est vrai que ce soucis de rendu est un peu ennuyeux dans les zones rurales qui sont pourtant si importantes (et si étendues). On pourrait encore parler de la sous-évaluation des territoires ruraux par les populations urbaines, mais je dois y aller, on verra une autre fois. OMG, la logorrhée est contagieuse ! ;o) Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
2012/5/29 Arnaud Vandecasteele arnaud@gmail.com Bonjour à tous, C'est peut être aussi une des limites des méthodes collaboratives et mondiales. Comment en effet avoir un rendu pertinent pour des régions aussi disparates ? Je prêche pour ma paroisse, mais une solution serait (peut être) de penser à une modélisation logique des informations. Cela permettrait de réduire les problèmes d'hétérogénéité sémantiques rencontrés. Un exemple serait la base geonames dont les informations peuvent être obtenues sous une forme ontologique (RDF) : http://www.geonames.org/ Arnaud Si seulement Geonames etait vraiment utile avec un vrai schema qui ait un sens :) Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Emilie, Je comprends tout à fait le sens de ta remarque et je te rejoins pleinement. Néanmoins, Geonames n'était là que pour donner un exemple d'application, pas pour servir de modèle à appliquer. Une modélisation doit être réalisée pour un objectif précis, elle n'a de sens que dans un contexte donné. C'est pourquoi Geonames peut sembler parfois un peu limité. Néanmoins, le graphe conceptuelle d'OSM est aujourd'hui complexe voir même parfois difficilement compréhensible. J'espère avoir un jour le temps de me pencher sur l'intersection potentielle entre ontologie et OpenStreetMap ! A. 2012/5/29 Emilie Laffray emilie.laff...@gmail.com 2012/5/29 Arnaud Vandecasteele arnaud@gmail.com Bonjour à tous, C'est peut être aussi une des limites des méthodes collaboratives et mondiales. Comment en effet avoir un rendu pertinent pour des régions aussi disparates ? Je prêche pour ma paroisse, mais une solution serait (peut être) de penser à une modélisation logique des informations. Cela permettrait de réduire les problèmes d'hétérogénéité sémantiques rencontrés. Un exemple serait la base geonames dont les informations peuvent être obtenues sous une forme ontologique (RDF) : http://www.geonames.org/ Arnaud Si seulement Geonames etait vraiment utile avec un vrai schema qui ait un sens :) Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Le 29 mai 2012 17:25, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mardi 29 mai 2012 16:55:23 Philippe Verdy a écrit : Justement le tag capital=* permettrait de cartographier en plus de façon plus qualitative (mais basée tout de même sur un critère objectif et facilement vérifiable et stable) bon nombre de chef-lieux d'entités administratives plus petites. Bonjour, Oui, effectivement, l'information objective du chef-lieu administratif serait pertinent pour trier les place=* à afficher. Par contre, je ne crois pas que le capital=* soit nécessaire pour les communes, puisque nous avons déjà le rôle admin_centre sur les relations administratives. C'est aussi le cas en Espagne. Pourtant on voit bien que la redondance (logique) ne nuit pas et donne un accès facile à l'information qui facilite énormément les requêtes, en réduisant considérablement le volume de données à demander au serveur et à traiter. L'effet est très positif et déjà visible dans Mapnik comme dans OpenMapQuest, qui s'en sortent nettement mieux avec cette information. Cette dénormalisation est très peu coûteuse et stable : - la règle est qu'on met en valeur de capital=* la plus petite valeur d'admin_level parmi toutes les relations dont la ville est chef-lieu ou capitale. - elle ne demande qu'un chiffre en valeur - cela permet d'éviter de rechercher et télécharger les membres de toutes les relations dont le noeud est membre, pour savoir quel rôle il a dans ces relations (ce n'est pas forcément le rôle admin_center), et savoir si ces relations sont bien de type boundary (avec boundary=administrative nécessaire, type=boundary recommandé mais pas absolument nécessaire), et pour connaître la valeur donné à admin_level=* dans cette relation. - c'est rapide à renseigner dans la base de données là où cela manque, cela ne surcharge que très peu les noeuds de villes où on le définit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
C'est quoi la commune centre ? Je voulais dire par là la commune dont le nom va être utilisé pour désigner (de manière officielle ou par habitude) l'agglomération. Je prends un exemple de par chez moi : j'ai trois communes Argenton-sur-creuse (5 177 habitants), Le Pêchereau (2 010 habitants), Saint-Marcel (1 606 habitants). Sur place, s'il n'y avait pas les panneaux, on ne verrait pas que l'on passe d'une commune à une autre. C'est Argenton-sur-Creuse qui donne son nom à l'agglomération (c'est le chef-lieu, c'est le nom de la communauté de commune, de la gare SNCF et c'est là qu'est le centre-ville commerçant). En nombre d'habitants, les trois réunis font 8 793 habitants, plus que 1 000 et on pourra mettre place=town :-) Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Le 29 mai 2012 16:50, sly (sylvain letuffe) li...@letuffe.org a écrit : la sélection des étiquettes est le gros point noir des rendus actuels avec des tuiles complètement muettes à zoom moyen en milieu rural où tout est place=village. Le critère de population est un critère quantitatif insuffisant Je suis d'accord car les communes française sont petites et la population de la commune centre ne représente pas la population de l'agglomération et donc son importance réelle. C'est quoi la commune centre ? Je pense qu'il voulait dire le village centre dans la même commune. Toutefois cette notion de village devrait prendre en compte non pas le côté urbain/agglomération, mais la classification administrative en cas de découpage de la commune. Par exemple en Belgique comme aussi en Espagne, la plupart des municipalités sont découpées en subdivisions de niveau 9 (appelées sections communales en Belgique et correspondant plus ou moins aux tracés des anciennes communes qui sont aujourd'hui réunies dans la même municipalité), voire au delà au niveau 10 (mais bien plus rarement, seulement dans les agglomérations denses et assez peuplées dans la zone sous-découpée administrativement). Au delà de capital=*, qui se base sur le découpage des boundary=admnistrative, on pourrait aussi envisager un autre tag basé sur d'autres types de frontières - par exemple les villes hôtes de tribunaux, sur la carte des frontières judiciaires : les districts judiciaires existent en Belgique et en Espagne, mais n'épousent pas parfaitement le découpage administratif; c'est aussi le cas en France, et pour ces 3 pays on pourrait avoir un nouveau type de relation boundary=judiciary,avec plusieurs niveaux selon qu'il s'agit de juridiction simples (découpage le plus fin, a priori celui des tribunaux d'instance en France) ou de juridictions d'appel (beaucoup moins nombreuses et regroupant plusieurs juridictions simples). Cela impliquerait alors un judiciary_level=* dans ces relations, contenant un seul chiffre pour le niveau de découpage de la carte judiciaire ; - au niveau du nœud de la ville, on pourrait alors voir aussi un tag de rappel (dénormalisé), tel que court=*, déterminé de façon similaire. - Le but étant là encore de fournir simplement certains critères objectifs (et non qualitatifs donc subjectifs) permettant de savoir quelle ville peut être affichée plutôt qu'une autre sur un rendu de carte (ensuite à chaque moteur de rendu de choisir lesquel de ces critères sont pertinents, puisque le seul place=* basé sur la population totale de la commune, sans tenir compte de sa surface, est très insuffisant), et sans avoir à parcourir un schéma compliqué comprenant de multiples relations à tester avec la liste complète de ses membres (une liste particulièrement longue et très coûteuse à traiter pour les niveaux administratifs les plus petits !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
2012/5/29 Arnaud Vandecasteele arnaud@gmail.com Emilie, Je comprends tout à fait le sens de ta remarque et je te rejoins pleinement. Néanmoins, Geonames n'était là que pour donner un exemple d'application, pas pour servir de modèle à appliquer. Une modélisation doit être réalisée pour un objectif précis, elle n'a de sens que dans un contexte donné. C'est pourquoi Geonames peut sembler parfois un peu limité. Néanmoins, le graphe conceptuelle d'OSM est aujourd'hui complexe voir même parfois difficilement compréhensible. J'espère avoir un jour le temps de me pencher sur l'intersection potentielle entre ontologie et OpenStreetMap ! A. Je te rejoins. Il y avait d'ailleurs recemment la meme discussion sur la mailing liste indienne ou ils veulent utiliser la norme indienne (lire gouvernementale) pour choisir ce qui est une ville, un village etc... Le probleme c'est que le schema probablement ne sera pas compatible au niveau international ce qui est dommage. Concernant la structure, je pense qu'il faut relativiser au moins pour les villes il faut relativiser. Je pense que la complexite apparait lie au tentative de conciliation de la norme internationale vis a vis d'une norme nationale. Je pense que la solution est d'utiliser un double niveau de lecture: - International: place=* + population=* - National: place:fr etc Je pense que cela permettrait un systeme plus simple au final. Maintenant, je sais que ce que tu suggeres n'est pas juste sur les villes. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Le 29 mai 2012 18:37, Vincent Calame vincent.cal...@exemole.fr a écrit : En nombre d'habitants, les trois réunis font 8 793 habitants, plus que 1 000 et on pourra mettre place=town :-) Ce critère reste subjectif car absolument pas généralisable. Les place=* en France, quand ils sont utilisés comme admin_center d'une commune, ne doivent pas compter plus (ni moins) d'habitants que la commune elle-même. Ce que tu voudrais c'est prendre en compte non pas le découpage adminsitratif, mais le découpage urbain, qui n'a rien à voir (il est totalement séparé par l'Insee,mais pris en compte partiellement pour le découpage des cantons). Peut-être vaut-il mieux alors prendre en compte le découpage cantonal pour l'instant (boundary=political, political_division=canton) et rapporter ensuite dans les relations définissant les cantons, le nœud membre défini admin_center du chef-lieu de canton. Dans ce cas on peut alors glisser en rappel, dans les propriétés de ce nœud un tag dénormalisé ajoutant political=canton. Note: plusieurs cantons géographiquement séparés se partagent un même nœud pour leur chef-lieu, qui dès lors n'est pas forcément dans la zone géographique du canton. Ce n'est pas grave et n'empêche pas de taguer le nœud commun de la commune chef-lieu de plusieurs cantons avec un unique political=canton. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Pardon corrigez partout admin_center en admin_centre. Vous avez compris de toute façon, pas la peine de me le rappeler. C'est une faute que je fais souvent dans les courriels, mais **jamais** dans les tags de la base OSM, parce que je n'ai **jamais** à le taper en entier dans JOSM où je ne tape que la première lettre a (il complète tout seul correctement parce que la valeur est déjà connue dans les autres données téléchargées). Le 29 mai 2012 18:47, Philippe Verdy verd...@wanadoo.fr a écrit : Le 29 mai 2012 18:37, Vincent Calame vincent.cal...@exemole.fr a écrit : En nombre d'habitants, les trois réunis font 8 793 habitants, plus que 1 000 et on pourra mettre place=town :-) Ce critère reste subjectif car absolument pas généralisable. Les place=* en France, quand ils sont utilisés comme admin_center d'une commune, ne doivent pas compter plus (ni moins) d'habitants que la commune elle-même. Ce que tu voudrais c'est prendre en compte non pas le découpage adminsitratif, mais le découpage urbain, qui n'a rien à voir (il est totalement séparé par l'Insee,mais pris en compte partiellement pour le découpage des cantons). Peut-être vaut-il mieux alors prendre en compte le découpage cantonal pour l'instant (boundary=political, political_division=canton) et rapporter ensuite dans les relations définissant les cantons, le nœud membre défini admin_center du chef-lieu de canton. Dans ce cas on peut alors glisser en rappel, dans les propriétés de ce nœud un tag dénormalisé ajoutant political=canton. Note: plusieurs cantons géographiquement séparés se partagent un même nœud pour leur chef-lieu, qui dès lors n'est pas forcément dans la zone géographique du canton. Ce n'est pas grave et n'empêche pas de taguer le nœud commun de la commune chef-lieu de plusieurs cantons avec un unique political=canton. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Le 29/05/2012 18:47, Philippe Verdy a écrit : Ce critère reste subjectif car absolument pas généralisable. Vive la subjectivité, vive le terrain, vive le réel. Les frontières administratives sont certes les seules frontières « objectives » dont nous disposons mais elles sont loin de représenter la réalité géographique des territoires. Plusieurs pays et non des moindres ont une capitale administrative différentes de la capitale économique. Quand on voit que sur le niveau de zoom par défaut (6) de la carte d'OpenMapQuest, pour la Côte d'Ivoire, il y a Yamoussoukro plus d'autres préfectures et pas Abdijan, on peut dire qu'il y a un problème. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Le 29 mai 2012 19:44, Vincent Calame vincent.cal...@exemole.fr a écrit : Le 29/05/2012 18:47, Philippe Verdy a écrit : Ce critère reste subjectif car absolument pas généralisable. Vive la subjectivité, vive le terrain, vive le réel. Contradiction dans la même phrase entre subjectivité et le réel ! Les frontières administratives sont certes les seules frontières « objectives » dont nous disposons Faux. Les frontières des EPCI ne sont pas administratives pourtant elles sont objectives. De même les frontières judiciaires. La carte scolaire et les académies (non administratives au sens où on l'entend pour les collectivités territoriales). De même la carte électorale (pas complètement liée aux frontières administratives, en témoignent nos cantons pour les élections aux conseils généraux, ou les circonscriptions européennes !) Avant de parler de critères subjectifs, on peut déjà cartographier ce qui est objectif et facilement vérifiable ! Et il n'y a pas que le chiffre de la population totale communale qui compte (ce qui omet aussi le paramètre de la densité de population). Si on admet les critères réellement objectifs, alors il faut cartographier le découpage urbain de l'INSEE ! Cela me semble plus prioritaire que de bidouiller localement avec les critères subjectifs avec lesquels il sera difficile de trouver un accord. Laissons les place=* tels qu'ils sont : juste en fonction de la population totale communale avec ses seuils prédéfinis. Car là au moins c'est vérifiable et on a le moyen de se mettre d'accord et de corriger (sans tenir compte de ce que font les moteurs de rendu avec). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
Bonjour, Ne pas tagger pour le rendu... C'est parfois difficile... Je tombe encore sur un cas avec OpenMapQuest, que j'utilise pas mal ces temps-ci avec mes contacts pour montrer des plans. L'interface est assez sympa (proche de ce que propose Google en terme de fonctionnalités) et le contenu est celui de OSM. Le rendu de openmapquest est différent de clui de OSM, plus lisible sur certains aspects (a mon gout) et donc assez adapté pour proposer une carte a un copain via email pour lui montrer un endroit, une adresse, etc... Malgré ces avantages a fort zoom, OpenMapQuest a un gros inconvénient a zoom moyen : on y voit fort peu de commune ce qui rend l'interprétation de certaines cartes très difficile pour l'utilisateur... Aujourd'hui je m'y penche un peu et je m'aperçois qua priori dans mon coin en tout cas, MapQuest n'affiche que les place=town pas les place=village (il ne semble pas tenir compte de la population)... J'habite Cognac (Charente) et autour de Cognac, la ville de Jarnac n'apparait pas (pourtant 4000 habitants) avec que Matha (2000) apparait... Du coup je m'aperçois que Matha est en town et Jarnac en village... Pourtant town est à priori réservés à plus de 10 000 habitants. Si je corrige ça, j'ai bien peur que la carte cité plus haut ne fasse plus apparaitre que Cognac, ça sera... vide... Bon je reste zen et j'essaye un feedback a openmapquest (sans trop y croire), mais bon c'est pas un bug, c'est juste un problème de rendu... -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest
En fait cela montre les limites du modèle uniforme basé sur la population. Cela fontionne bien sur les pays relativement plus denses que la France (Royaume-Uni, Allemagne, Belgique, Pays-Bas, Suisse) mais pas bien pour la France. D'autre part Mapquest semble avoir une base de données (alimentée je ne sais pas comment ni où) pour optimiser ses sélections de ce qu'il faut afficher pu pas à chaque niveau de zoom de son rendu. Cependant l'Espagne est à peu près dans le même cas que la France, et pourtant affiche bien plus de ville : il semble que cela est dû au fait que l'Espagne tague en plus capital=* en indiquant en valeur le numéro de niveau administratif dont la ville est capitale ou chef-lieu. Cela a pour effet d'avoir pour Mapquest un autre critère permettant d'afficher quand même une ville, même si elle n'atteint pas (ou n'atteint plus) les seuils uniformes de population. Si on l'utilisait pour la France, on pourrait donc taguer aussi capital=* pour tous les niveaux administratifs de 2 à 7 (inutile pour le niveau 8), car Mapquest ne semble pas tenir compte des membres de rôle admin_centre présents (normalement) dans les relations définissant chaque niveau administratif (et qui ne sont pas toujours des noeuds isolés mais parfois un way fermé autour de l'agglomération (quand elle est plus petite que la commune entière), ou d'un quartier, ou d'une place, ou bien parfois aussi la relation désignant toute la commune (parfois plus au Royaume-Uni et en Allemagne). Le modèle avec le tag capital=* semble résoudre le problème assez bien en Espagne alors que les statuts 'city, town, village indicatifs respectent le critère de population à seuils uniques pour tous les pays. Il permet aussi, quand plusieurs communes proches seraient candidates à l'affichage, mais pas toutes affchables simultanément à une échelle donnée, de savoir laquelle afficher (ce devrait être celle ayant la valeur capital=* la plus petite. Par exemple ce serait très utile autour de Paris pour éviter d'afficher quelques villes au hasard mais même pas les chef-lieux de départements ! Le 28 mai 2012 12:41, Pierre-Alain Dorange pdora...@mac.com a écrit : Bonjour, Ne pas tagger pour le rendu... C'est parfois difficile... Je tombe encore sur un cas avec OpenMapQuest, que j'utilise pas mal ces temps-ci avec mes contacts pour montrer des plans. L'interface est assez sympa (proche de ce que propose Google en terme de fonctionnalités) et le contenu est celui de OSM. Le rendu de openmapquest est différent de clui de OSM, plus lisible sur certains aspects (a mon gout) et donc assez adapté pour proposer une carte a un copain via email pour lui montrer un endroit, une adresse, etc... Malgré ces avantages a fort zoom, OpenMapQuest a un gros inconvénient a zoom moyen : on y voit fort peu de commune ce qui rend l'interprétation de certaines cartes très difficile pour l'utilisateur... Aujourd'hui je m'y penche un peu et je m'aperçois qua priori dans mon coin en tout cas, MapQuest n'affiche que les place=town pas les place=village (il ne semble pas tenir compte de la population)... J'habite Cognac (Charente) et autour de Cognac, la ville de Jarnac n'apparait pas (pourtant 4000 habitants) avec que Matha (2000) apparait... Du coup je m'aperçois que Matha est en town et Jarnac en village... Pourtant town est à priori réservés à plus de 10 000 habitants. Si je corrige ça, j'ai bien peur que la carte cité plus haut ne fasse plus apparaitre que Cognac, ça sera... vide... Bon je reste zen et j'essaye un feedback a openmapquest (sans trop y croire), mais bon c'est pas un bug, c'est juste un problème de rendu... -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ 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
