GISCloud gibi oluşturma performansı ile Vektör Çokgenler oluşturma?


59

Her bir poligonu bir hover etkinliğinde farklı bir renk göstermemi sağlamak amacıyla bu tür verileri sonsuza dek yüklemeden bir web haritası oluşturmam ve vektör çokgenleri katlamama izin verecek sağlam bir çözüm arıyordum .

Bildiğim kadarıyla, bunu tuval, SVG, Flash ile başarmak için 3 özel seçenek var.

Flash, en hızlı görüntü oluşturma ve en temiz görüntüyü sağladığı gibi, Apple iPhone / iPod'larda çalışacaksa en iyi çözüm gibi görünüyor. Tuval ikinci en iyi seçenek gibi görünüyor, ancak haritada gösterilen yüzlerce poligon varsa ÇOK uzun sürüyor, oysa SVG'nin oluşturulması daha uzun sürüyor.

Ben neredeyse bu soruna bir çözüm bulma konusunda umudunu kaybetti ama bugün GISCloud adında bir şirket rastladım http://www.giscloud.com (şu anda ücretsiz kayıt işleminde beta).

Bu şirketin SOMEHOW'u bir haritada yüzlerce vektörü gerçek zamanlı olarak oluşturmanın harika bir yolunu bulmayı başardı. Yaklaşımları karşısında hayrete düştüm ve topluluğa olan sorum, broşür, açılış katmanı, balmumu gibi mevcut teknolojilerle kullanım için yaklaşımlarını nasıl çoğaltabileceğimizle ilgili.

Bu muhteşem demoyu izleyerek kendinize bir göz atın: http://www.giscloud.com/map/284/africa

Sayfadaki çokgenlerin herhangi birinin üzerine geldiğinizden emin olun ve bu çokgenlerin gerçekten vektör olduğunu görmek için zoom kontrollerini test edin.

Firebug ile istekleri inceleyerek fark ettim, haritanın belirli json dosyaları talep ediyor olmasıdır. Zoom seviyesine / bölgeye bağlı olarak talep edilen birden fazla json dosyası varmış gibi görünüyor.


Burada ayrıca giscloud'un bir vektörün üzerine geldiği sayfadaki verileri yükledikten sonra yeni bir istek oluşturmadan hemen rengi değiştirdiğini belirtmeliyim.

ÖRNEKLER:

URL yapısının standart döşeme hizmeti mantığını takip ettiğini varsayıyorum (örneğin, en son 3. seviye yakınlaştırma seviyesi ...).

Her durumda, bu json dosyalarının gerçek verilerini analiz ettim ve kullandıkları mantık, sadece bu veri değerlerine dayanarak vektörlerini oluşturdukları bir tür mantık izliyor:

  • width / height: her json isteğinde sunulan verinin genişliğini ve yüksekliğini tanımlarlar
  • piksel: burada bir şekilde genelleştirilmiş nokta seviyeleri için bazı genel x / y piksel koordinatlarıyla ilgili olduğunu varsaydığım piksel değerlerini tanımlar. Yakınlaştırma seviyesine bağlı olarak bir şekilde bölgeyi otomatik olarak basitleştirmenin bir yolu olduğunu tahmin ediyorum. Piksel koordinatları kullandıklarını farz ediyorum, sanırım enlem / boylam verilerle karşılaştırıldığında yüklenmesi gereken verilerin boyutunu önemli ölçüde azalttığını tahmin ediyorum.
  • stilleri: burada iki RGB css değeri tanımlar. Çokgen dosya rengini temsil eden "F" ve çokgen sınır rengini temsil eden "S".
  • geom: işte burada tahmin ediyorum ki, bir şekilde harita döşemesinin penceresinden yola çıkılarak bu verilerin tanımlandığı yerdeki, yüklenmekte olan kiremit içindeki her bir poligonu özel olarak tanımlamayı tanımlıyorlar. Ayrıca ilginç olan, her girişin isteğe bağlı bir özellik veya özellik bağlantı değeri olarak kullanıldığını düşündüğüm bir "S" değerine sahip olduğudur ve her girişin sonunda, burada bir vektör kimliği ile birlikte belirli bir kimlik tanımlayan görünen bir alan vardır. Tahmin ettiğim katman kimliği, çağrılan her json döşemesi isteğindeki verileri bir şekilde birleştirmek için kullanılır.

Aynı zamanda, talep edilen döşeme için yüklenmesi gereken verilerin boyutuna bağlı olarak, her döşeme için yüklenmesi gereken verileri otomatik olarak belirleme ve bölmenin bir yolunu bulduklarını da varsayıyorum.

İşte bu isteklerden birinin çıkarılmış bir dökümü:

{"width":256,"height":256,"tile":
{"pixels":
[0,6461,-1,0,5,148,0,509,-1,10715,-1,1,-1,251,-1,1,-1,1,-1,251,-2,3,-1,255,-1,249,-2,5,-2,247,-1,509,-3,251,-1,2,-2,253,-2,252,-2,254,-1,255,-1,254,-1,255,-1,1276,-2,13,-1,233,-1,2,-1,253,-1,1,-1,255,-1,247,-1,1306,-1,1533,-1,1269,-1,1276,-1,2303,-1]},

"styles":
[{"f":"rgb(99,230,101)","s":"rgb(5,148,0)","lw":"0"}],

"geom":
[
{"s":0,"p":[4,143,5,144,3,146,1,146,2,143,4,143],"c":"layer1156_5098"},
{"s":0,"p":[-2,143,0,140,2,141,2,144,1,146,-2,144,-2,143],"c":"layer1156_5067"},
{"s":0,"p":[7,143,5,144,4,143,2,143,2,141,5,138,6,139,5,141,7,143],"c":"layer1156_5051"},
{"s":0,"p":[10,141,11,137,12,137,14,137,12,142,9,143,9,142,10,141],"c":"layer1156_5041"},
{"s":0,"p":[1,136,0,140,-2,143,-2,136,1,136],"c":"layer1156_5038"},
{"s":0,"p":[8,143,5,141,5,137,8,136,10,137,10,141,8,143],"c":"layer1156_5033"},
{"s":0,"p":[5,137,2,141,0,140,1,136,1,136,2,135,3,136,5,137],"c":"layer1156_5028"},
{"s":0,"p":[10,134,12,136,11,138,8,135,10,134],"c":"layer1156_5020"},
{"s":0,"p":[-2,133,0,136,-2,136,-2,133],"c":"layer1156_5005"},
{...}
...
]
}

Aynı (veya benzer) hız türünü postgis kullanarak nasıl çoğaltabiliriz (ki ben de kullandıkları gibi).


Ah! JSON dosyasına bakmayın, etrafta dolaşan görünüşte önemsiz görünen diğer fotoğraflara bakın :) Aşağıdaki cevaba bakın.
Ragi Yaser Burhum

“3 özel seçenek var” ... Peki Silverlight, doğranmış karaciğer nedir?
Kirk Kuykendall

Silverlight eklentisinin çalışmasını gerektirir ve aslında giscloud'un kullandığı çözümden daha hızlı olduğunu sanmıyorum, ancak doğrudan bir karşılaştırma yapmadım.
NetConstructor.com

2
Bu soru, olağan soru-cevap formatına uymayan konuşacak çok ilginç şeyler ortaya çıkarır. Web Haritası Dünyasında Vektörleri Kullanma
matt wilkie 1:11

@RagiYaserBurhum Benzer bir teknik kullanarak bunun seyahat izoronu
djq

Yanıtlar:


56

Geçmişte kullanılan bu tekniği gördüm. Bana Michal Migurski'nin TileStache'yi oluştururken girdi vermesine yardımcı olan Zain Memon (Trulia'dan) bana açıklandı. Zain bir süre önce eski SF GeoMeetup toplantılarımızdan birinde bu tekniği kullanan Trulia demosunu anlattı . Aslında, gelecek hafta SF’de iseniz (bu, bir fişe lame teşebbüsümdür, buna dokunacak, bu yüzden görünmekten çekinmeyin :)

Tamam, şimdi açıklamaya.

İlk olarak, yukarıdaki json dosyalarına bakarken biraz yanlış yere bakıyorsun.

Açıklayayım (mümkün olduğunca kısa), neden.

Döşemeler normal işlenmiş karolar gibi geçiriliyor, orada önemli bir şey yok, bunu nasıl yapacağımızı biliyoruz ve bu yüzden bunu açıklamaya gerek yok.

Eğer Firebug bunu incelemek, ayrıca, boş gibi görünüyor görüntülerin bir sürü olsun göreceksiniz bunun gibi .

Neden boş? O değil. Pikseller veri içerir - yalnızca geleneksel görülebilir resim verileri değildir. Piksellerde kodlanmış verileri iletmek için çok akıllı bir teknik kullanıyorlar.

Son on yılda olan, insanların depolama verimliliği pahasına biçimlerde okunabilirlik ve taşınabilirlik verilerini alıp sattıklarıdır.

Bu xml örnek verileri örneğini alın:

<data>

  <feature>
    <point>
      <x> -32.1231 </x>
      <y> 10.31243 </y>
    </point>
    <type> 
      sold
    </type>
   </feature>

  <feature>
    <point>
      <x> -33.1231 </x>
      <y> 11.31243 </y>
    </point>
    <type> 
      available
    </type>
   </feature>

</data>

Tamam, bunu aktarmak için kaç tane ısırık var? Utf8 olmamız şartıyla (bu içerikle uğraşırken karakter başına 1 bayt). Eh, bu 176 baytı yapan (bu sayede basitlik uğruna vermeyeceğim çeşitli nedenlerden dolayı iyimser oluyor) yaklaşık 176 karakterimiz var (sekmeleri veya boşlukları saymadan ). Dikkat et, bu 2 puan için!

Yine de, neden bahsettiğini anlamayan akıllı bir göt, bir yerde "json'un sana daha yüksek sıkıştırma verdiğini" iddia edecektir.

Güzel, json ile aynı xml saçmalığını koyalım:

{ "data": [
            "feature" : { "x" : -32.1231, "y" : 10.31243 , "type": "sold" },
            "feature" : { "x" : -33.1231, "y" :11.31243, "type": "avail" },
          ]
}

Burada kaç bayt var? ~ 115 karakter söyleyin. Hatta biraz hile yaptım ve daha küçük yaptım.

Alanımın 256x256 piksel içerdiğini ve her özelliğin bir piksel olarak işlenebileceği ve çok fazla özelliğe sahip olduğum ve o kadar dolu olduğumun yakınlaştırma düzeyindeyim. 65.536 özellik olduğunu göstermek için ne kadar veriye ihtiyacım var?

54 karakter (veya utf bayt - ve hatta bazı özellikleri görmezden geliyorum) "özellik" girişi ile çarpılır x 65,536 = 3,538,944 veya yaklaşık 3,3 MB

Sanırım resmi aldın.

Ancak verileri hizmet odaklı bir mimaride bu şekilde aktarıyoruz. Okunabilir şişirilmiş bok.

Ya her şeyi kendim icat ettiğim ikili bir düzende taşımak istersem? Bunun yerine, bu bilgiyi tekli bant görüntüsünde (yani siyah beyaz) kodladım. Ve 0 anlamına gelir satılan ve 1 kullanılabilir demektir ve 2 bilmiyorum demektir. Heck, 1 baytta, kullanabileceğim 256 seçeneğim var - ve bu örnek için sadece 2 veya üçünü kullanıyorum.

Bunun depolama maliyeti nedir? 256x256x 1 (yalnızca bir bant). 65,536 bayt veya 0,06 MB. Ve bu, görüntü sıkıştırma konusundaki onlarca yıllık araştırmadan ücretsiz olarak elde ettiğim diğer sıkıştırma tekniklerini de dikkate almıyor.

Bu noktada, kendinize neden insanlar json'a seri hale gelmek yerine ikili biçimde kodlanmış veri göndermiyor? İlk önce, javascript ikili verileri taşımak için büyük zaman harcıyor , bu yüzden insanlar bunu tarihsel olarak yapmadılar.

Etrafında harika bir çalışma bazı insanlar tarafından HTML5'in yeni özellikleri ortaya çıktığında, özellikle tuvalde kullanıldı . Peki bu müthiş mesele nedir? Görünüşe göre, görüntüde görünen şey üzerine kodlanmış tel üzerinden veri gönderebilir, ardından o görüntüyü pikselleri doğrudan değiştirmenize izin veren bir HTML5 Canvas'a aktarabilirsiniz ! Artık bu verileri almak, istemci tarafında kodunu çözmek ve istemcide json nesnelerini oluşturmak için bir yolunuz var.

Bir dakika dur ve bunu düşün.

Çok sayıda anlamlı coğrafi referanslı veriyi yüksek oranda sıkıştırılmış bir biçimde, web uygulamalarında geleneksel olarak yapılan herhangi bir şeyden daha küçük büyüklükteki emirleri kodlama ve javascript'te manipüle etme yönteminiz var.

HTML tuvalini çizmek için bile kullanılmasına gerek kalmaz, sadece ikili kod çözme mekanizması olarak kullanılır!

Firebug'da gördüğünüz bütün görüntüler bu işte. İndirilen her bir döşeme için kodlanmış verileri içeren bir resim. Süper küçükler, ancak anlamlı verileri var.

Peki bunları sunucu tarafında nasıl kodlarsınız? Verileri sunucu tarafında genelleştirmeniz ve kodlanmış verilere sahip her yakınlaştırma düzeyi için anlamlı bir döşeme oluşturmanız gerekir. Şu anda, bunu yapmak için, kendi yuvarlamanız gerekiyor - kutudan açık kaynaklı bir çözüm bulunmuyor, ancak bunu yapabilmek için ihtiyacınız olan tüm araçlara sahipsiniz. PostGIS, genelleme işlemlerini GEOS üzerinden gerçekleştirecek, TileCache, fayans üretimini tetiklemenize yardımcı olmak için kullanılabilir. İstemci tarafında, özel "sahte fayanslara" geçmek için HTML5 Canvas'ı kullanmanız ve ardından fareyi üzerinde efektleri olan vektörleri temsil eden gerçek istemci tarafı javascript nesneleri oluşturmak için OpenLayers'ı kullanmanız gerekir.

Daha fazla veri kodlamanız gerekiyorsa, piksel başına her zaman RGBA görüntüleri oluşturabileceğinizi unutmayın (bu, piksel başına 4 bayt veya piksel başına temsil edebileceğiniz 4,294,967,296 sayı ). Bunu kullanmak için birkaç yol düşünebilirim :)

Güncelleme : Aşağıdaki QGIS sorusunu cevaplama.

Diğer çoğu Masaüstü CBS gibi QGIS de sabit bir zum düzeyi yoktur. Her ölçekte yakınlaştırma ve sadece görüntü oluşturma esnekliğine sahiptirler. WMS veya fayans bazlı kaynaklardan veri gösterebilirler mi? Elbette yapabilirler, ancak çoğu zaman bu konuda aptallar: Farklı bir dereceye kadar yakınlaştır, sınırlayıcı kutuyu hesapla, gerekli döşemeyi hesapla, yakala, göster. Çoğu zaman, başka şeyler görmezden geliyorlar, bunu başaracak http üstbilgi önbellekleri gibi, yeniden yapmak zorunda kalmayacaklardı. Bazen basit bir önbellek mekanizması uyguluyorlar (eğer isterseniz döşemeyi kontrol edin, istemeyin). Ancak bu yeterli değil.

Bu teknikle, karoların ve vektörlerin her yakınlaştırma seviyesinde tekrar kaplanması gerekir . Neden? Çünkü vektörler yakınlaştırma seviyelerine uyum sağlamak için genelleştirilmiştir.

Fayansları bir HTML5 tuvaline koyma hilesi olduğu sürece, tamponlara erişebiliyorsunuz, bu her şeye gerek yok. QGIS, Python ve C ++ dilinde kod yazmanıza izin verir, her iki dilin de ikili arabellekleri işlemek için mükemmel desteği vardır, bu nedenle bu çalışma bu platform için gerçekten önemsizdir.

* GÜNCELLEME 2 **:

Genelleştirilmiş vektör döşemelerinin ilk etapta nasıl oluşturulacağı hakkında bir soru vardı (sonuçları görüntülere koymadan önce 1. adımdaki bebek). Belki de yeterince açıklığa kavuşturmadım. Tilestache, verilerinizin her yakınlaştırma düzeyinde etkili "vektör döşemeleri" oluşturmanıza olanak tanır (hatta döşeme sınırını geçtiğinde verileri kırpmanıza veya kırpmanıza izin vermeyen bir seçeneğe sahiptir). Bu, vektörleri çeşitli yakınlaştırma seviyelerinde fayanslara ayırma işini üstlenir. "Klibi değil" seçeneğini seçerdim (ancak daha fazla alanı kapsıdığı keyfi bir döşemeyi seçer). O zaman, her vektörü GEOS genelleme seçeneği üzerinden büyük bir sayı ile besleyebilirsiniz, aslında, polillerin ve poligonların kendi üzerine çökmesine yetecek kadar büyük olmasını istersiniz, çünkü eğer öyleyse, o aşamadan bu yana onları zum seviyesinden çıkarabilirsiniz. ilgisiz, alakasız, konu dışı, yersiz. Tilestache, bu mantığı koyabileceğiniz kolay pythonic veri sağlayıcıları yazmanıza bile izin verir. Bu aşamada, onlara json dosyaları (bazı Afrika harita örneklerinde olduğu gibi) veya pngs içine serileştirilmiş geometriler, örneğin yukarıda verdiğim diğer örneklerde (veya Trulia bir) olduğu gibi hizmet etmeyi seçebilirsiniz.


