4

How to deal with a problem of intersection of geometry shape (linestring, polygon) and 180 meridian?

I have polygons distributed all over the Earth globe, some of them intersecting 180 meridian.

The problem is, to define a polygon being over the 180 meridian, I have to split it into two. I couldn't find a way to define a polygon from let say +170 to -170 meridian.

What I already tried - shift the -180/+180 system to 0/+360 system, which does not solves the problem, it just moves it to a different position of the globe.

I can split the polygons which are placed over 180 meridian but I would like to avoid this.

My goal is to check intersection of linestrings and polygons without limitation of splitting the globe. Is there any way to define geometric shapes (polygons, linestrings) without the limit of splitting them if they intersect 180 meridian?

Improve this question
3
  • How can you possibly avoid splitting the polygon outside the the date line? It's valid to have a geometry that starts at longitude +179 and extends to longitude +181, but if you have other data from -180 to -179, they won't overlap (unless you represent it (and everything else) twice, once on either side of the dateline). There are index consequences to having a geometry that spans the globe in two parts, but there are also consequences for storing the parts as separate features. In the end, this becomes a personal preference as to how to model it.
    – Vince
    Commented Jan 19, 2022 at 14:47
  • Could you provide an example of your polygons and an example of the interect check you're trying to do. I think you could probably get away with some fancy SQL to only do the shift_longitude where applicable
    – RedM
    Commented Jan 21, 2022 at 8:46
  • I have polygons distributed all over the globe, all together they cross every meridian. I will have linestrings (flight paths) also distributed in the same way. So with shift_longitude it could get messy to decide when to use and when not to. I will prepare some example and will add it here.
    – David Langr
    Commented Jan 24, 2022 at 7:31

1 Answer 1

Reset to default
1

This might not solve your problem since it is regionally specific. I managed to get around the 180 wraparound issue by converting my geometries to an SRID that was specified in meters and didn't wrap back around.

If that doesn't work for you then possible doing something with ST_Shift_Longitude could help.

Improve this answer
2
  • Thank you for you answer, unfortunately ST_Shift_Longitude won't solve my problem as it moves that 180 meridian problem to 0 meridian. I have polygons distributed all over the globe, as well the linestrings (representing flight paths) will be.
    – David Langr
    Commented Jan 20, 2022 at 15:06
  • 1
    I have had a similar issue, the solution I found was to use PostgreSQL CASE in my request, testing the geometry with ST_Length, and then only applying the St_Shift_Longitude to those with a length greater than a given value (180 in my case), leaving the other ones unchanged.
    – Kasper
    Commented Nov 1, 2022 at 11:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.