Speaking of serializing class names, the GeoServer configuration migth also
do that:
https://github.com/geoserver/geoserver/blob/6e9e25c0c7cdda9ada9f33f8255130d3afc76801/src/main/src/main/java/org/geoserver/catalog/AttributeTypeInfo.java#L71
(see getBinding).
However, I don't remember under what conditions it happens, or does not,
but found one instance in the data dir I use to play
the most with GeoServer:
> myDaaDir/workspaces $ grep -r "com.vividsolutions" . | grep xml
./importer/taz_shapes/tasmania_cities/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPoint</binding>
and then checked others and found the same in a number of them as well,
e.g.:
./many_states/workspaces/the_states/many_states/states_101/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
./many_states/workspaces/the_states/many_states/states_1010/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
./many_states/workspaces/the_states/many_states/states_1011/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
./many_states/workspaces/the_states/many_states/states_1012/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
./many_states/workspaces/the_states/many_states/states_1013/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
./many_states/workspaces/the_states/many_states/states_1014/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
./many_states/workspaces/the_states/many_states/states_1015/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
./many_states/workspaces/the_states/many_states/states_1016/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
...
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/lineCompound3d-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.LineString</binding>
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/skipcolumn-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.Geometry</binding>
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/ftjoin-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.Geometry</binding>
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/lake-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.Polygon</binding>
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/ft1-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.Point</binding>
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/geoline-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.LineString</binding>
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/road-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.LineString</binding>
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/a_3dfloor-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.MultiPolygon</binding>
./large_jdbcconfig/workspaces/topp-copy-210/gttest-copy-210/lakes_null-copy-210/featuretype.xml:
<binding>com.vividsolutions.jts.geom.Geometry</binding>
...
Maybe this was already covered, but just in case...
Cheers
Andrea
On Fri, Aug 10, 2018 at 6:12 PM Jody Garnett <jody.garn...@gmail.com> wrote:
> 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
>>
>
--
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