2
Şimdiye kadar, bu tekniği kullanırken gördüğüm her bir kişi kodu göndermedi. IMHO, çünkü önemli kısım sunucuda gerçekten oluyor ve bunun için bir "standart" yok ve çünkü her bir pikselin ne anlama geldiğini seçmek (1 = satıldı, 2 = boşuna, vb.) Mevcut haritanıza göre bu kod büyük olasılıkla "genel" değil.
Ragi Yaser Burhum

1
QGIS'e gelince, cevap biraz daha karmaşık, çalışma yolundaki cevabımı güncelleyeceğim. Çıldırmayın, bir trene binerim, bu yüzden benim için GIS.SE'ye cevap verirken sürüş yok :)
Ragi Yaser Burhum 20:11

12
+1 Bu okunabilir cevabı
sıkmadığınız

1
Bunu Silverlight veya Flash ile yapabilirsin. Bununla birlikte, önemli kısmın sunucuda olduğunu unutmayın, böylece Flash veya Silverlight bu kadar yardımcı olmaz.
Ragi Yaser Burhum

2
Dört yıl sonra, gelişen birçok şey var ve bu metin kutusunun açıklamak için sadece ~ 500 karakteri var. Özet şu ki, WebGL olgunlaşmış ve serileştirme tekniklerinin ötesinde, insanlar Topojson gibi formatlarda sabit hassasiyetli delta kodlaması (60'larda yaptığımız gibi) uyguluyorlar. Bu iyi bir şey. Bunların bazılarını OGC’nin standartlarında görmeyi çok isterdim ... yine de, OGC’nin etrafındaki politika son zamanlarda çok karmaşıktı. İşte iki yıl önceki duygularım: blog.burhum.com/post/50036141569/the-ogc-is-stuck-in-1999
Ragi Yaser Burhum

23

Doğrudan bir e-posta listesi yayınında geliştirici Dino Ravnic'den :

Nasıl yaptığımız büyük bir sır değil, bu yüzden bunu seninle paylaşmaktan mutlu olurum ... anahtar iki şeyde:

  1. Bir döşemeden çıkarılması, görünebilmesi için küçük olan tüm vektörleri, yani piksel olarak hesaplandığında alanlarını 1 pikselden daha küçüktür. bu yüzden böyle bir vektörü düşürüyoruz ve bunun yerine bir piksel yerleştiriyoruz, dolayısıyla json döşememizde "piksel"

  2. gerçekte görünecek olan vektörler genelleştiriliyor ve ardından koordinatları piksel olarak bir döşemeye yazılıyor

İstemci bölümünde, bu statik pikselleri ve görünür vektörleri tuval üzerinde oluşturuyoruz. Vektörlerin üzerine, asılı durma, yani etkileşimi sağlamak için fare olay işleme uyguladık. ve bu kadar.

Arka uç harita motorumuz tüm ağır kaldırma işlemlerini gerçekleştiriyor, çünkü herhangi bir ön hazırlık kullanmıyoruz ve tüm karolar anında üretiliyor. Hızlıca yenilenebilecek bir haritaya sahip olmak bizim için çok önemli.

Böylece müşteri tarafı kolay kısmı gibi geliyor. Verilerin herhangi bir önbellekleme olmadan oluşturulması etkileyicidir.

Ayrıca , ilginizi çekebilecek bir barındırma hizmetinden de bahseder . Hazır bir hizmet kullanmanın maliyeti ile yeniden yaratmaya çalışmanın maliyetini ölçmek isteyebilirsiniz.


Beni burada kafam karıştıran kısım, isteklerin postgise gönderilmesi ve standart geojsonu lat / long değerlerini geri almak yerine (realtime olarak) lat / long değerlerini xyz koordinatlarına dönüştürüp tükürmek gibi görünmesi gibi görünüyor. yakınlaştırma düzeyine ve gereken harita döşemelerine bağlı olarak. Sizce bu hızları elde etmek için ne kullanılıyor?
NetConstructor.com

@ netconstructor Belki de geometri zaten xyz geometrisinde depolanmıştır, dolayısıyla dönüştürmeye gerek yoktur?
coğrafya

göreceli xyz koordinatları muhtemelen daha az bant genişliğine ihtiyaç duyan göreli enlem / boylamdan daha kısadır.
Matthew Snape

doğru ama bu verileri anında dönüştürüyorlar
NetConstructor.com

17

OSGeo listesinde tanımladığım gibi, anahtar, alt piksel geometrisi için pikseller ve belirli bir seviyede gerçekten görülebilen özellikler için genelleştirilmiş geometriye sahip pikseller içeren vektör JSON döşemeleri olarak veri sunmaktır. Performans harika çünkü bu teknik tüm gereksiz vektör bilgilerini ortadan kaldırıyor ve sadece harita üzerinde görsel bir etkisi olacak olan vektörleri bırakıyor. Pikseller boşlukları doldurmak ve bu alt piksel vektörleri yerine yerleştirmek için vardır. Karo formatı ile ilgili budur.

Arka uç tarafında gerçek ağır kaldırma var. TileStache'yi veya başka bir harita motorunu kullanmıyoruz çünkü kendi optimizasyonumuzu yaptığımız gibi, bazı optimizasyonlarla bu tür vektör grafiklerini gerçek zamanlı olarak üretebildik.

İlk önce harita döşemelerini SWF'ler olarak sunmaya başladık ve son zamanlarda JSON'a çıktı verdik, böylece grafikleri işlemek için HTML5 Canvas'ı kullanabildik. Aşağıda bu tür vektör teknolojisini raster teknolojisi (mapnik) ile karşılaştıran bir kıyaslama bulabilirsiniz. Adil bir karşılaştırma için, sadece CGI modunda sonuçları arayın.

http://www.giscloud.com/blog/realtime-map-tile-rendering-benchmark-rasters-vs-vectors/

Bu teknolojiyi harita döşemesi barındırma hizmeti olarak sunmayı planlıyoruz. Buradaki fikir, coğrafi verilerinizi bulutta barındırmak ve HTML5 aracılığıyla döşemeleri önbelleklemenize gerek kalmadan herhangi bir harita istemcisine yüksek hızda teslim etmektir. Bu betaya katılmak istiyorsanız bizimle bizimle iletişime geçmekten çekinmeyin: http://www.giscloud.com/contact/


1
Vektör verileri için fayans kullanma fikri çok ilginç ("mekansal indeksleme" için başka bir ifade gibi görünüyor). Birkaç karoyu geçen özelliklerle nasıl başa çıkıyorsunuz? Kesildiler mi?
julien

3
evet, vektörler karoya karşı
kırpılıyor

14

Geçtiğimiz günlerde çok yakın bir soruya benzeyen OSGeo Açık Katmanlar forumunda , GIS Cloud geliştiricileri, GeoJSON geometrilerinin ve statik piksellerin ilginç bir karışımı olan yaklaşımlarını açıkladı. Aslında GeoJSON dosyalarının önceden oluşturulmuş bir önbelleğini kullanmak yerine anında tüm vektör döşemelerini oluştururlar.

Esri, ArcGIS Server ve Özellik Katmanlarını kullanarak , anında geometrileri genelleştirebilen ve tel üzerinden JSON olarak gönderebilen benzer bir yaklaşım uyguladı .

Şimdi uygulayabileceğiniz düz bir yöntem için, Tilestache ile ( PostGIS desteğine sahip ) vektör karoları oluşturabilir ve bunları Polymaps'ta tüketebilirsiniz . Polymaps SVG kullanır, ancak performans oldukça iyidir ve harita öğelerini stillendirmek için CSS kuralları vardır, bu yüzden özellik oluşturma tamamen size bağlıdır. Burada ne soran benzer bir şeyden çalışan bir blog yazısı olduğunu.


1
@wwnick - Cevabınız için teşekkürler, ancak GisCloud.com, her şeyin gerçek zamanlı olduğu anlamına gelen öğeleri önbelleğe almak zorunda kalmadan bu şaşırtıcı işlem gücüne izin veren bazı ek yöntemler kullanıyor gibi görünüyor. Soruya bir ödül ekledim ve derinlemesine bir çözüm sunmak için katılmaya istekli olacağınızı umuyordum. Şimdiye kadar cevabınız için teşekkürler!
NetConstructor.com

6

Canvas kullanarak OpenLayers ile bir oyun oynadım ve makul sonuçlar aldım.

Diğer cevaplarda belirtildiği gibi: vektörleri anında göstermek ve göstermek için - her yakınlaştırma seviyesi ve her veri kümesi için genelleştirilmesi gerekir. Ayrıca, boyutu azaltmak için Google çoklu çizgi kodlamasını kullanabilirsiniz.

Basit bir teslimat mekanizması kullandım. Her geometri, bir JavaScript HTTP yanıtı içindeki bir JavaScript işleviydi. Karo temelli vektör teslimatı kadar gelişmiş değil, basit ve Açık Kaynak!

Canvas ile Google Haritalar v3'ü denemeyi başaramadım, ancak etkileyici birkaç New York Times demo görmüştüm .


Bu yaklaşımla ilgili sorun, 500.000 poligonla uğraşırken çözümlerinin kadar çabuk olmamaları ve yani performansın gerçekten de kötü olmasıdır
NetConstructor.com

lütfen eklenen ödüllere dikkat edin ve lütfen ayrıntılı bir çözüm sunun. BTW New York Times çok havalı iken giscloud.com kullandığı çözümden farklı olarak flaş kullanmaktadır.
NetConstructor.com

bağlantınız çevrimdışı
NetConstructor.com 28:12 '

Evet, bunun için üzgünüm - benim "hobim" şimdi 4 yıl çokgenlerle ilişki kurduktan sonra sona erdi! GISCloud, nüfus sayım demomun birkaç yıl önce yayına girmesinden bu yana teknolojinin ne kadar ileri geldiğini gösteriyor ... Yukarıdaki açıklamada referansları kaldırdım.
eksi34

1
Geç olması hiç olmamasından daha iyi! Olabildiğince "kutunun dışında" olacak şeyleri güncelledim ve GitHub'a müşteri tarafı kodunu gönderdim . Yeni kodun kurulumu blog olarak yayınlandı . Şimdi direk olarak PostGIS'ten gelen çokgenleri okur ve anında inceltmeyi PostGIS RESTful Web Servis Çerçevesi ( PRWSF ) aracılığıyla bir Leaflet Javascript API istemcisine uygular . Neredeyse hiçbir arka uç kodlaması gerekmez!
eksi34

6

Bu şirket tarafından hangi çözümün kullanıldığını tam olarak bilmiyorum (belki doğrudan onlara sorabilirsiniz) ancak bir fikrim var.

Ağ aktarımını iyileştirmek ve vektör verilerini oluşturma hızını arttırmak için anahtar çözüm, onları yakınlaştırma düzeyine göre genelleştirmek: Daha düşük yakınlaştırma seviyesi için tasarlanmış bin nesnenin yüksek yakınlaştırma düzeyinde aktarılması ve görüntülenmesi genellikle çok zaman alıyor (ve ayrıca yararsızdır, çünkü nihai ekran genellikle okunaklı değildir - örneğin bu görüntüye bakınız ). Bunu uygulamak için, postgis sunucusu veritabanınızın çok ölçekli olması gerekir : Her yakınlaştırma düzeyi için, bu yakınlaştırma düzeyine uygun nesnenin bir gösterimi olmalıdır. Bu farklı gösterimler genelleme teknikleri kullanılarak otomatik olarak hesaplanabilir.. Ayrıca, sunucu tarafından müşteriye gönderilen vektör verisi sadece uzaysal uzamaya değil, aynı zamanda yakınlaştırma seviyesine de bağlı olmalıdır: Sunucu yakınlaştırma seviyesine bağlı olarak uygun verileri gönderir. Bu mükemmel makalede savunulan yaklaşım budur :-)


0

Büyük bir coğrafi veri setini görselleştirmek ve keşfetmek için her karo için veri bloğu kullanan Stanford Visualization Group tarafından geliştirilen bir yazılımın demo ve kaynak kodu olan ilginç bir makale var. Yalnızca nokta veri kümesi için kullanılabilir, ancak ilginç bir yol olabilir.

http://vis.stanford.edu/papers/immens

CartoDB platformları ve Torque adlı kütüphane ile canlılık, bir şekilde yüksek hacimli verilerin nasıl çekileceğini deniyor.

http://cartodb.github.io/torque/
https://github.com/CartoDB/torque/tree/new_torque

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.