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 <[email protected]> > 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 [email protected] >> <mailto:[email protected]>. 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 >> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>>> On Sun, 9 Mar 2025 at 04:06, Javier Jimenez Shaw <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>> > <mailto:[email protected]>> 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 >>>> >> [email protected] <mailto:[email protected]> >>>> >> https://lists.osgeo.org/mailman/listinfo/proj >>> _______________________________________________ >>> PROJ mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.osgeo.org/mailman/listinfo/proj >> >> >> _______________________________________________ >> PROJ mailing list >> [email protected] <mailto:[email protected]> >> https://lists.osgeo.org/mailman/listinfo/proj > _______________________________________________ > PROJ mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
