Closed airbreather closed 4 months ago
[...] SQL server requires polygons to be stored as it does [...] [...] The only reference to the storage format is the vague sentence [...]
@IanKemp I don't have the time to respond to your entire comment right now (in fact, I shouldn't even be spending the time I'm spending to type out this comment right now), but I did want to respond to these bits -- the disconnect has very little to do with the storage format as you suggest. Rather, there is a fundamental gap between NTS and SQL Server over the very nature of the data being stored.
In NTS, a polygon ring is defined as either a "shell" or as a "hole". It gets away with this because its algorithms interpret the point data as locations on a plane that extends "infinitely" in two dimensions.
In SQL Server, the geography
type needs more information than just "is it a shell or a hole?" in order to determine how to partition the world into "things outside the ring" and "things inside the ring". If you put down a fence around yourself, for example, it could mean one of two things: either "I am standing inside this fence" or "everything in the world is inside this fence except for me".
So in SQL Server, the developers define the "inside" / "outside" determination using the ring's orientation.
I think the distinction is important, because if it was "just" a difference in the storage format, then it would absolutely make sense for that to be handled here.
After NetTopologySuite/NetTopologySuite@a819cdd makes it to a release, we can start recommending that people start using GeometryFactoryEx
and setting OrientationOfExteriorRing
as appropriate, which could help resolve this in a lot of situations.
After https://github.com/NetTopologySuite/NetTopologySuite/commit/a819cdd makes it to a release, we can start recommending that people start using GeometryFactoryEx and setting OrientationOfExteriorRing as appropriate, which could help resolve this in a lot of situations.
Has been released with v2.1.0
I strongly disagree with this argument. That SQL server requires polygons to be stored as it does is SQL server's problem, i.e. a concern of the persistence layer - what you are suggesting is to make it a concern of layers higher up the stack, which is completely the wrong thing to do because those layers don't and shouldn't need to know or care about the nitty-gritty of data persistence and retrieval.
And fundamentally, by throwing an exception what you are saying is "your data is wrong". But it's not - it's just that SQL Server chooses to store it in a way that may make it look wrong when you later retrieve it. Which, again, is an issue that no other RDMBS would have.
An EF hook to transform data on the way in/out of the persistence provider would solve this problem, because then I could just do the geo normalisation + reverse in a general manner there. (Which is essentially what I'm attempting to do in my
DbContext
above.) But it would be a very edge-case scenario and as such seems like something the EF team wouldn't be particularly interested in prioritising, which means I can't rely on it happening anytime soon.God that documentation is useless. The only reference to the storage format is the vague sentence "The interior of the polygon in an ellipsoidal system is defined by the left-hand rule" - there is nothing that says "your polygon has to be defined counterclockwise or SQL Server's EF provider will refuse to save it".
I suspect rather less confusion with the option, as opposed to a lot of unhappiness without it, as currently.
Originally posted by @IanKemp in https://github.com/NetTopologySuite/NetTopologySuite.IO.SqlServerBytes/issues/4#issuecomment-538321039