13

I was reading a thread on the geospatial extension for Presto in this Github issue, where a function, line_locate_point, was introduced. It was based off PostGIS's ST_LineLocatePoint function, which returns a float representing the fraction along a line of the closest point on that line to a given location.

The question was brought up why it was named line_locate_point and not ST_LineLocatePoint like the PostGIS version. The response was that this function does not exist in the SQL/MM Part 3 standard, and so it should not start with ST_.

Reading quickly through the standard, I don't see any comments on how to handle cases where you introduce a spatial function to your database that is not in the standard. Is the spirit of the ST_ prefix to differentiate spatial functions from non-spatial functions (as seems to be the case with PostGIS), or is it to indicate that the function complies with an equivalent function in SQL/MM Part 3?

Looking at the current state of Presto's API, I have to say that the latter approach looks less clean and introduces some confusion as to why the names aren't consistent, but perhaps this could be addressed by a simple note at the top.

My question, then, is whether there is some aspect of the standard that I'm overlooking that allows for extensions to it beyond the defined set of spatial objects, or alternatively, if this is expressly forbidden by some written or unwritten rule of following standards.

Improve this question
7
  • I think it is a fair question, but, essentially comes down to a matter of opinion. I expect all functions that are manifestly spatial, ie, they operate on a vector, raster, topology, 3D surface, etc, to take the prefix ST_. It had never occcured to me to ask if this was appropriate usage based on whether it was in a spec or not. While interoperability is important and desirable, I certainly wouldn't want Postgis held back by only implementing functions in the SQL/MM spec. And I think using some other prefix would cause lots of confusion.
    – John Powell
    Commented May 4, 2018 at 11:11
  • I don't understand why my question was just put on hold for being "opinion based." My question is explicitly about whether it is opinion-based, or if there is some aspect of the standard I'm overlooking that makes this decision fact-based.
    – Brideau
    Commented May 4, 2018 at 13:41
  • Apologies, I have just re-read your question and there is indeed a clear, non-opinion based question in there. My 2c is that if it is explicitly spatial, it gets an ST_, irrespective of whether it is in the standards or not. I have cast a reopen vote.
    – John Powell
    Commented May 4, 2018 at 13:51
  • For my mind it is opinion based. SQL/MM standard cannot deny developers from creating their own functions with ST_ prefix if they want, even non-spatial functions. However, developers may deside to do it in another way. As a comparison SpatiaLite has many spatial but non-SQL/MM functions which have ST_ synonyms, some others which do not have gaia-gis.it/gaia-sins/spatialite-sql-latest.html.
    – user30184
    Commented May 4, 2018 at 14:31
  • Whether or not SQL/MM can or cannot force a developer to do something isn't the question I'm asking. I'm asking about what the standard itself recommends. The standard is 1500 pages long, and I haven't read every line of it, so I'm asking the community here - some of whom help to write it and related standards - what is recommended, or perhaps whether it defers these decisions to another standard or explicitly chose not to address this. These are fact-based requests.
    – Brideau
    Commented May 4, 2018 at 14:48

1 Answer 1

Reset to default
1

The OpenSpatial spec says numerous things about this,

When integrating this SQL with that of SQL/MM, the type-name prefix "ST_" should be used as appropriate.

And,

Class names in SQL/MM carry a "ST_" prefix. This is optional and implementations may chose to drop this prefix as has been done in various places in this standard.

From this Committee Draft ISO/IEC CD13249-3 ed 5

This part of ISO/IEC 13249 uses the prefix ST_ for user-defined type, attribute, SQL-invoked routinetable and view names. This part of ISO/IEC 13249 uses the prefix 'ST_Private' for names of certain attributes. The use of 'ST_Private' indicates that the attribute is not for public use.

So here is what we have,

  • SQL/MM suggests using the prefix.
  • SQL/MM says the prefix is however optional.
  • ISO uses the ST_ prefix too..

I would say this,

  • The use of ST_ should be thought of as non-reserved keywords to end users. There is really no reason to make end-user functions with this prefix. You're better off just using STx_. We know of at least two bodies that have published with this prefix suggestions (OpenSpatial) SQL/MM and ISO. In addition, many RDBMS's pollute symbols with that prefix.

There may be more to the history, but I can't find any more contemporary information on this.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.