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