Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    paul van genuchten
    @pvgenuchten

    Looking at the code, maybe you need to customize a different header template?

    that template also includes common-header.ftl

    Jody Garnett
    @jodygarnett

    @pvgenuchten I have an answer for you ... the documentation does not match the code. Not sure which is right.

    • [x] Creating a file in GEOSERVER_DATA_DIR/templates/getfeature-header.ftl works
    • [ ] The documentation indicates GEOSERVER_DATA_DIR/ogc/features/getfeature-header.ftl

    Please try the templates/getfeature-header.ftl directory and report back.

    image.png
    Here is a very simple test
    paul van genuchten
    @pvgenuchten
    i'm interested to override common-header.ftl, not getfeature-header.ftl
    (getfeature-header includes common-header)
    paul van genuchten
    @pvgenuchten
    this works fine for most of the endpoints, except for the items endpoint
    Jody Garnett
    @jodygarnett
    image.png
    @pvgenuchten placing templates/common-header.ftl alongside templates/getfeature-header.ftl works (see modified breadcrumbs below)

    If I understand correctly the #include element:

    <#global pagecrumbs="<li class='breadcrumb-item'><a href='"+serviceLink("")+"'>Home</a></li><li class='breadcrumb-item'><a href='"+serviceLink("collections")+"'>Collections</a></li><li class='breadcrumb-item active'>Feature</li>">
    <#include "common-header.ftl">
    
    TEST Test test

    Does not know about our search order, and just looks in the same location as getfeature-header.ftl

    paul van genuchten
    @pvgenuchten
    Ok, going to try that
    Jody Garnett
    @jodygarnett
    excellent, hope it works (I am building main, are you building or using a nightly build?)
    paul van genuchten
    @pvgenuchten
    I use 2.19.nightly
    Andrea Aime
    @aaime
    The OGC API implementations are dveloped only on main, the code on 2.19.x is pretty much dead (receiving no backports)
    2 replies
    Jody Garnett
    @jodygarnett

    aside: I have been having fun testing postgis/geoserver performance (eventually found the problem was old version of postgis pre TWKB).

    During testing I was surprised that using "prepared statements" was a small bit slower than using text. I understood that using prepared statements (and simplify fast ) would engage TWKB and I expected more of an effect.

    Andrea Aime
    @aaime
    do you also have an older version of postgresql?
    Prepared statements were pretty bad performance wise since version... hum... what was it? 11 or 12?
    they learned to re-plan the query in a PS based on actual value around those versions (which makes all the difference)
    James Hughes
    @jnh5y
    Are you saying that prepared statements have gotten worse recently?
    Andrea Aime
    @aaime
    they got better
    Jody Garnett
    @jodygarnett
    I updated to the latest postgresql 13 and postgis 3.2 (following the chart )
    Andrea Aime
    @aaime
    there were pretty much unusable before
    James Hughes
    @jnh5y
    good to know
    Andrea Aime
    @aaime
    @jodygarnett then dunno... my experience with recent versions is the opposite, prepared statements are somewhat faster... may be system specific, data specific... who knows
    Jody Garnett
    @jodygarnett
    The difference is small (for 2 million buildings):
    • no simplification: prepared statements on 9.3 seconds, or off 8.9 seconds, is unexpected
    • fast simplification: prepared statements on - 6.3s, 6.25s vs off - 5.87s, 5.93s
    James Hughes
    @jnh5y
    what timing is that? ingest? query?
    Jody Garnett
    @jodygarnett
    Cool just wanted to compare your recent experience, I can dig more.
    It is a getmap at a city scale, url taken from layer preview at 1000x1000, testing using curl for timing.
    James Hughes
    @jnh5y
    ok, do all the buildings have to get returned? (I imagine you are picking up some rendering time, etc)
    Andrea Aime
    @aaime
    difference is like 6%? Not that much, could be caused by other things (like, you should be doing a load test and do averages, checking nothing else is going on)
    Jody Garnett
    @jodygarnett
    Just having fun trying out the new toys; this was intended as a mean test to compare having the database in different locations.
    Yep, as indicated this result was not the primary goal, just a surprising (to me) result. Since it also sounds a small bit surprising to you I can spend some more time on it.
    Andrea Aime
    @aaime
    Jody Garnett
    @jodygarnett
    That is very interesting about the first five requests being used to decide between generic and custom plan.
    Jody Garnett
    @jodygarnett
    going to go post the meeting notes
    Jody Garnett
    @jodygarnett
    Checking now the overheads now:
    • 2778.254 ms SELECT "fid",ST_AsTWKB(ST_Simplify(ST_Force2D(....
    • 2633.465 ms SELECT "fid",ST_AsTWKB(ST_Simplify(.... 5% overhead
    • 1552.512 ms SELECT "fid",ST_AsTWKB( ... is simpify needed before TKWB?
    • 1999.616 ms SELECT "fid",ST_AsTWKB(ST_Force2D(....
    I guess St_Simplify is useful when zoomed in to remove co-linear points
    James Hughes
    @jnh5y
    what are those timing measuring?
    (to me) it makes sense that simplifying first would be slower since one would be doing some topology first...
    I wonder, if depending on the precision, if there's any simplification which could be performed as part of that step?
    e.g., if one knew that they were doing a topological simplification and immediately reducing the precision, would you do some of the simplification first?
    Jody Garnett
    @jodygarnett
    Right now I am considering checking geometry_columns to see if we can remove the ST_Force2D in some cases
    Jody Garnett
    @jodygarnett
    This is CPU bound on the rendering, so ST_Force2D is not going to be noticed
    Jody Garnett
    @jodygarnett

    @pvgenuchten did a bit more testing, updated docs here geoserver/geoserver#5124

    I am not content and would like a single global common-header.ftl to be used if supplied.

    paul van genuchten
    @pvgenuchten
    thanx jody, i can confirm that placing common-header.ftl in data/workspaces, the /items/* case works fine for me
    to summarise: to override common-header for /collections, you need to add the override in /data/templates/ogc/features, for /items you need to place it in data/workspaces
    Jody Garnett
    @jodygarnett

    I imagine if you add it once to to data/workspaces or templates it should work for both, something to test.

    Maybe the best way to think of it is adding ogc/features/<something>.ftl and common-header.ftl

    Andrea Aime
    @aaime
    Heads up for my fellow GS devs, next week I'm gonna be seaside, not sure how much I'll check mail, if at all
    Jody Garnett
    @jodygarnett
    Enjoy the ocean!