¿Es el prefijo ST_ apropiado para funciones no incluidas en SQL / MM Parte 3?

12

Estaba leyendo un hilo sobre la extensión geoespacial para Presto en este tema de Github , donde line_locate_pointse introdujo una función . Se basó en la ST_LineLocatePointfunción de PostGIS , que devuelve un flotante que representa la fracción a lo largo de una línea del punto más cercano en esa línea a una ubicación determinada.

Se planteó la pregunta de por qué se nombró line_locate_pointy no ST_LineLocatePointcomo la versión PostGIS. La respuesta fue que esta función no existe en el estándar SQL / MM Parte 3, por lo que no debería comenzar con ST_.

Al leer rápidamente el estándar, no veo ningún comentario sobre cómo manejar los casos en los que introduce una función espacial en su base de datos que no está en el estándar. ¿El espíritu del ST_prefijo es diferenciar funciones espaciales de funciones no espaciales (como parece ser el caso con PostGIS), o es para indicar que la función cumple con una función equivalente en SQL / MM Parte 3?

Mirando el estado actual de la API de Presto , tengo que decir que el último enfoque parece menos limpio e introduce cierta confusión en cuanto a por qué los nombres no son consistentes, pero quizás esto podría abordarse con una simple nota en la parte superior.

Mi pregunta, entonces, es si hay algún aspecto del estándar que estoy pasando por alto que permita extensiones más allá del conjunto definido de objetos espaciales, o alternativamente, si esto está expresamente prohibido por alguna regla escrita o no escrita de seguir los estándares .

postgis sql spatial-database standards Brideau
fuente
Creo que es una pregunta justa, pero esencialmente se reduce a una cuestión de opinión. Espero que todas las funciones que son manifiestamente espaciales, es decir, operen en un vector, ráster, topología, superficie 3D, etc., tomen el prefijo ST_. Nunca se me había ocurrido preguntar si este era un uso apropiado en función de si estaba en una especificación o no. Si bien la interoperabilidad es importante y deseable, ciertamente no me gustaría que Postgis se detenga al implementar solo funciones en la especificación SQL / MM. Y creo que usar algún otro prefijo causaría mucha confusión.
John Powell
No entiendo por qué mi pregunta se suspendió por estar "basada en la opinión". Mi pregunta es explícitamente si está basada en una opinión o si hay algún aspecto del estándar que estoy pasando por alto que hace que esta decisión esté basada en hechos.
Brideau
Disculpas, acabo de volver a leer su pregunta y, de hecho, hay una pregunta clara y sin opiniones. Mi 2c es que si es explícitamente espacial, obtiene un ST_, independientemente de si está en los estándares o no. He emitido un voto de reapertura.
John Powell
En mi opinión, se basa en la opinión. El estándar SQL / MM no puede negar que los desarrolladores creen sus propias funciones con el prefijo ST_ si lo desean, incluso las funciones no espaciales. Sin embargo, los desarrolladores pueden decidir hacerlo de otra manera. Como comparación, SpatiaLite tiene muchas funciones espaciales pero no SQL / MM que tienen sinónimos ST_, algunas otras que no tienen gaia-gis.it/gaia-sins/spatialite-sql-latest.html .
user30184
Si SQL / MM puede o no forzar o no a un desarrollador a hacer algo no es la pregunta que estoy haciendo. Estoy preguntando qué recomienda el estándar en sí. El estándar tiene 1500 páginas y no he leído cada línea, por lo que le pregunto a la comunidad aquí, algunos de los cuales ayudan a escribirlo y los estándares relacionados, qué se recomienda, o tal vez si difiere estas decisiones. otro estándar o eligió explícitamente no abordar esto. Estas son solicitudes basadas en hechos.
Brideau

Respuestas:

1

La especificación OpenSpatial dice numerosas cosas sobre esto,

Al integrar este SQL con el de SQL / MM, el prefijo de nombre de tipo " ST_" debe usarse según corresponda.

Y,

Los nombres de clase en SQL / MM llevan un " ST_" prefijo. Esto es opcional y las implementaciones pueden optar por eliminar este prefijo como se ha hecho en varios lugares en este estándar.

De este Comité Borrador ISO / IEC CD13249-3 ed 5

Esta parte de ISO / IEC 13249 usa el prefijo ST_para el tipo definido por el usuario, el atributo, la tabla de rutina invocada por SQL y los nombres de vista. Esta parte de ISO / IEC 13249 usa el prefijo ' ST_Private' para los nombres de ciertos atributos. El uso de ' ST_Private' indica que el atributo no es para uso público.

Entonces aquí está lo que tenemos,

  • SQL / MM sugiere usar el prefijo.
  • SQL / MM dice que el prefijo es opcional.
  • ISO también usa el ST_prefijo.

Yo diría esto

  • El uso de ST_debe considerarse como palabras clave no reservadas para los usuarios finales. Realmente no hay razón para hacer funciones de usuario final con este prefijo. Es mejor que solo lo uses STx_. Sabemos de al menos dos cuerpos que han publicado con este prefijo sugerencias (OpenSpatial) SQL / MM e ISO. Además, muchos símbolos de RDBMS contaminan con ese prefijo.

Puede haber más en la historia, pero no puedo encontrar más información contemporánea sobre esto.

Evan Carroll
fuente