Discussion :

[Alexandre T]

Bonjour à tous,

J'ai décidé de reprendre le projet opensource doctrine-spatial. Doctrine, un abstracteur de base de données, permet de faire le lien entre les objets PHP et la base de données. Doctrine spatial est une extension pour intégrer les types géométriques, géographiques et les fonctions spatiales. Le projet est dormant depuis 2017. Je le reprends. Je remarque dans le code quelques écueils que je voudrais éviter.

Par exemple, la fonction CONTAINS permet de déterminer si un objet en contient un autre. En MySQL 5.7, elle se nommait CONTAINS, en MySQL 8.0, elle se nomme ST_CONTAINS, en PostgreSQL, elle se nomme ST_CONTAINS et en MariaDB, l'algorithme est différent et ne renvoie pas le même résultat qu'en MySQL 5.7. (Je crois que les arguments sont inversés, mais je n'ai pas vérifié).

Bref, l'objectif d'un abstracteur de données est de rendre l'application compatible quelque soit le moteur de base de données derrière. Actuellement, le développeur se retrouve à créer des requêtes DQL (Doctrine Query Language), mais il doit adapter le nom des fonctions en fonction du SGBD. Je trouve cela incohérent avec l'objectif de doctrine : faire abstraction du SGBD.

La solution que j'ai choisie pour choisir la syntaxe de la fonction est la suivante :

• Je privilégie la norme SQL,
• À défaut, je suis la syntaxe de PostgreSQL puis de Microsoft SQL Server (j'ai bon espoir que quelqu'un me propose un "pull request" un jour)
• Voire je privilégie ce que décrit l'OGC (Open Geospatial Consortium) (travail fastidieux)

Derrière ce vœu pieu, je suis confronté à un problème, je ne trouve rien dans la norme SQL définissant les fonctions spatiales.

Existe-t-il une norme, une extension de la norme, définissant les fonctions spatiales ? L'objectif est de sélectionner un nom standardisé et un ordre des arguments standardisé également.

[SQLpro]

Comme j'ai beaucoup travaillé sur le spatial (voir les articles que j'ai écrit à ce sujet), je te confirme différents points :
1) la norme SQL est un sous ensemble du standard OGC. Tu peut donc te caler sur le standard OGC, car tôt ou tard, les fonctions SQL normalisées seront celles de la norme. Cependant, les SGBDR étant ensembliste, certaines fonctions ne peuvent s'appliquer tandis que d'autres sont spécifiques aux algorithmes spatiaux apppliquées à un monde ensembliste (par exemple agrégation spatiale)
2) PostgreSQL suit la norme de très près, mais d'un peu trop. En effet, la norme ce sont des fonctions dont le nom commence par ST_. Mais PostgreSQL y a ajouté beaucoup de fonctions en ST_ qui n'ont rien à voir avec la norme. Si certaines nouvelles fonctions normalisées voient le jour dans le futur, il est possible qu'elles utilisent un nom déjà pris par PostgreSQL conduisant a une différence fonctionnelle, ce qui est problématique. Par exemple PostgreSQL propose la fonction ST_MakeValid qui n'existe pas dans le standard OGC ni dans la norme…. Mais il est probable qu'elle soit réalisée un de ces jour… Et pour information, elle ne donne pas le même résultat que la méthode MakeValid (sans ST_) de MS SQL Server…
3) SQL Server utilisant des méthodes appliquées aux types GEO (du fait de la programmation objet, car utilisation de la machine .net de manière sous-jacente pour les algorithme GEO) les noms sont légèrement différents car en notation objet pointée par une méthode et non pas en application de fonctions. De ce fait pour bien distinguer la chose MS a décidé d'omettre le caractère underscore qui suit le préfixe ST...
4) le spatial dans MySQL / MariaDB est fortement bugué en sus d'être très imprécis. En gros il est inexploitable !

A +

PS : mes articles :
https://blog.developpez.com/sqlpro/p...on_geographiqu
https://blog.developpez.com/sqlpro/p..._geographiqu_2

[Alexandre T]

Merci beaucoup Frédéric,

