Esperiencia de uso ogr2ogr para generar fileGDB de ESRI

Trabajando recientemente en un proyecto tuve la experiencia de generar la geodatabase de ESRI, como parte de la entrega para estudio ambiental que se hace para el ANLA creando las vistas en postgres [lmu_eia_gdb] y subiéndolas por ogr2ogr todo funcionó muy bien, generar una versión de aproximadamente 80 features, algunos de ellos con más de 20.000 registro tomaba un poco menos de 2 horas. Dependiendo del tipo de información y si haía o no parte del cascarón existente formulado por el ANLA los comandos son de tipo

1-cargar feature existente

ogr2ogr -update -append -f "FileGDB" M:\EIA_CHIURA\ENTREGA_GEODATABASE_LMU\GDB_FEB\EIA.gdb PG:"host=p1186 user=consulta_1186 dbname=sip_db password=consulta_1186" lmu_eia_gdb.v_arq_potencialarqueologico -lco FEATURE_DATASET=MEDIO_SOCIOECONOMICO -nln PotencialArqueologico -progress -skipfailures

2-cargar tabla existente

ogr2ogr -update -append -f "FileGDB" M:\EIA_CHIURA\ENTREGA_GEODATABASE_LMU\GDB_FEB\EIA.gdb PG:"host=p1186 user=consulta_1186 dbname=sip_db password=consulta_1186" lmu_eia_gdb.v_tb_soc_areainfluencia_social -nln AreaInfluenciaSocialTB -progress -skipfailures

3-crear feature nuevo

ogr2ogr -update -overwrite -f "FileGDB" M:\EIA_CHIURA\ENTREGA_GEODATABASE_LMU\GDB_FEB\EIA.gdb PG:"host=p1186 user=consulta_1186 dbname=sip_db password=consulta_1186" lmu_eia_gdb_v_com_zona_vida -lco FEATURE_DATASET=COMPLEMENTARIO -nln com_zona_vida -t_srs "EPSG:3115" -progress -skipfailures

4-crear tabla nueva

ogr2ogr -update -overwrite -f  "FileGDB" M:\EIA_CHIURA\ENTREGA_GEODATABASE_LMU\GDB_FEB\EIA.gdb PG:"host=p1186 user=consulta_1186 dbname=sip_db password=consulta_1186" lmu_eia_gdb.v_tbcom_flo_censofustaltb -nln comflocensofustalTB -progress

La única dificultad que encontré fue por la utilización de caracteres que no codificaban de manera adecuada esto generaba una capa vacía y ninguna advertencia al subir a la geodatabase, es una práctica que sugiero al migrar información con textos de fuentes no controladas (ej: nombres geográficos) verificar que su contenido esté codificando de manera adecuada. Para esto se puede usar una consulta de expresión regular cómo:

select id, nombre_geo

from lmu_eia_hid.t_lotico_linea 

where nombre_geo ~ '[^[:ascii:]]';

aunque hay caracteres especiales que codifican de manera adecuada otros requieren ser revisados:

Esta consulta detecta otros carácteres especiales que usamos en latinoamérica como la ñ y las vocales tildades. Sin embargo el caracter que se ve como un cuadro no está codificado de manera adecuada y debe ser corregido por ejemplo

update lmu_eia_hid.t_lotico_linea set nombre_geo='Arroyo Caño la Caimanera' where id=1690;