Re: [Geoserver-users] Null namespace in WFS response for layer based on disabled PostGIS store [SEC=UNCLASSIFIED]

2016-10-12 Thread Johnson, Steven (Contractor)
UNCLASSIFIED
Thanks for your help Ben and Andrea.

I guess the null namespace issue is a bit of a moot point anyway given that the 
WFS should not be serving features when the store is disabled.

We'll take your advice Ben about monitoring and re-enable the datastore via the 
REST API if indeed the store is available but disabled in GeoServer.

From: Andrea Aime [mailto:andrea.a...@geo-solutions.it]
Sent: Wednesday, 12 October, 2016 5:13 a.m.
To: Ben Caradoc-Davies
Cc: Johnson, Steven (Contractor); geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Null namespace in WFS response for layer based 
on disabled PostGIS store [SEC=UNCLASSIFIED]

On Tue, Oct 11, 2016 at 8:19 PM, Ben Caradoc-Davies 
> wrote:
Andrea, I am sure you are right. I have closed this one as duplicated by 
GEOS-7792 (which links to this thread and the fixes for disabled layers). I 
note that I did not see the null behaviour in my tests with WFS 2.0 / GML 3.2.

Interesting, I've tried a similar path to the one that triggers the wfs 1.1 
null prefixes, but using the wfs 2.0 protocol, and I indeed could not reproduce 
either... not sure why?
This is what I've tried, on a freshly start up GeoServer:
http://localhost:8080/geoserver/topp/ows?service=WFS=2.0.0=GetFeature=topp:tasmania_cities=1
http://localhost:8080/geoserver/sf/ows?service=WFS=2.0.0=GetFeature=sf:roads=1

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.

---

IMPORTANT: This email remains the property of the Department of Defence and is 
subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have 
received this email in error, you are requested to contact the sender and 
delete the email.
--
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] Reprojection is not working in Image Mosaic

2016-10-12 Thread Jin Ho Jo
Hi,

I am newly set up Image Mosaic Store/Layer on Geoserver and trying to make it 
work.
And I can get images from Image Mosaic, but have an issue which is image 
reprojection is not working.
Image appears in designated location on the map correctly, but it is just flat 
image, not reprojected.
It is correctly reprojected in regular browse image layers.

I am working on Image Mosaic Layer on Geoserver 2.9.0 and Openlayers2, Java 1.8 
on Windows 7.
And using EPSG:4326, and set USE_JAI_IMAGEREAD as 'false'.

Sample image not projected is attached.

Can you please check this and what is needed to make it reprojected?

Thanks
Jin
--
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] Hexagon Binning

2016-10-12 Thread Martin Davis
You might be able to use Rendering Transformations to do this:

http://docs.geoserver.org/latest/en/user/styling/sld/extensions/rendering-transform.html

But it will take a bit of code...

On Wed, Oct 12, 2016 at 6:07 AM, Volkan Gümüs  wrote:

> Hello everybody!
>
> I'm looking for a way to overlay my WMS layer with a layer that is
> binned through hexagons. I'd like to set an edge length (let's say
> 300meters) and receive hexagons for the whole map.
>
> Is there a way to get this kind of hexagon layer without the need to
> create previously all hexagons as postgis objects?
>
> I'd like to achieve this without geometry creation or at least only
> using lazy geometry creation (on demand).
>
> Thank you!
>
> Volkan Gümüs
>
> 
> --
> 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
>
--
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] Native JAI

2016-10-12 Thread Rini.Angreani
Hi Andrea,


Thanks for your help. I also found the log in GeoWebCache and did a comparison 
with non populated tile cache :-).

I thought I would double check by asking the list to cover all the bases - in 
case it's used elsewhere.

Thanks again.


Cheers

Rini


From: andrea.a...@gmail.com  on behalf of Andrea Aime 

Sent: Wednesday, 12 October 2016 3:44 PM
To: Angreani, Rini (Mineral Resources, Kensington WA); Simone Giannecchini; 
Kevin Smith
Cc: GeoServer Mailing List List; Warren, Peter (Mineral Resources, North Ryde)
Subject: Re: [Geoserver-users] Native JAI

Hi Rini,
that log is actually from GeoWebCache, so a proper performance comparison 
should be done
by hitting a non yet populated tile cache and force GWC to popupate it... like 
a seeding operation
for example.

