Geocodificación y procesamiento a gran escala en ESRI


9

Ok, entonces supongo que este tipo de consulta / encuesta informal sobre qué tan grande es el conjunto de datos que está utilizando en sus mundos ESRI ...

Estoy construyendo y manteniendo un conjunto de datos a nivel estatal, donde tengo que procesar hasta el nivel de la casa individual, no nivel de parcela pero múltiples direcciones postales por parcela para nuestros sistemas. En muchos lugares estoy usando direcciones teóricas calculadas a partir de la red de calles o datos de USPS AMS / AIS. Entonces, mi lista de direcciones es de aproximadamente 13.5 millones de direcciones y crece mensualmente o trimestralmente.

¿Alguien en este momento mantiene un sistema en vivo de dirección / información de búsqueda adecuada que es tan grande en un conjunto de datos continuo?

Me encantaría colaborar o hablar más sobre cómo otros manejan un conjunto de datos tan grande. Estoy viendo problemas en los que el software ESRI parece estar explotando cuando intento realizar tareas como intersecciones o uniones espaciales. ESRI dice que no ven este tipo de problemas, pero he tenido estos problemas desde 9.3.1, así que no puedo ser la primera / única persona que hace esto, ya que puedo recrearlo en varias máquinas.

Mi plataforma en este momento es ESRI ArcGIS 10 en el escritorio, hablando con ArcSDE 9.3.1-sp1 en un servidor SQL2008 usando el objeto espacial GEOMETRY. Entonces no estoy haciendo nada realmente exótico; pero todavía me parece que en algunas áreas tal vez estoy empujando el sobre.

[Más lejos]

Lo que me interesa saber es qué están haciendo otras personas para optimizar sus procesos para lidiar con estos conjuntos de datos. Voy a agregar palabras clave de un millón de registros al mes en adelante, y aunque Geocodificación, etc. no es un problema cuando comienzas a ejecutar otros procesos y a vincular datos para un análisis posterior, comienzas a lidiar con uniones complejas. Bueno, usted genera datos de Intersects / Overlays / Identities usando Only_FID y obtiene una tabla intermedia delgada para unirse también; pero cuando comienza a tratar de dividir y conquistar la creación de esa tabla, comienza a encontrar problemas en los que necesita dividir sus datos de origen en áreas de trabajo, pero luego tiene IDS repetidos que no puede fusionar; por lo que te quedan bloques de datos más pequeños que no puedes volver a completar fácilmente.

Pensando en las opciones que desglosan los datos a escala de Condado por Condado, luego usando vistas espaciales para volver a unirlos, etc. Solo tengo curiosidad por saber si otros usuarios están viendo el mismo tipo de problemas en una escala tan grande pero pequeña. huellas


3
60 millones de direcciones geocodificadas en Oracle Spatial (11g) ArcSDE y visualizadas en ArcGIS y la aplicación web (interna). No se trata de la dirección geocodificada sino difusa (direcciones no coincidentes), esta es una buena guía scdhec.gov/gis/presentations/ESRI_Conference_08/tws/workshops/…
Mapperz

Estoy de acuerdo, la geocodificación nunca ha sido el problema. Mi problema es cuando tienes un conjunto de datos tan grande que necesitas tener un proceso continuo que otros procesos se vuelvan muy difíciles. Funciones / tareas como Intersects, Spatial-Joins, etc., donde debe unirse a otros datos en un entorno altamente normalizado para el modelado.
DEWright,

¿Están indexados sus datos espaciales? Según los documentos, SQL Server usa índices de B-Tree. Intente cargar los datos en una base de datos PostGIS con índices GIST y compare el rendimiento. Esto le dirá si es un problema de SQL Server.
Sean

No hay problemas con ese tipo de cosas, pero lo que sí veo en general es que cuando se trata de tantos puntos y se realizan funciones profundas que duran tanto, se buscan formas de optimizarlos. Y tengo curiosidad por saber qué están haciendo otros usuarios a gran escala.
DEWright,

Si la pregunta es abierta, debería reformularse y crear un wiki comunitario.
Sean

Respuestas:


1

Como es una pregunta abierta (antigua), le daré una respuesta abierta: Usar la base de datos correctamente puede ahorrar enormes cantidades de tiempo. La forma obvia de hacer algo no es necesariamente la más rápida, por ejemplo, cuando recientemente quise eliminar muchas filas de Oracle, resulta que solo enviar: delete from TABLE1 where ID = 123para cada función fue increíblemente lento y que hay algunas cosas sofisticadas de Oracle que puedo hacer para hacerlo órdenes de magnitud más rápido.

Básicamente, si encuentra un problema particular que es un cuello de botella, haga una pregunta específica relacionada con ese cuello de botella a los expertos. Entonces, para el lado de ArcGIS que probablemente estaría aquí (o los foros de ESRI, o su soporte de ESRI), pero para un problema del lado de la base de datos (y las cosas generalmente serán más rápidas si los hace allí), querrá preguntar en http : //www.stackoverflow.com


No tanto abierto final; pero buscando más formas teóricas de manejar este tema. Mi camino más reciente me hizo construir mi propia lógica de búsqueda difusa para hablar con mi propia base de datos SQL2008. Eliminando la dependencia del motor ESRI para confiar en índices bien ajustados para intentar hacer esto más rápido. Como no podemos saber lo suficiente sobre los aspectos internos de los motores de BING o Google, solo podemos suponer que usarían su propia lógica de grano fino.
DEWright

Puede descubrir un poco de las escenas detrás de escena de Google en sus trabajos de investigación
GIS-Jonathan
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.