GML, KML, GeoJSON - Hız oluşturma 3109 çokgen?


12

Geoserver ile çalışıyorum, Openlayer'lara ABD Alt 48 ilçesine (3109 çokgen - çok daha fazla köşe) hizmet ediyorum. İlçeler bir postgis veritabanına yüklenir. Bu miktarda köşe noktasını müşteriye aktarmaya çalışırken geliştirici deneyimini merak ediyorum.

Hangi WFS formatıyla en iyi sonuçları elde ettiniz? Geoserver için ek ayar kullanılmış mı?

Döşenmiş WMS'nin daha hızlı olacağını anlıyorum, ancak openLayers kullanarak bir choropleth haritasında dinamik değişikliklere izin vermek istiyorum. kullanıcı bir form gönderir, bir Python betiği çağrılır ve açık katmanların harita bölmesini yeniden yüklemesi için yeni veri kutuları döndürülür. Ayrıca, açık katmanlardaki çokgen karmaşıklığını azaltmadan önce tam çözünürlük biçiminde denemek istiyorum.

Yanıtlar:


4

Belki bu yeni fikirleri tetikler: Kullanıcıların bir haritayı birçok öğe ile düzenleyebileceği bir uygulama var.

Tüm verileri WFS olarak göndermek yerine, WMS eşlemelerini kullanıyorum ve kullanıcı bir seçimi tıklattığında veya çizdiğinde, seçilen öğeleri WFS olarak getiriyorum .

Sunucuya bir güncelleme gönderdikten sonra, WMS katmanını yenileyiyorum.

Bunu nasıl yapabileceğinizi gösteren bazı OpenLayers örnekleri vardır. Muhtemelen biraz ince ayar yapmanız gerekecek, ancak OpenLayers + GeoServer sizin için zor kısmı çözecek. Veriler gzip ile gönderilir, böylece orijinal biçim o kadar da önemli değildir; darboğaz değil. OpenLayers ve GeoServer'ın bilgi alışverişinde hangi biçimi kullandıklarını anlamasına izin verin.

Bu yaklaşım oldukça iyi ölçekleniyor. Yavaş bağlantıları ve yavaş bilgisayarları olan kişiler bile haritayı düzenlemek için kullanabilir. Yüzlerce öğeyi getirmek çok hızlıdır ve muhtemelen düzenlemek için aynı anda daha fazlasına ihtiyacınız olmayacaktır.

Son olarak .. konu dışı, ancak harita verileriyle istemci tarafı şeyler yapmak istediğiniz gibi: OpenLayers ile çokgen çizmek istiyorsanız IE7 ve daha düşük sorunlu olacağını unutmayın. OpenLayers, istemci tarafı çizim için SVG kullanır ve IE7 ve daha düşük sürümlerde yerleşik destek yoktur. Bu kullanıcıların berbat eski bir eklentiyi indirmeleri gerekir. Diğer tüm tarayıcılar iyidir.


IE8 neredeyse kötü olacak. OpenLayers'ın birkaç oluşturucusu vardır ve Canvas veya SVG'yi desteklemeyen tarayıcılar için IE7'nin desteklediği VML'ye başvurur. Farklı oluşturucular, farklı yerlerde daha iyi ve daha kötü performans sağlar, örneğin, fareyle üzerine
gelme

3

Bence GEOJSON, en iyi format, okunması kolay, javascript'te kullanımı kolay ve genellikle GML / KML'den daha küçük boyutlu. Stil hakkında bilgi bile içerebilir, buraya bakın .

Resmi bir standart değildir, ancak hem broşür hem de açık katmanlarda ve qgis gibi birçok gis masaüstü uygulamasında desteklenir.


2

GeoJSON'u kullanmak sisteminizi hızlandırmak için iyi bir başlangıçtır, ancak yeterli olmayabilir. Veri katmanınızın yakınlaştırma katmanı başına bir tane olmak üzere birkaç sürümünü oluşturmayı ve her sürüme genelleme / basitleştirme yöntemlerini uygulamayı düşünmelisiniz . İstemci, seçilen yakınlaştırma düzeyine bağlı olarak ilgili katmanı istemelidir. Bu, sunucu ile istemci arasında alışverişi yapılan verilerin ayrıntı düzeyinin uygun olmasını sağlayacak ve hem ağ aktarımını hem de oluşturmayı daha önemli ölçüde artıracaktır. Daha ileri gitmek için, sisteminizi vektör döşemesi ve uzamsal indeksleme ile bu belgede açıklandığı gibi genişletebilirsiniz , ancak openlayers ve geoserver'ın bunu başarabileceğinden emin değilim!

Kesin: GML'yi unutun.


Tam çözünürlüklü WFS çok yavaş olduğunda bu benim geri dönüş yöntemimdir. Bu boyuttaki sorunlarla ilgileniyorum ve hem tam çözünürlük hızını hem de gerekirse düşük çözünürlük hızını bildirmek istiyorum.
Jay Laura

2

Neden yeni bir SLD dosyası oluşturmak ve bunu isteğinizle WMS sunucusuna göndermek için python komut dosyanızı kullanmıyorsunuz.

Burada bir örnek var .


Bunu düşündüm ve muhtemelen bu seçeneği hız için test edeceğim. Bu geliştirme için değil, araştırma için, bu yüzden WFS'yi denemek istiyorum.
Jay Laura

1

Ben zaten iki kez benzer bir yolda aşağı ve az sayıda nokta veya gerçekten basit çokgenler daha fazla bir şey için istemci tarafı render iyi bir fikir değil. Kendinizi bu mimariye bağladıktan sonra geri çekilmenin maliyeti yüksektir ve herhangi bir projede, çeşitli paydaşlar / amirler sisteminizin neler yapabileceğini görmeye başladığında gereksinimlerde bir değişiklik veya veri hacminde bir artış göreceksiniz. Tarayıcı tabanlı istemci tarafı oluşturma yaklaşımı ölçeklenmez.

Eğer dinamik görüntü oluşturmak istiyorsanız ikinci bir yaklaşım izliyorum. Daha önce burada farklı ama ilgili bir sorun için bir dizi seçenek tanımlamıştım . Ayrıca, istemci tarafı oluşturmaya yardımcı olmak için çokgen genelleştirmesi kullandım ve kesinlikle yardımcı olsa da, daha fazla yakınlaştırma yaparken genelleştirilmemiş çokgeni aşağı çekmek istediğiniz gibi daha zor sorunlar yaratır.

Bilinen bir platformla çalışıyor olsanız bile (örneğin, tüm istemcilerin donanımını, tarayıcı sürümünü ve eklentilerini biliyorsunuz) bu olası değildir, bu istemcilerin ne tür bir yük altında olduğu hakkında hiçbir fikriniz yoktur. Bu tür bir yaklaşım, tarayıcının kullanıcı deneyimini akıcı tutmak için çok fazla CPU zamanı alabilmesini gerektirir ve başka her şey kullanıcılarınızı rahatsız edecektir.

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.