[PROJ] Determine "cut line" for arbitrary projection

Mon Mar 10 02:33:08 PDT 2025

I'm very interested in this question as I'm in need of end-of-the-world
lines for cartographic purposes.

I suppose there is no single solution for all projections, but the
solutions can probably be categorised into those that:

1. Are mathematically derivable, e.g. azimuthal projections covering a
hemisphere or global projections like Mollweide.
2. Require editorial decisions such as cut-off at +/- 85 degrees, e.g.
Mercator
3. Interrupted projections for which the cutlines would need to be
retrieved from a datasource, or user-defined.
4. Those with known limited extents, e.g Ordnance Survey National Grid.

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?
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.

Best,

Will

On Sun, 9 Mar 2025 at 17:07, Kristian Evers via PROJ <proj at lists.osgeo.org>
wrote:

> 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
> https://observablehq.com/@d3/adaptive-sampling. 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.
>
> /Kristian
>
> On 9 Mar 2025, at 01.57, David O'Sullivan via PROJ <proj at lists.osgeo.org>
> wrote:
>
> 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.
>
> https://southosullivan.com/misc/briesemeister-cut.png
>
> You can clearly see the 'cut' as a discontinuity in the values of the x
> coordinate of the projection.
>
> 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.
>
> 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.
>
> Best
>
> David
>
> --
>
> David O'Sullivan
>
> Geospatial Stuff dosull.github.io
> Hon Prof University of Auckland
>
>
>
>
> On 09/03/2025 12:13, Michael Sumner via PROJ wrote:
>
>
> You don't often get email from proj at lists.osgeo.org. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> 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).
>
> 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.
>
> Will try, very interested in this discussion.
>
> Cheers, Mike
>
> On Sun, Mar 9, 2025, 08:27 Javier Jimenez Shaw via PROJ <
> proj at lists.osgeo.org> wrote:
>
>> Implementing the Spilhaus projection I learned how the images in the
>> documentation are generated, like the one in
>> https://proj.org/en/latest/operations/projections/spilhaus.html
>> 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.
>>
>> On Sat, 8 Mar 2025 at 22:03, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>>
>>> On Sun, 9 Mar 2025 at 04:06, Javier Jimenez Shaw <j1 at jimenezshaw.com>
>>> wrote:
>>> >
>>> > If you mean in a generic way, I think the answer is no.
>>> > 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.
>>>
>>> Testing Spilhaus in QGIS was actually the motivation for this
>>> question. It works fine for rasters, but for vectors there's extreme
>>> artifacts caused by rendering features crossing the boundaries of this
>>> projection.
>>>
>>> >
>>> > "... latitude (or projected x coordinate) " Do you mean longitude? See
>>> that the longitude you are looking for may depend on the latitude.
>>>
>>> 🤦 of course! (*although for the above mentioned Spilhaus projection I
>>> guess we'd need something more complex than a single line longitude
>>> line anyway!)
>>>
>>> Nyall
>>>
>>> >
>>> >
>>> > On Sat, 8 Mar 2025 at 07:30, Nyall Dawson via PROJ <
>>> proj at lists.osgeo.org> wrote:
>>> >>
>>> >> Hi list,
>>> >>
>>> >> 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.
>>> >>
>>> >> 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?
>>> >>
>>> >> Nyall
>>> >>
>>> >> _______________________________________________
>>> >> PROJ mailing list
>>> >> PROJ at lists.osgeo.org
>>> >> https://lists.osgeo.org/mailman/listinfo/proj
>>>
>> _______________________________________________
>> PROJ mailing list
>> PROJ at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/proj
>>
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20250310/de32fdab/attachment.htm>