Re: [OSM-talk-fr] Soucis sur Nominatim
Il y a peut être un truc étrange avec deux way Bourgogne - Franche Comté qui viennent polluer la liste administrative des détails de France: http://nominatim.openstreetmap.org/details.php?place_id=98156803 Ces deux way sont les polygones des enclaves signalées par Pierre et étant des chemins fermés avec les tags admin_level et autre, Nominatim semble se mélanger les crayons. J'ai retiré les tags, pour que seules les relations s'appuyant dessus soient prises en compte par Nominatim et de plus cela ne devrait rien changer aux rendus Mapnik et autre. Voir: http://www.openstreetmap.org/browse/changeset/14069909 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
C'est ce que tu crois, le rendu est bien différent pour ces exclaves, il disparait même à certains niveaux de zoom là où la frontière de région apparaît encore. J'appelle cette modif taguer pour le rendu (Nominatim) au lieu de signaler l'anomalie à Nominatim (qui en a bien d'autres dans ses heuristiques hasardeuses). Car ta modif consiste à ne mettre plus aucun attribut sur les ways fermés faisant partie d'une ou plusieurs relations et qui servent à coder des exclaves : cela marche bien pour les landuse=* ou natural=* mais pas encore pour les boundary (qui sont de plus différenciés par types et par niveau) : on ne les trouve plus par une requête sur les ways, uniquement par une requête sur les relations. Pire, des nœuds situés dans une exclave sont maintenant considérés comme faisant partie de la surface de la relation englobante (c'est une autre anomalie aussi dans Nominatim qui ne sait pas se débrouiller correctement avec les surfaces bien décrites, et parfois invente des règles de résolution encore plus floues pour interpréter de façon grossière des géométries défaillantes, comme on l'a vu il y a quelques mois encore pour Rennes en Loire-Atlantique et Pays de la Loire au lieu de l'Ille-et-Vilaine et la Bretagne, ou pour l'Ille-et-Vilaine classée en Pays de la Loire). Nominatim a toujours été assez mauvais dans ses heuristiques (acceptables quand la géométrie est défaillante, mais dans certaines limites qui étaient très largement dépassées) et ce n'est pas nouveau. Mais là il l'est aussi dans les cas où aucune heuristique n'est nécessaire avec une géométrie correcte, tout bonnement car ses imports de géométrie convertis en OpenGIS (avec sa propre version de l'outil de conversion OSM vers PostgreSQL) ne sont pas corrects (moins bons en tout cas que les mêmes conversions faites pour Mapnik ou d'autres moteurs de rendus). Bref Nominatim est seul à se tromper, et on corrige en modifiant le comportement des autres moteurs ? Le 28 novembre 2012 09:23, Christian Quest cqu...@openstreetmap.fr a écrit : Il y a peut être un truc étrange avec deux way Bourgogne - Franche Comté qui viennent polluer la liste administrative des détails de France: http://nominatim.openstreetmap.org/details.php?place_id=98156803 Ces deux way sont les polygones des enclaves signalées par Pierre et étant des chemins fermés avec les tags admin_level et autre, Nominatim semble se mélanger les crayons. J'ai retiré les tags, pour que seules les relations s'appuyant dessus soient prises en compte par Nominatim et de plus cela ne devrait rien changer aux rendus Mapnik et autre. Voir: http://www.openstreetmap.org/browse/changeset/14069909 ___ 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] Soucis sur Nominatim
Bon... la bonne nouvelle c'est que Nominatim se met à jour très très vite, ce qui facilite les corrections ! La mauvaise, c'est que ça coinçait toujours... la Côte d'Or est en Champagne-Ardenne et la Nièvre est un niveau trop haut... Le noeud label de Champagne Ardenne avait plein de tags du genre place=state des names en veux-tu en voilà, et un admin_level=4... du coup, ça mettait sûrement la pagaille et la Champagne-Ardenne était liée à ce noeud et pas à la relation ! Des enclaves entre Nièvre et Côté d'Or avaient aussi leurs way surtagguées alors qu'elles font partie de multiples relations. Après nettoyage... la Côte d'Or est retournée en Bourgogne :-) J'espère que ça va être bon aussi pour la Nièvre... -- 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] Soucis sur Nominatim
Tagguer un way fermé d'une enclave (je parle de celle de Beauvernois entre Bourgogne et Franche-Comté signalée par Pierre) en boundary=administrative + admin_level=4 + name=région1-région2 est pour moi une erreur car ce polygone fermé avec ces attributs décrit clairement une nouvelle région car comment le distinguer d'une région tagguée de la même façon ? Si ces enclaves sont mal rendues par Mapnik (ce qui ne semble d'ailleurs pas être le cas après avoir joué du /dirty), c'est du côté de Mapnik qu'il faut faire des corrections et pas tagguer pour contourner les bugs de Mapnik. Nominatim a certe des défauts lui aussi, mais ces défauts n'apparaissent que lorsqu'on fait des mélanges entre différents modèles de description. Remettre tout sur un même modèle cohérent permet à Nominatim de s'y retrouver mais aussi à tout les outils qui réutiliseront les données. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Les ways surtagués le sont depuis longtemps et partout avec boundary=administrative et le plus petit admin_level=* parmi les relations dont ils sont membres. Cela n'a jamais posé ce genre de problème et cela aide encore pas mal d'outils qui ne savent pas lire les relations parentes et se contentent des noeuds et ways (ils ne travaillent pas au niveau surface, juste sur le filaire). En aucun cas cela n'a jamais posé la moindre ambiguïté d'interprétation concernant les surfaces car cela a toujours signifié le type de séparation entre les relations qu'on *peut* (sans être obligé de le faire) chercher de chacun des deux côtés. Il n'y a que sur les lignes de côtes qu'on ne met plus ces attributs car ce ne sont pas des limites administratives en tant que telles, même si des relations les réutilisent à défaut d'autre chose pour approcher au mieux la ligne de base administrative difficile à placer (sachant aussi que la ligne de côte est aussi difficile à placer exactement, les deux lignes se confondent pour l'instant dans leurs limites de précision). En revanche pour les landuse=* ou natural=*, les attributs du chemin et des relations ont des effets néfastes quand ils existent des deux côtés (car tous les landuse ne sont pas nécessairement des relations s'ils sont un unique chemin fermé). C'est peut-être là le hic de Nominatim avec ces petites exclaves, inclues comme enclaves d'une autre surface unique : elles sont définies comme des chemins fermés et non des suites de chemins ouverts membres de relations. Nominatim les traite comme les landuse=* et natural=* Mais il y a encore légions de landuse=* et natural=* qui définissent leur unique chemin fermé dans une relation avec les mêmes attributs (ce qui n'est pas non plus un doublon quand la relation peut avoir d'autres membres que ce seul chemin fermé). On compte par exemple les water=riverbank, les bâtiments en pagaille, les relations place=island pour les petites îles non découpées administrativement et donc la ligne de côte est un unique chemin fermé (mais pourtant dans une relation avec les mêmes attributs et souvent aucun autre way membre ou juste des noeuds membres sous des rôles divers. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Le problème n'est pas là: la relation n'est visiblement pas fermée et cette page le signale: http://www.openstreetmap.org/browse/relation/27768 Regarde où sont les cercles : il ne sont PAS QUE sur les deux nœuds de Dijon et du label de la région, mais le long de la frontière, là où elle est brisée sur les extrémités. A chaque fois c'est sur des nœuds de jonction sur des communes récemment ajoutées. Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Le 28 novembre 2012 10:55, Christian Quest cqu...@openstreetmap.fr a écrit : Tagguer un way fermé d'une enclave (je parle de celle de Beauvernois entre Bourgogne et Franche-Comté signalée par Pierre) en boundary=administrative + admin_level=4 + name=région1-région2 est pour moi une erreur car ce polygone fermé avec ces attributs décrit clairement une nouvelle région car comment le distinguer d'une région tagguée de la même façon ? Si ces enclaves sont mal rendues par Mapnik (ce qui ne semble d'ailleurs pas être le cas après avoir joué du /dirty), c'est du côté de Mapnik qu'il faut faire des corrections et pas tagguer pour contourner les bugs de Mapnik. Nominatim a certe des défauts lui aussi, mais ces défauts n'apparaissent que lorsqu'on fait des mélanges entre différents modèles de description. Remettre tout sur un même modèle cohérent permet à Nominatim de s'y retrouver mais aussi à tout les outils qui réutiliseront les données. ___ 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] Soucis sur Nominatim
Bref c'est pour ça que Nominatim se trompe : il ne voyait comme contour fermé que les enclaves et ignorait les lignes non fermées. Ce problème est là dans Nominatim depuis longtemps : pour trouver une région d'appartenance d'un lieu, il utilise alors une heuristique approximative basée sur les centroïdes des régions fermées les plus proches. (Cela a toujours été le cas par exemple pour Rennes qui passe en Pays de la Loire dans Nominatim, chaque fois que la relation Bretagne n'est plus fermée, ce qui arrive souvent étant donné la complexité de sa limite côtière : le centroïde de la Bretagne étant alors calculé uniquement sur les îles fermées tout autour, majoritairement dans le Finistère et les côtes d'Armor et ce centroïde des îles bretonnes est très éloigné vers l'ouest, bien plus éloigné du lieu cherché que celui du contour fermé des Pays de la Loire). Nominatim ne détecte pas ces anomalies de frontières ouvertes pour utiliser d'abord (avant l'importation des seuls polygones), une heuristique de fermeture des extrémités ouvertes les plus proches au moins par un segment, ce qui éviterait pourtant des anomalies très grossières avec son heuristique actuelle. Le 28 novembre 2012 11:37, Philippe Verdy verd...@wanadoo.fr a écrit : Le problème n'est pas là: la relation n'est visiblement pas fermée et cette page le signale: http://www.openstreetmap.org/browse/relation/27768 Regarde où sont les cercles : il ne sont PAS QUE sur les deux nœuds de Dijon et du label de la région, mais le long de la frontière, là où elle est brisée sur les extrémités. A chaque fois c'est sur des nœuds de jonction sur des communes récemment ajoutées. Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Le 28 novembre 2012 10:55, Christian Quest cqu...@openstreetmap.fr a écrit : Tagguer un way fermé d'une enclave (je parle de celle de Beauvernois entre Bourgogne et Franche-Comté signalée par Pierre) en boundary=administrative + admin_level=4 + name=région1-région2 est pour moi une erreur car ce polygone fermé avec ces attributs décrit clairement une nouvelle région car comment le distinguer d'une région tagguée de la même façon ? Si ces enclaves sont mal rendues par Mapnik (ce qui ne semble d'ailleurs pas être le cas après avoir joué du /dirty), c'est du côté de Mapnik qu'il faut faire des corrections et pas tagguer pour contourner les bugs de Mapnik. Nominatim a certe des défauts lui aussi, mais ces défauts n'apparaissent que lorsqu'on fait des mélanges entre différents modèles de description. Remettre tout sur un même modèle cohérent permet à Nominatim de s'y retrouver mais aussi à tout les outils qui réutiliseront les données. ___ 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] Soucis sur Nominatim
2012/11/28 Philippe Verdy verd...@wanadoo.fr: Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Les paroles s'envolent, les écrits restent. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Le 28 novembre 2012 11:37, Philippe Verdy verd...@wanadoo.fr a écrit : Le problème n'est pas là: la relation n'est visiblement pas fermée et cette page le signale: http://www.openstreetmap.org/browse/relation/27768 Regarde où sont les cercles : il ne sont PAS QUE sur les deux nœuds de Dijon et du label de la région, mais le long de la frontière, là où elle est brisée sur les extrémités. A chaque fois c'est sur des nœuds de jonction sur des communes récemment ajoutées. Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Ils sont nouveaux mais correspondent à quoi ? As-tu au moins regardé avant d'affirmer que la relation est brisée ? La relation n'est pas brisée, je les ai toutes vérifiées dans JOSM avant de renvoyer mes modifs. Ces noeuds désormais visibles, sont ceux qui portent des tags, en l'occurrence j'en ai trouvé un qui est une borne géodésique. http://www.openstreetmap.org/?lat=48.0573lon=3.829744zoom=18layers=Mrelation=27768 Avant d'affirmer n'importe quoi et de faire partir ceux qui te lisent encore sur de fausses pistes, il serait bon de VERIFIER. Pour vérifier qu'un multipolygone ferme bien il y a des outils fiables disponibles comme http://analyser.openstreetmap.fr/ -- 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] Soucis sur Nominatim
Alors ces cercles sont juste une nuisance inutile. Ils ne servent à rien dans le cas d'une visualisation d'une relation, si ce ne sont : ni des nœuds membres, ni des extrémités non connectées de ways membres (là ils seraient bien plus utiles). Le cercle devrait aussi être distingué par un symbole différent de celui des nœuds membres (par exemple un carré fin et non un cercle épais, ou une autre couleur que le bleu des membres). Cela prête largement à confusion car rien dans les données de la relation elle même ne mentionne ces nœuds, il n'y a pas lieu même de les signaler dans cette analyse (le rendu en arrière plan s'en chargera, et on peut cliquer sur un chemin de la liste pour le détailler). De très nombreux noeuds sur tous les chemins membres pourraient avoir ces cercles, et cela sera illisible sur la minicarte. Je veux bien comprendre ces symboles en revanche quand on visualise un chemin (fermé ou pas d'ailleurs), pour les nœuds avec attributs, là c'est utile. Car ces nœuds sont bien membres du chemin (même si on n'en voit pas les attributs dans la définition du chemin lui-même). Mais tant qu'à faire autant le signaler dans la liste des noeuds en dessous, et pas forcément sur la mini-carte qui est surtout là pour avoir un aperçu rapide de l'objet dans son état actuel. Plus utile serait aussi d'indiquer dans les listes de membres et d'attributs ceux qui ont été ajoutés, modifiés ou retirés dans la dernière modification visualisée, par un fond de couleur comme dans l'éditeur de conflits de JOSM (même si on ne voit pas la valeur précédente) et aussi, dans les mêmes listes de membres, ceux-ci sont dans une version faisant partie de ce même changeset (par une mise en gras par exemple ou un indicateur cliquable (par exemple un lien (modifié) invidant à consulter les données de ce membre modifié, même si la présence de ce membre n'a pas changé dans la relation). Si le rôle d'un membre a changé, ce rôle aussi devrait être signalé comme modifié. Si l'ordre des membres d'une relation a changé, c'est une modif mineure, le fond de couleur n'est pas absolument nécessaire ou doit rester discret (beige clair comme dans JOSM?) Actuellement on n'a que le lien historique qui souvent plante (il charge souvent trop de versions et pour les relations cela déborde souvent la capacité du serveur à afficher des listes interminables), et pas non plus moyen par ce lien d'afficher un diff navigable entre deux versions successives. Tout le monde n'a pas JOSM pour voir ce qui est touché (Potlatch ne sait pas faire), et cela prend aussi beaucoup de temps et on n'est pas toujours prêt à charger un objet pour en consulter l'historique quand on a des modifs en cours et qu'on va voir en ligne un objet qui n'est pas partie des données modifiées en cours. Ce que j'ai dit sur le comportement très approximatif de Nominatim reste vrai sur les relations ouvertes. Le 28 novembre 2012 12:06, Christian Quest cqu...@openstreetmap.fr a écrit : Le 28 novembre 2012 11:37, Philippe Verdy verd...@wanadoo.fr a écrit : Le problème n'est pas là: la relation n'est visiblement pas fermée et cette page le signale: http://www.openstreetmap.org/browse/relation/27768 Regarde où sont les cercles : il ne sont PAS QUE sur les deux nœuds de Dijon et du label de la région, mais le long de la frontière, là où elle est brisée sur les extrémités. A chaque fois c'est sur des nœuds de jonction sur des communes récemment ajoutées. Ces cercles sont nouveaux sur les pages /browse/relation/* (qui avant ne marquaient pas les extrémités des lignes non fermées, et qu'on avait du mal à voir même en zoomant au maximum comme ici). Ils sont nouveaux mais correspondent à quoi ? As-tu au moins regardé avant d'affirmer que la relation est brisée ? La relation n'est pas brisée, je les ai toutes vérifiées dans JOSM avant de renvoyer mes modifs. Ces noeuds désormais visibles, sont ceux qui portent des tags, en l'occurrence j'en ai trouvé un qui est une borne géodésique. http://www.openstreetmap.org/?lat=48.0573lon=3.829744zoom=18layers=Mrelation=27768 Avant d'affirmer n'importe quoi et de faire partir ceux qui te lisent encore sur de fausses pistes, il serait bon de VERIFIER. Pour vérifier qu'un multipolygone ferme bien il y a des outils fiables disponibles comme http://analyser.openstreetmap.fr/ -- 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
[OSM-talk-fr] Soucis sur Nominatim
Bonjour, En recherchant les communes de Dijon, Auxerre, saint-père, etc. toute situé en Bourgogne. Nominatim indique qu'elles sont dans d'autre régions. Dijon, Côte-d'Or, Franche-Comté, France Auxerre, Yonne, Champagne-Ardenne, 89000, France Kézako ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Le mercredi 28 novembre 2012 à 00:07 +0100, Nicolas Frery a écrit : Bonjour, En recherchant les communes de Dijon, Auxerre, saint-père, etc. toute situé en Bourgogne. Nominatim indique qu'elles sont dans d'autre régions. Dijon, Côte-d'Or, Franche-Comté, France Auxerre, Yonne, Champagne-Ardenne, 89000, France Kézako ? Bonne question. Je n'ai pas ce problème sur mon nominatim http://nominatim.paulla.asso.fr/ J'utilise la version 2.0.0. Le serveur officiel utilise une version plus récente. Si on compare la page de détails http://nominatim.paulla.asso.fr/details.php?place_id=99442259 http://nominatim.openstreetmap.org/details.php?place_id=97982683 on voit que dans Address il y a une virgule en moins dans chaque ligne. et que (named features only) a disparu (supprimé dans git il y a 3 semaines) Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soucis sur Nominatim
Une recherche à partir de http://nominatim.openstreetmap.org/ indique que seuls deux départements sont reconnues sous la relation Bourgogne, soit l'Yonne et et la Saône-et-Loire. voir http://nominatim.openstreetmap.org/details.php?place_id=97330189 La Nièvre et la Côte-d'Or sont dans les limbes. En regardant les relations Bourgogne et Saône-et-Loire, je constate aussi des trouées du côté de la commune de Beauvernois. Il y a deux trouées et une grande échancrure. Y a-t-il un problème de ce côté? Beauvarnais http://www.openstreetmap.org/browse/relation/1194193 Saône-et-Loire http://www.openstreetmap.org/?lat=46.8494lon=5.4495zoom=14layers=Mrelation=7397Bourgogne http://www.openstreetmap.org/?lat=46.8494lon=5.4495zoom=14layers=Mrelation=27768 Pierre De : Nicolas Frery nico...@zoubi.info À : Talk-fr@openstreetmap.org Envoyé le : Mardi 27 novembre 2012 18h07 Objet : [OSM-talk-fr] Soucis sur Nominatim Bonjour, En recherchant les communes de Dijon, Auxerre, saint-père, etc. toute situé en Bourgogne. Nominatim indique qu'elles sont dans d'autre régions. Dijon, Côte-d'Or, Franche-Comté, France Auxerre, Yonne, Champagne-Ardenne, 89000, France Kézako ? ___ 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
