Etykieta wielokąta powtórzona dla każdej płytki

Używam samodzielnego GeoWebCache do obsługi kafelków ze zdalnego GeoServera. Mój problem polega na tym, że etykieta wielokąta jest dodawana do każdego z obsługiwanych kafelków, zamiast tylko raz w centroidie wielokąta.

Znalazłem post omawiający problem:
http://osgeo-org.1560.n6.nabble.com/polygon-label-repeated-for-each-tile-td4995203.html

Pierwsza odpowiedź wspomniała o możliwym rozwiązaniu:

„Podsumowując, proponuję użyć silnika renderowania kafelków (GeoWebCache, MapProxy, TileCache), zamiast żądać małego obrazu od GeoServer i pozwolić silnikowi renderowania kafelków wykonać później krojenie kafelków. Prześlesz mniej zapytań do GeoServer 1 duży obraz zamiast wielu małych obrazów), co przyspiesza całkowity czas tworzenia pamięci podręcznej kafelków. ”

Problem polega na tym, że nie mogłem tego zrobić, odwołując się do dokumentacji GeoWebCache, a wyżej wspomniany post nie wyjaśnia, jak to zaimplementować.

Znalazłem również post z odpowiedzią, która prowadzi do dokumentacji „kafelkowej” GeoWebCache , ale mój kod już używa wszystkich niezbędnych atrybutów, a mimo to etykieta wyświetla się wiele razy:

var Layer_1874 = new OpenLayers.Layer.WMS(
    'Grundkort',
    '/wms10.ashx'
    , {
        format: 'image/png',
        srs: 'EPSG:25832',
        layers: 'ballerupkommune_grundkort_bk',
        tiled: true,
        tilesOrigin: '698804,6173460'
    }
    , {
        displayInLayerSwitcher: true,
        isBaseLayer: true,
        transitionEffect: 'resize',
        displayOutsideMaxExtent: true,
        visibility: false
    }
);

Czy ktoś ma pomysł?

Poniżej znajduje się przykład reguły SLD, która umieszcza etykietę na środku geometrii elementu. Do umieszczenia etykiety użyto funkcji ogc: Function o nazwie „centroid”. Możesz przeczytać więcej o funkcjach SLD w dokumentach GeoServer , a niektóre przykłady podano tutaj .

<sld:Rule>
      <MaxScaleDenominator>5000</MaxScaleDenominator>
      <sld:TextSymbolizer>
        <sld:Geometry>
          <ogc:Function name="centroid">
            <ogc:PropertyName>the_geom</ogc:PropertyName>
          </ogc:Function>
        </sld:Geometry>
        <sld:Label>
          <ogc:PropertyName>LOT_NAME</ogc:PropertyName>
        </sld:Label>
        <sld:Font>
          <sld:CssParameter name="font-family">Arial</sld:CssParameter>
          <sld:CssParameter name="font-size">11</sld:CssParameter>
          <sld:CssParameter name="font-style">normal</sld:CssParameter>
          <sld:CssParameter name="font-weight">bold</sld:CssParameter>
        </sld:Font>
        <sld:LabelPlacement>
          <sld:PointPlacement>
            <sld:AnchorPoint>
              <sld:AnchorPointX>
                <ogc:Literal>0.0</ogc:Literal>
              </sld:AnchorPointX>
              <sld:AnchorPointY>
                <ogc:Literal>0.5</ogc:Literal>
              </sld:AnchorPointY>
            </sld:AnchorPoint>
            <sld:Rotation>
              <ogc:Literal>0</ogc:Literal>
            </sld:Rotation>
          </sld:PointPlacement>
        </sld:LabelPlacement>
        <sld:Halo>
          <sld:Radius>
            <ogc:Literal>1.0</ogc:Literal>
          </sld:Radius>
          <sld:Fill>
            <sld:CssParameter name="fill">#FFFFFF</sld:CssParameter>
          </sld:Fill>
        </sld:Halo>
        <sld:VendorOption name="conflictResolution">true</sld:VendorOption>
        <sld:VendorOption name="goodnessOfFit">0</sld:VendorOption>
        <sld:VendorOption name="autoWrap">60</sld:VendorOption>
      </sld:TextSymbolizer>
    </sld:Rule>

Również książka kucharska SLD jest świetnym odniesieniem. Jedną z rzeczy, które mogą cię potknąć, jest kolejność tagów w SLD. W przypadku powyższej reguły TextSymbolizer można sprawdzić wymaganą kolejność, przeglądając definicję schematu. Nie martw się, to nie jest zbyt przerażające! Wystarczy wyszukać „textymbolizer” w tym pliku .xsd, a powinieneś łatwo znaleźć znacznik „sekwencji”. Przekonasz się, że odniesienia do elementów są zgodne z kolejnością w moim przykładzie. (Uwaga: nie użyłem atrybutu „wypełnienia” symbolizatora tekstu, moje wypełnienie dotyczy tylko aureoli).

Obliczanie etykiet z rozdzielczością kolizji (odsuwanie etykiet na bok lub usuwanie etykiet o niższym priorytecie, aby się nie nakładały) wymaga znajomości każdej etykiety, która może kolidować z rysowaną etykietą, każdej etykiety, która może się z nimi kolidować itd. . Ogólnie rzecz biorąc, albo musisz obliczyć wszystkie etykiety na raz, patrząc na każdą cechę, albo podzielić mapę na bloki z etykietami obliczonymi w każdym bloku.

Domyślnie GeoWebCache używa bloku kafelków 4x4 zwanego „metabilnym”. Kiedy poprosisz o kafelek, którego nie ma w pamięci podręcznej, GWC zażąda całego metapliku jako jednego dużego obrazu z zaplecza, a następnie pokroić metaplik na kafelki, które buforuje. Możesz dostosować współczynnik metastabilności podczas konfigurowania warstwy. Większe metatile dają lepiej wyglądające etykiety, ale zwiększają opóźnienie braku pamięci podręcznej. Jeśli nie używasz rozdzielczości kolizji etykiet na zapleczu, możesz ustawić metatiling na 1x1.

Możesz także powiedzieć GWC, aby dodał rynnę wokół metabilizatora, czyli dodatkowej przestrzeni, która zostanie odcięta. Jest to ryzykowne, jeśli masz rozdzielczość kolizji etykiet, ponieważ etykieta może być umieszczona inaczej lub nawet zostać całkowicie usunięta po drugiej stronie metabilizowanej granicy. Jeśli masz etykiety, które są całkowicie ustalone na miejscu i nigdy nie są tłumione, aby uniknąć kolizji, możesz użyć szerokiej rynny, aby umożliwić etykietom przekraczanie granic kafelków. Będzie to miało koszt wydajności, ponieważ GeoServer będzie musiał renderować większy kafelek.

Możesz ustawić metatiling i rynnę na zakładce Warstwa kafelków w konfiguracji warstw, lub domyślną, która będzie używana dla nowych warstw, możesz ustawić na stronie Domyślne buforowanie.

Aby wyłączyć rozwiązywanie konfliktów, możesz użyć conflictResolutionopcji dostawcy w swoich stylach.