<div dir="ltr"><div>I'm very interested in this question as I'm in need of end-of-the-world lines for cartographic purposes.</div><div><br></div><div>I suppose there is no single solution for all projections, but the solutions can probably be categorised into those that:</div><div><br></div><div>1. Are mathematically derivable, e.g. azimuthal projections covering a hemisphere or global projections like Mollweide.<br></div><div>2. Require editorial decisions such as cut-off at +/- 85 degrees, e.g. Mercator</div>3. Interrupted projections for which the cutlines would need to be retrieved from a datasource, or user-defined.<div>4. Those with known limited extents, e.g Ordnance Survey National Grid.</div><div><div><br></div><div>Couldn't the cutlines be reasonably easily generated in geographic coordinates from either user-supplied or default projection parameters, using one of the above methods?</div><div>An example for a derivable extent would be an orthographic projection where the cutline is just 90 degrees in spherical distance from the centre point.<br></div><div><br></div><div>Best,</div><div><br></div><div>Will</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, 9 Mar 2025 at 17:07, Kristian Evers via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="line-break:after-white-space">In general I think this is just a tough problem to solve. I laid the foundation for the projection images in the PROJ docs and learned along the way that it’s complicated to do generically. During my initial work I did some research to see if there was a good solution I could borrow. The most promising idea I found was the concept of “adaptive resampling” as presented by Mike Bostock at <a href="https://observablehq.com/@d3/adaptive-sampling" target="_blank">https://observablehq.com/@d3/adaptive-sampling</a>. The basic idea is to densify the vertices in areas with high distortion and possibly removing ones in areas with low distortion. For visualisation purposes I think this is neat solution but it may not be desirable in a GIS where you want the user to have full control over the vertices in a geometry.<div><br></div><div>/Kristian<br id="m_4378259941697397393lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 9 Mar 2025, at 01.57, David O'Sullivan via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>> wrote:</div><br><div>

  
    
  
  <div bgcolor="#FFFFFF"><p>This is something a colleague (Luke Bergmann) and I have explored
      intermittently at various times. Here's a picture of a 'projected
      coordinate surface' for the x coordinate of the Briesemeister
      projection (an oblique Hammer), plotted against longitude and
      latitude.</p><p><a href="https://southosullivan.com/misc/briesemeister-cut.png" target="_blank">https://southosullivan.com/misc/briesemeister-cut.png</a><br>
    </p><p>You can clearly see the 'cut' as a discontinuity in the values of
      the x coordinate of the projection.</p><p>Of course this is only a small aspect of any complete solution
      and as Mike points out it's all very well handling points, dealing
      with polygons is a lot harder. There are likely projections with
      cut lines that don't show up quite so obviously as
      discontinuities, and this kind of stuff is never far from floating
      point and NaN errors.<br>
    </p><p>We've had some qualified success generating tinshift JSONs to
      'simulate' known projections, by excluding triangles that overlap
      any part of the cut in a projection and only projecting points
      that are inside 'valid' triangles as part of an ongoing attempt to
      allow for arbitrary numerical projections in platforms that use
      PROJ. Kind of messy though and support for tinshift seems a bit
      uneven even in tools that incorporate PROJ.</p><p>Best</p><p>David</p><p>--<br>
    </p><p>David O'Sullivan</p><p>Geospatial Stuff <a href="http://dosull.github.io" target="_blank">dosull.github.io</a><br>
      Hon Prof University of Auckland<br>
    </p><p><br>
    </p><p><br>
    </p><p><br>
    </p>
    <div>On 09/03/2025 12:13, Michael Sumner via
      PROJ wrote:<br>
    </div>
    <blockquote type="cite">
      
      <table border="0" cellspacing="0" cellpadding="0" width="100%" style="background:revert;color:revert;direction:revert;font-size:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;padding:revert;text-align:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert;border:0px;display:table;width:100%;table-layout:fixed;float:none;border-spacing:0px" align="left">
        <tbody style="background:revert;border:revert;color:revert;direction:revert;font-size:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;padding:revert;table-layout:revert;text-align:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;width:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert;display:block">
          <tr style="background:revert;border:revert;color:revert;direction:revert;display:revert;font-size:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;padding:revert;table-layout:revert;text-align:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;width:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert">
            <td valign="middle" width="1px" bgcolor="#A6A6A6" cellpadding="7px 2px 7px 2px" style="background-image:revert;background-position:revert;background-size:revert;background-repeat:revert;background-origin:revert;background-clip:revert;border:revert;color:revert;direction:revert;display:revert;font-size:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;table-layout:revert;text-align:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert;padding:7px 2px;background-color:rgb(166,166,166);width:0px">
              <br>
            </td>
            <td valign="middle" width="100%" bgcolor="#EAEAEA" cellpadding="7px 5px 7px 15px" style="background-image:revert;background-position:revert;background-size:revert;background-repeat:revert;background-origin:revert;background-clip:revert;border:revert;direction:revert;display:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;table-layout:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert;width:100%;background-color:rgb(234,234,234);padding:7px 5px 7px 15px;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:12px;font-weight:normal;color:rgb(33,33,33);text-align:left">
              <div style="background:revert;border:revert;color:revert;direction:revert;display:revert;font-size:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;padding:revert;table-layout:revert;text-align:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;width:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert">
                You don't often get email from <a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>. <a href="https://aka.ms/LearnAboutSenderIdentification" style="background:revert;color:revert;direction:revert;display:revert;font-size:revert;opacity:revert" target="_blank"> Learn why this is important</a>
              </div>
            </td>
            <td valign="middle" align="left" width="75px" bgcolor="#EAEAEA" cellpadding="7px 5px 7px 5px" style="background-image:revert;background-position:revert;background-size:revert;background-repeat:revert;background-origin:revert;background-clip:revert;border:revert;direction:revert;display:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;table-layout:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert;width:75px;background-color:rgb(234,234,234);padding:7px 5px;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:12px;font-weight:normal;color:rgb(33,33,33);text-align:left">
              <br>
            </td>
          </tr>
        </tbody>
      </table>
      <div><p dir="ltr">In the past I've had success filtering out bad
          segments that are "long" (in native CRS), for example with
          omerc. I guess we could generate spanning segments across the
          grid domain (maybe with a rectangle or triangle grid from
          longlat)and analytically find that boundary (endpoint pixels
          that have segments that are "too long).</p><p dir="ltr">I think this would work for omerc and spilhaus, not
          sure about generally. Certainly repointing polygons back
          together is much harder and probably needs mesh decomposition.</p><p dir="ltr">Will try, very interested in this discussion.</p><p dir="ltr">Cheers, Mike</p>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Sun, Mar 9, 2025, 08:27
            Javier Jimenez Shaw via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
            <div dir="ltr">
              <div>Implementing the Spilhaus projection I learned how
                the images in the documentation are generated, like the
                one in <a href="https://proj.org/en/latest/operations/projections/spilhaus.html" rel="noreferrer" target="_blank">
https://proj.org/en/latest/operations/projections/spilhaus.html</a></div>
              <div>if you have a look at docs/plot/plotdefs.json you
                will see that the workaround is to not plot very long
                lines, that are usually crossing from one border of the
                projection to another.</div>
            </div>
            <br>
            <div class="gmail_quote">
              <div dir="ltr" class="gmail_attr">On Sat, 8 Mar 2025 at
                22:03, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" rel="noreferrer" target="_blank">nyall.dawson@gmail.com</a>>
                wrote:<br>
              </div>
              <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
                On Sun, 9 Mar 2025 at 04:06, Javier Jimenez Shaw <<a href="mailto:j1@jimenezshaw.com" rel="noreferrer" target="_blank">j1@jimenezshaw.com</a>>
                wrote:<br>
                ><br>
                > If you mean in a generic way, I think the answer is
                no.<br>
                > Each projection has its own peculiarities and
                behaviours. Spilhaus (by the way, not yet in PROJ, but
                coming in 9.6.0) is a good example.<br>
                <br>
                Testing Spilhaus in QGIS was actually the motivation for
                this<br>
                question. It works fine for rasters, but for vectors
                there's extreme<br>
                artifacts caused by rendering features crossing the
                boundaries of this<br>
                projection.<br>
                <br>
                ><br>
                > "... latitude (or projected x coordinate) " Do you
                mean longitude? See that the longitude you are looking
                for may depend on the latitude.<br>
                <br>
                🤦 of course! (*although for the above mentioned
                Spilhaus projection I<br>
                guess we'd need something more complex than a single
                line longitude<br>
                line anyway!)<br>
                <br>
                Nyall<br>
                <br>
                ><br>
                ><br>
                > On Sat, 8 Mar 2025 at 07:30, Nyall Dawson via PROJ
                <<a href="mailto:proj@lists.osgeo.org" rel="noreferrer" target="_blank">proj@lists.osgeo.org</a>>
                wrote:<br>
                >><br>
                >> Hi list,<br>
                >><br>
                >> A question: given an arbitrary projection/CRS,
                is it possible to determine the latitude (or projected x
                coordinate) at which features would need to be "cut" in
                order to avoid artifacts when those features wrap around
                the projection extremes.<br>
                >><br>
                >> Eg if it was EPSG:4326, we'd need to cut the
                features at +/- 180. But if it's another projection...
                say mercator or spilhaus or ... is there any way to
                reliably determine this cutting line?<br>
                >><br>
                >> Nyall<br>
                >><br>
                >> _______________________________________________<br>
                >> PROJ mailing list<br>
                >> <a href="mailto:PROJ@lists.osgeo.org" rel="noreferrer" target="_blank">PROJ@lists.osgeo.org</a><br>
                >> <a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">
                  https://lists.osgeo.org/mailman/listinfo/proj</a><br>
              </blockquote>
            </div>
            _______________________________________________<br>
            PROJ mailing list<br>
            <a href="mailto:PROJ@lists.osgeo.org" rel="noreferrer" target="_blank">PROJ@lists.osgeo.org</a><br>
            <a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
PROJ mailing list
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>PROJ mailing list<br><a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>