Géocodage et traitement à grande échelle dans ESRI


9

Ok, donc je suppose que ce genre de requête / enquête informelle sur la taille d'un ensemble de données que vous utilisez dans vos mondes ESRI ...

Je construis et gère un ensemble de données à l'échelle de l'État, où je dois traiter jusqu'au niveau de la maison individuelle, pas niveau colis mais plusieurs adresses postales par colis pour nos systèmes. Dans de nombreux endroits, j'utilise des adresses théoriques calculées à partir du réseau routier ou des données USPS AMS / AIS. Donc, ma liste d'adresses est d'environ 13,5 millions d'adresses et augmente mensuellement ou trimestriellement.

Y a-t-il quelqu'un en ce moment qui gère un système en direct d'informations d'adresse / de recherche correctement de cette taille dans un ensemble de données continu?

J'adorerais collaborer ou parler davantage de la façon dont les autres gèrent un si grand ensemble de données. Je vois des problèmes où le logiciel ESRI semble exploser lorsque j'essaie d'effectuer des tâches telles que des intersections ou des jointures spatiales. ESRI dit qu'ils ne voient pas ce genre de problèmes, mais je les ai depuis depuis la version 9.3.1, je ne peux donc pas être la première / seule personne à le faire car je peux le recréer sur plusieurs machines.

Ma plate-forme est actuellement ESRI ArcGIS 10 sur le bureau, parlant à ArcSDE 9.3.1-sp1 sur un backend SQL2008 à l'aide de l'objet géographique GEOMETRY. Je ne fais donc rien de vraiment exotique; mais il me semble toujours que dans certains domaines, je pousse peut-être l'enveloppe.

[Plus loin]

Ce qui m'intéresse, c'est de savoir ce que font les autres pour optimiser leurs processus de traitement de ces ensembles de données. Je vais ajouter des mots d'un million d'enregistrements par mois à l'avenir, et bien que le géocodage, etc. ne soit pas un problème lorsque vous commencez à exécuter d'autres processus et à lier des données pour une analyse plus approfondie, vous commencez à traiter des jointures complexes. Eh bien, vous générez des données à partir d'intersections / superpositions / identités à l'aide de Only_FID et vous obtenez également une table intermédiaire fine à joindre; mais lorsque vous commencez à essayer de diviser et de conquérir la création de cette table, vous commencez à rencontrer des problèmes où vous devez diviser vos données source en zones de travail, mais vous avez ensuite des IDS répétitifs que vous ne pouvez pas fusionner; de sorte que vous vous retrouvez avec des blocs de données plus petits que vous ne pouvez pas facilement reconstituer.

Penser aux options qui décomposent les données à l'échelle comté par comté, puis utiliser des vues spatiales pour les regrouper, etc ... Juste curieux de savoir si d'autres utilisateurs examinent les mêmes types de problèmes à une si grande échelle mais à une petite échelle empreintes.


3
60 millions d'adresses géocodées dans Oracle Spatial (11g) ArcSDE et visualisées dans ArcGIS et Web App (interne). Il ne s'agit pas de l'adresse géocodée mais floue (adresses mal appariées) c'est un bon guide scdhec.gov/gis/presentations/ESRI_Conference_08/tws/workshops/…
Mapperz

Je suis d'accord, le géocodage n'a jamais été le problème. Mon problème vient du fait que vous avez un si grand ensemble de données que vous avez besoin d'un processus continu que d'autres processus deviennent très difficiles. Fonctions / tâches comme intersections, jointures spatiales, etc., où vous devez ensuite vous associer à d'autres données dans un environnement hautement normalisé pour la modélisation.
DEWright

Vos données spatiales sont-elles indexées? Selon les documents, SQL Server utilise des index B-Tree. Essayez de charger les données dans une base de données PostGIS avec des index GIST et comparez les performances. Cela vous indiquera s'il s'agit d'un problème avec SQL Server.
Sean

Aucun problème avec ce genre de chose, mais ce que je vois dans l'ensemble, c'est que lorsque vous traitez avec tant de points et que vous effectuez des fonctions approfondies qui durent si longtemps, vous cherchez des moyens de les optimiser. Et je suis curieux de savoir ce que font les autres utilisateurs à grande échelle.
DEWright

Si la question est ouverte, elle devrait être reformulée et créer un wiki communautaire.
Sean

Réponses:


1

Comme il s'agit d'une (ancienne) question ouverte, je vais vous donner une réponse ouverte: une utilisation correcte de la base de données peut vous faire gagner énormément de temps. La façon évidente de faire quelque chose n'est pas nécessairement la plus rapide, par exemple lorsque j'ai récemment voulu supprimer beaucoup de lignes d'Oracle, il s'avère que l'envoi: delete from TABLE1 where ID = 123pour chaque fonctionnalité était incroyablement lent et qu'il y a des trucs Oracle fantaisistes que je peux faire pour accélérer les ordres de grandeur .

Donc, fondamentalement, si vous trouvez un problème particulier qui est un goulot d'étranglement, posez une question spécifique relative à ce goulot d'étranglement aux experts. Donc, pour le côté ArcGIS qui serait probablement ici (ou les forums ESRI, ou votre support ESRI), mais pour un problème côté base de données (et les choses seront généralement plus rapides si vous les faites là-bas), vous voudrez demander à http : //www.stackoverflow.com


Pas tellement ouvert; mais en cherchant davantage de meilleures façons théoriques de traiter ce sujet. Mon chemin le plus récent m'a fait construire ma propre logique de recherche floue pour parler à ma propre base de données SQL2008. Suppression de la dépendance du moteur ESRI pour s'appuyer sur des index bien réglés pour essayer d'accélérer cela. Puisque nous ne savons pas assez sur les composants internes des moteurs de BING ou de Google, nous pouvons seulement supposer qu'ils utiliseraient leur propre logique fine.
DEWright

Vous pouvez découvrir un peu des coulisses de Google à partir de leurs documents de recherche
GIS-Jonathan
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.