Thanks for the report Gyorgy, this was overlooked in the upgrade process -
we were quite focused on serialization, but did not think about any of our
formats recording class names (usually you would record the geometry type
which is a shorter string).
Started an issue here https://osgeo-org.atlassian.net/browse/GEOT-6087
--
Jody Garnett
On Fri, 10 Aug 2018 at 05:50, György Tomcsányi <
gyorgy.tomcsa...@microstep-mis.com> wrote:
> Hi Andrea,
>
> we are preparing the pull request.
>
> We had a small problem when upgrading Geoserver to the latest build to
> test it. We had existing mosaics in the data dir, and Geoserver failed to
> start because of the JTS version upgrade. File
> <mosaic_dir>/.mosaic/<mosaic_name>.properties contains a reference to
> "com.vividsolutions.jts.geom.Polygon" which needed to be edited manually.
>
> I understand this is probably a work in progress.. but I have not found
> mentions of this in the Upgrade to JTS 1.15 document.
> Is this something that must be done manually after updating Geoserver or
> is there a way to do this automagically?
>
> best regards,
> Gyorgy
>
>
> On 9. 8. 2018 18:52, Andrea Aime wrote:
>
> Ah,
> by looking at it, it would seems the store wrapper in the mosaic module is
> not correctly
> delegating down the visitor and thus breaking database optimizations.
> Yep, pull requests are quite welcomed, please pay attention to the rules
> to contribute,
> detailed here:
> https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md
>
> In particular, note code formatting (just running maven on the command
> line will reformat the code as expected), presence of tests, and
> contribution agreement
>
> Cheers
> Andrea
>
>
> On Thu, Aug 9, 2018 at 6:30 PM György Tomcsányi <
> gyorgy.tomcsa...@microstep-mis.com> wrote:
>
>> Hello all,
>>
>> we are using GeoServer to display a large number of GeoTIFFs using
>> ImageMosaic data stores. The data has several dimensions (time and
>> custom). We are adding new data to these stores periodically and the
>> goal is to be able to display years of data (millions of granules). We
>> have encountered performance problems with the WMS GetCapabilities
>> operation. It is most noticeable when using Oracle database (or PostGIS
>> with parameter WrapStore=true). My colleague Ivan (in CC) implemented
>> changes which improved the performance for our use case significantly.
>> We would like to publish these changes and hopefully merge them into the
>> official repo.
>>
>> Details:
>> our performance problems are caused by the queries for values and
>> defaults for dimensions. The currently used queries vary depending on
>> the selected presentation for the dimension:
>>
>> 1. query for values:
>> "List":
>> * PostGIS (with WrapStore=false): SELECT distinct("<dim_name>")
>> FROM "<table_name>"
>> * Oracle: SELECT FID, <DIM_NAME> FROM <table_name>
>> * PostGIS (with WrapStore=true): SELECT "fid","<dim_name>" FROM
>> "<table_name>"
>> First version is clearly the fastest, because it loads only
>> distinct values.
>>
>> "Interval and resolution":
>> The queries are the same as for "List", but in this case we only
>> really need the min/max values, which could be calculated much faster in
>> the database.
>>
>> 2. query for defaults (when using smallest/biggest domain value):
>> * PostGIS (with WrapStore=false): SELECT <min | max> ("<dim_name>")
>> FROM "<table_name>"
>> * Oracle: SELECT FID, <DIM_NAME> FROM <table_name>
>> * PostGIS (with WrapStore=true): SELECT "fid","<dim_name>" FROM
>> "<table_name>"
>> Again the first PostGIS variant is clearly the fastest. Others load
>> all the values to the application where the min/max values are calculated.
>>
>> Our proposed solution creates optimized queries depending on which
>> presentation and default setting is used for the dimension. The needed
>> additional information from the settings is sent to the lower level
>> functions using new RenderingHints. The goal of the optimized queries is
>> to load only the needed values from the database (usually what the
>> current PostGIS query does). Unit tests were also added.
>>
>> We would like to get some feedback on this. Can I submit merge requests
>> (to both GeoTools and GeoServer) to review the code?
>> We are looking forward to any comments.
>>
>> best regards,
>> Gyorgy Tomcsanyi
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> --
>
> Regards, Andrea Aime == GeoServer Professional Services from the experts!
> Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
> 8844549 http://www.geo-solutions.it 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.*
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
