[PROJ] Determine "cut line" for arbitrary projection

[David O'Sullivan]

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 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/20250309/64e40c60/attachment-0001.htm>