Thanks, George. I have updated https://issues.apache.org/jira/browse/CALCITE-4186 <https://issues.apache.org/jira/browse/CALCITE-4186> based upon your remarks.
Julian > On Sep 28, 2020, at 7:23 AM, George Percivall <[email protected]> wrote: > > Julian, > > Thanks for posting information about your progress. > > The links that you provide for CALCITE draw on this blog: > http://lin-ear-th-inking.blogspot.com/2007/06/subtleties-of-ogc-covers-spatial.html > The blog proposes a Covers operation. > I was not familiar with Martin’s blog so had to reach out to some people more > versed than me in Simple Features and the DE-9IM. > Surprisingly since the blog was written in 2007 and that it also appears that > Covers in in PostGIS, there is was no familiarity with Martin’s blog. > > If implemented in accordance with DE-9IM, there is no need to add a Covers > operation. > Davis is pretty explicit in his blog about this assumption: "Polygons do not > contain their boundary". > But DE-9IM, Simple Features and published papers that led to the standards > treat polygons as closed, i.e., the polygons contain their boundaries. > Davis’s assumption that polygons are open, i.e., dont contain their boundary, > leads to a misinterpation of the Contains operation. > When implemented in accordance with the standards, the addition of Covers is > not needed. > > Implementing Simple Features Contains consistent with the standard is a > better course than adding a Covers operation. > The SF spec is free: > https://portal.opengeospatial.org/files/?artifact_id=25354 > > Regards, > George > > >> On Sep 24, 2020, at 7:29 PM, Julian Hyde <[email protected]> wrote: >> >> Thank you, Martin. I don't work full-time in GIS (I spend about a week >> thinking about GIS every two years) and resources like this are very >> useful to keep me up to date. Please keep them coming! >> >> In other news. I finally merged two Geospatial features into Calcite's >> master branch [1] [2]. These make it possible to add efficient >> Geospatial indexing in a DB that does not have specialized Geospatial >> data structures; regular b-tree indexes or sorted tables are >> sufficient. I'm sure these approaches are well below a specialized GIS >> system in terms of performance, but allow you to build a hybrid system >> that does other things (e.g. streaming, documents, XML, analytics) >> well also. >> >> Julian >> >> [1] https://issues.apache.org/jira/browse/CALCITE-1861 >> >> [2] https://issues.apache.org/jira/browse/CALCITE-2160 >> >> On Wed, Sep 23, 2020 at 1:34 PM Martin Desruisseaux >> <[email protected]> wrote: >>> >>> Hello all >>> >>> Last week, an Open Geospatial Consortium (OGC) virtual meeting was hold. >>> During that meeting, we got a link to a video about dynamic Coordinate >>> Reference Systems (CRS). This video explains issues to be aware for >>> anyone who wants to locate a point on Earth with a precision better than >>> 3 meters. In particular the use of WGS84 is not sufficient for such >>> precision, unless coordinate values are completed by an epoch. >>> >>> https://youtu.be/IKM-bR6SwVs >>> >>> This video is produced by IOGP (International Association of Oil & Gas >>> Producers). IOGP is the creator and maintainer of the EPSG geodetic >>> dataset, which provides Coordinate Reference System definitions used by >>> about all GIS (Geographic Information Systems) to my knowledge. The >>> presenter is Roger Lott, who has been the editor of ISO 19111 >>> (referencing by coordinates) latest revision, of ISO 19162 (Well Known >>> Text 2) standard and is currently leading the standardization of a file >>> format for datum shift grids deformation models and more. The recent >>> advances in OGC/ISO international standards on referencing by >>> coordinates owe him a lot. >>> >>> More details on the topic discussed in the video can be found there: >>> >>> >>> https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/ >>> >>> Martin >>> >>> > > > -- > <https://www.ogc.org/webinars> >
