Hi all,
I've been thinking about the attribute selection in vector tile production.
During the meeting I've shown its importance in keeping vector tiles small
and how it enables merging multiple
features into one (the less attributes, the more likely that two features
share the same values).

I also proposed to create a dedicated configuration section for vector
tiles, in the layer publishing tab, to
select which attributes go into the vector tiles, and eventually which ones
go into the label sidecar layer.
Thinking about it a bit more, I want to make that configurable in the style
instead. Reasoning:


   - Keeps all the vector tile configuration in one bit (the style being
   already used for scale dependencies and feature filtering)
   - Allows to have different styles generate different types of vector
   tiles. One could have a simpler and a richer vector tile set. The style is
   also a WMTS/OGC API Tiles request parameter, which allows to tell apart the
   two tile sets.
   - Allows settings to be scale dependent (we might want more/less
   attributes depending on the scale, and also have the label sidecar layer
   only when zoomed in enough )

With this in mind, the configurations would go into FeatureTypeStyle and
Rule (FTS for general statements, Rule for scale dependent ones)...
a style designed to drive VTs normally has one of each.

Even in the case of a style that plays both the role of server side
rendering and VT driving, we could have the machinery pick the
configuration
from the list active portions at the current scale denominator/zoom level
(rendering tools already filter down a style based on the active rules,
eliminating the FTS that are left without any active rule). In case of
conflict, I'd go for picking the union of the attributes.

The vendor options would be:

   - vt-attributes: comma separated list of attributes to include in the
   vector tile
   - vt-label: true/false, enables the creation of a separate label layer
   - vt-label-attributes: comma separated list of list of attributes to
   include in the label layer

Here is an example of a CSS style used to drive the creation of a
topp:states equivalent as MVT,
with the idea that the label sidecar layer will only be available after
zoom level 4:

topp:states {
   fill: black;
   vt-attributes: 'PERSONS';
   [@z >= 4] {
     vt-label: true;
     vt-label-attributes: 'STATE_ABBR,STATE_NAME';  // in case we want to
display full name when zoomed in
   }
}

Thoughts?

Regards,

Andrea Aime


==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  339 8844549

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail


On Tue, Aug 13, 2024 at 7:30 PM Torben Barsballe <torbenbarsba...@gmail.com>
wrote:

> Attending
>
>    -
>
>    Torben Barsballe
>    -
>
>    Andrea Aime
>    -
>
>    Dave Blasby
>    -
>
>    Kevin Smith
>
>
> Actions from prior meetings:
>
>    -
>
>    [Done] Jody: request or setup discourse channels (for screenshots)
>    -
>
>    Please help review PRs everyone!
>
> Agenda
>
>    -
>
>    2.24.5 and 2.26-RC releases managers
>    -
>
>    2.26-RC incoming OMG!
>    -
>
>    Javascript/CSP/Wicket fun
>    -
>
>    TilematrixSet support in CSS and more
>    -
>
>    JDK 17 officially supported
>    -
>
>    Vector tiles chit chat
>
> Actions
>
>    -
>
>    Volunteer for 2.26-RC
>
>
> 2.24.5 and 2.26-RC releases managers
>
> Andrea to do 2.24.5 and 2.26-RC needs a release manager (see also mail
> communication).
>
> 2.24.5 last officially planned.
> 2.26-RC incoming OMG!
>
> September 2nd final deadline for new features.
>
> Some ideas:
>
>    -
>
>    PMD 7.x updates
>    -
>
>       GT <https://github.com/geotools/geotools/pull/4813> (incomplete,
>       stuck on “main”, needs help)
>       -
>
>       GWC <https://github.com/geowebcache/geowebcache> merged
>       -
>
>       GS <https://github.com/geoserver/geoserver/pull/7577> failures in
>       GWC due to changes, needs help
>       -
>
>    Run GWC Azure tests on Azurite
>    <https://github.com/GeoWebCache/geowebcache/pull/1304>, using
>    TestContainers
>    -
>
>    Bunch of dependency upgrades by Steve Ikeoka
>    -
>
>    Significant performance improvements in WMS metatiling
>    <https://github.com/geoserver/geoserver/pull/7457>
>    -
>
>    Data dir catalog loader
>    <https://github.com/geoserver/geoserver/pull/7421> (Andrea to test
>    again)
>    -
>
>    OGCAPI Inline JS Refactor
>    <https://github.com/geoserver/geoserver/pull/7587> (merged)
>    -
>
>    CSP headers PR <https://github.com/geoserver/geoserver/pull/7514>
>
>
> Stuff too late to merge:
>
>    -
>
>    Wicket upgrade <https://github.com/geoserver/geoserver/pull/7154>, a/b
>    testing not started
>    -
>
>    What about the markdown switch
>    <https://github.com/geoserver/geoserver/pull/7462>?
>
> Javascript/CSP/Wicket fun
>
> Some of the changes in the Wicket-9 upgrade produced CSP failures
>
> These should now be fixed <https://github.com/bradh/geoserver/pull/16>for
> homepage / WPS Request builder / WMS Request Builder
> TilematrixSet support in CSS and more
>
> Want to introduce Zoom level support into CSS to allow for writing
> vectorTile styles
>
> YSLD has classes to support this already - ZoomContext
> <https://github.com/geotools/geotools/blob/029dc5c8ccc503de3cfd7f4d1c939d8056c260c4/modules/extension/ysld/src/main/java/org/geotools/ysld/parse/ZoomContext.java#L27>,
> ZoomContextFinder
> <https://github.com/geotools/geotools/blob/029dc5c8ccc503de3cfd7f4d1c939d8056c260c4/modules/extension/ysld/src/main/java/org/geotools/ysld/parse/ZoomContextFinder.java#L27>,
> GWCZoomContextFinder
> <https://github.com/geoserver/geoserver/blob/6e9e25c0c7cdda9ada9f33f8255130d3afc76801/src/extension/ysld/src/main/java/org/geoserver/ysld/GWCZoomContextFinder.java#L22>.
> They are sufficiently generic to be trivial to bring up to gt-main.
>
> GeoServer should be the only user of the classes, so this refactor
> shouldn’t cause dependency issues for users of GeoTools.
>
> It would also be good practice to have YSLD (etc.) look-up GWC-related
> classes dynamically.
> JDK 17 officially supported
>
>    -
>
>    Marlin integration issue solved, now starts and works with Java 17 and
>    Java 21.
>    -
>
>    Depending on context/how it gets started, you might need to tweak the
>    JVM options, adding “--add-opens” and friends. We have that documented.
>    -
>
>    Tomcat 9 deployment + Java 17 seems to work without needing tweaks
>
>
> And also add Java 21 as experimental (actually GeoServer Cloud uses it by
> default).
> Vector tiles chit chat
>
> Tile Size Improvement Discussion:
>
>    -
>
>    Filter attributes before tiles generation
>    -
>
>    Seperate label and rendering layers
>    -
>
>    Merge features that share all attributes
>
> All of this configurable through the GUI
>
> Example from OpenMapTiles (a tile from St. Luis, zoom level 14), this
> selection is “one MVT feature”, all the buildings sharing the same
> attributes are one multi-polygon:
>
>
> This reduces MVT size tremendously (as well as browser-side rendering
> speed)
> _______________________________________________
> Geoserver-devel mailing list
> geoserver-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to