L’erreur shapely.errors.GEOSException: TopologyException: side location conflict ressemble à un simple souci de géométrie invalide, alors qu’elle provient aussi de comportements de GEOS selon les versions.
Elle surgit souvent pendant des opérations topologiques comme intersects() ou overlaps(), au pire moment, quand votre pipeline tourne en production.
Le message cite parfois une coordonnée précise du type side location conflict at 4.2314434050749767 51.619151982899062, comme si votre polygone avait trébuché sur un pavé mal aligné.
Qu'est-ce que la TopologyException "side location conflict" dans Shapely ?
La TopologyException correspond à une exception levée par GEOS quand il détecte un conflit topologique lors d’un calcul.
Le libellé exact « side location conflict » décrit un désaccord sur la “localisation latérale” d’un segment ou d’une frontière pendant l’évaluation.
Shapely ne fait que relayer l’erreur, puisque GEOS exécute le moteur des opérations topologiques.
Cette exception apparaît souvent pendant intersects(), overlaps() ou des opérations similaires qui exigent une topologie cohérente.
Le message standard « This can occur if the input geometry is invalid » induit en erreur, car l’échec survient aussi avec des géométries qui passent is_valid().
Plusieurs rapports mentionnent le souci sur Shapely 2.0.5 avec GEOS 3.11+ à 3.13, avec des coordonnées comme -18.954926312734656 -132.64786633489828.
Causes principales de l'erreur
Géométries complexes ou malformées
Le paradoxe frappe souvent ici : is_valid() annonce “tout va bien”, puis overlaps() ou intersects() déclenche une exception, comme si la géométrie avait un vice caché.
Les MultiPolygon denses, avec beaucoup d’anneaux et de sommets, accentuent ce type de conflit, surtout quand des frontières frôlent d’autres frontières à l’échelle du cheveu.
Le message pointe parfois une coordonnée, ce qui donne un indice sur la zone exacte où la topologie se contredit.
- MultiPolygon avec 6+ parties et 32+ sommets.
- Import de géométries depuis un shapefile.
- Polygones tracés depuis une photo ou une numérisation.
- Overlaps entre polygones “valides” au sens de is_valid().
Le même type de conflit remonte aussi dans PostGIS ou Inkstitch, ce qui renforce l’idée d’un problème de “conflit latéral” au niveau du moteur géométrique.
Le bug ne vit pas uniquement dans votre code, il vit aussi dans la façon dont certaines topologies se résolvent au millimètre.
Problèmes de versions GEOS/Shapely
Une autre cause fréquente vient d’un bug ou d’une incompatibilité entre versions, en particulier autour de Shapely 2.0.5.
Des retours signalent une persistance sous Linux sur intersects(), même après des tentatives de nettoyage de géométrie.
Dans ce cas, la géométrie sert parfois de bouc émissaire, alors que la version de GEOS fait la pluie et le beau temps.
| Version/Contexte | Statut rapporté | Conséquence typique |
|---|---|---|
| GEOS 3.11–3.12 | Bug confirmé | TopologyException sur opérations topologiques. |
| GEOS 3.13.0 | Correction partielle | Overlaps mieux, Intersects signalé encore instable sur Linux. |
| Dernières releases (au 3 avril 2025) | Correctif annoncé | Disparition des cas connus selon retours et patchs. |
Comment diagnostiquer l'erreur rapidement
Le diagnostic vise un objectif simple : savoir si vous combattez une géométrie capricieuse ou un bug GEOS lié à votre stack.
Les tests ci-dessous restent courts et reproductibles, donc exploitables dans un projet pressé.
- Exécutez is_valid() sur les deux géométries avant l’opération.
- Réduisez le cas à un script minimal : charger en WKB, faire un assert geom.is_valid, puis lancer overlaps() ou intersects().
- Reproduisez hors Shapely via geosop pour isoler le moteur GEOS du reste de votre environnement.
- Vérifiez les versions avec pip show shapely puis la version GEOS via geosop, notez aussi l’OS si vous êtes sous Linux, et journalisez les coordonnées d’erreur en prod.
Solutions immédiates et workarounds
Downgrade GEOS vers 3.10.x
Le downgrade vers GEOS 3.10.x représente le raccourci le plus rentable dans une grande partie des cas rapportés.
Plusieurs retours confirment qu’un rollback depuis GEOS 3.13.0 ou depuis la série 3.11–3.12 fait disparaître l’exception sur intersects() ou overlaps().
Cette approche évite de charcuter vos géométries, ce qui économise du temps et limite les surprises métier.
- Commande conda : conda install geos=3.10.
- Cas d’usage : Retour depuis GEOS 3.13.0 quand intersects() casse sous Linux.
- Vérification : Relancez vos tests intersects() et overlaps() sur un échantillon représentatif.
Utiliser make_valid() ou buffer(0)
Le duo make_valid() et buffer(0) sert de balai topologique : il nettoie les incohérences et recalcule une géométrie “utilisable” pour les opérations.
Cette méthode a un prix, car elle peut modifier la forme, surtout quand des polygones se chevauchent.
- Syntaxe Shapely : shapely.make_valid(geom) et le classique geom.buffer(0).
- Variante NTS : feature.MakeValid() selon les outils et chaînes de traitement.
- Limite principale : Fusion ou altération sur des MultiPolygon avec des zones overlapping.
- Risque concret : Changement de forme et suppression de zones communes.
Cette approche fonctionne bien quand vous traitez des entités séparées, sans recouvrement interne ambigu.
Elle déforme parfois le rendu, donc elle exige une validation visuelle ou métier si la géométrie sert à facturer, délimiter, ou trancher un litige.
Mettre à jour vers dernières versions
La mise à jour vers une paire GEOS/Shapely récente corrige une partie des anomalies, notamment autour de overlaps().
Une vérification de compatibilité s’impose avant upgrade, car les environnements SIG vivent rarement seuls dans leur coin.
| À vérifier | Pourquoi |
|---|---|
| Version GEOS/Shapely. | Les correctifs dépendent du couple de versions, pas d’un seul paquet. |
| OS (Linux). | Des retours signalent encore intersects() instable selon le build. |
| Lien changelog/référence (libgeos/geos#1026). | Le suivi upstream indique ce qui a été corrigé et quand. |
Les retours indiquent un correctif complet au 3 avril 2025 sur les dernières releases.
Des cas restent signalés sur intersects() sous Linux selon les environnements, donc un test de non-régression garde sa place.
Prévenir l'erreur dans vos projets
La prévention vise la production : réduire les plantages, limiter les cas non reproductibles, garder des logs exploitables.
Une simple validation is_valid() ne suffit pas, car c’est l’opération topologique elle-même qui déclenche la crise.
- Validez is_valid() et testez intersects/overlaps sur vos cas critiques.
- Encadrez avec try/except GEOSException et utilisez un fallback buffer(0).
- Évitez les MultiPolygon overlapping dans une même feature.
- Faites la conversion “Polygon 2 sommets → MultiLineString” pour intersects (tel quel).
- Monitoriez et logguez les coordonnées du message d’erreur pour détecter des patterns.
