Geography STDistance() and ShortestLineTo() overestimate polygon-to-polygon distance in SRID 104001 (unit sphere)

Question

Geography STDistance() and ShortestLineTo() overestimate polygon-to-polygon distance in SRID 104001 (unit sphere)

KoizumiJunko-6191 0

(Microsoft SQL Server 2022)
In SRID 104001 (unit sphere), STDistance() between two non-intersecting polygons returns values that are too large. In the cases tested, the error was up to about 63 km (converted with R = 6371 km) for polygons 200–500 km apart. ShortestLineTo() is affected as well: one of its end points is not the closest point. For the same polygons in SRID 4326 the results are correct. Point-to-point and point-to-polygon distances in SRID 104001 are correct.

Example (EGY–CYP): STDistance(EGY polygon, CYP polygon) = 404.30 km, while STDistance(point on the EGY boundary, CYP polygon) = 351.18 km. This is impossible, because the distance between two sets cannot exceed the distance from one of their points to the other set. In SRID 4326 both give 350.39 km.

The polygons are from our own country boundary data (EGY: MultiPolygon, 1,058 points; CYP: 116 points; both STIsValid() = 1), which I cannot share. The same polygons were loaded into SRID 104001 with geography::STGeomFromWKB(geo_shape.STAsBinary(), 104001).

Is there a fix to SRID 104001 or a recommended workaround other than using SRID 4326?

0 comments

1 answer

Your answer

Answer 1

Myself, I don't work a lot with spatial, so I am not in position to comment on the case specifically. And even less do I understand the difference between these SRIDs. But if you have some other environment which supports spatial calculations, I would encourage you to try the operations there as well. It could be that this is something that follows from the definition of the SRIDs.If you truly believe that Microsoft has implemented SRID 104001 incorrectly, and you think it should be fixed, the proper way to proceed is to open a support case. This would require that you have a support contract.

You can also report the issue on https://feedback.azure.com/d365community/forum/04fe6ee0-3b25-ec11-b6e6-000d3a4f0da0 to let Microsoft know about the issue. But this is no guarantee that there will be a fix, as they will triage as they see fit. If you report the issue there, I recommend that you compose a repro that demonstrates the problem, preferably with simpler polygons than 1058 points.