Polígono con los mismos puntos una y otra vez

Question

Estoy en el proceso de leer shapefiles (que nos proporciona el proveedor que se ocupa de los productos GIS) utilizando un programa C# y cargándolos en una base de datos SQL. Primero leo el texto de la forma y luego uso ese texto para actualizar mis tipos de geometría y geografía. Y lo hago como parte de un paquete SSIS.

Mi paquete SSIS falló en un shapefile y me lanzó una excepción:

Se ha producido un error de .NET Framework durante la ejecución de la rutina definida por el usuario rutina o "geometría" agregada: System.FormatException: 24305: La entrada del polígono no es válida porque el anillo no tiene suficientes puntos distintos. Cada anillo de un polígono debe contener al menos tres puntos distintos.

Después de ejecutar algunas actualizaciones manuales, encontré el registro que me estaba dando problemas. Entonces saqué partes del polígono múltiple y ejecuté selecciones individuales en ellas, creando polígonos individuales, por ejemplo

SELECT geometry::STGeomFromText('POLYGON(( 118.501323586697 -20.3203577291617, 118.504216161911 -20.3220101539757, 118.502671059623 -20.3212136027048, 118.501323586697 -20.3203577291617 ))', 4326).MakeValid()

Finalmente, encontré el polígono que era la forma problemática: 'POLYGON(( 118.860739531873 -20.2274797478397, 118.860739531873 -20.2274797478397, 118.860739531873 -20.2274797478397, 118.860739531873 -20.2274797478397 ))'

Estoy tratando de entender cómo arreglar esto para que mi paquete SSIS se ejecute y traduzca y cargue mis tablas SQL sin que yo tenga que arreglar nada manualmente. Cualquier ayuda será muy apreciada.

Answer 1

Todo proceso ETL consiste en digerir los datos. En algún punto de su recorrido, está tratando de digerir datos malos.

Entonces, ¿cómo escribirías un sistema que intente digerir, digamos, un punto e intente cargarlo en un polígono?

Claro que puedes escribir cosas que permitan digerirlas. Si se trata de un punto, bueno, pues se amortigua en 5 metros, ¡bam! Tienes una geometría digerible sin intervención manual.

Pero esa no es la cuestión.

Actualmente está pensando en su proceso ETL como una caja negra binaria para su usuario ("funciona" frente a "no funciona") - y quiere que el "no funciona" desaparezca.

Esto es fundamentalmente una falacia.

Piense en su proceso ETL como un serie de puertas en su lugar. Algunas cosas pueden pasar, y otras no. Ese polígono de mierda que tienes ahí, seguramente proviene de una función de geoprocesamiento o de una operación de ajuste de topología en la que la geometría se colapsó sobre sí misma debido a algún problema de tolerancia.

No quieres eso en tu GIS hasta que se arregle.

La puerta debería detenerlo, porque, créeme, ese polígono causará más problemas si se deja entrar en el resto de tu GIS.

Lo que quiero decir es que los fallos silenciosos son la mayoría de las veces (con algunas excepciones) un mal enfoque, más aún en el caso del ETL.