Re: [Geoserver-users] Legend issue - multiple symbols for cased lines
Actually it turns out that for our particular case (cased polygon outlines) the visual quality of simply having two LIneSymbolizers in the same rule is acceptable (although obviously not ideal where polygons meet). And this of course produces a correct Legend. So we'll go with this for now. On Thu, Feb 23, 2017 at 10:59 AM, Martin Davis wrote: > Makes sense, Andrea. > > In this particular case the rules are as simple as can be - no filters or > scale dependency. So that should be the easiest case to handle. > > I can see how this could be hard to do for complex rules. But then again, > if the rules are different, the Legend should probably show separate > entries for them. > > Not sure I'll be able to rustle up funding to work on this, but I'll give > it a try. > > On Thu, Feb 23, 2017 at 10:36 AM, Andrea Aime < > andrea.a...@geo-solutions.it> wrote: > >> On Thu, Feb 23, 2017 at 7:19 PM, Martin Davis wrote: >> >>> As I understand it, the recommended approach for producing "cased" lines >>> (e.g. for roads or polygon outlines) is to specify each different line >>> style in a separate FeatureTypeStyle. >>> >>> However, this seems to produce Legend graphics with the different line >>> styles on separate lines. (See attached map tile and legend). >>> >>> Is this a known issue? Any workaround or fix? >>> >> >> Well know issue. Fix is not trivial (not at all), but I have something in >> mind. >> >> So, the two feature type styles are painted separately, and might be >> completely unrelated... like, for example, two feature type styles >> could be used to z order features that should appear in the back and in >> the front. >> >> So one would have to compare rules in higher FTS with the lower ones, and >> if they are a match, merge the >> symbolizer from the higher FTS with the lower rules, making the higher >> fts rule disappear. >> Basically, restructure the SLD so that you end up with a single FTS. >> >> The tricky part is defining what a "match" is. In general, it's taking >> the filters of the two rules, combining them, >> and determining that they are not "logically empty". The >> SimplifyingFilterVisitor has some symbolic evaluation >> capabilities, but they are limited and sometimes expensive. >> >> I think you can imagine how this can easily spiral out of control with >> very complex styles (having many FTS layers). >> Still, I'd give it a try, maybe trying to constrain the application of >> this logic to some "sane-ish" simpler case. >> >> Cheers >> Andrea >> >> >> -- >> == >> 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 <+39%200584%20962313> >> fax: +39 0584 1660272 <+39%200584%20166%200272> >> mob: +39 339 8844549 <+39%20339%20884%204549> >> >> http://www.geo-solutions.it >> http://twitter.com/geosolutions_it >> >> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* >> >> Le informazioni contenute in questo messaggio di posta elettronica e/o >> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il >> loro utilizzo è consentito esclusivamente al destinatario del messaggio, >> per le finalità indicate nel messaggio stesso. Qualora riceviate questo >> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di >> darcene notizia via e-mail e di procedere alla distruzione del messaggio >> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, >> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od >> utilizzarlo per finalità diverse, costituisce comportamento contrario ai >> principi dettati dal D.Lgs. 196/2003. >> >> >> >> The information in this message and/or attachments, is intended solely >> for the attention and use of the named addressee(s) and may be confidential >> or proprietary in nature or covered by the provisions of privacy act >> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection >> Code).Any use not in accord with its purpose, any disclosure, reproduction, >> copying, distribution, or either dissemination, either whole or partial, is >> strictly forbidden except previous formal approval of the named >> addressee(s). If you are not the intended recipient, please contact >> immediately the sender by telephone, fax or e-mail and delete the >> information in this message that has been received in error. The sender >> does not give any warranty or accept liability as the content, accuracy or >> completeness of sent messages and accepts no responsibility for changes >> made after they were sent or for other risks which arise as a result of >> e-mail transmission, viruses, etc. >> >> --- >> > > -- Check out the vibrant tech community on one of the world's most engaging te
Re: [Geoserver-users] Legend issue - blank entries for label rules
Ok... at least this confirms this is known behaviour, not something we're missing. On Thu, Feb 23, 2017 at 10:24 AM, Andrea Aime wrote: > On Thu, Feb 23, 2017 at 7:12 PM, Martin Davis wrote: > >> It looks like GeoServer produces a "blank line" in Legends if a >> TextSymbolizer is specified in a separate rule (as is often done for >> scale-dependent labelling). Is there any way to turn this off? >> > > Yep: https://github.com/geoserver/geoserver/blob/master/CONTRIBUTING.md > > >> This behaviour actuall seems a bit useless, so perhaps it could be >> prevented in the code? >> > > Agreed it should > > Cheers > Andrea > > -- > == > 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 <+39%200584%20962313> > fax: +39 0584 1660272 <+39%200584%20166%200272> > mob: +39 339 8844549 <+39%20339%20884%204549> > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* > > Le informazioni contenute in questo messaggio di posta elettronica e/o > nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il > loro utilizzo è consentito esclusivamente al destinatario del messaggio, > per le finalità indicate nel messaggio stesso. Qualora riceviate questo > messaggio senza esserne il destinatario, Vi preghiamo cortesemente di > darcene notizia via e-mail e di procedere alla distruzione del messaggio > stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, > divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od > utilizzarlo per finalità diverse, costituisce comportamento contrario ai > principi dettati dal D.Lgs. 196/2003. > > > > The information in this message and/or attachments, is intended solely for > the attention and use of the named addressee(s) and may be confidential or > proprietary in nature or covered by the provisions of privacy act > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection > Code).Any use not in accord with its purpose, any disclosure, reproduction, > copying, distribution, or either dissemination, either whole or partial, is > strictly forbidden except previous formal approval of the named > addressee(s). If you are not the intended recipient, please contact > immediately the sender by telephone, fax or e-mail and delete the > information in this message that has been received in error. The sender > does not give any warranty or accept liability as the content, accuracy or > completeness of sent messages and accepts no responsibility for changes > made after they were sent or for other risks which arise as a result of > e-mail transmission, viruses, etc. > > --- > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Legend issue - multiple symbols for cased lines
Makes sense, Andrea. In this particular case the rules are as simple as can be - no filters or scale dependency. So that should be the easiest case to handle. I can see how this could be hard to do for complex rules. But then again, if the rules are different, the Legend should probably show separate entries for them. Not sure I'll be able to rustle up funding to work on this, but I'll give it a try. On Thu, Feb 23, 2017 at 10:36 AM, Andrea Aime wrote: > On Thu, Feb 23, 2017 at 7:19 PM, Martin Davis wrote: > >> As I understand it, the recommended approach for producing "cased" lines >> (e.g. for roads or polygon outlines) is to specify each different line >> style in a separate FeatureTypeStyle. >> >> However, this seems to produce Legend graphics with the different line >> styles on separate lines. (See attached map tile and legend). >> >> Is this a known issue? Any workaround or fix? >> > > Well know issue. Fix is not trivial (not at all), but I have something in > mind. > > So, the two feature type styles are painted separately, and might be > completely unrelated... like, for example, two feature type styles > could be used to z order features that should appear in the back and in > the front. > > So one would have to compare rules in higher FTS with the lower ones, and > if they are a match, merge the > symbolizer from the higher FTS with the lower rules, making the higher fts > rule disappear. > Basically, restructure the SLD so that you end up with a single FTS. > > The tricky part is defining what a "match" is. In general, it's taking the > filters of the two rules, combining them, > and determining that they are not "logically empty". The > SimplifyingFilterVisitor has some symbolic evaluation > capabilities, but they are limited and sometimes expensive. > > I think you can imagine how this can easily spiral out of control with > very complex styles (having many FTS layers). > Still, I'd give it a try, maybe trying to constrain the application of > this logic to some "sane-ish" simpler case. > > Cheers > Andrea > > > -- > == > 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 <+39%200584%20962313> > fax: +39 0584 1660272 <+39%200584%20166%200272> > mob: +39 339 8844549 <+39%20339%20884%204549> > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* > > Le informazioni contenute in questo messaggio di posta elettronica e/o > nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il > loro utilizzo è consentito esclusivamente al destinatario del messaggio, > per le finalità indicate nel messaggio stesso. Qualora riceviate questo > messaggio senza esserne il destinatario, Vi preghiamo cortesemente di > darcene notizia via e-mail e di procedere alla distruzione del messaggio > stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, > divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od > utilizzarlo per finalità diverse, costituisce comportamento contrario ai > principi dettati dal D.Lgs. 196/2003. > > > > The information in this message and/or attachments, is intended solely for > the attention and use of the named addressee(s) and may be confidential or > proprietary in nature or covered by the provisions of privacy act > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection > Code).Any use not in accord with its purpose, any disclosure, reproduction, > copying, distribution, or either dissemination, either whole or partial, is > strictly forbidden except previous formal approval of the named > addressee(s). If you are not the intended recipient, please contact > immediately the sender by telephone, fax or e-mail and delete the > information in this message that has been received in error. The sender > does not give any warranty or accept liability as the content, accuracy or > completeness of sent messages and accepts no responsibility for changes > made after they were sent or for other risks which arise as a result of > e-mail transmission, viruses, etc. > > --- > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Legend issue - multiple symbols for cased lines
On Thu, Feb 23, 2017 at 7:19 PM, Martin Davis wrote: > As I understand it, the recommended approach for producing "cased" lines > (e.g. for roads or polygon outlines) is to specify each different line > style in a separate FeatureTypeStyle. > > However, this seems to produce Legend graphics with the different line > styles on separate lines. (See attached map tile and legend). > > Is this a known issue? Any workaround or fix? > Well know issue. Fix is not trivial (not at all), but I have something in mind. So, the two feature type styles are painted separately, and might be completely unrelated... like, for example, two feature type styles could be used to z order features that should appear in the back and in the front. So one would have to compare rules in higher FTS with the lower ones, and if they are a match, merge the symbolizer from the higher FTS with the lower rules, making the higher fts rule disappear. Basically, restructure the SLD so that you end up with a single FTS. The tricky part is defining what a "match" is. In general, it's taking the filters of the two rules, combining them, and determining that they are not "logically empty". The SimplifyingFilterVisitor has some symbolic evaluation capabilities, but they are limited and sometimes expensive. I think you can imagine how this can easily spiral out of control with very complex styles (having many FTS layers). Still, I'd give it a try, maybe trying to constrain the application of this logic to some "sane-ish" simpler case. Cheers Andrea -- == 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 *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Legend issue - blank entries for label rules
On Thu, Feb 23, 2017 at 7:12 PM, Martin Davis wrote: > It looks like GeoServer produces a "blank line" in Legends if a > TextSymbolizer is specified in a separate rule (as is often done for > scale-dependent labelling). Is there any way to turn this off? > Yep: https://github.com/geoserver/geoserver/blob/master/CONTRIBUTING.md > This behaviour actuall seems a bit useless, so perhaps it could be > prevented in the code? > Agreed it should Cheers Andrea -- == 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 *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc. --- -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] Legend issue - multiple symbols for cased lines
As I understand it, the recommended approach for producing "cased" lines (e.g. for roads or polygon outlines) is to specify each different line style in a separate FeatureTypeStyle. However, this seems to produce Legend graphics with the different line styles on separate lines. (See attached map tile and legend). Is this a known issue? Any workaround or fix? -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] Legend issue - blank entries for label rules
It looks like GeoServer produces a "blank line" in Legends if a TextSymbolizer is specified in a separate rule (as is often done for scale-dependent labelling). Is there any way to turn this off? This behaviour actuall seems a bit useless, so perhaps it could be prevented in the code? -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] Complex GML 3.1.1 from App Schema
Hi I have created an app schema for two different feature types, type 1 contains a field of type 2 that is then populated via a mapping file. However when I do a WFS request with GML 3.1.1, I get: Edinburgh Castle Open Stone Stone 1 1 3.1987 55.9486 http://www.opengis.net/gml/srs/epsg.xml#4326";> 3.1987 55.9486 However, when I do GML3.2 I get: Edinburgh Castle Open Stone Stone 1 1 3.1987 55.9486 http://stategeothermaldata.org/uri-gin/aasg/xmlschema/thermalconductivity/2.0"; id="administrativeareas.1"> Edinburgh 55.9533 3.1883 POINT (3.1883 55.9533) POINT (3.1987 55.9486) The feature of type 2 is imbedded in the Area element (albeit with a null namespace). I am then trying to use the QGIS GML Application toolbox to parse the output into related tables, however I believe that it only works with 3.1.1 (throws an error with 3.2). Additionally, if I change the type of the Area field in the XSD to xs:string then it produces a string representation of the entire feature in GML 3.1.1. I can then import this into QGIS using the aforementioned plugin. However it obviously doesn't parse out the object (because its a string and not of feature type 2). What am I doing wrong? Thanks in advance Sam -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Complex-GML-3-1-1-from-App-Schema-tp5309269.html Sent from the GeoServer - User mailing list archive at Nabble.com. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] Add store RPFTOC: Could not list layers for this store, an error occurred retrieving them: Incorrect input type!
I am attempting to add a store for raster data source RPFTOC -- RPFTOC Coverage format. When I hit save I get the following: Could not list layers for this store, an error occurred retrieving them: Incorrect input type! In the catalina.out I see the following error: Getting list of coverages for saved store file:data/CADRG/250/RPF/A.TOC java.lang.RuntimeException: Could not list layers for this store, an error occurred retrieving them: Incorrect input type! at org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:158) at org.geoserver.web.data.layer.NewLayerPageProvider.getItems(NewLayerPageProvider.java:61) at org.geoserver.web.wicket.GeoServerDataProvider.fullSize(GeoServerDataProvider.java:243) -- I am using the following: geoserver-2.10.1-war.zip apache-tomcat-7.0.75.tar.gz geowebcache-1.9.1-war.zip geoserver-2.10.1-gdal-plugin.zip gdal-data.zip imageio-ext-1.1.16-jars.zip In catalina.sh I have the following set: export PATH="/usr/java//jdk1.8.0_25/bin:$PATH" JAVA_OPTS="-server -Xmx256M" In setcalsspath.sh I have the following set: export LD_LIBRARY_PATH=/opt/gdal-1.9.2_x64_rh6_Cent:$LD_LIBRARY_PATH export GDAL_DATA=/cctt/work/gdal_data/gdal-data When I use gdalinfo on the A.TOC I get valid information back about my data.(Did not include but can if needed.) My CADRG data is stored in following path: /opt/apache-tomcat-7.0.75/webapps/geoserver/data/data/CADRG/250/RPF And has the following structure: CADRG 250 RPF A.TOC CADRGJA zone1 00ywz01x.ja1 zone2 100 RPF 50 RPF Prior to the exception I do see the following in catalina.out Feb 22, 2017 5:55:15 PM it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL INFO: GDAL Native Library loaded (version: 1.9.2) Any help would be greatly appreciated! Thank you, Chris -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] YSLD Rule LegendGraphic Missing
The SLD schema allows Rule elements to contain a LegendGraphic element but they are ignored when GeoServer converts an SLD style to YSLD. This is not currently implemented according to the YSLD Reference: http://docs.geoserver.org/latest/en/user/styling/ysld/reference/rules.html Example: ... image/png ... Steve Ikeoka -- View this message in context: http://osgeo-org.1560.x6.nabble.com/YSLD-Rule-LegendGraphic-Missing-tp5309253.html Sent from the GeoServer - User mailing list archive at Nabble.com. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Database pooling for clustered Geoserver configuration
All, I am copying in here what I have done to make this work in Ubuntu 16.04. I would recommend do the reading in the links in this post before implementing the following. *#Move the JDBC driver to the tomcat container instead of the geoserver application.* sudo mv /opt/apache-tomcat-7.0.73-1/webapps/geoserver/WEB-INF/lib/postgresql-9.4.1211.jar /opt/apache-tomcat-7.0.73-1/lib/postgresql-9.4.1211.jar sudo mv /opt/apache-tomcat-7.0.73-2/webapps/geoserver/WEB-INF/lib/postgresql-9.4.1211.jar /opt/apache-tomcat-7.0.73-2/lib/postgresql-9.4.1211.jar sudo mv /opt/apache-tomcat-7.0.73-3/webapps/geoserver/WEB-INF/lib/postgresql-9.4.1211.jar /opt/apache-tomcat-7.0.73-3/lib/postgresql-9.4.1211.jar sudo mv /opt/apache-tomcat-7.0.73-4/webapps/geoserver/WEB-INF/lib/postgresql-9.4.1211.jar /opt/apache-tomcat-7.0.73-4/lib/postgresql-9.4.1211.jar *#Edit all the context.xml files for the different tomcat instances.* sudo nano /opt/apache-tomcat-7.0.73-1/conf/context.xml sudo nano /opt/apache-tomcat-7.0.73-2/conf/context.xml sudo nano /opt/apache-tomcat-7.0.73-3/conf/context.xml sudo nano /opt/apache-tomcat-7.0.73-4/conf/context.xml *#Add the following lines in context.xml files which are edited.* *#Restart all tomcat instances* sudo service tomcat-1 restart sudo service tomcat-2 restart sudo service tomcat-3 restart sudo service tomcat-4 restart Regards, D. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Database-pooling-for-clustered-Geoserver-configuration-tp5306937p5309251.html Sent from the GeoServer - User mailing list archive at Nabble.com. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Geoserver 2.9.2 GC overhead limit exceeded
Thank you for your suggestions, I have finally received .jar list: /imageio-ext-arcgrid-1.1.15.jar imageio-ext-gdalarcbinarygrid-1.1.15.jar imageio-ext-gdal-bindings-1.9.2.jar imageio-ext-gdaldted-1.1.15.jar imageio-ext-gdalecw-1.1.15.jar imageio-ext-gdalecwjp2-1.1.15.jar imageio-ext-gdalehdr-1.1.15.jar imageio-ext-gdalenvihdr-1.1.15.jar imageio-ext-gdalerdasimg-1.1.15.jar imageio-ext-gdalframework-1.1.15.jar imageio-ext-gdalidrisi-1.1.15.jar imageio-ext-gdalkakadujp2-1.1.15.jar imageio-ext-gdalmrsid-1.1.15.jar imageio-ext-gdalmrsidjp2-1.1.15.jar imageio-ext-gdalnitf-1.1.15.jar imageio-ext-gdalrpftoc-1.1.15.jar imageio-ext-geocore-1.1.15.jar imageio-ext-imagereadmt-1.1.15.jar imageio-ext-png-1.1.13.jar imageio-ext-streams-1.1.15.jar imageio-ext-tiff-1.1.15.jar imageio-ext-utilities-1.1.15.jar/ Waiting for the next crash. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-9-2-GC-overhead-limit-exceeded-tp5306122p5309242.html Sent from the GeoServer - User mailing list archive at Nabble.com. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] FW: Serving 4 bands GeoTiff with GeoServer WMS
Hi Samuel, I didn't see your previous email (ended somehow in spam?), therefore sorry for not having answered before. I'm also keeping the whole list in CC in case anyone else is able to share his knowledge and provide additional feedbacks. When dealing with more than 3 bands in WMS (where > 3 is not alpha channel) you could consider setting up an SLD to select the bands you need (through RasterSymbolizer's channel selection [1] ) or setup a coverageView to reorder/reorganize the bands as you need [2]. Also note from your gdalinfo attachment that your images are 16bit per band. You may consider to reprocess them to convert to 8 bit before serving the dataset through WMS OR you can add contrastEnhancement to your SLD to have bands rescaled to 8 bit. Preprocessing in advance should allow for better rendering performances since the operation is made once before configuring the layer instead of having the constrast enhancement processing done on the fly for each getMap. Does it helps? Cheers, Daniele [1]: http://docs.geoserver.org/latest/en/user/styling/sld/reference/rastersymbolizer.html#channelselection [2]: http://docs.geoserver.org/latest/en/user/data/raster/coverageview.html [3]: http://docs.geoserver.org/latest/en/user/styling/sld/reference/rastersymbolizer.html#contrastenhancement On Thu, Feb 23, 2017 at 3:03 AM, Samuel Damesin < samuel.dame...@scionresearch.com> wrote: > Hi Daniele, > > > > Sorry for the reminder but do you think you could help me with this? I am > still confused and don’t know where to look or how to handle this. My goal > is to publish 4 (or more in the future) bands tiffs via the WMS > functionality of Geoserver. > > > > Many thanks, > > Sam > > > > > > *From:* Samuel Damesin > *Sent:* Thursday, 2 February 2017 10:35 a.m. > *To:* 'Daniele Romagnoli' < daniele.romagn...@geo-solutions.it > > *Subject:* RE: [Geoserver-users] Serving 4 bands GeoTiff with GeoServer > WMS > > > > Hi Daniele, > > > > Thank you for your reply and help. > > > >- Are you sure that QGIS is really rendering all 4 bands? As far as I >remember from some tests I did in the past, it has Red,Green,Band band >selection in the Properties->Style section of the layer where it is usually >assigning Band1, Band2 and Band3 respectively. Moreover it was using the >NIR as Alpha band in the Transparency Section. Can you double check that? > > > > Well, what I meant is that I can see in the layer’s properties that it has > 4 bands and display them as I like (with the tiff loaded from a local > file). See attachments, the ones called “local file” are with the file > loaded locally, the one called “wms” are the one when publishing with WMS. > You can see that I don’t have the same “properties” and no access to the > “multiband color” option. > > It does seem that by default it is using the 4th band as an alpha layer, > because using the default “raster” style it shows a kind of transparent > image. > > > >- Do you a gdalinfo output of one of these datasets? > > > > Yes, see attachment. > > > >- Which GeoServer version are you using? > > · Version I am using: GeoServer Version2.10.0 > > · Git Revision94615dac4a2056ed47e2e67fa823ea63325058cf > > · Build Date28-Oct-2016 09:41 > > · GeoTools Version16.0 (rev ae16e116c58d9f4bc3fcec2566fca3 > dd8dd92120) > > · GeoWebCache Version1.10.0 (rev 1.10.x/ > 8908bc23e322f84849517758e5134167e4feb73d) > > > >- I'm wondering if it is related to QGIS rendering of an external WMS >layer. > > What happens if you open the OpenLayers preview in GeoServer and what > about a getFeatureInfo request? > > That’s also strange, the openlayers preview work nicely (I can see a RGB > color). > > > >- I think that the histogram and pyramids have been internally >computed by QGIS on the local GeoTIFF. > > There is no relation with the WMS layer. > > What I meant is that it seems that QGIS (and ArcGIS) understand or read > both layers differently. See attachments, for some reasons the properties > are not the same and I don’t have access to the same options. > > > > Hope this make sense, please let me know if you have additional questions. > > > > Thanks, > > sam > > > > *From:* dany.geoto...@gmail.com [mailto:dany.geoto...@gmail.com > ] *On Behalf Of *Daniele Romagnoli > *Sent:* Thursday, 2 February 2017 12:17 a.m. > *To:* Samuel Damesin > *Cc:* geoserver-users@lists.sourceforge.net > *Subject:* Re: [Geoserver-users] Serving 4 bands GeoTiff with GeoServer > WMS > > > > Hi Sam, > > > > > > On Wed, Feb 1, 2017 at 2:46 AM, sdamescion com> wrote: > > Hi there, > > I have a couple of 4 bands (R, G, B, NIR) geotifs that I would like to > serve > as a WMS service with GeoServer. When loading the tifs localy in QGIS they > are nicely displayed as 4 bands, > > > > Are you sure that QGIS is really rendering all 4 bands? > > As far as I remember from some tests I did in the past, it has > Red,Green,Band band selection in the Propert
[Geoserver-users] Error Monitor Extension
Hi list, I'm trying to get the monitor extension work but I'm getting this errors while GeoServer startup. After them it doesn't work anything. My idea is to store all the monitored information into a PostgreSQL DB so I've downloaded both "monitor" and "monitor-hibernate" extensions. Here is my configuration files info: Hibernate.properties #Wed Dec 09 14:18:34 CET 2015 hibernate.use_sql_comments=true databasePlatform=org.hibernate.dialect.PostgreSQLDialect generateDdl=true hibernate.format_sql=true showSql=false hibernate.generate_statistics=true hibernate.session_factory_name=SessionFactory hibernate.hbm2ddl.auto=update hibernate.bytecode.use_reflection_optimizer=true database=GeoServer_MONITOR hibernate.show_sql=false DB.properties driver=org.postgresql.Driver url=jdbc:postgresql://192.168.1.153:5432/GeoServer_MONITOR username=postgres password= defaultAutoCommit=false Monitor.properties # the storage mode, one of: memory, hibernate # Note: hibernate mode requires the hibernate extension storage=hibernate # the monitor mode, one of: live, history mode=history # synchronization mode, one of: sync, async, async_update # # WARNING: this is an advanced configuration option. You probably do not want # to change this unless instructed to by a developer sync=async # The maximum allowable length for a request body (in bytes). Longer bodies will be trimmed to # this length. maxBodySize=1024 # Disable logging of bodies entirely # maxBodySize=0 # Allow unlimited body lengths. This could take up a lot of space quite rapidly. # maxBodySize=-1 # If you increase or unbound the maximum body length, you must also change the hibernate mappings # file. # The CRS to log bounding boxes in bboxLogCrs=EPSG:4326 # Bounding Box Log Level: controls when to record bounding boxes. # 'none': Don't record bounding boxes # 'no_wfs': Record bounding boxes for WMS and WCS requests, but not WFS. This is the default # 'full': Record a bounding box for all requests for which one can be produced. WFS is not amenable # to being logged this way so the boxes produced will be approximate at best. bboxLogLevel=no_wfs Errors while startup: 2017-02-23 09:14:28,577 INFO [org.geoserver.monitor] - Configuring monitoring database from: C:\datos\geoserver_data_directory\data_dir\monitoring\db.properties 2017-02-23 09:14:29,014 WARN [org.springframework.beans.factory.support.DisposableBeanAdapter] - Invocation of destroy method failed on bean with name 'geoServerLoader': java.lang.NullPointerException 2017-02-23 09:14:29,014 ERROR [org.springframework.web.context.ContextLoader] - Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'controlFlowCallbackProxy' defined in URL [jar:file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7_64/webapps/ROOT/WEB-INF/lib/gs-monitor-core-2.8.0.jar!/applicationContext.xml]: Cannot resolve reference to bean 'monitor' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'monitor' defined in URL [jar:file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7_64/webapps/ROOT/WEB-INF/lib/gs-monitor-core-2.8.0.jar!/applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.geoserver.monitor.Monitor]: Constructor threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibMonitorDAO' defined in URL [jar:file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7_64/webapps/ROOT/WEB-INF/lib/gs-monitor-hibernate-2.8.0.jar!/applicationContext-hib2.xml]: Cannot resolve reference to bean 'hibSessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibSessionFactory' defined in URL [jar:file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7_64/webapps/ROOT/WEB-INF/lib/gs-monitor-hibernate-2.8.0.jar!/applicationContext-hib2.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: javassist/util/proxy/MethodFilter at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:329) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:107) at org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:630) at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:148) at org.springframework.beans.factory.support.AbstractAutowireCapab
