Değişen sokak ağı ile coğrafi kodlanmış noktalar arasındaki bütünlük nasıl korunur?

Çift merkezli bir Navteq sokak ağına karşı coğrafi olarak kodlanmış yüz binlerce noktayı koruyoruz. Her Navteq güncellemesiyle değişen noktalarımız ve sokak ağı arasında referans bütünlüğünü koruma zorluğu ile karşı karşıyayız. Noktalarımızın yüksek bir yüzdesi manuel olarak coğrafi olarak kodlanmıştır, bu yüzden bunları otomatik bir coğrafi kod işlemiyle tekrar çalıştıramayız.

Bazı noktalar sokak adresiyle, bazıları ise bir kavşaktan uzaklık ve yönle, bazıları ise GPS koordinatlarıyla coğrafi olarak kodlanır. Her durumda, güncellenmiş sokak ağında mümkün olan en yakın eşleşmeyi korumamız gerekir.

Bu sorunu doğrusal referans, coğrafi kodlama ve yakalama tekniklerini kullanarak tek merkezli bir ağda daha önce çözdüm, ancak süreç çok katı ve kırılgandı. (Ayrıntılar için http://thewyvern.co/Thesis.final.pdf adresine bakın.)

Bu sorunla karşılaşan başka biri var mı? Önerin var mı? Güçlü bir çözüm geliştirmemize yardımcı olabilecek herhangi bir araştırmaya işaret edebilir misiniz?

Bağlam için: ArcObjects'te kodlanmış, sadece kısmen ESRI'nin Locator sınıfına dayanan özel bir coğrafi kodlama algoritması kullanıyoruz. Sistemimiz ArcGIS Server 9.3.1'e dayanmaktadır ve veriler Oracle üzerinde ArcSDE 9.3.1'de saklanmaktadır. Navteq verileri şekil dosyası biçiminde teslim edilir.

geocoding linear-referencing snapping

— NW1
kaynak

Sorunuza coğrafi kod, veri formatları, kullanılabilir yazılım vb. Gibi hangi bilgileri kullandığınız gibi daha fazla bilgi ekleyebilir misiniz? ArcGIS kullanıyorsanız, geometrik bir ağ kullanmayı düşündünüz mü? FME'niz varsa San Antonio Su Sistemi'nin bu sunumu ilginizi çekebilir .

— blah238

"Topolojik bütünlük" çok geniş bir terimdir ve ben olarak merak ediyorum tam olarak neyi sen onun tarafından demek. Coğrafi olarak kodladığınız düğümlerin sokak kenarlarının bir parçası olmasını ister misiniz? Çünkü düzeltmelerle parsel düzeyinde coğrafi kodlama kullanmak, coğrafi olarak kodlanmış noktaları parsellerin bir kısmına kolayca koyabilir ve yine de "topolojik olarak doğru" olabilir

— Ragi Yaser Burhum

@Ragi: Noktaların diğer özelliklere göre ağ alanında konumlandırılması anlamında (bence) topolojik bir sorundur. Ama belki de bu terim burada yararsızdır.

— nw1

Düğüm ve merkez çizgisi arasında bir öznitelik ilişkisi (PK / FK) var mı, yoksa merkez çizgilerini güncellemeden önce düğümlere bir ilişki eklenebilir mi? Eminim NAVTEQ, geometri değişse bile aynı kalması gereken yarı kalıcı bir kimlik tutar. Bir merkez hattı kimliği ve çizginin aşağı yüzdesi, merkez hattı güncellemelerinden sonra düğümlerinizi uygun şekilde bulmak için yeterli olur mu?

— MWrenn

Deneyimlerime göre, ID sadece geometri bölündüğünde değişir, genellikle başka bir yol veya yaya geometrisiyle yeni bir kavşak nedeniyle, sadece ayarlanmaz. Aksini görüyor musun? Sanırım bu çözümün ele alması gereken davaların kapsamını belirlemeye çalışıyorum.

— MWrenn

Şu anda ajansım için aynı senaryoya ya da en azından benzer bir senaryoya işaret eden bir soruna bakıyorum.

Hedeflediğim şu; tüm adres noktalarının eşleştikleri sokağın kimliği vardır; ve AIS'den USPS Range. Her satıcı sokak güncellemesinde değişiklik tespiti için bir kontrol yapmamız gerekir; değişiklik olan sokak segmenti kimlikleri için bu kimliğe referansta bulunan noktaları yalıtırız; daha sonra en yakın sokak segmenti kimliğini seçmek için bir tampon yaparak bunların her biri arasında dolaşacağız, böylece bunları uygun şekilde koruyabiliriz.

Bu zaman alıcı bir işlem olacaktır, ancak bunun adil bir miktarını yazabilirsiniz (bu şimdi modelleniyorum) ve yalnızca satıcı verilerinizi güncellediğinizde gerçekleşmesi gerekir. Adreslerimiz için birkaç kaynaktan güncelleme alacağız, bu yüzden puanları alıp birleştireceğiz ve ardından satıcı veri güncellememiz her defasında bunları güncelleyeceğiz, hatta TIGER / Edge'e refernce ekleyebilirim, ancak bu sadece gelecekteki demografik modelleme kullanımları için.

Aralıklı adresleri, eyalet çapında adresleme ve yönlendirme kaynağını destekleyecek parsel düzeyindeki verilerle köprülemek için çalışıyoruz.

— DEWright
kaynak