Re: [Geoserver-users] Layer very slow to display

[Edward Mac Gillavry]

Georges,

>From the link you sent along, the map scale appears to be 1:9M. Spatial 
>indexes have their benefits when zoomed in to do a quick 
bounding-box comparison if I understand Geoserver workings correctly. 
When you are zoomed out to 1:9M, it will simply retrieve all features.

Maybe, you can add scale-dependent rules in the SLD: i.e. don't show all 
features on all zoom levels. This particularly is for the ZNIEFF regions! 
Opening your WMS in QGIS, I zoomed in to 1:300.000 and added the ZNIEFF layer. 
Then, I was able to view them :-)

It's not a matter of the number of ZNIEFF features, but the level of detail in 
their outlines. These outlines follow river beds and mountain valleys it seems. 
Maybe use generalised versions of these features to display these areas at 
smaller scales.

You can simply add new layers that have the generalised outlines in a 
Layergroup for ZNIEFF, or more advanced, use the GeoServer extension 
"Pregeneralized Features":

http://docs.geoserver.org/latest/en/user/data/vector/featurepregen.html

Best of luck,

Edward


> From: r...@russ-hore.co.uk
> To: georges.hi...@gmail.com; geoserver-users@lists.sourceforge.net
> Date: Fri, 23 Oct 2015 11:37:54 +
> Subject: Re: [Geoserver-users] Layer very slow to display
> 
> Is it a lack of an index on the table?
> 
> Russ
> 
> >  ---Original Message---
> >  From: Georges H 
> >  To: geoserver-users 
> >  Subject: [Geoserver-users] Layer very slow to display
> >  Sent: 23 Oct '15 11:28
> >  
> >  Hi
> >  
> >  I have a layer very slow to display (from a Postgres DB), I do not
> >  understand why, beacause I have other layers which I think to be more
> >  bigger, without problem, and also from Postgres DB.
> >  
> >  Here for example:
> >  http://cartoperso.com/gs271/DRIIHM/wms?
> service=WMS=1.1.0=GetMap=DRIIHM:znieffs==-5.14112752212846,41.329845
> 4351757,9.55966584021411,51.090843415036=768=509=EPSG:4326=application/open
> layers
> >  
> >  What do you think about ? Are there ways to improve the display speed
> >  on Geoserver,
> >  
> >  Thank you !
> >  
> >  GEORGES HINOT
> >  CNRS - DRIIHM - UMS BBEES (3468)
> >  
> >  Musée d'Histoire Naturelle de Paris, Maison Buffon
> >  
> >  Géomaticien - Administrateur BDD - Intégrateur
> >  georges.hi...@gmail.com
> >  georges.hi...@mnhn.fr
> >  _Tél : 01 40 79 80 44_
> >  _Tél : 06 47 61 84 92_
> >  Le site du LabEx DRIIHM
> >  
> >  Le métacalogue du LabEx DRIIHM
> >  
> >  -
> >  
> > --
> >  
> >  -
> >  ___
> >  Geoserver-users mailing list
> >  Geoserver-users@lists.sourceforge.net
> >  https://lists.sourceforge.net/lists/listinfo/geoserver-users
> >  
> 
> --
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
  --
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Layer very slow to display

[russ]

Is it a lack of an index on the table?

Russ

>  ---Original Message---
>  From: Georges H 
>  To: geoserver-users 
>  Subject: [Geoserver-users] Layer very slow to display
>  Sent: 23 Oct '15 11:28
>  
>  Hi
>  
>  I have a layer very slow to display (from a Postgres DB), I do not
>  understand why, beacause I have other layers which I think to be more
>  bigger, without problem, and also from Postgres DB.
>  
>  Here for example:
>  http://cartoperso.com/gs271/DRIIHM/wms?
service=WMS=1.1.0=GetMap=DRIIHM:znieffs==-5.14112752212846,41.329845
4351757,9.55966584021411,51.090843415036=768=509=EPSG:4326=application/open
layers
>  
>  What do you think about ? Are there ways to improve the display speed
>  on Geoserver,
>  
>  Thank you !
>  
>  GEORGES HINOT
>  CNRS - DRIIHM - UMS BBEES (3468)
>  
>  Musée d'Histoire Naturelle de Paris, Maison Buffon
>  
>  Géomaticien - Administrateur BDD - Intégrateur
>  georges.hi...@gmail.com
>  georges.hi...@mnhn.fr
>  _Tél : 01 40 79 80 44_
>  _Tél : 06 47 61 84 92_
>  Le site du LabEx DRIIHM
>  
>  Le métacalogue du LabEx DRIIHM
>  
>  -
>  
> --
>  
>  -
>  ___
>  Geoserver-users mailing list
>  Geoserver-users@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/geoserver-users
>  

