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@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@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@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@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.daw...@gmail.com> wrote: >> >>> On Sun, 9 Mar 2025 at 04:06, Javier Jimenez Shaw <j...@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@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@lists.osgeo.org >>> >> https://lists.osgeo.org/mailman/listinfo/proj >>> >> _______________________________________________ >> PROJ mailing list >> PROJ@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/proj >> > > _______________________________________________ > PROJ mailing > listPROJ@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj > > _______________________________________________ > PROJ mailing list > PROJ@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > > > _______________________________________________ > PROJ mailing list > PROJ@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj >
_______________________________________________ PROJ mailing list PROJ@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj
