De Kml a Geodatabase
Lunes, 17 de Diciembre de 2007
Antes hablábamos de como Arc2Earth permite conectar ArcGIS con Google Earth, subir y bajar datos en ambos sentidos. Ahora gracias a Geochalkboard conocemos como importar datos desde archivos kml/kmz directamente a una Geodatabase de ArcCatalog.
Desde el menú de Arc2Earth, se selecciona import/import kml-kmz, luego aparece un panel donde configuramos la forma de importación de datos:
Luego el panel muestra en la pestaña “general” las opciones para definir si el archivo tiene compatibilidad con estándares de GeoRSS.
En caso de ingresarlo a una Geodatabase Personal, se elige el destino de la base mdb.
En caso de tener implementada una base Enterprise vía ArcSDE, se debe escribir la cadena que define el nombre de la base de datos, usuario, password y ruta de servidor. También se pueden configurar características del Feature class de destino, en caso que hayan reglas configuradas para que interprete el estilo configurado en el kml.
En la pestaña “schema data”, se pude especificar si el archivo kml tiene atributos de lenguaje kml 2.2, donde la estrucutura xml permite definir atributos más específicos domo labels, estilos de línea y shapes complejos. Estos incluso pueden ser definidos como plantillas (templates) e importar solamente aquellos objetos del archivo que coinciden con la plantilla… de esa forma se puede definir filtros para lo que no deseamos importar.
En la pestaña “options”, se puede especificar si desdeamos que los datos importados reemplacen el contenido existente cuyas características sean coincidentes (replace), si desamos que reemplacen todo lo existente o si deseamos que se agreguen (append).
También aquí se elige el destino donde serán almacenadas las imágenes (overlays) de terreno.
Algunos vínculos de interés:
Video ilustrativo de como funciona la importación con Arc2Earth
Cursos disponibles de el uso de Arc2Earth
Aunque ESRI asegura que lo hace para mejorar la dificultad que causa el hecho que la lectura que hace el “core” cuando el servicio es activado se ve afectado por la instalación de otras aplicaciones y diversidad de estándares tanto de software como hardware que terminan creando conflictos de socket o la necesidad de implementar una licencia por procesador.
En el fondo suponemos este es uno de los objetivos de ESRI, desde hace mucho tiempo que requiere un sistema que sea más difícil de violar, en similitud al que usan otras plataformas donde la clave generada para activación amarra tanto el sistema operativo como los datos del equipo y la dependencia constante de conectividad web. Aunque ya hay quienes piratean este tipo de licencias, son más difíciles de masificar sin embargo pareciera que la intención de proteger el licenciamiento se va más a las aplicaciones de servidor, no tanto de cliente de modo que este objetivo no es tan consistente.
Esto es una necesidad urgente para ESRI y para otras plataformas, puesto que sus costos por brindar soporte a ArcView 3x deben ser más altos que las ventas que logra por esa aplicación. AutoDesk logró poco a poco disminuir este tipo de dificultades siendo franco al 
Aunque no lo crean, algunas cosas serán más cómodas (se supone), como por ejemplo el uso de las licencias ArcGIS Server, que actualmente anda en $35,000 “por procesador”, al manejar un licenciamiento que no sea por socket, se puede esperar que ponerle un procesador extra al servidor no requerirá otros $35,000, pues soportaría hasta 4 cores dentro del mismo socket… tengo mis dudas.
Gis Lounge
MundoGeo
Cartesia Extrema
Maestros del Web
The Cad Geek blog
Línea (Line)