--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Layer very slow to display

[Georges H]

Hi

I have a layer very slow to display (from a Postgres DB), I do not
understand why, beacause I have other layers which I think to be more
bigger, without problem, and also from Postgres DB.

Here for example:
http://cartoperso.com/gs271/DRIIHM/wms?service=WMS=1.1.0=GetMap=DRIIHM:znieffs==-5.14112752212846,41.3298454351757,9.55966584021411,51.090843415036=768=509=EPSG:4326=application/openlayers

What do you think about ? Are there ways to improve the display speed on
Geoserver,

Thank you !

*Georges Hinot*
*CNRS - DRIIHM - UMS BBEES (3468)*
Musée d'Histoire Naturelle de Paris, Maison Buffon
Géomaticien - Administrateur BDD - Intégrateur
georges.hi...@gmail.com
georges.hi...@mnhn.fr
*Tél : 01 40 79 80 44*
*Tél : 06 47 61 84 92*
Le site du LabEx DRIIHM 

Le métacalogue du LabEx DRIIHM

--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Layer very slow to display

[Georges H]

Hi, thanks for advices !

I had already a spatial index.

Then, after yours advices, I have added another index on the gid field,
without changes.

Then , always thanks to yours advices, I have added an
"100" in my SLD. And indeed,
after this, just 3 or 4 seconds are necessary to load the layer. It is
better !

Then, I have added a "Header HTTP cache". And when the layer has already
been display, it display immediately ! Cool !

But do you really think that with "Pregeneralized Features" I will can
improve the display speed of this layer ?

Can I just improve changing my "MaxScaleDenominator" ?

Thanks

2015-10-23 16:25 GMT+02:00 Edward Mac Gillavry :

> Georges,
>
> From the link you sent along, the map scale appears to be 1:9M. Spatial
> indexes have their benefits when zoomed in to do a quick bounding-box
> comparison if I understand Geoserver workings correctly. When you are
> zoomed out to 1:9M, it will simply retrieve all features.
>
> Maybe, you can add scale-dependent rules in the SLD: i.e. don't show all
> features on all zoom levels. This particularly is for the ZNIEFF regions!
> Opening your WMS in QGIS, I zoomed in to 1:300.000 and added the ZNIEFF
> layer. Then, I was able to view them :-)
>
> It's not a matter of the number of ZNIEFF features, but the level of
> detail in their outlines. These outlines follow river beds and mountain
> valleys it seems. Maybe use generalised versions of these features to
> display these areas at smaller scales.
>
> You can simply add new layers that have the generalised outlines in a
> Layergroup for ZNIEFF, or more advanced, use the GeoServer extension
> "Pregeneralized Features":
>
> http://docs.geoserver.org/latest/en/user/data/vector/featurepregen.html
>
> Best of luck,
>
> Edward
>
>
> > From: r...@russ-hore.co.uk
> > To: georges.hi...@gmail.com; geoserver-users@lists.sourceforge.net
> > Date: Fri, 23 Oct 2015 11:37:54 +
> > Subject: Re: [Geoserver-users] Layer very slow to display
>
> >
> > Is it a lack of an index on the table?
> >
> > Russ
> >
> > > ---Original Message---
> > > From: Georges H 
> > > To: geoserver-users 
> > > Subject: [Geoserver-users] Layer very slow to display
> > > Sent: 23 Oct '15 11:28
> > >
> > > Hi
> > >
> > > I have a layer very slow to display (from a Postgres DB), I do not
> > > understand why, beacause I have other layers which I think to be more
> > > bigger, without problem, and also from Postgres DB.
> > >
> > > Here for example:
> > > http://cartoperso.com/gs271/DRIIHM/wms?
> >
> service=WMS=1.1.0=GetMap=DRIIHM:znieffs==-5.14112752212846,41.329845
> >
> 4351757,9.55966584021411,51.090843415036=768=509=EPSG:4326=application/open
> > layers
> > >
> > > What do you think about ? Are there ways to improve the display speed
> > > on Geoserver,
> > >
> > > Thank you !
> > >
> > > GEORGES HINOT
> > > CNRS - DRIIHM - UMS BBEES (3468)
> > >
> > > Musée d'Histoire Naturelle de Paris, Maison Buffon
> > >
> > > Géomaticien - Administrateur BDD - Intégrateur
> > > georges.hi...@gmail.com
> > > georges.hi...@mnhn.fr
> > > _Tél : 01 40 79 80 44_
> > > _Tél : 06 47 61 84 92_
> > > Le site du LabEx DRIIHM
> > >
> > > Le métacalogue du LabEx DRIIHM
> > >
> > > -
> > >
> --
> > >
> > > -
> > > ___
> > > Geoserver-users mailing list
> > > Geoserver-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-users
> > >
> >
> >
> --
> > ___
> > Geoserver-users mailing list
> > Geoserver-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>



