Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jody Garnett
    @jodygarnett
    @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!
    Navid Taheri
    @navid.ta:matrix.org
    [m]
    Hi everyone,
    I imported some geopackages files to my PostGIS store in GeoServer via ogr2ogr and for publishing that layer in GeoServer I used POST method explaide in featuretype GeoServer RESTful API, But I've big issue I can not check how many of files(layers) imported and published successfully, I'm going to know is there any way I'll be able to check publish progress state?
    Brad Hards
    @bradh
    @navid.ta:matrix.org You should be able to tell based on the REST API response.
    Or you could just GET the /layers later?
    Depends on what you're really trying to do here (or better, why you are trying to do it - what the information need is, the problem you are trying to solve).
    Navid Taheri
    @navid.ta:matrix.org
    [m]
    Thank you for your answer, I didn't know It was possible via feeaturetype RESTful API, because I tested method in my Linux terminal and then I didn't get any response.
    If you want to know why I did use this method(ogr2ogr and featuretype REST API) because I did know any options, GeoServer Importer REST API can not support conversion for geodatabases or archive files and then I did search, However I understood I can import my non shapefiles to PostGIS store by that method I explained in above.
    In GeoServer Importer extension REST, it is possible to check state of files in each step, state announce by some specific name such "PENDING", "COMPLETE", "ERROR" , etc, I'm looking a way to find out how can I know state or even I'll get a progress number percentage for each layer importing procedure.
    rappidGIS
    @rappidGIS
    Hi guys. I would like to use the lat & long coordinate data in the GS. I already search it in the db but couldn't find it. Please help sir. Thanks.
    Brad Hards
    @bradh
    What do you mean you didn't get any response? No response to the POST?
    @rappidGIS Your question doesn't have enough detail to be answered. We can't see your screen, have no idea what you're trying to do. Please explain what you are trying to do, what you've tried, what happened, and what you expected to happen instead.
    rappidGIS
    @rappidGIS
    @bradh ok I will get the picture. thanks