That said, the JAI "crop" operation is actually doing nothing, it's just making 
the image look smaller
to the callers by changing its origin, width and height (thus metadata),
so I don't see how a native extension can make any difference. From the javadoc 
of CropOpImage:

 *  Tiles that are completely inside or intersect the cropped region
 * (this image's bounds) are simply forwarded from the source.  Do NOT
 * create a child raster even if a tile is not contained in this image's
 * bounds.  Tiles that are outside the croppped region result in a
 * null return.

My guess is that the comment actually relates to an issue in the Java JPEG 
encoder that fails
to encode properly shifted images (ones with origin not 0,0). However this 
should have been
fixed in the meantime.
Simone, do you remember any better?

To see if the code still has any merit, one should try to remove the 
BufferedImage extraction code here
and see if that actually makes any difference:
https://github.com/GeoWebCache/geowebcache/blob/master/geowebcache/core/src/main/java/org/geowebcache/layer/MetaTile.java#L319

It is also to be noted that GeoServer is using its own metatile subclass, with 
entirely different code, it would be nice to just push back
the override, but I'm not 100% sure it's possible (due to dependencies that 
might be available in GeoServer, but not in GeoWebCache):
https://github.com/geoserver/geoserver/blob/master/src/gwc/src/main/java/org/geoserver/gwc/layer/GeoServerMetaTile.java#L162

But yeah, in the context of GeoServer that warning is just noise, since the 
code depending on that variable is not even executed.

Cheers
Andrea


On Wed, Oct 12, 2016 at 8:07 AM, 
> wrote:
Hi list,

We notice a warning about Native JAI not being installed in the log files. I 
did a simple WMS GetMap performance comparison with and without native JAI, and 
they seem to be pretty much the same. Does anyone know if/how native JAI affect 
performance?

WARN [layer.MetaTile] - * Native JAI is not installed, meta tile 
cropping may be slow 

Thanks
Rini

--
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 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 

[Geoserver-users] Hexagon Binning

2016-10-12 Thread Volkan Gümüs
Hello everybody!

I'm looking for a way to overlay my WMS layer with a layer that is 
binned through hexagons. I'd like to set an edge length (let's say 
300meters) and receive hexagons for the whole map.

Is there a way to get this kind of hexagon layer without the need to 
create previously all hexagons as postgis objects?

I'd like to achieve this without geometry creation or at least only 
using lazy geometry creation (on demand).

Thank you!

Volkan Gümüs

--
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] EPSG:4326 vs CRS:84

2016-10-12 Thread Bart Verbeeck
Thinks, but this was only a small typo, it doesn't make a difference, the shift 
is larger.

-Original Message-
From: Brad Hards [mailto:br...@frogmouth.net]
Sent: woensdag 12 oktober 2016 12:40
To: Bart Verbeeck ; geoserver-users@lists.sourceforge.net
Subject: RE: [Geoserver-users] EPSG:4326 vs CRS:84

Perhaps because the BBOX is not the same.
In the first:  50.94258788037
In the second: 50.942587880378

Brad






Informatie Vlaanderen e-mail disclaimer: 
http://www.vlaanderen.be/informatievlaanderen

--
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] EPSG:4326 vs CRS:84

2016-10-12 Thread Brad Hards
Perhaps because the BBOX is not the same.
In the first: 50.94258788037
In the second: 50.942587880378

Brad




--
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] EPSG:4326 vs CRS:84

2016-10-12 Thread Bart Verbeeck
Dear list

Why is there a small shift in the produced images?
1. EPSG:4326
2. CRS:84

BBOX is the same (but X/Y reversed of course)

http://geoservices.beta.informatievlaanderen.be/raadpleegdiensten/GRB/wms?LAYERS=GRB_BSK=XML=image%2Fpng=TRUE=1.3.0=WMS=GetMap==EPSG%3A4326=50.930396718688,4.0970421803527,50.94258788037,4.1092333420348=512=512

http://geoservices.beta.informatievlaanderen.be/raadpleegdiensten/GRB/wms?LAYERS=GRB_BSK=XML=image%2Fpng=TRUE=1.3.0=WMS=GetMap==CRS:84=4.0970421803527,50.930396718688,4.109233342034,50.942587880378=512=512

Thanks for your help

Bart