-- 
*Georges Hinot*
*CNRS - DRIIHM - UMS BBEES (3468)*
Musée d'Histoire Naturelle de Paris, Maison Buffon
Géomaticien - Administrateur BDD - Intégrateur
georges.hi...@gmail.com
georges.hi...@mnhn.fr
*Tél : 01 40 79 80 44*
*Tél : 06 47 61 84 92*
Le site du LabEx DRIIHM 

Le métacalogue du LabEx DRIIHM

--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GeoServer w/ CAS Performance

[Danny Cheng]

Hi Christian:

Yes, my configuration without CAS meant no security at all. I would think basic 
authentication would be faster? Also, I guess it’s worth mentioning that our 
CAS server is on a separate machine apart from where we have GeoServer 
installed. Of course, I haven’t actually done the test to verify this, but 
that’s my assumption.

Thanks,
Danny

From: Christian Mueller [mailto:christian.muel...@os-solutions.at]
Sent: Tuesday, October 20, 2015 2:07 AM
To: Danny Cheng
Cc: Andrea Aime; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] GeoServer w/ CAS Performance

Hi Danny

Is your configuration without CAS  a public configuration meaning no security 
at all. ?
Does it make a difference if you use basic auth instead of CAS ?

Normally, the initial request should last longer.

Cheers
Christian


On Mon, Oct 19, 2015 at 8:15 PM, Danny Cheng 
> wrote:
Hi Christian,

I checked the log and have confirmed that only the initial GeoServer request is 
hitting CAS – which is good. Maybe the 100ms difference with CAS on/off is just 
an one-off result.

Thanks,
Danny


From: Christian Mueller 
[mailto:christian.muel...@os-solutions.at]
Sent: Monday, October 19, 2015 7:43 AM
To: Andrea Aime
Cc: Danny Cheng; 
geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] GeoServer w/ CAS Performance

Hi Andrea

For stateless authentication we have a cache to avoid the overhead for each 
request.

Additionally, you can allow session creation for each filter chain individually 
(in this case the cache is not used).

I am waiting for the reply of Danny, maybe there is a bug.

Cheers
Christian


On Mon, Oct 19, 2015 at 9:54 AM, Andrea Aime 
> wrote:
Christian,
thinking out loud here, we normally setup OGC services so that they don't 
create a session
because of the many clients hitting the server and the cost of keeping sessions.

However, for stuff like CAS where an authentication can make us do a network 
call, would it be better
to advise allowing session creation instead? Or do we have other caching 
strategies?

This is more of a general question, it may or not related to  Danny's problem

Cheers
Andrea


On Sun, Oct 18, 2015 at 3:18 PM, Christian Mueller 
> 
wrote:
Hy Danny

Please check the log file of the CAS Server. There you can see the incoming 
requests and check if each GeoServer request triggers a CAS request.

Cheers
Christian



On Sun, Oct 18, 2015 at 4:34 AM, Danny Cheng 
> wrote:
Hi,

I currently have a system with CAS single sign on integrated. I noticed that 
with CAS enabled my OGC requests are taking ~100ms longer to get a response. Is 
this expected? I would expect that only the initial request would get a hit, 
but for me all my requests are taking the hit.

Thanks,
Danny

--

___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users



--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH


--

___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users



--
==
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 Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
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 

Re: [Geoserver-users] Geoserver-users Digest, Vol 113, Issue 90

[Florian Hoedt]

Hi Andrea,
I can not update my GeoServer currently therefore the implementation you
have mentioned is not possible for me.
There should be some way to define by SLD and layer config that one value
should be transparent. Actually I had a setup which done exactly that, but
I have no copy of the sld and layer config anymore.

On Thu, Oct 22, 2015 at 10:01 AM, Andrea Aime 
wrote:

