GML, KML, GeoJSON - Szybkość renderowania 3109 wielokątów?

Współpracuję z Geoserver, obsługując 48 dolnych hrabstw w USA dla openlayerów (3109 wielokątów - dużo więcej wierzchołków). Powiaty są ładowane do bazy danych Postgis. Jestem ciekawy doświadczenia programistów, gdy próbuję przesłać taką liczbę wierzchołków do klienta.

W jakim formacie WFS osiągnąłeś najlepsze wyniki? Czy zastosowano dodatkowe strojenie do Geoserver?

Zdaję sobie sprawę, że kafelkowy WMS byłby szybszy, ale chcę pozwolić na dynamiczne zmiany na mapie choropleth przy użyciu openLayers, tj. użytkownik przesyła formularz, wywoływany jest skrypt w języku Python i zwracane są nowe pojemniki danych dla openlayerów w celu ponownego załadowania div mapy. Chcę również wypróbować to w pełnej rozdzielczości, zanim zmniejszy złożoność wielokątów w openlayers.

Może to wywołuje kilka nowych pomysłów: Mam uruchomioną aplikację, w której użytkownicy mogą edytować mapę z wieloma elementami.

Zamiast wysyłać wszystkie dane jako WFS, korzystam z map WMS, a kiedy użytkownik kliknie lub narysuje wybór, pobieram wybrane elementy jako WFS .

Po wysłaniu aktualizacji z powrotem do serwera odświeżam warstwę WMS.

Istnieje kilka przykładów OpenLayers, które pokazują, jak to zrobić. Prawdopodobnie będziesz musiał go trochę ulepszyć, ale OpenLayers + GeoServer opracuje dla ciebie trudną część. Dane są przesyłane w formacie gzip, więc oryginalny format nie jest nawet tak ważny; to nie jest wąskie gardło. Pozwól OpenLayers i GeoServer dowiedzieć się, jakiego formatu używają do wymiany informacji.

To podejście całkiem dobrze się skaluje. Nawet osoby z powolnymi połączeniami i powolnymi komputerami mogą go używać do edycji mapy. Pobieranie setek elementów jest bardzo szybkie i prawdopodobnie nie będziesz potrzebować więcej niż to w tym samym czasie do edycji.

_{Wreszcie ... nie na temat, ale jeśli zamierzasz robić rzeczy po stronie klienta z danymi map: Pamiętaj, że IE7 i niższe będą problematyczne, jeśli chcesz rysować wielokąty za pomocą OpenLayers. OpenLayers używa SVG do rysowania po stronie klienta, a IE7 i niższe nie mają wbudowanej obsługi. Ci użytkownicy będą musieli pobrać starą, plugawą wtyczkę. Wszystkie inne przeglądarki są w porządku.}

GEOJSON jest moim zdaniem najlepszym formatem, jest łatwy do odczytania, łatwy w użyciu w javascript i ogólnie mniejszy niż GML / KML. Może nawet zawierać informacje o stylu, patrz tutaj .

Nie jest to oficjalny standard, ale jest obsługiwany zarówno w ulotkach, jak i openlayers oraz w wielu aplikacjach gis-desktop, takich jak qgis.

Korzystanie z GeoJSON to dobry początek do przyspieszenia systemu, ale może nie być wystarczający. Należy rozważyć zbudowanie kilku wersji warstwy danych, po jednej na warstwę powiększenia, i zastosować metody uogólnienia / uproszczenia do każdej wersji. Klient powinien poprosić o odpowiednią warstwę w zależności od wybranego poziomu powiększenia. Zapewni to odpowiedni poziom szczegółowości danych wymienianych między serwerem a klientem, a także znacznie zwiększy zarówno transfer sieciowy, jak i renderowanie. Aby pójść dalej, możesz rozszerzyć swój system o kafelki wektorowe i indeksowanie przestrzenne, jak opisano w tym dokumencie , ale nie jestem pewien, czy openlayers i geoserver poradzą sobie ... jeszcze!

Na pewno: zapomnij o GML.

Dlaczego nie użyć skryptu Python do utworzenia nowego pliku SLD i przesłania go do serwera WMS wraz z żądaniem.

Oto przykład .

Byłem już dwa razy podobną drogą, a renderowanie po stronie klienta dla czegoś więcej niż niewielkiej liczby punktów lub naprawdę prostych wielokątów po prostu nie jest dobrym pomysłem. Po przywiązaniu się do tej architektury wycofanie się jest kosztowne, aw każdym projekcie prawdopodobnie zobaczysz albo zmianę wymagań, albo wzrost ilości danych, gdy różni interesariusze / przełożeni zaczną widzieć, do czego zdolny jest Twój system. Metoda renderowania oparta na przeglądarce nie jest skalowana.

Jeśli chcesz dynamicznego renderowania, popieram podejście @ iant. I wcześniej opisano szereg opcji dla innego, ale związany z tym problem tutaj . Użyłem również uogólnienia wielokąta, aby pomóc w renderowaniu po stronie klienta, i chociaż zdecydowanie pomaga, generuje trudniejsze problemy, na przykład jeśli chcesz rozebrać nieogólniony wielokąt, gdy użytkownik powiększa obraz.

Nawet jeśli pracujesz na znanej platformie - np. Znasz sprzęt, wersję przeglądarki i wtyczki wszystkich klientów - co jest mało prawdopodobne, nie masz pojęcia, pod jakim obciążeniem działają ci klienci. Takie podejście wymaga, aby przeglądarka mogła uzyskać dużo czasu procesora, aby utrzymać płynność obsługi, a wszystko inne zirytuje użytkowników.