Informatie Vlaanderen e-mail disclaimer: 
http://www.vlaanderen.be/informatievlaanderen

--
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] Geoserver-users] EPSG:4326 vs CRS:84

2016-10-12 Thread Bart Verbeeck


Dear list

Why is there a small shift in the produced images?
1. EPSG:4326
2. CRS:84

BBOX is the same (but X/Y reversed of course)

http://geoservices.beta.informatievlaanderen.be/raadpleegdiensten/GRB/wms?LAYERS=GRB_BSK=XML=image%2Fpng=TRUE=1.3.0=WMS=GetMap==EPSG%3A4326=50.930396718688,4.0970421803527,50.94258788037,4.1092333420348=512=512

http://geoservices.beta.informatievlaanderen.be/raadpleegdiensten/GRB/wms?LAYERS=GRB_BSK=XML=image%2Fpng=TRUE=1.3.0=WMS=GetMap==CRS:84=4.0970421803527,50.930396718688,4.109233342034,50.942587880378=512=512

Thanks for your help

Bart



Informatie Vlaanderen e-mail disclaimer: 
http://www.vlaanderen.be/informatievlaanderen

--
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] EPSG:4326 vs CRS:84

2016-10-12 Thread Bart Verbeeck

Sorry for eventual double posting

Dear list

Why is there a small shift in the produced images?
1. EPSG:4326
2. CRS:84

BBOX is the same (but X/Y reversed of course)

http://geoservices.beta.informatievlaanderen.be/raadpleegdiensten/GRB/wms?LAYERS=GRB_BSK=XML=image%2Fpng=TRUE=1.3.0=WMS=GetMap==EPSG%3A4326=50.930396718688,4.0970421803527,50.94258788037,4.1092333420348=512=512

http://geoservices.beta.informatievlaanderen.be/raadpleegdiensten/GRB/wms?LAYERS=GRB_BSK=XML=image%2Fpng=TRUE=1.3.0=WMS=GetMap==CRS:84=4.0970421803527,50.930396718688,4.109233342034,50.942587880378=512=512

Thanks for your help

Bart



Informatie Vlaanderen e-mail disclaimer: 
http://www.vlaanderen.be/informatievlaanderen

--
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] ImageMosaic with predefined projection

2016-10-12 Thread Arnaud L.
Hi all,

I'm migrating a bunch of our services and data to GeoServer (2.8.4, 
Windows).
We have a quite large raster store here. It consists of some hundreds of 
thousands of TIFF files with their accompanying TFW worldfile.
They are all in the same projection.

I thought it would be easy to configure an ImageMosaic with this data 
since all the needed information is already stored in a PostGIS 
database, but I have an issue because our TIFFs are not GeoTIFFs, and 
they also don't have a PRJ file.

I could create a PRJ file for every TIFF, but that would mean a lot of 
wasted space (and time). I could also convert all of them to GeoTIFF, 
but that's a hard work. I have yet to find a tool that *modifies* a TIFF 
to make it a GeoTIFF. All the tools I've found make copy of images (i.e. 
  create a new GeoTIFF file instead of converting the TIFF to GeoTIFF).
This does not integrate well in our processes at all.

Is there a way to setup my datastore so that GeoServer doesn't look for 
a PRJ file and just uses a projection that I would hardcode somewhere ?

Thanks a lot for your help !
Arnaud

--
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] Problem changing bounding box of imagemosaic layer

2016-10-12 Thread Sabine Ohlendorf

Hi Jason,

thanks for your hint. Untfortunately it is not the solution of the problem. I checked the indexer.properties file, caching is already set to false.

Sabine

 

Gesendet: Freitag, 30. September 2016 um 14:44 Uhr
Von: "Jason Newmoyer" 
An: "P O'Toole" 
Cc: "Sabine Ohlendorf" , "geoserver-users@lists.sourceforge.net" 
Betreff: Re: [Geoserver-users] Problem changing bounding box of imagemosaic layer


I remember having a similar issue that I worked through. Now I can ingest tiles in real time and see updates immediately to the layer. 
 

I believe it was this setting in the indexer.properties file:

 


# (Optional) A boolean flag to disable/enable caching. When enabled the ImageMosaic will try to pin in memory the entire content of the index to reduce loading/query time. If we have a large granule index and/or we want to ingest in real time new granules (e.g. the index is on a database and we interact directly with it) we need to disable caching, otherwise we can enable it.

