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>
