<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Well, the old semantic has been there since 2.0, which is a very long time.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">A further question for it would be: what do the next functions do? What does a distance calculation between a 2d and 3d object return? does it also respect that semantic? </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">P</div> <div id="bloop_sign_1424783296256082176" class="bloop_sign">

        <title></title>

        <div>

            <br>

        </div>

        -- <br>

        Paul Ramsey<br>

        http://cleverelephant.ca<div>http://postgis.net

</div>

<script type="application/ld+json">

{

  "@context": "http://schema.org",

  "@type": "em",

  "name": "John Doe",

  "jobTitle": "Graduate research assistant",

  "affiliation": "University of Dreams",

  "additionalName": "Johnny",

  "url": "http://www.example.com",

  "address": {

    "@type": "PostalAddress",

    "streetAddress": "1234 Peach Drive",

    "addressLocality": "Wonderland",

    "addressRegion": "Georgia"

  }

}

</script>

</div> <br><p style="color:#000;">On February 24, 2015 at 7:44:23 AM, Sandro Santilli (<a href="mailto:strk@keybit.net">strk@keybit.net</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>For the record, I've committed code ensuring the stated semantic

(missing dimensions have infinite range).

<br>

<br>BUT, I found a document of yours that expects differently-dimensioned

<br>geometries to not overlap:

<br>http://workshops.boundlessgeo.com/postgis-intro/3d.html

<br>

<br>Snippet:

<br>

<br>  -- Returns false (one 2-D one 3-D)

<br>  SELECT 'POINT Z (1 1 1)'::geometry &&&

<br>         'POLYGON ((0 0, 0 2, 2 2, 2 0, 0 0))'::geometry;

<br>

<br>That query returns TRUE now, for the 2-D polygon having an

infinite Z range.

<br>

<br>Is that enough exposure to require a mention in the NEWS as a

backward incompatible change ?

<br>

<br>REF: http://trac.osgeo.org/postgis/ticket/3045

<br>

<br>--strk;

<br>

<br>On Thu, Feb 19, 2015 at 06:44:38PM +0100, Sandro Santilli wrote:

<br>> On Thu, Feb 19, 2015 at 09:04:16AM -0800, Paul Ramsey wrote:

<br>> > My preference was always to allow, for example, a 2d query box to extract a 3d column of data from a volume of points, and I would have implemented that way if I could. Now, what i cannot tell you, is why I felt I couldn’t…

<br>>  

<br>> So your preference here is for number 2:

<br>>  

<br>>     1. Missing dimension is unknown, return NULL

<br>>  -> 2. Missing dimension is infinite, contains everything <-

<br>>     3. Missing dimension is empty, contains nothing

<br>>     4. An impossible comparison was requested, raise exception

<br>>  

<br>> That is a 2d query box is infinitely tall and 2d points are found

<br>> in 3d boxes at any height. Sounds good to me, as long as documented

> as such and consistently enforced.

<br>>  

<br>> For example, in the query reported in

<br>> http://trac.osgeo.org/postgis/ticket/3045

> rows 2,3,4 and 5 should be reported to overlap the query box, right ?

<br>>  

<br>> --strk;

<br>>  

<br>> > On February 19, 2015 at 8:46:22 AM, Sandro Santilli (strk@keybit.net) wrote:

<br>> > > The current &&& operator assumes 0 as the value of dimensions that are

<br>> > > missing from one of the operands.

<br>> > >   

<br>> > > This results in confusing behavior, like this:

<br>> > >   

<br>> > > select 'POINT(0 0)'::geometry &&& 'POINT(0 0 1)'::geometry; -- false

<br>> > > select 'POINT(0 0)'::geometry &&& 'POINT(0 0 0)'::geometry; -- true

<br>> > >   

> > > I think the above two selects should give the same answer instead.

<br>> > > Possibilities are:

<br>> > >   

<br>> > > 1. Missing dimension is unknown, return NULL

<br>> > > 2. Missing dimension is infinite, return true

<br>> > > 3. Missing dimension is empty, return false

<br>> > > 4. An impossible comparison was requested, raise exception

<br>> > >   

<br>> > > Which one would you prefer ?

> > > And what constraints do we have being the operator used by index scan ?

<br>> > >   

<br>> > > --strk;

<br>> > >   

<br>> > > () Free GIS & Flash consultant/developer

<br>> > > /\ http://strk.keybit.net/services.html

<br>> > >   

<br>> >  

<br></div></div></span></blockquote></body></html>