Caching=false



 


 
Jason Newmoyer
Newmoyer Geospatial Solutions
843.606.0424
ja...@newmoyergeospatial.com

 



 

On Thu, Sep 29, 2016 at 3:00 PM, P O'Toole  wrote:

Sabine –

Hm. I may be wrong, but this sounds like a bug. You might consider filing a report.

If you update the underlying data frequently in the work that you do and can't wait on a bugfix, I would try to determine what else forces an update, such as clearing Geoserver's cache for the layer, etc ( potentially relevant: http://gis.stackexchange.com/questions/77240/ ) . (Obviously, you've found that deleting/recreating the layer does the trick.) From there, you may just automate this, and arrange to clone/delete/remake/empty the cache for the layer using Geoserver's configuration REST API, and have this happen either periodically or whenever you make edits from your database.

- Patrick


-Original Message-
From: Sabine Ohlendorf [mailto:sabine.ohlend...@gmx.de]
Sent: Thursday, September 29, 2016 2:07 AM
To: P O'Toole 
Cc: geoserver-users@lists.sourceforge.net
Subject: Aw: Re: Problem changing bounding box of imagemosaic layer

Hi Patrick,
I also tried viewing the data via an OpenLayers web application (not only Geoservers prewiew) and the data is still clipped to the old bounding box.
Sabine



>
> Have you tried viewing the data in QGIS or OpenLayers before and after changing the bounding box? Are data being clipped to the old bounding box still or is it simply Geoserver's preview that's going stale when you chance the bbox?
>
> - Patrick O'Toole
>
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users









--
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] Native JAI

2016-10-12 Thread Andrea Aime
Hi Rini,
that log is actually from GeoWebCache, so a proper performance comparison
should be done
by hitting a non yet populated tile cache and force GWC to popupate it...
like a seeding operation
for example.

That said, the JAI "crop" operation is actually doing nothing, it's just
making the image look smaller
to the callers by changing its origin, width and height (thus metadata),
so I don't see how a native extension can make any difference. From the
javadoc of CropOpImage:

 *  Tiles that are completely inside or intersect the cropped region
 * (this image's bounds) are simply forwarded from the source.  Do NOT
 * create a child raster even if a tile is not contained in this image's
 * bounds.  Tiles that are outside the croppped region result in a
 * null return.

My guess is that the comment actually relates to an issue in the Java JPEG
encoder that fails
to encode properly shifted images (ones with origin not 0,0). However this
should have been
fixed in the meantime.
Simone, do you remember any better?

To see if the code still has any merit, one should try to remove the
BufferedImage extraction code here
and see if that actually makes any difference:
https://github.com/GeoWebCache/geowebcache/blob/master/geowebcache/core/src/main/java/org/geowebcache/layer/MetaTile.java#L319

It is also to be noted that GeoServer is using its own metatile subclass,
with entirely different code, it would be nice to just push back
the override, but I'm not 100% sure it's possible (due to dependencies that
might be available in GeoServer, but not in GeoWebCache):
https://github.com/geoserver/geoserver/blob/master/src/gwc/src/main/java/org/geoserver/gwc/layer/GeoServerMetaTile.java#L162

But yeah, in the context of GeoServer that warning is just noise, since the
code depending on that variable is not even executed.

Cheers
Andrea


On Wed, Oct 12, 2016 at 8:07 AM,  wrote:

> Hi list,
>
>
>
> We notice a warning about Native JAI not being installed in the log files.
> I did a simple WMS GetMap performance comparison with and without native
> JAI, and they seem to be pretty much the same. Does anyone know if/how
> native JAI affect performance?
>
>
>
> WARN [layer.MetaTile] - * Native JAI is not installed, meta tile
> cropping may be slow 
>
>
>
> Thanks
>
> Rini
>
> 
> --
> 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 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 

[Geoserver-users] Native JAI

2016-10-12 Thread Rini.Angreani
Hi list,

We notice a warning about Native JAI not being installed in the log files. I 
did a simple WMS GetMap performance comparison with and without native JAI, and 
they seem to be pretty much the same. Does anyone know if/how native JAI affect 
performance?

WARN [layer.MetaTile] - * Native JAI is not installed, meta tile 
cropping may be slow 

Thanks
Rini
--
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