[PROJ] Determine "cut line" for arbitrary projection

[Kristian Evers]

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 <mailto: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 <mailto: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 <mailto:nyall.dawson at gmail.com>> wrote:
>>>> On Sun, 9 Mar 2025 at 04:06, Javier Jimenez Shaw <j1 at jimenezshaw.com <mailto: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 <mailto: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 <mailto:PROJ at lists.osgeo.org>
>>>> >> https://lists.osgeo.org/mailman/listinfo/proj
>>> _______________________________________________
>>> PROJ mailing list
>>> PROJ at lists.osgeo.org <mailto:PROJ at lists.osgeo.org>
>>> https://lists.osgeo.org/mailman/listinfo/proj
>> 
>> 
>> _______________________________________________
>> PROJ mailing list
>> PROJ at lists.osgeo.org <mailto: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/7225ec66/attachment-0001.htm>