<div dir="ltr"><div>Thanks Even. It make sense.</div><div>And that explains why I cannot use a bbox in projinfo with w==e and s==n to represent a single point. Unfortunately.<br></div><div>IMHO the boundaries of the bounding box are included in the region, so a boundary with w==e and s==n would be valid one... that is a single point. That could intersect with another (non degenerated) bounding box normally.<br></div><div>I am using that understanding in a branch of the crs-explorer so allow a point or a rectangle intersect with a CRS without complicating the code a lot.</div><div>But I don't want to open a discussion about that now in PROJ.</div><div>Now I understand the algorithm and can implement it in js. Thank you.<br></div><div><br></div><div>Cheers,</div><div>Javier.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 8 Jun 2024 at 23:48, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    Javier,
    <blockquote type="cite">
      <div dir="ltr">
        <div>But the second and third I would expect</div>
        <div>
          <div>    if (W == -180.0 && E == 180.0) {<br>
                    return true;<br>
                }<br>
            <br>
                if (oW == -180.0 && oE == 180.0) {<br>
                    return true;<br>
                }</div>
          <div>if it covers the whole planet (from -180 to 180) it
            clearly intersects, right? Or am I missing something? (after
            is passes the first if statement on N-S)<br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>This is mostly for symmetry with the intersection() method that
      needs to deal specifically with that case where the other bounding
      box crosses the antimeridian. For normal cases, for intersects(),
      we could remove that extra check as you suggested, but when trying
      to do so, this causes the test added in
<a href="https://github.com/OSGeo/PROJ/commit/c3c9068b54cc190ce81c1fd7ea8b62aaa4c2af97#diff-076233f62785619274b55e6b0d7e45a7d5a25c019b07046f77c2ad0504f7f92dR289" target="_blank">https://github.com/OSGeo/PROJ/commit/c3c9068b54cc190ce81c1fd7ea8b62aaa4c2af97#diff-076233f62785619274b55e6b0d7e45a7d5a25c019b07046f77c2ad0504f7f92dR289</a>
      to fail. This is a edge / non-nominal case that was added when
      dealing with an issue discovered by ossfuzz. Not sure what the
      expected result false/true should be for a degenerate bbox with
      W=E=180. Not that I think it really matters (and I'm not willing
      to initiate yet another discussion about emptyness, which would be
      better brought to geos-dev :-) ). The only thing that matters here
      is to make sure this doesn't go into infinite recursion in those
      edge cases.<br>
    </p>
    <p>Comments added in <a href="https://github.com/OSGeo/PROJ/pull/4169" target="_blank">https://github.com/OSGeo/PROJ/pull/4169</a><br>
    </p>
    <blockquote type="cite"><span style="white-space:pre-wrap">
</span></blockquote>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>

</blockquote></div>