Le préfixe ST_ convient-il aux fonctions non incluses dans SQL / MM partie 3?

12

Je lisais un fil sur l'extension géospatiale pour Presto dans ce numéro Github , où une fonction line_locate_point, a été introduite. Il était basé sur la ST_LineLocatePointfonction de PostGIS , qui renvoie un flottant représentant la fraction le long d'une ligne du point le plus proche sur cette ligne jusqu'à un emplacement donné.

La question a été soulevée pourquoi il a été nommé line_locate_pointet non pas ST_LineLocatePointcomme la version PostGIS. La réponse a été que cette fonction n'existe pas dans la norme SQL / MM Part 3 et qu'elle ne doit donc pas commencer par ST_.

En lisant rapidement la norme, je ne vois aucun commentaire sur la façon de gérer les cas où vous introduisez une fonction spatiale dans votre base de données qui n'est pas dans la norme. L'esprit du ST_préfixe est-il de différencier les fonctions spatiales des fonctions non spatiales (comme cela semble être le cas avec PostGIS), ou est-ce pour indiquer que la fonction est conforme à une fonction équivalente dans SQL / MM Partie 3?

En regardant l' état actuel de l'API de Presto , je dois dire que cette dernière approche semble moins propre et introduit une certaine confusion quant à la raison pour laquelle les noms ne sont pas cohérents, mais cela pourrait peut-être être résolu par une simple note en haut.

Ma question est donc de savoir s'il existe un aspect de la norme que j'écarte qui autorise des extensions au-delà de l'ensemble défini d'objets spatiaux, ou alternativement, si cela est expressément interdit par une règle écrite ou non écrite des normes suivantes .

postgis sql spatial-database standards Brideau
la source
Je pense que c'est une question juste, mais qui se résume essentiellement à une question d'opinion. Je m'attends à ce que toutes les fonctions qui sont manifestement spatiales, c'est-à-dire qu'elles opèrent sur un vecteur, un raster, une topologie, une surface 3D, etc., prennent le préfixe ST_. Il ne m'était jamais venu à l'esprit de demander si c'était une utilisation appropriée, selon que c'était dans une spécification ou non. Bien que l'interopérabilité soit importante et souhaitable, je ne voudrais certainement pas que Postgis soit freiné par l'implémentation de fonctions uniquement dans la spécification SQL / MM. Et je pense que l'utilisation d'un autre préfixe causerait beaucoup de confusion.
John Powell
Je ne comprends pas pourquoi ma question a été simplement suspendue parce qu'elle était "basée sur l'opinion". Ma question est explicitement de savoir si elle est fondée sur l'opinion, ou s'il y a un aspect de la norme que j'écarte qui rend cette décision fondée sur des faits.
Brideau
Toutes mes excuses, je viens de relire votre question et il y a en effet une question claire, sans opinion. Mon 2c est que s'il est explicitement spatial, il obtient un ST_, qu'il soit ou non dans les normes. J'ai voté à nouveau.
John Powell
Pour moi, c'est basé sur l'opinion. La norme SQL / MM ne peut pas empêcher les développeurs de créer leurs propres fonctions avec le préfixe ST_ s'ils le souhaitent, même des fonctions non spatiales. Cependant, les développeurs peuvent souhaiter le faire d'une autre manière. À titre de comparaison, SpatiaLite possède de nombreuses fonctions spatiales mais non SQL / MM qui ont des synonymes ST_, d'autres qui n'ont pas gaia-gis.it/gaia-sins/spatialite-sql-latest.html .
user30184
Que SQL / MM puisse ou non forcer un développeur à faire quelque chose n'est pas la question que je pose. Je demande ce que la norme elle-même recommande. La norme fait 1 500 pages et je n'en ai pas lu toutes les lignes, je demande donc à la communauté ici - dont certains aident à l'écrire et aux normes connexes - ce qui est recommandé, ou peut-être si cela reporte ces décisions à une autre norme ou a explicitement choisi de ne pas y remédier. Ce sont des demandes fondées sur des faits.
Brideau

Réponses:

1

La spécification OpenSpatial dit de nombreuses choses à ce sujet,

Lors de l'intégration de ce SQL avec celui de SQL / MM, le préfixe de nom de type " ST_" doit être utilisé selon les besoins.

Et,

Les noms de classe dans SQL / MM portent un ST_préfixe " ". Ceci est facultatif et les implémentations peuvent choisir de supprimer ce préfixe comme cela a été fait à divers endroits dans cette norme.

De ce comité Projet ISO / IEC CD13249-3 ed 5

Cette partie de l'ISO / CEI 13249 utilise le préfixe ST_pour le type défini par l'utilisateur, l'attribut, la table de routage invoquée par SQL et les noms de vue. Cette partie de l'ISO / CEI 13249 utilise le préfixe ' ST_Private' pour les noms de certains attributs. L'utilisation de " ST_Private" indique que l'attribut n'est pas destiné à un usage public.

Voici donc ce que nous avons,

  • SQL / MM suggère d'utiliser le préfixe.
  • SQL / MM dit que le préfixe est cependant facultatif.
  • ISO utilise également le ST_préfixe.

Je dirais ceci,

  • L'utilisation de ST_doit être considérée comme un mot-clé non réservé pour les utilisateurs finaux. Il n'y a vraiment aucune raison de créer des fonctions d'utilisateur final avec ce préfixe. Vous feriez mieux d'utiliser simplement STx_. Nous connaissons au moins deux organismes qui ont publié avec ce préfixe des suggestions (OpenSpatial) SQL / MM et ISO. De plus, de nombreux symboles SGBDR polluent avec ce préfixe.

Il y a peut-être plus dans l'histoire, mais je ne peux trouver aucune information plus contemporaine à ce sujet.

Evan Carroll
la source