prashtx
commented
8 years ago If these start cropping up more often, this could be a job for the task system. We could have a regular, repeated task that detects and removes or repairs invalid geometries. If it can record state, then it could notice that there are no new rows (most of the time) and quickly exit. Alternatively the API could queue up a task when it detects an invalid-geometry error. Potentially the originally API request would fail with a 500 status. If it's a request for a large area of parcels, then it's a shame for it to fail on account of one bad geometry. But this would not require the task to maintain state over time.
We had a bunch of bad geometries when running an older version of postgres+postgis. At that time, it was easy to accidentally import bad geometries and difficult to root them out, so I had to perform some binary searches to hone in on the bad rows. If that's still how we'd need to do it, then it would be expensive to perform regularly, so an on-demand or stateful approach would be really helpful.
We sometimes get errors like this:
We can probably detect and fix these errors (by removing the offending broken ring). Is it worth any performance hit?
Low priority for now, as these are fairly rare. They do take time to fix manually, so an automated solution would be preferable.