Je vais me baser sur ce document : http://portal.opengeospatial.org/fil...ifact_id=25354 et notamment le chapitre 7.2.8.2
Je te rejoins sur le fait que c'est inexploitable en MySQL. Les fonctions Contains et ST_Contains retournent des résultats différents et certaines fonctions ne retournent pas le même résultat sous MariaDB, qui est pourtant un Fork. Bref... Je le maintiens, car je ne vais pas supprimer ce qui existe, mais ce n'est vraiment pas mon objectif principal. Je change les tests réalisés par mon prédecesseur pour me limiter au fait que la fonction n'explose pas, qu'elle accepte les bons arguments (dans le bon ordre sic), mais je ne compare plus les résultats. (MySQL5.7 et MySQL8, ne retourne pas le même résultat pour la surface d'un point après être passé dans la fonction st_buffer. ST_AREA(ST_BUFFER(POINT(0 0),3)))

Ce que tu dis sur le respect de la norme va me poser un souci je pense. Du coup, voilà ce que je pense faire. Je préfixe le mot-clé du langage DQL par ST si et seulement si la fonction est déclarée dans les documents de l'OGC sinon je la préfixe par SP_ (pour spécific) afin d'éviter tout conflit avec une fonction ou un mot clé SQL existant (Je pense à la méthode UNION par exemple).

• Pour Area, j'aurai donc ST_AREA en DQL, que j'utilise la fonction SQL Area(MySQL5.7), ST_Area(MySQL8 et PostGreSQL)
• Pour MakeValid, j'aurai donc SP_AREA en DQL que même si derrière j'appelle la fonction SQL ST_MakeValid de PostGreSQL.

Il n'y aura pas de problème de rétrocompatibilité, puisque :

1. Je changerai le numéro de version pour bien stipuler que je n'assure pas toute la rétrocompatibilité
2. Les développeurs utilisant la librairie (dans Symfony notamment) peuvent changer le mot clé DQL par celui de leur choix pour leur application via un fichier de configuration.

Je note comme résolu, j'ai mes réponses

Merci beaucoup pour les liens, je vais lire de suite !

[SQLpro]

ça me parait jouable….. !

Pour l'anecdote voici une bug particulièrement croustillant sur MySQmerde :
https://blog.developpez.com/sqlpro/p...oudre_aux_yeux

Cherche GeomFromtext….

A +

[Alexandre T]

Bonjour Frédéric,

Oui j'avance dans le développement et je me retrouve confronté à de nombreux problèmes dans les tests.
Par exemple, la fonction ST_Buffer accepte bien le bon nombre d'arguments, mais en MySQL, le troisème argument ne peut accepter qu'un type, le retour de la fonction ST_Buffer_Strategy. Une invention MySQL qui me donne l'impression qu'ils ont choisi une solution de facilité.

En revanche, MySQL reste toujours incapable de couper une ligne en deux.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SET @ligneA = ST_GeomFromText('LINESTRING(0 0, 10 10)');
SET @ligneB = ST_GeomFromText('LINESTRING(10 0, 0 10)');
SELECT ST_AsTEXT(ST_DIFFERENCE(@ligneA, @ligneB)) AS DIFFERENCE, VERSION() as VERSION;

DIFFERENCE	VERSION
LINESTRING(0 0,10 10)	8.0.19

Alors que le résultat attendu est une ligne coupée, cad une multiligne composée de deux lignes qui se séparent en (5 5)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT ST_AsText(ST_DIFFERENCE(
    ST_GeomFromText('LINESTRING(0 0, 10 10)'), 
    ST_GeomFromText('LINESTRING(10 0, 0 10)')
)), VERSION();

DIFFERENCE	VERSION
MULTILINESTRING((0 0,5 5),(5 5,10 10))	"PostgreSQL 9.6.6, compiled by Visual C++ build 1800, 64-bit"

La création des tests unitaires en devient infernale.

Est-ce qu'il existe une traduction anglosaxone de ton billet ? Je voudrais en faire mention dans le README de la librairie sous l'avertissement où je déconseille avec vigueur d'utiliser mysql comme mariadb.

Deuxième souci, je galère sans exemplaire de la norme ISO/IEC 13249-3:2016. (Et je n'ai pas 300€ pour l'acheter, je suis en train de la négocier avec mon employeur, mais ce n'est pas gagné). Je galère justement concernant ce que tu disais sur Postgis. PostGis préfixe par ST toutes les fonctions, y compris celle qui sont propres à PostgreSQL.
Par exemple, la fonction ST_ConvexHull reçoit une collection comme paramètre, je voulais utiliser ST_COLLECT pour rassembler des géométries et faire des tests, mais je ne trouve pas de trace de cette fonction dans le géostandard.

Y aurait-il une documentation, une publication du standard autre que celle que j'utilise ? https://www.ogc.org/standards/sfs

[SQLpro]

Est-ce qu'il existe une traduction anglosaxone de ton billet ? Je voudrais en faire mention dans le README de la librairie sous l'avertissement où je déconseille avec vigueur d'utiliser mysql comme mariadb.

Hélas non, mais un coup de google translate et quelques corrections….

Deuxième souci, je galère sans exemplaire de la norme ISO/IEC 13249-3:2016. (Et je n'ai pas 300€ pour l'acheter, je suis en train de la négocier avec mon employeur, mais ce n'est pas gagné). Je galère justement concernant ce que tu disais sur Postgis. PostGis préfixe par ST toutes les fonctions, y compris celle qui sont propres à PostgreSQL.
Par exemple, la fonction ST_ConvexHull reçoit une collection comme paramètre, je voulais utiliser ST_COLLECT pour rassembler des géométries et faire des tests, mais je ne trouve pas de trace de cette fonction dans le géostandard.

Y aurait-il une documentation, une publication du standard autre que celle que j'utilise ? https://www.ogc.org/standards/sfs

Tu peut partir sur le standard OGC....

A +