#1 Mon 28 June 2021 12:02
Incohérence de résultat d'intersection Spatialite
Bonjour à toutes et tous,
peux présent sur le forum depuis trop longtemp, me revoilà avec une incohérence que je n'arrive pas à comprendre, dans spatialite, pour les besoins d'un étudiant :
Je dispose de deux tables, une de point d'observation d'espèce (109418 lignes), une de mailles carrée (2921 enregistrements)
Je souhaite compter le nombre de taxons observés par maille mais le résultat est incohérent.
Une requête toute basique qui liste les mailles en intersection avec les données me retourne l'ensemble des mailles (2921 lignes) au lieu des 642 attendues...
Est-ce que je passe à coté d'une subtilité de spatialite ?
Code:
select distinct carroyage.id FROM carroyage, donnees WHERE st_intersects(carroyage.geom, donnees.geom)
La syntaxe JOIN ON me retourne bien sûr le même résultat.
Merci d'avance pour vos éclairages éventuels...
Mathieu BOSSAERT
Association GeoRezo
Hors ligne
#2 Mon 28 June 2021 13:36
- tumasgiu
- Membre
- Lieu: Ajaccio
- Date d'inscription: 5 Jul 2010
- Messages: 1160
Re: Incohérence de résultat d'intersection Spatialite
Salut
y'a t'il dans données des lignes avec des géométries qui valent NULL ?
Si oui, st_intersects va alors renvoyer -1 qui apparemment serait évalué comme la valeur vrai
dans la clause WHERE, et donc tous les carreaux vont avoir au moins un match.
http://www.gaia-gis.it/gaia-sins/spatia … atest.html
Dernière modification par tumasgiu (Mon 28 June 2021 13:39)
Hors ligne
#3 Mon 28 June 2021 14:24
Re: Incohérence de résultat d'intersection Spatialite
Merci Tumas !!!
C'était bien ça. Je n'y aurai jamais pensé ! En tout cas pas avant quelques jours de repos qui se font attendre :-)
J'ai donc complété la clause WHERE avec des conditions NOT NULL sur les deux géométries.
Et j'ai un résultat conforme à ce que j'obtiens avec PostGIS.
Code:
select distinct carroyage.id FROM carroyage JOIN donnees ON st_intersects(carroyage.geom, donnees.geom) WHERE carroyage.geom IS NOT NULL AND donnees.geom IS NOT NULL
Mathieu BOSSAERT
Association GeoRezo
Hors ligne
#4 Mon 28 June 2021 15:53
- tumasgiu
- Membre
- Lieu: Ajaccio
- Date d'inscription: 5 Jul 2010
- Messages: 1160
Re: Incohérence de résultat d'intersection Spatialite
Le repos c'est important en effet
Je pense que la requête aurait même pu être simplifiée comme ceci :
Code:
select distinct carroyage.id FROM carroyage, donnees WHERE st_intersects(carroyage.geom, donnees.geom) > 0
Hors ligne
#5 Tue 29 June 2021 09:53
Re: Incohérence de résultat d'intersection Spatialite
Oui c'est sûr !
Je n'ai pas pris le temps de regarder la doc de sqlite.
Qui mentionne ceci :
2.1. Boolean Datatype
SQLite does not have a separate Boolean storage class. Instead, Boolean values are stored as integers 0 (false) and 1 (true).
il me faudra creuser mais cje trouve curieux que
Code:
SELECT -1 is true ou SELECT -500 is true
retournent 1.
Comme si en fait toute valeur entière, positive ou négative autre que 0 soit évaluée comme "true"
Mais c'est surtout la doc de la fonction st_intersects de spatialite que j'aurais du lire !
The return type is Integer, with a return value of 1 for TRUE, 0 for FALSE, and –1 for UNKNOWN corresponding to a function invocation on NULL arguments;
convenience predicate: TRUE if the intersection of g1 and g2 is not empty
Merci encore Tumas.
Mathieu BOSSAERT
Association GeoRezo
Hors ligne
#6 Tue 29 June 2021 11:43
- tumasgiu
- Membre
- Lieu: Ajaccio
- Date d'inscription: 5 Jul 2010
- Messages: 1160
Re: Incohérence de résultat d'intersection Spatialite
il me faudra creuser mais cje trouve curieux que
Code:
SELECT -1 is true
ou
SELECT -500 is true
retournent 1.
Comme si en fait toute valeur entière, positive ou négative autre que 0 soit évaluée comme "true"
Je pense que ca vient du C (sqlite est écrit en C) ou le type booléen n'existe pas et que faux = 0 et vrai = tout le reste.
Ce que je me demande, c'est pourquoi les dev de spatialite ont décidé qu'une fonction dont au moins l'un des arguments
est NULL ne devait pas renvoyer NULL (je ne sais pas si c'est dans le standard SQL, mais c'est tout de même
une convention que j'ai tout le temps rencontré dans les autres sgbd).
Cela a peut être à voir avec le fait que spatialite utilise geos comme backend, et que les fonctions geos renvoie des entiers,
c'était peut être plus simple à développer comme çà.
Hors ligne