Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid polygon from source dataset, but valid in SQL Server, rejected by writer due to shell orientation #34

Open
sam-gardiner opened this issue Dec 5, 2024 · 0 comments

Comments

@sam-gardiner
Copy link

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

var wktReader = new WKTReader();
var polygon = wktReader.Read("POLYGON ((-3.1881192452535125 54.15712105863824, -3.1881192347011487 54.157121058586824, -3.1881192347011487 54.157121058586824, -3.1881192452535125 54.15712105863824))");

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant