You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a polygon from a source dataset that I am moving from one platform to another. This polygon is actually a part of a multi-polygon, but I've narrowed the issue down to a particular polygon.
This polygon is nonsense, IsValid = false. I imagine this is some clumsy clicking in a GIS tool. The data comes from multiple original sources and the ability to control this input is limited.
My use case is simply shifting data from system A to system B. Any cleanup ought to be taking place within system A or system B.
SQL Server itself is quite content with this data (insofar as it is being used as a storage mechanism), and my preference would be that no data manipulation takes place in transit between the two systems.
Currently, I believe my options are either drop the invalid polygons or use an exception handler that attempts a manual SQL update using the WKT from the polygon, in order to bypass the checking on the shell orientation performed here.
It would be ideal for my use case if I could somehow express that for this polygon I don't care if something is wrong with it. I'd rather try saving it and then only handle what SQL Server itself rejects. (Possibly relates to #15).
Potentially, attempting to save an invalid polygon is my way of saying that I don't care - try anyway?
Alternatively, it would have been helpful if the thrown exception cited the invalid polygon instead of the shell orientation of it to avoid a misleading exception on the stack trace - since that is in some respects only accidentally getting hit. If IsCCW had come back as true but IsValid still false, it would have potentially progressed all the same and successfully saved the data to the database.
The text was updated successfully, but these errors were encountered:
I have a polygon from a source dataset that I am moving from one platform to another. This polygon is actually a part of a multi-polygon, but I've narrowed the issue down to a particular polygon.
Here's a reader for the polygon, SRID 4326
This polygon is nonsense,
IsValid = false
. I imagine this is some clumsy clicking in a GIS tool. The data comes from multiple original sources and the ability to control this input is limited.My use case is simply shifting data from system A to system B. Any cleanup ought to be taking place within system A or system B.
SQL Server itself is quite content with this data (insofar as it is being used as a storage mechanism), and my preference would be that no data manipulation takes place in transit between the two systems.
Currently, I believe my options are either drop the invalid polygons or use an exception handler that attempts a manual SQL update using the WKT from the polygon, in order to bypass the checking on the shell orientation performed here.
It would be ideal for my use case if I could somehow express that for this polygon I don't care if something is wrong with it. I'd rather try saving it and then only handle what SQL Server itself rejects. (Possibly relates to #15).
Potentially, attempting to save an invalid polygon is my way of saying that I don't care - try anyway?
Alternatively, it would have been helpful if the thrown exception cited the invalid polygon instead of the shell orientation of it to avoid a misleading exception on the stack trace - since that is in some respects only accidentally getting hit. If IsCCW had come back as true but IsValid still false, it would have potentially progressed all the same and successfully saved the data to the database.
The text was updated successfully, but these errors were encountered: