I was just wondering about what happens on the boundary. This should really be noted on the documentation for cts:element-attribute-pair-geospatial-boxes() and possibly elsewhere.
If northern boundaries are open, then the result makes sense. I know there is bad data in the database and that must map to the pole. As such, the quadrangle query using * cts:element-attribute-pair-geospatial-query*() doesn't specify boundaries-north-excluded and I get those 26 data points back. Of course, what I want is for "92 latitude" to never come back for the quadrangle by an option on the query and not by changing the index. Thanks. On Tue, Mar 19, 2013 at 3:37 PM, Mary Holstege <[email protected]>wrote: > On Tue, 19 Mar 2013 15:24:01 -0700, Alex Milowski <[email protected]> > wrote: > > > > > Why is -90 latitude treated differently from 90 latitude? > > > > I don't have time to look at this in detail right now, but there > is an important asymmetry in these bounds: > lower bounds are closed, upper bounds are open. > > If this were a regular range index, you would also get > results for everything less than the lowest bound and > everything greater than or equal to the upper bound. > That's true for geo as well, but harder to wrap your > brain around. > > Poles are special case code everywhere, so it is > possible there is an improperly handled edge case > here. (If I can talk about "edge" in the context of > a surface with no edges...) > > //Mary > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > -- --Alex Milowski "The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered." Bertrand Russell in a footnote of Principles of Mathematics
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
