[postgis-devel] Questions about compliance of PostGIS with OGC standards

[Simon Greener]

If my recollection is right, the ST prefix is not required, GEOMETRY and ST_GEOMETRY are interchangeable.

There is also the question as to whether true type inheritance is required: should there be an instantiable geometry supertype (singly inherited) or only instantiable subtypes like point.

⁣Get BlueMail for Android ​

On 8 Jan 2021, 12:58, at 12:58, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>
>
>> On Jan 5, 2021, at 1:32 PM, Aleksandra Stasiak
><aleksandra.stasiak at wmii.uni.lodz.pl> wrote:
>> 
>> Dear Sir/ Madam
>> I am an academic teacher and I am trying to write a scientific
>article about some aspects of databases and their extesions and I have
>some problems with understanding a few things connected with PostGIS
>(and compliance with the OGC standards). Could I ask you for help?
>> 
>> There is a sentence in the PostGIS documentation saying that "PostGIS
>is compliant with the Open Geospatial Consortium's (OGC) OpenGIS
>Specifications". However, on OGC websites, when we search for products
>compliant with the Simple Feature Access standard or with an older
>version, i.e. Simple Features SQL, PostGIS does not appear if we select
>products with the "Compliant Products Only" option or when we select
>products with the "Reference Implementations Only" option, only by
>searching with the "All Implementations" option. Why? Why is it not
>just compliant with these specifications? What kind of implementation
>of standards is that?
>
>https://www.ogc.org/resource/products/compliant?display_opt=3&specid=522
>https://www.ogc.org/resource/products/compliant?display_opt=3&specid=149
>
>I see Crunchy Certified PostGIS in there a couple times. Also old
>submissions by Refractions and Boundless.
>In any event, OGC Certification is a pay-to-play deal. We are
>"compliant" because we've followed and implemented the standard. The
>entry in the cerfified list are because Crunchy has spent the time to
>run the tests and submit them to OGC, and paid OGC some money to be
>listed as "officially certified". 
>
>In a very "shrinkwrapped software" touch, OGC also ties certifications
>to software release version, so in theory we have to go back and
>re-cerfity each time we do a release. As you can imagine, we don't have
>much appetite for that.
>
>> I have also noticed that PostGIS has the functions converting from
>WKT format such as ST_PointFromText, ST_LineFromText,
>ST_PolygonFromText, ST_GeomCollFromText, ST_MPointFromText etc. (for
>all clasess of geometries) with a more general ST_GeomFromText
>function. But for the WKB format there is no function like 
>ST_PolygonFromWKB or ST_GeomCollFromWKB, there are only
>ST_PointFromWKB, ST_LineFromWKB (or ST_LinestringFromWKB as alias) and
>of course more general ST_GeomFromWKB. Why PostGIS does not have
>functions converting from WKB for all classes (as it does for WKT)? It
>is not a problem? ST_GeomFromWKB is enough for compliance?
>
>If you read the actual compliance test, you'll find it's a joke. It was
>never updated for standards after the 1.0 standard, and is internally
>inconsistent in a number of places. In implementing SQL/MM, which is
>where a lot of these duplicative function signatures come from, we
>eventually stopped. For our implementation, which has just one actual
>database type (geometry) having 7 separate constructors (14! both WKT
>and WKB!) is pretty silly, and we probably shouldn't have done the WKT
>ones, but once they are added it's hard to remove them.
>
>> In many places of the documentation there are fragments saying that
>some function "Return a specified ST_Geometry value" (for instance in
>description of function ST_GeometryFromText). I know that ST_GEOMETRY
>is the root of the SQL/MM hierarchy of classes, but I don't understand
>these descriptions - PostGIS doesn't technically have ST_GEOMETRY type
>(it has geometry, geography, and some types for boxes). So does
>ST_GEOMETRY value denote here a value with geometry type, with geometry
>that would belong to the ST_GEOMETRY class according to the SQL/MM
>classification? 
>
>Yes, it looks like the documents use ST_Geometry and Geometry
>interchangeably. The only place where ST_ or not has a practical effect
>is the ST_GeometryType() and GeometryType() functions, that actually
>return different answers.
>
>
>> Is the compliance with OGC standard concern geometry type or
>geography type (or both)?
>
>OGC has nothing to say about geography, and has published no standards
>about how to handle geodetic objects. It's a massive blind spot but I
>guess none of their sponsors really cares. So for compliance only
>geometry really "matters", even though the function names are common
>between the two of them for a lot of things.
>
>ATB,
>
>P
>
>
>
>> I would be grateful for explaining these things to me.
>> Best wishes,
>> Aleksandra Stasiak
>> <Outlook-0k0ma5sf.png>
>> This message and its attachments are confidential and protected by
>law. If you are not the intended recipient of the message, please
>contact the  sender immediately and delete the message with its
>attachments. Also, in that case, further dissemination of the message
>or its  attachments, as well as sharing or disclosing their content in
>its  entirety or part is strictly forbidden.
>> 
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210108/f3ab1233/attachment.html>