ESRI'da Büyük Ölçekli Coğrafi Kodlama ve İşleme


9

Tamam, bu yüzden ESRI dünyalarınızda bir veri kümesini ne kadar büyük kullandığınıza dair gayri resmi bir sorgulama / anket

yapıyorum ... Bireysel ev düzeyine kadar işlemek zorunda olduğum eyalet çapında bir veri kümesi oluşturuyorum ve koruyorum parsel seviyesi ancak sistemlerimiz için parsel başına birden fazla posta adresi. Birçok yerde sokak ağından veya USPS AMS / AIS verilerinden hesaplanan teorik adresleri kullanıyorum. Bu yüzden Adres Listem kabaca 13.5 milyon adres ve aylık veya üç aylık olarak büyüyor.

Orada kimse şu anda sürekli bir veri kümesinde bu kadar büyük bir canlı adres / düzgün arama bilgi sistemi koruyor mu?

İşbirliği yapmak veya başkalarının bu kadar büyük bir veri kümesini nasıl ele aldıkları hakkında daha fazla konuşmak isterim. Kesişim veya uzamsal birleşimler gibi görevleri yerine getirmeye çalıştığımda ESRI yazılımının patladığı anlaşılıyor. ESRI, bu tür sorunları görmediklerini söylüyor, ancak 9.3.1'e kadar bu sorunları yaşadım, bu yüzden bunu birden fazla makinede yeniden oluşturabildiğim için bunu yapan ilk / tek kişi olamam.

Platformum şu anda Masaüstünde ESRI ArcGIS 10, GEOMETRY uzamsal nesnesini kullanarak bir SQL2008 arka ucunda ArcSDE 9.3.1-sp1 ile konuşuyor. Bu yüzden gerçekten egzotik bir şey yapmıyorum; ama yine de bana öyle geliyor ki bazı bölgelerde zarfı itiyorum.

[Daha ileri]

İlgilendiğim şey, diğer insanların bu veri kümeleriyle başa çıkmak için süreçleri optimize etmek için ne yaptıklarını. Bir ay ileride milyonlarca kayıttan upwords ekleyeceğim ve Geocoding vb. Diğer süreçleri çalıştırmaya başladığınızda ve daha fazla analiz için veri bağlarken karmaşık birleşimlerle uğraşmaya başladığınızda sorun olmaz. Sadece Kesitler / Bindirmeler / Kimliklerden veriyi Only_FID kullanarak çıktılar ve katılmak için ince bir orta tablo elde edersiniz; ancak bu tablonun oluşturulmasını bölmeye ve fethetmeye başladığınızda, kaynak verilerinizi çalışma alanlarına bölmeniz gereken sorunları vurmaya başlarsınız, ancak daha sonra birleştiremeyeceğiniz IDS'leri tekrar edersiniz; böylece tekrar kolayca oluşturamayacağınız küçük veri blokları kalır.

Verileri County-by-County ölçeğine bölen seçenekleri düşünmek, sonra tekrar birleştirmek için uzamsal görünümler kullanmak vb. ayak izi.


3
Oracle Spatial (11g) ArcSDE'de coğrafi kodlanmış 60 milyon adres ve ArcGIS ve Web App'te (Dahili) Visualized. Coğrafi kodlanmış adresle ilgili değil, bulanık (yanlış eşleşmiş adresler), bu iyi bir rehberdir scdhec.gov/gis/presentations/ESRI_Conference_08/tws/workshops/…
Mapperz

Katılıyorum, coğrafi kodlama hiçbir zaman sorun olmamıştı. Benim sorunum öyle büyük bir veri kümesine sahipseniz, diğer süreçlerin çok zorlaştığı bir sürekli işlem yapmanız gerektiğinde ortaya çıkıyor. Kesişmeler, Uzamsal Birleşmeler vb. Gibi işlevler / Görevler, daha sonra modelleme için oldukça normal bir ortamda diğer verilere katılmanız gerekir.
DEWright

Uzamsal verileriniz dizine eklendi mi? Dokümanlara göre, SQL Server B-Tree dizinlerini kullanır. Verileri GIST dizinleriyle bir PostGIS veritabanına yüklemeyi deneyin ve performansı karşılaştırın. Bu bir SQL Server sorunu olup olmadığını söyleyecektir.
Sean

Bu tür bir şeyle ilgili bir sorun yok, ama genel olarak gördüğüm şey, çok fazla nokta ile uğraşırken ve çok uzun süre çalışan derin işlevler yaptığınızda onları optimize etmenin yollarına bakmanızdır. Ve diğer büyük ölçekli kullanıcıların ne yaptığını merak ediyorum.
DEWright

Eğer soru bu açık uçluysa, yeniden ifade edilmeli ve bir topluluk viki yapmalıdır.
Sean

Yanıtlar:


1

(Eski) açık uçlu bir soru olduğu için size açık uçlu bir cevap vereceğim: Veritabanını uygun şekilde kullanmak çok fazla zaman kazandırabilir. Bir şeyi yapmanın bariz yolu en hızlı değildir, örneğin son zamanlarda Oracle'dan çok sayıda satır silmek istediğimde, sadece göndermenin ortaya çıktığı ortaya çıktı: delete from TABLE1 where ID = 123her özellik inanılmaz derecede yavaştı ve yapabileceğim bazı fantezi Oracle şeyleri var daha hızlı sipariş vermek için .

Temel olarak bir darboğaz olan belirli bir sorun bulursanız, bu darboğazla ilgili belirli bir soruyu uzmanlara sorun. Bu yüzden muhtemelen burada olacak olan ArcGIS tarafı için (veya ESRI forumları veya ESRI desteğiniz), ancak veritabanı tarafındaki bir sorun için (ve eğer orada yaparsanız işler genellikle daha hızlı olacaktır) http : //www.stackoverflow.com


Çok açık uçlu değil; ancak bu konuyu ele almanın daha iyi teorik yollarını arıyor. En son yolum kendi SQL2008 DB ile konuşmak için kendi bulanık arama mantığımı oluşturmamı sağladı. Bunu daha hızlı denemek için iyi ayarlanmış dizinlere güvenmek için ESRI motoruna bağımlılık kaldırıldı. BING'in veya Google'ın motorlarının iç kısımları hakkında yeterince bilgi sahibi olamadığımız için, sadece orada kendi ince taneli mantığını kullanacaklarını varsayabiliriz.
DEWright

Onların araştırma makaleleri gelen Google'ın perde arkası biraz anlamaya - research.google.com/pubs/papers.html
CBS-Jonathan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.