Use ST_PointOnSurface even fo ways in place of ST_Centroid

[frodrigo]

ST_PointOnSurface est la version de ST_Centroid qui assure que le point retourné est dans/sur l'objet en question.

ST_PointOnSurface malgré son nom fonctionnement également pour les lignes.

ST_PointOnSurface assure que le point n'est hors du polygone ou de la ligne.

[vdct]

Quel est le problème qu'on cherche à résoudre ici ? Je ne parle pas de théorie, mais de cas concrets.

[frodrigo]

Stabiliser les codes des pseudo fantoir pour réduire les différentes entre deux versions de la bano. Actuellement des lignes sont les mêmes avec juste ce code qui changes. Infinie le but est d'évaluer la quantité de changement entre deux versions pour éviter les régressions lors du déploiement des données dans un geocodeur. El jue, 6 feb 2025, 20:59, vdct ***@***.***> escribió:

…

Quel est le problème qu'on cherche à résoudre ici ? Je ne parle pas de théorie, mais de cas concrets. — Reply to this email directly, view it on GitHub <#434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANT5DVMKVZO775PRANSXPT2OPEL5AVCNFSM6AAAAABWGIKQ36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBRGAYDONRSG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[vdct]

Je pense que ta réponse a sa place dans la PR #433
Ma question porte sur les problèmes que résoud concrètement l'usage de ST_PointOnSurface

[frodrigo]

C'est pour s'assurer que les centroïdes sont bien liées aux objets concernés.

Par exemple, le centroïde de cette commune est dans la commune voisine https://www.openstreetmap.org/relation/147333 et la modif dans charge_points_nommes_centroides_OSM.sql corrige ça. D'autant plus ici que ST_PointOnSurface est déjà utilise ailleurs dans le même fichier pour calculer le "même" "centroide" sur la même table.

De façon générale, utiliser le ST_PointOnSurface à la place du ST_Centroid c’est plus une bonne pratique pour éviter des problèmes cachés. Si tu veux que j’aille te trouver un exemple concret dans la sortie de la BANO ou ça pourrait être mieux en utilisant ST_PointOnSurface je peux passer du temps dessus.

[vdct]

a modif dans charge_points_nommes_centroides_OSM.sql corrige ça

Non car on ne calcule pas de géométrie pour un point de commune, on prend les coordonnées du node avec le role admin_centre.

Plus largement, le calcul de centroide se fait majoritairement sur de toutes petites surfaces, essentiellement les buildings, pour affecter des coordonnées à l'adresse présente sur le building. Que le point soit dedans ou au bord voire en dehors du bâtiment est un non-sujet vu qu'il n'y a aucune nécessité de tagguer le point dans le bâtiment habituellement, le point peut être assez loin des bâtiments quand il est placé à la limite public-privé.

Pour les surfaces plus importantes que les bâtiments, l'essentiel consiste en un calcul pour les lieux-dits, qui sont reçus du Cadastre comme des polygones et exploités comme des points. J'identifie 1% des lieux-dits surfaciques pour lesquels le centroide n'est pas dans l'emprise. Ce point est purement indicatif, il s'apparente aux nodes place=* d'OSM dont le positionnement est hyper subjectif. Donc on est vraiment dans le fignolage.

Globalement c'est un calcul forcément plus coûteux que le simple centroide, et il est répété 35000 fois par jour pour le refresh de la base. Je n'ai pas cherché à quantifier le temps ajouté, mais sur le principe, rajouter un calcul est ok si ça apporte un saut de qualité. C'est pas le cas ici, et la mention de bonne pratique ne me semble pas évidente dans le contexte.