Re: [OSM-talk-fr] Nominatim et plan d'eau
je ne juge personne, je constate jsute que c'est un truc pas fini et il ne faut pas s'attendre à de bons résultats car les données collectées sont trop insuffisantes. Le simple fait d'avoir un gros paquet de noeuds "admin_level=15" infique que c'est un truc jeté là en vrac en attendant, pour résoudre seulement une toute petite partie des cas, juste à titre de test pour en mesurer la portée avant de savoir ce qu'on doit en faire. Mais c'est dommage d'exposer ce truc dans la vue publique pour tout le monde alors que visiblement ça n'est fait que pour les développeurs. Cette partie de Niominatim n'est d'ailleurs pas documentée, donc pas soutenue, elle ne peut être que "provisoire" en attendant de trouver des solutions et les mettre en oeuvre. Mais il est clair qu'avec juste de noeuds centroïdes pour ces données il n'y a pas moyen de gérer ça proprement et le schéma de la base de données Nominatim va devoir changer, ainsi que les algos de recherche, classification et calcul de pertinence, qui pour l'instant ne tiennent pas compte (ne serait-ce que pour indiquer l'importance) de la longueur réelle (des objets linéaires) ni de la surface réelle (des objets surfaciques). Le classement ensujite pour la pertinance est largement faussé sur ces objets. Et en plus un seul noeud ne surffira pas, il faudra aussi une bounding box (donc admettre deux noeuds séparés du centroïde calculé malgré tout assez bizarrement pour la position des pseudo-noeuds "'placeid" de Nominatim, sans tenir compte de la topologie des objets concaves ou morcelés, comme je l'ai montré pour L'Île-Saint-Denis qui est un exemple type, magré tout simple mais il y en a de bien plus compliquées et bien plus grands, notamment à la frontière belgo-néerlandaise et en Espagne). D'ailleurs Nominatim ne tient pas compte non plus de l'admin_level réellement tagué (alors qu'il a les données) et on constate des inversions inattendues entre les niveaux quand il les classe (il semble faire plus confiance en priorité uniquement aux distances relatives entre les centroïdes, puis effectue seulement un filtrage pour masquer les objets "homonymes" (à priorui plus grands et classés après mais selon le mauvais critère). Bref c'est le constat: Nominatim n'est pas utilisable pour chercher correctement les objets non directement liés aux adresses (dont ceux dans le "vrac" du pseudo-niveau 15 et classés systématiquement e n fin de liste mais comme s'ils étaient inclus dans les objets classés avant comme de petits hameaux ou lieux-dits ou des batiments isolés) Le sam. 17 oct. 2020 à 19:31, Topographe Fou a écrit : > Philippe, comme tous les projets "l'approximation", le "bancale", le > "n'importe comment" et le "stupide" ne pourront s'améliorer qu'avec des > humains derrière. Et ces humains, comme tous les humains qu'ils soient de > Nominatim ou d'ailleurs, méritent mieux comme encouragement (et > remerciements) que ce que j'ai lu à deux reprises aujourd'hui. Quand bien > même le fond serait juste, la forme est juste écoeurante, ce qui gâche tout. > > Sans avoir à rentrer dans le code tu peux rédiger un ticket sans ces > jugements pour apporter ta pierre à l'édifice. > > Cordialement > > LeTopographeFou > *De:* ver...@gmail.com > *Envoyé:* 17 octobre 2020 5:52 PM > *À:* talk-fr@openstreetmap.org > *Répondre à:* talk-fr@openstreetmap.org > *Objet:* Re: [OSM-talk-fr] Nominatim et plan d'eau > > En fait Nominatim traite les éléments naturels quels que soit leur taille > comme des noeuds et leur attribue un admin_level=15 (totalement > synthétique) pour classer les résultats. Il les considère plus petits que > les noms de batiments (house_name) auxquels il veut les attacher > pouyr attribuer une adresse et sinon il cherche un highway. > Ces éléments naturels sont donc classés n'importe comment. > > Et je ne spécule pas du tout sur le fait qu'il crée bel et bien des noeuds > "place" artificiels, avec un id interne puisque c'est bien ce qu'il affiche > dans ses résultats. Et peu importe si cela ne correspond à rien et que > l'attribut synthétique admin_level ne correspond lui aussi à rien du tout. > La logique est totalement fausse qui conduit à les "rattacher" à d'autres > objets très éloignés et arbitraires qui n'incluient pourtant même pas du > tout ces noeuds synthétiques. > > C'est une très grossière approximation de Nominatim: on ne peut pas > réduire ces objets à un simple noeud et Nominatim ne sait pas leur attacher > plutôt une bounding box pour avoir quelquechose de plus pertinent. Il se > base juste sur une mesure de distance entre deux noeuds (dont le noeud > artificiel et un autre noeud arbitraire d'un highway ou d'un vraie relation > boundary). > > C'est très bancale. C'est un gros manque sur quelquechose qu'i n'a pas
Re: [OSM-talk-fr] Nominatim et plan d'eau
Philippe, comme tous les projets "l'approximation", le "bancale", le "n'importe comment" et le "stupide" ne pourront s'améliorer qu'avec des humains derrière. Et ces humains, comme tous les humains qu'ils soient de Nominatim ou d'ailleurs, méritent mieux comme encouragement (et remerciements) que ce que j'ai lu à deux reprises aujourd'hui. Quand bien même le fond serait juste, la forme est juste écoeurante, ce qui gâche tout.Sans avoir à rentrer dans le code tu peux rédiger un ticket sans ces jugements pour apporter ta pierre à l'édifice.Cordialement LeTopographeFou De: ver...@gmail.comEnvoyé: 17 octobre 2020 5:52 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Nominatim et plan d'eau En fait Nominatim traite les éléments naturels quels que soit leur taille comme des noeuds et leur attribue un admin_level=15 (totalement synthétique) pour classer les résultats. Il les considère plus petits que les noms de batiments (house_name) auxquels il veut les attacher pouyr attribuer une adresse et sinon il cherche un highway.Ces éléments naturels sont donc classés n'importe comment.Et je ne spécule pas du tout sur le fait qu'il crée bel et bien des noeuds "place" artificiels, avec un id interne puisque c'est bien ce qu'il affiche dans ses résultats. Et peu importe si cela ne correspond à rien et que l'attribut synthétique admin_level ne correspond lui aussi à rien du tout. La logique est totalement fausse qui conduit à les "rattacher" à d'autres objets très éloignés et arbitraires qui n'incluient pourtant même pas du tout ces noeuds synthétiques.C'est une très grossière approximation de Nominatim: on ne peut pas réduire ces objets à un simple noeud et Nominatim ne sait pas leur attacher plutôt une bounding box pour avoir quelquechose de plus pertinent. Il se base juste sur une mesure de distance entre deux noeuds (dont le noeud artificiel et un autre noeud arbitraire d'un highway ou d'un vraie relation boundary).C'est très bancale. C'est un gros manque sur quelquechose qu'i n'a pas été réellement développé mais laissé en vrac dans une classe fourre-tout (pseudo-admin_level=15) en attendant un développement sérieux.Tant que ces objets restent assimilable à un noeud et qu'ils sont réellement inclus dans une relation admin_level ou assez proche à un highway indexés pour les rendre "routables" (Nominatim n'indexe pas tous les highways, seulement ceux ayant un nom ou un numéro de référence) il va retourner n'importe quoi, c'est le hasard le plus complet en terme de classification, il n'y a strictement rien qui soit alors réellement pertinent.Personellement je pense qu'une première amélioration de Nominatim serait qu'il vire les noeuds "place" synthétiques pour les objets qui ne sont pas des noeuds (objets linéraires et surfaces polygonales/multi-polygonales), et qu'il les remplace au moins par des bounding box, afin de rendre les calculs de pertinence bien meilleurs. Et il devrait le faire au moins pour tous les objets actuellement classés en pseudo-admin_level=15. et sans doute aussi (après tests pour éveluer les effets de bords dans la détermination des adresses) pour les highways (quoique pour eux il vaudrait sans doute mieux qu'il indexe les deux extrémités, à moins que ce soit un chemin fermé ou que ce soit un "polyligne" formant des branches ou un réseau dans une relation assimilable alors à une surface approximée par la boundingbox)Le sam. 17 oct. 2020 à 15:56, Sarah Hoffmann <lon...@denofr.de> a écrit :Bonjour, apropos la question pourquoi un lac s'attache a une rue et prends son adresse. C'est justement quelque chose qu'il faut revoir et probablement reviser. L'attachement aux rues marche bien pour les petits POIs comme boite aux lettres ou des supermarches. Ca marche meme bien pour un petit pont de village mais ce n'est pas une bonne idee pour les grandes lacs ou baies. Quand a toutes les autres speculations, j'ai vraiment pas envie de les discuter parce qu'ils sont exactement ca: speculations qui ont rien du tout a voir avec comment Nominatim fonctionne. Sarah On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote: > Tu ne réponds pas à la question ni au cas évoqué autour de > l'Île-Saint-Denis. > > En effet strictement rien n'associe ce polygone à la route en tant > "qu'adresse". C'est stupide comme association surtout pour ce type > d'élément. De plus c'est Nominatim qui en interne a généré un "place node" > (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone). > > En créant ce
Re: [OSM-talk-fr] Nominatim et plan d'eau
En fait Nominatim traite les éléments naturels quels que soit leur taille comme des noeuds et leur attribue un admin_level=15 (totalement synthétique) pour classer les résultats. Il les considère plus petits que les noms de batiments (house_name) auxquels il veut les attacher pouyr attribuer une adresse et sinon il cherche un highway. Ces éléments naturels sont donc classés n'importe comment. Et je ne spécule pas du tout sur le fait qu'il crée bel et bien des noeuds "place" artificiels, avec un id interne puisque c'est bien ce qu'il affiche dans ses résultats. Et peu importe si cela ne correspond à rien et que l'attribut synthétique admin_level ne correspond lui aussi à rien du tout. La logique est totalement fausse qui conduit à les "rattacher" à d'autres objets très éloignés et arbitraires qui n'incluient pourtant même pas du tout ces noeuds synthétiques. C'est une très grossière approximation de Nominatim: on ne peut pas réduire ces objets à un simple noeud et Nominatim ne sait pas leur attacher plutôt une bounding box pour avoir quelquechose de plus pertinent. Il se base juste sur une mesure de distance entre deux noeuds (dont le noeud artificiel et un autre noeud arbitraire d'un highway ou d'un vraie relation boundary). C'est très bancale. C'est un gros manque sur quelquechose qu'i n'a pas été réellement développé mais laissé en vrac dans une classe fourre-tout (pseudo-admin_level=15) en attendant un développement sérieux. Tant que ces objets restent assimilable à un noeud et qu'ils sont réellement inclus dans une relation admin_level ou assez proche à un highway indexés pour les rendre "routables" (Nominatim n'indexe pas tous les highways, seulement ceux ayant un nom ou un numéro de référence) il va retourner n'importe quoi, c'est le hasard le plus complet en terme de classification, il n'y a strictement rien qui soit alors réellement pertinent. Personellement je pense qu'une première amélioration de Nominatim serait qu'il vire les noeuds "place" synthétiques pour les objets qui ne sont pas des noeuds (objets linéraires et surfaces polygonales/multi-polygonales), et qu'il les remplace au moins par des bounding box, afin de rendre les calculs de pertinence bien meilleurs. Et il devrait le faire au moins pour tous les objets actuellement classés en pseudo-admin_level=15. et sans doute aussi (après tests pour éveluer les effets de bords dans la détermination des adresses) pour les highways (quoique pour eux il vaudrait sans doute mieux qu'il indexe les deux extrémités, à moins que ce soit un chemin fermé ou que ce soit un "polyligne" formant des branches ou un réseau dans une relation assimilable alors à une surface approximée par la boundingbox) Le sam. 17 oct. 2020 à 15:56, Sarah Hoffmann a écrit : > Bonjour, > > apropos la question pourquoi un lac s'attache a une rue et prends > son adresse. C'est justement quelque chose qu'il faut revoir et > probablement reviser. L'attachement aux rues marche bien pour les > petits POIs comme boite aux lettres ou des supermarches. Ca marche > meme bien pour un petit pont de village mais ce n'est pas une bonne > idee pour les grandes lacs ou baies. > > Quand a toutes les autres speculations, j'ai vraiment pas envie de > les discuter parce qu'ils sont exactement ca: speculations qui ont > rien du tout a voir avec comment Nominatim fonctionne. > > Sarah > > On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote: > > Tu ne réponds pas à la question ni au cas évoqué autour de > > l'Île-Saint-Denis. > > > > En effet strictement rien n'associe ce polygone à la route en tant > > "qu'adresse". C'est stupide comme association surtout pour ce type > > d'élément. De plus c'est Nominatim qui en interne a généré un "place > node" > > (avec un ID interne) sur le polygone (il n'y a aucun node dans le > polygone). > > > > En créant ce "place node", c'est là qu'il a cherché stupidement à lui > > donner une adresse et à chercher une route proche. Et c'est là que > > l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus > > pourquoi il trouve la relation associée à un lieu-dit ou hameau encore > plus > > éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien > > plus proches et que cela n'a strictement rien à voir non plus avec la > route > > départementale trouvée dans les environs du noeud. > > > > Franchement c'est là que se joue l'approximation: le noeud interne > "place" > > ajouté ne représente pas correctement le plan d'eau, on pourrait toujours > > tenter d'ajouter un noeud "label" dans la relation OSM je suis presque > > certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne > > ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera > > pas suffisant pour des relations à cheval sur plus d'une seule > frontière). > > > > Et comment fait Nominatim pour même chercher une "adresse" (un highway) > > sinon en procédant là aussi visiblement à une approximation ne tenant pas > > compte de la
Re: [OSM-talk-fr] Nominatim et plan d'eau
Bonjour, apropos la question pourquoi un lac s'attache a une rue et prends son adresse. C'est justement quelque chose qu'il faut revoir et probablement reviser. L'attachement aux rues marche bien pour les petits POIs comme boite aux lettres ou des supermarches. Ca marche meme bien pour un petit pont de village mais ce n'est pas une bonne idee pour les grandes lacs ou baies. Quand a toutes les autres speculations, j'ai vraiment pas envie de les discuter parce qu'ils sont exactement ca: speculations qui ont rien du tout a voir avec comment Nominatim fonctionne. Sarah On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote: > Tu ne réponds pas à la question ni au cas évoqué autour de > l'Île-Saint-Denis. > > En effet strictement rien n'associe ce polygone à la route en tant > "qu'adresse". C'est stupide comme association surtout pour ce type > d'élément. De plus c'est Nominatim qui en interne a généré un "place node" > (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone). > > En créant ce "place node", c'est là qu'il a cherché stupidement à lui > donner une adresse et à chercher une route proche. Et c'est là que > l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus > pourquoi il trouve la relation associée à un lieu-dit ou hameau encore plus > éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien > plus proches et que cela n'a strictement rien à voir non plus avec la route > départementale trouvée dans les environs du noeud. > > Franchement c'est là que se joue l'approximation: le noeud interne "place" > ajouté ne représente pas correctement le plan d'eau, on pourrait toujours > tenter d'ajouter un noeud "label" dans la relation OSM je suis presque > certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne > ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera > pas suffisant pour des relations à cheval sur plus d'une seule frontière). > > Et comment fait Nominatim pour même chercher une "adresse" (un highway) > sinon en procédant là aussi visiblement à une approximation ne tenant pas > compte de la géométrie réelle mais juste des bounding box (comme on le voit > dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets > situés dans une concavité de l'île mais dans la commune à l'ouest de l'île > ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans une > concavité encore plus grande. > > Ce sont bien les concavités frontalières qui causent problème ici: l'algo > de recherche d'association de noeuds aux adresses "proches" est > carrément faux dans ce cas, et encore plus quand ce noeud créé > artificiellement ne peut pas luis seul représenter la surface d'un > (multi-)polygone. > > Le mode "debug" ici ne répond pas du tout à ce que fait Nominatim, il donne > juste un aperçu sur la façon dont un objet isolé a été indexé (sur quels > champs "utiles") mais pas du tout comment cet index sera ensuite utilisdé > dans une recherche, notamment pour découper une chaine unique en éléments > "pertinents", créer des listes d'objets indexés candidats, > éliminer sauvagement des objets dans ces listes en ne retenant que les plus > "probables" avant de calculer des intersections pour "accélérer" le calcul > d'intersections de ces listes (note: il y a différentes façon de > découper/simplifier la chaine de recherche, plus elle est longues et plus > le nombre de possibilités croit exponentiellement, Nominatim doit faire des > simplifications pour réduire le nombre de possibilités à croiser, et il > simplifie aussi le traitement des géométries pendant le croisement des > listes d'objets en tronquant ces listes avec des critères de "pertinence" > non basés sur la géométrie réelle mais ici on voit que c'est même pire > puisqu'il se contente juste d'une géométrie réduite à un seul noeud > artificiel, et au final, il peut se retrouver avec une liste totalement > vide, ou sinon une liste n'ayant plus assez de candidats, ou un seul qui > n'est plus du tout pertinent et qu'il ne vérifie finalement même pas à la > fin pour voir si la géométrie correspond. > > Quand Nominatim ne trouve pas d'objets ou n'en retrouve pas assez, il ne > sait pas réduire lui-même ses critères de pertinence (pour ne pas filtrer > aussi sauvement ses listes d'objets à croiser avant de faire l'assemblage > et le croisement sur les éléments assemblés de la chaine de recherche). Il > n'utilise pas du tout la géométrie réelle, pour lui tout objet indexé est > réduit à un noeud unique, qui peut être arbitraire, et c'est même pire que > s'il avait réduit la géométrie non pas à un seul noeud mais à une > bounding-box (deux noeuds sur une diagonale). Et même à la fin quand il > obtient une liste de résultats filtrés, il ne charge pas la géométrie > réelle des objets pour vérifier la pertinence réelle. > > Nominatim ne travaille qu'en une seule passe (zéro ou un seul objet, pour > lui c'est suffisant!) et ne sait pas
Re: [OSM-talk-fr] Nominatim et plan d'eau
Et d'ailleurs ça se voit concernant son analyse de "pertinence": il retient la départementale comme "pertinente" car il a déterminé la distance comme étant nulle, ce qui est ici totalement faux; les distances calculées sont fausses, même pour le noeud "place" ajouté artificiellement (il y a aussi un autre noeud "place" artificiel pour la départementale). C'est carrément stupide, les objets ne peuvent pas être valament représentés par un seul noeud (comme décrit sur https://nominatim.org/release-docs/develop/api/Output/#place_id-is-not-a-persistent-id), il en faudrait au moins 2 pour calculer une pertinence non pas sur la seule distance de point à point, mais en tenant compte des surfaces d'intersection des rectangles et sinon en prenant la distance minimale d'écart entre ces rectangles (20 cas possibles de placement relatif quand il n'y a aucune intersection entre 2 rectangles dont 21 façons de calculer cette distance minimale) comme un critère de valeur négative. Et même avec cette modif, on va avoir des cas tordus dans les concavités frontalières ou les méandres du linéaire des rues/routes pour rechercher une adresse pertinente, et c'et là qu'il faut une notation seondaire pour mieux trier les listes d'objets ou revoir les seuils de filtrage en amont Cependant ce que tu suggères est que pour cet étang, il suffirait de nommer la petite route qui la borde et vient du sud-ouest. Mais tu n'explique pas du tout pourquoi ce n'est pas suffisant dans le cas du Quai d'Asnières à côté de l'île-Saint-Denis, un cas qui nécessite de tenir compte de la géométrie réelle et pas d'une simple approximation à un seul noeud artificiel ni même à une bounding-box car on n'ira pas non plus ajouter un nouveau nom qui existe déjà et n'a pas besoin d'être ajouté artificiellement dans la base de données en tant que pseudo-nom (on a déjà eu les "pseudo-noeuds" avec les membres de rôle "label" dans les relations, des noeuds que Nominatim n'utilise plus du tout, ni non plus la plupart des moteurs de rendus. Nominatim n'utilise pas non plus les noeuds "admin_centre" alors qu'ils seraient encore utiles pour affiner la note de pertinence au delà du seul noeud (ou de la seule bounding box) et éviter un filtrage trop précoce des listes d'objets candidats avant le croisement de ces listes (cela lui permettrait la plupart du temps de continuer à travailler en une seule passe). Le sam. 17 oct. 2020 à 13:00, Philippe Verdy a écrit : > Tu ne réponds pas à la question ni au cas évoqué autour de > l'Île-Saint-Denis. > > En effet strictement rien n'associe ce polygone à la route en tant > "qu'adresse". C'est stupide comme association surtout pour ce type > d'élément. De plus c'est Nominatim qui en interne a généré un "place node" > (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone). > > En créant ce "place node", c'est là qu'il a cherché stupidement à lui > donner une adresse et à chercher une route proche. Et c'est là que > l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus > pourquoi il trouve la relation associée à un lieu-dit ou hameau encore plus > éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien > plus proches et que cela n'a strictement rien à voir non plus avec la route > départementale trouvée dans les environs du noeud. > > Franchement c'est là que se joue l'approximation: le noeud interne "place" > ajouté ne représente pas correctement le plan d'eau, on pourrait toujours > tenter d'ajouter un noeud "label" dans la relation OSM je suis presque > certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne > ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera > pas suffisant pour des relations à cheval sur plus d'une seule frontière). > > Et comment fait Nominatim pour même chercher une "adresse" (un highway) > sinon en procédant là aussi visiblement à une approximation ne tenant pas > compte de la géométrie réelle mais juste des bounding box (comme on le voit > dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets > situés dans une concavité de l'île mais dans la commune à l'ouest de l'île > ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans une > concavité encore plus grande. > > Ce sont bien les concavités frontalières qui causent problème ici: l'algo > de recherche d'association de noeuds aux adresses "proches" est > carrément faux dans ce cas, et encore plus quand ce noeud créé > artificiellement ne peut pas luis seul représenter la surface d'un > (multi-)polygone. > > Le mode "debug" ici ne répond pas du tout à ce que fait Nominatim, il > donne juste un aperçu sur la façon dont un objet isolé a été indexé (sur > quels champs "utiles") mais pas du tout comment cet index sera ensuite > utilisdé dans une recherche, notamment pour découper une chaine unique en > éléments "pertinents", créer des listes d'objets indexés candidats, > éliminer sauvagement des objets dans ces listes en ne
Re: [OSM-talk-fr] Nominatim et plan d'eau
Tu ne réponds pas à la question ni au cas évoqué autour de l'Île-Saint-Denis. En effet strictement rien n'associe ce polygone à la route en tant "qu'adresse". C'est stupide comme association surtout pour ce type d'élément. De plus c'est Nominatim qui en interne a généré un "place node" (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone). En créant ce "place node", c'est là qu'il a cherché stupidement à lui donner une adresse et à chercher une route proche. Et c'est là que l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus pourquoi il trouve la relation associée à un lieu-dit ou hameau encore plus éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien plus proches et que cela n'a strictement rien à voir non plus avec la route départementale trouvée dans les environs du noeud. Franchement c'est là que se joue l'approximation: le noeud interne "place" ajouté ne représente pas correctement le plan d'eau, on pourrait toujours tenter d'ajouter un noeud "label" dans la relation OSM je suis presque certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera pas suffisant pour des relations à cheval sur plus d'une seule frontière). Et comment fait Nominatim pour même chercher une "adresse" (un highway) sinon en procédant là aussi visiblement à une approximation ne tenant pas compte de la géométrie réelle mais juste des bounding box (comme on le voit dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets situés dans une concavité de l'île mais dans la commune à l'ouest de l'île ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans une concavité encore plus grande. Ce sont bien les concavités frontalières qui causent problème ici: l'algo de recherche d'association de noeuds aux adresses "proches" est carrément faux dans ce cas, et encore plus quand ce noeud créé artificiellement ne peut pas luis seul représenter la surface d'un (multi-)polygone. Le mode "debug" ici ne répond pas du tout à ce que fait Nominatim, il donne juste un aperçu sur la façon dont un objet isolé a été indexé (sur quels champs "utiles") mais pas du tout comment cet index sera ensuite utilisdé dans une recherche, notamment pour découper une chaine unique en éléments "pertinents", créer des listes d'objets indexés candidats, éliminer sauvagement des objets dans ces listes en ne retenant que les plus "probables" avant de calculer des intersections pour "accélérer" le calcul d'intersections de ces listes (note: il y a différentes façon de découper/simplifier la chaine de recherche, plus elle est longues et plus le nombre de possibilités croit exponentiellement, Nominatim doit faire des simplifications pour réduire le nombre de possibilités à croiser, et il simplifie aussi le traitement des géométries pendant le croisement des listes d'objets en tronquant ces listes avec des critères de "pertinence" non basés sur la géométrie réelle mais ici on voit que c'est même pire puisqu'il se contente juste d'une géométrie réduite à un seul noeud artificiel, et au final, il peut se retrouver avec une liste totalement vide, ou sinon une liste n'ayant plus assez de candidats, ou un seul qui n'est plus du tout pertinent et qu'il ne vérifie finalement même pas à la fin pour voir si la géométrie correspond. Quand Nominatim ne trouve pas d'objets ou n'en retrouve pas assez, il ne sait pas réduire lui-même ses critères de pertinence (pour ne pas filtrer aussi sauvement ses listes d'objets à croiser avant de faire l'assemblage et le croisement sur les éléments assemblés de la chaine de recherche). Il n'utilise pas du tout la géométrie réelle, pour lui tout objet indexé est réduit à un noeud unique, qui peut être arbitraire, et c'est même pire que s'il avait réduit la géométrie non pas à un seul noeud mais à une bounding-box (deux noeuds sur une diagonale). Et même à la fin quand il obtient une liste de résultats filtrés, il ne charge pas la géométrie réelle des objets pour vérifier la pertinence réelle. Nominatim ne travaille qu'en une seule passe (zéro ou un seul objet, pour lui c'est suffisant!) et ne sait pas reprendre son filtrage en réduisant ses seuils de pertinence avant les croisements, afin d'obtenir des listes d'objets suffisamment peuplées (pas trop) avant de classer par pertinence en tenant compte de la géométrie réelle (ce qui peut être couteux et lent puisqu'il lui faudrait charger la géométrie complète ces objets, là j'admets qu'il doit limiter la longueur de ces listes). Le sam. 17 oct. 2020 à 12:18, Sarah Hoffmann a écrit : > On Sat, Oct 17, 2020 at 07:15:22AM +0200, Philippe Verdy wrote: > > Si tu enlèves "Saibnt-Jean-de-Braye", Nominatim le trouve. > > > > Sans doute parce que le plan d'eau est à cheval sur deux communes, et > l'est > > indexé que sur une seule, sans doute le centroïde. > > > > Mais si tu cherches sur l'autre commune, Nominatim ne le trouve
Re: [OSM-talk-fr] Nominatim et plan d'eau
On Sat, Oct 17, 2020 at 07:15:22AM +0200, Philippe Verdy wrote: > Si tu enlèves "Saibnt-Jean-de-Braye", Nominatim le trouve. > > Sans doute parce que le plan d'eau est à cheval sur deux communes, et l'est > indexé que sur une seule, sans doute le centroïde. > > Mais si tu cherches sur l'autre commune, Nominatim ne le trouve pas non > plus: > > https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Marigny-les-Usages#map=17/47.94215/2.00436 > > Donc une solution possible serait de couper le multipolygone en deux > parties, une pour chaque commune Non! Ca change rien pour Nominatim et ca casse le lac. Si tu veux savoir, ce qui se passe avec la recherche, tu peux te servir de l'interface debug de Nominatim. Va sur https://nominatim.openstreetmap.org/ui/details.html. La on peut entrer soit l'ID de l'objet que tu cherche soit l'URL openstreetmap. Quand il y a un erreur au retour, ca veut dire que Nominatim ne connait pas l'objet. Dans le cas du lac, ca marche et on voit le page du details: https://nominatim.openstreetmap.org/ui/details.html?osmtype=R=2431148=natural Ici, c'est la partie 'Address' qui est le plus interessant. On peut voir ici ou l'objet etait place par Nominatim. Le lac utilise l'adresse de la route D2152. C'est la plus proche du lac, mais malheuresement elle se trouve ni dans Saint-Jean-de-Braye, ni dans Marigny-les-Usages. Cést pour ca que 'Étang du Ruet, Saint-Jean-de-Braye' ne marche pas. Sarah > Le jeu. 15 oct. 2020 à 09:57, Cyrille37 OSM via Talk-fr < > talk-fr@openstreetmap.org> a écrit : > > > Hello, > > > > Nominatim ne trouve pas "Étang du Ruet, Saint-Jean-de-Braye" alors qu'il > > existe bien: > > > > > > https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Saint-Jean-de-Braye#map=17/47.94215/2.00436 > > > > Est-ce à cause du natural=water (plan d'eau) ou qu'il s'agit d'une > > relation multi-polygone ? > > > > Merci de vos lumières :-) > > Cyrille37 > > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nominatim et plan d'eau
Si tu enlèves "Saibnt-Jean-de-Braye", Nominatim le trouve. Sans doute parce que le plan d'eau est à cheval sur deux communes, et l'est indexé que sur une seule, sans doute le centroïde. Mais si tu cherches sur l'autre commune, Nominatim ne le trouve pas non plus: https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Marigny-les-Usages#map=17/47.94215/2.00436 Donc une solution possible serait de couper le multipolygone en deux parties, une pour chaque commune Les multipolygones "naturels" pouvant être très grands, il semble que Nominatim ait fait un choix bancal de ne pas les indexer avec ce nom quand il est ambigu, et ne sait pas quoi retirer de la requête. Pourtant en cherchant un peu: https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Les%20%C3%89poisses#map=17/47.94220/2.00266 Là il trouve, mais au nom d'un hameau proche qui ne fait partie d'aucune des deux communes mais d'une troisième limitrophe des deux autres, Boigny-sur-Byonne, bien qu'elle ne couvre aucune partie du multipolygone du plan d'eau. Bizarre malgré tout car le point géolocalisé pour centrer la vue est bien au centre du plan d'eau et pas du tout à Boigny-sur-Byonne. Je me demande donc si l'indexation par Nominatim ne se contente pas d'indexer les multipolygones uniquement sur leur bounding-box, peut-être élargie ou arrondie avec une zone tampon (arrondi les limites du "quad" contenant tout l'objet), et qu'ensuite il n'indexe qu'un seul des sommets de ce rectangle, au lieu du centre de ce rectangle ou du son centroïde qu'il ne sait pas ou ne veut pas calculer sur un multipolygone pouvant contenir des dizaines de milliers de noeuds pour les plus grands Ou alors il fait pareil pour indexer les communes selon aussi leur bounding box (sans ajouter de zone tampon d'arrondi autour), et il va alors juste chercher alors une commune en intersection (avec la bounding box du plan d'eau) mais où cette intersection est la plus grande: cela ne demande pas beaucoup de calcul de géométrie. Si une des deux hypothèses est vraie, alors Nominatim a bien des problèmes à trouver correctement les objets à cheval sur plusieurs communes, et proches d'une autre. Un test est à faire sur une chemin à cheval sur deux communes dans une zone incluse dans la concavité d'une autre. Et là je pense à une commune très concave comme l'Île-Saint-Denis, où pourraient avoir été indexés à tord des objets faisant en fait partie de Villeneuve-la-Garenne: Quai d'Asnières, L'Île-Saint-Denis Là non plus Nominatim ne trouve rien, mais avec: Quai d'Asnières, Saint-Denis Là il trouve alors que la commune de Saint-Denis est plus éloignée encore de Villeneuve-la-Garenne. Cela semble confirmer une grossière approximation par Nominatim basée sur les bounding-box uniquement ! Le jeu. 15 oct. 2020 à 09:57, Cyrille37 OSM via Talk-fr < talk-fr@openstreetmap.org> a écrit : > Hello, > > Nominatim ne trouve pas "Étang du Ruet, Saint-Jean-de-Braye" alors qu'il > existe bien: > > > https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Saint-Jean-de-Braye#map=17/47.94215/2.00436 > > Est-ce à cause du natural=water (plan d'eau) ou qu'il s'agit d'une > relation multi-polygone ? > > Merci de vos lumières :-) > Cyrille37 > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nominatim et plan d'eau
Hello, Nominatim ne trouve pas "Étang du Ruet, Saint-Jean-de-Braye" alors qu'il existe bien: https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Saint-Jean-de-Braye#map=17/47.94215/2.00436 Est-ce à cause du natural=water (plan d'eau) ou qu'il s'agit d'une relation multi-polygone ? Merci de vos lumières :-) Cyrille37 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