> Hi Floarian,
> GeoServer historically has had no support for "nodata" pixels.
> In version 2.8.0 we have a first implementation of nodata support, but
> it's not enabled by default
> as we have seen some misbehaviors in it.
>
> If you want to try it out, get GeoServer 2.8.0 and add the following
> system variable declarations to the "java"
> call running the web container for GeoServer (e.g., Tomcat, Jetty):
>
> -Dorg.geotools.coverage.jaiext.enabled=true
>
> Cheers
> Andrea
>
>
> On Wed, Oct 21, 2015 at 4:59 PM, Florian Hoedt 
> wrote:
>
>> Hello List
>> I have trouble to display overlaying rasters which contain topografic
>> informations. The rasters are the german topografic map (DGK) which is
>> represented by two layers: The base layer shows all roads and cities as
>> value 0 rastercells, the relief layers shows all topolines as value 0
>> rastercells. The other cells have 1 as value. I translated them with
>> gdal_translate to geotiff an set 1 as no_data value - which should get rid
>> of those "no info cells". In QGIS they show up properly and I can see both
>> layers (1 value cells are transparent/ non existing). If used in GeoServer
>> I am unable to see both layers, since the 1 value cells are rendered as
>> white pixels. Something is wrong on the GeoServer side. Here are my
>> settings:
>>
>> *Rasterdaten Parameter*
>> Accurate resolution computation
>> AllowMultithreading
>> BackgroundValues
>> Filter
>> FootprintBehavior
>> InputTransparentColor
>>
>> MaxAllowedTiles
>> MergeBehavior
>> OutputTransparentColor
>>
>> SORTING
>> SUGGESTED_TILE_SIZE
>> USE_JAI_IMAGEREAD
>>
>>
>>
>> Bänderdetails zu Raster
>>
>>- Bänder
>>Datentyp
>>Null-Werte
>>minRange
>>maxRange
>>Einheit
>>Unsigned 8 bits
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *SLD:> xmlns="http://www.opengis.net/sld "
>> xmlns:sld="http://www.opengis.net/sld "
>> xmlns:ogc="http://www.opengis.net/ogc "
>> xmlns:gml="http://www.opengis.net/gml "
>> version="1.0.0">  
>> c411930gs_ProjectRaster
>> c411930gs_ProjectRaster
>> 
>> 
>> grid
>>   > color="#00" opacity="1.0" quantity="0.0"/>
>> > quantity="1.0"/>
>>   
>>   *
>>
>>
>> *gdalinfo for one of the rasters:*
>> Driver: GTiff/GeoTIFF
>> Files:
>> N:/temp/Geonode/DataToImport/Hx/DGK_5/trans/c411930hf_ProjectRaster.tif
>> Size is 6299, 6299
>> Coordinate System is:
>> PROJCS["ETRS_1989_UTM_Zone_N32",
>> GEOGCS["GCS_ETRS_1989",
>> DATUM["European_Terrestrial_Reference_System_1989",
>> SPHEROID["GRS 1980",6378137,298.2572221010002,
>> AUTHORITY["EPSG","7019"]],
>> AUTHORITY["EPSG","6258"]],
>> PRIMEM["Greenwich",0],
>> UNIT["degree",0.0174532925199433]],
>> PROJECTION["Transverse_Mercator"],
>> PARAMETER["latitude_of_origin",0],
>> PARAMETER["central_meridian",9],
>> PARAMETER["scale_factor",0.9996],
>> PARAMETER["false_easting",3250],
>> PARAMETER["false_northing",0],
>> UNIT["metre",1,
>> AUTHORITY["EPSG","9001"]]]
>> Origin = (32497927.42072654900,5742142.37387320120)
>> Pixel Size = (0.31737939837,-0.31737939984)
>> Metadata:
>>   AREA_OR_POINT=Area
>>   DataType=Thematic
>> Image Structure Metadata:
>>   INTERLEAVE=BAND
>> Corner Coordinates:
>> Upper Left  (32497927.421, 5742142.374) (  8d58'11.72"E, 51d49'48.37"N)
>> Lower Left  (32497927.421, 5740143.201) (  8d58'11.77"E, 51d48'43.66"N)
>> Upper Right (32499926.594, 5742142.374) (  8d59'56.17"E, 51d49'48.38"N)
>> Lower Right (32499926.594, 5740143.201) (  8d59'56.17"E, 51d48'43.67"N)
>> Center  (32498927.007, 5741142.787) (  8d59' 3.96"E, 51d49'16.02"N)
>> Band 1 Block=6299x1 Type=Byte, ColorInterp=Palette
>>   Min=0.000 Max=1.000
>>   Minimum=0.000, Maximum=1.000, Mean=0.972, StdDev=0.164
>>   NoData Value=1
>>   Overviews: 3150x3150, 1575x1575, 788x788, 394x394, 197x197, 99x99
>>   Metadata:
>> RepresentationType=THEMATIC
>> STATISTICS_COVARIANCES=2,68819748864689E-02
>> STATISTICS_MAXIMUM=1
>> STATISTICS_MEAN=0,97235370834899
>> STATISTICS_MINIMUM=0
>> STATISTICS_STDDEV=0,16395723493176
>>   Color Table (RGB with 256 entries)
>> 0: 0,0,0,255
>> 1: 255,255,255,255
>>
>>
>>
>>>
>>
>>
>> --
>>
>>