[Geoserver-devel] [GEOS-8042] fix for InsertElementHandler

2017-03-21 Thread Morgan Thompson
Hi,

We've created a pull request #2175 to address GEOS-8042 (incorrect FID
return order). It would be great to get a review, we're hoping to make it
into the release.

Morgan Thompson
Junior Engineer | Boundless
mthomp...@boundlessgeo.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


[Geoserver-devel] [JIRA] (GEOS-8044) Vertically mirrored output when using GeoServer as an image server (EPSG:404000)

2017-03-21 Thread Vasile Craciunescu (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Vasile Craciunescu created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-8044  
 
 
  Vertically mirrored output when using GeoServer as an image server (EPSG:404000)   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 2.9.0, 2.10.0, 2.10.2, 2.11-RC1  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 21/Mar/17 11:51 PM  
 
 
Environment: 
 Ubuntu Server 14.04; Oracle Java 1.8.0_65; Native JAI; Native JAI ImageIO; Tomcat7  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Vasile Craciunescu  
 

  
 
 
 
 

 
 At least starting with version 2.9.0, the layers registered with EPSG:404000 (image server) are rendered mirrored vertically. It was working correctly with previous versions.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 

[Geoserver-devel] Jenkins build is back to normal : GeoTools-Master-OpenJDK8 #418

2017-03-21 Thread jenkins
See 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] WCS 2.0.1 with SCALESIZE [SOLVED]

2017-03-21 Thread Rahkonen Jukka (MML)
All right, the SCALESIZE axis are output grid axes which are named as i and j 
in DescribeCoverage
gml:axisLabels>i jhttp://localhost:8080/geoserver/wcs?service=WCS=2.0.1=GetCoverage=sf__sfdem=E(589980,59)=N(4913700,4923700)=http://www.opengis.net/def/axis/OGC/1/i(200),http://www.opengis.net/def/axis/OGC/1/j(200)

Now I wonder if it is necessary and useful to require that long format for axis 
names. The KVP examples in the Scaling Extension standard are using this short 
and more human-writable syntax:
…& SCALESIZE=i(1000),j(1000),k(10) &…

-Jukka-


Lähettäjä: Rahkonen Jukka (MML)
Lähetetty: 21. maaliskuuta 2017 20:03
Vastaanottaja: 'Geoserver-devel'
Aihe: [Geoserver-devel] WCS 2.0.1 with SCALESIZE

Hi,

Is there something wrong with this GetCoverage?

localhost:8080/geoserver/wcs?service=WCS=2.0.1=GetCoverage=sf__sfdem=E(589980,59)=N(4913700,4923700)=E(200),N(200)

The error from GeoServer 2.11-RC1 is
"ScaleAxisUndefined" locator="E">

-Jukka Rahkonen-
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


[Geoserver-devel] GeoTools / GeoServer Meeting 2017-03-21

2017-03-21 Thread Ben Caradoc-Davies

GeoTools / GeoServer Meeting 2017-03-21


Attending

Ben Caradoc-Davies

Jody Garnett

Kevin Smith

Torben Barsballe

Devon Tucker


Agenda

1.

   Release 2.11 / 17.0 scheduled for 22 March

2.

   FOSS4G Abstracts Reminder

3.

   REST API Sprint Prep

4.

   Bug/Review roundup


Actions

Actions:

 *

   DT: Set up sprint prep review meeting with Justin

 *

   BCD: Reach out to potential mongodb module maintainer

 *

   All: Support release process :)


Previous Meeting actions:

 *

   JG: (done) Release Thursday/Friday

 *

   DB: Look at dependency upgrade for GEOS-7920

 *

   All: (done) Look for code sprint sponsors

 *

   B/JG: Find most complicated REST finder, and sort out an approach as
   part of prep


Release 2.11 / 17.0 scheduled for 22 March

Volunteers: Andrea, Alessandro


We have a couple of fixes short-listed:

 *

   NO: Style Modify Event regression

 *

   JG: Fix windows service memory defaults


About the GeoServer 2.11 Blog Announcement:

 *

   I would like to do better job of thanking companies and customers
   for release functionality
   (sorry for any missed during previous blog posts).

 *

   Especially like to thank volunteers and new developers
   (sorry for any missed during previous blog post).

 *

   Technical blogs to link to really help for the “about geoserver
   2.11” section - updated previous post to link to geosolutions blogs


Windows build server hates us, please coordinate release with Torben and 
Larry (sorry).



   FOSS4G Abstracts Reminder

Deadline is today!

 *

   State of GeoServer submitted - Andrea/Kevin/Jody

 *

   GeoServer Feature Frenzy submitted - Andrea/Kevin/Jody

 *

   GeoTools mbstyle presentation submitted to new tech track - Torben/David


   REST API Sprint Prep

Wiki page is here:

 *

   https://github.com/geoserver/geoserver/wiki/REST-API-Refresh


Goal of prep is to set up the above page with examples to work through:


1.

   Test that fully serializes/deserialize REST response (done)

2.

   Create StyleInfo bindings (xstream xml and json generation)

3.

   StyleController (we have an example, being revised as we learn)

4.

   XMLConverter for StyleInfo (done)

5.

   JSON Converter for StyleInfo (done)

6.

   HTML Converter for StyleInfo (in progress)

7.

   Technical choice between swagger documents vs swagger generation
   (not made)

1.

   Mike/Matt working on this

8.

   REST-API generation maven build (in progress)


This example will get us started, during the sprint we will need to address:

 *

   resourcestore rest api has dynamic path mapping and will be different

 *

   extensions in general (importer, gwc, geogig, backup restore, others…)


Wiki page is falling behind the work/progress.


 *

   Branch not stable yet? Working off of Devon’s private branch for
   now, Torben providing PRs

 o

   Could we stabilize for wednesday meeting with Justin?
   No review first, and then make a branch after feedback

 *

   Discussion:

 o

   Differences with Spring MVC

 o

   Interceptor can get a handle on controller

 o

   Freemarker wrapper and using a converter

 o

   Can use same wrapper for every class with some additional data


Review with Justin scheduled for Wednesday - Devon to schedule meeting time.


   Bug/Review roundup

GEOS-8042 - Series of 
WFS-T bugs just reported by geogig team; will try and get these fixes in.


 *

   GEOT-5685 

 *

   GEOT-5684 

 *

   GEOT-5683 


GEOS-8040 - Style 
Publisher was recently updated to support workspaces, and KML output is 
breaking styles in subfolders, this is a hard break - ideas:


 *

   styles/folder#foo.png (treat a folder as a bulk icon factory -
   similar to a zip of icons?)

 *

   styles/folder-foo.png - handle via naming convention

 *

   styles/foo.png - flatten out the subfolders when searching for icon

 *

   styles/conflict/foo.png - allow the conflict and just search both?

 *

   styles/workspace/foo.png (work around is make a workspace with the
   expected “sub folder name”)


GEOS-8030 WIndows 
server installer memory defaults



GEOS-8041 GWC Security 
Vulnerability - waiting for details (thanks for following our security 
procedures)



GEOS-8034 YSLD color 
map invalid



Unsupported modules are racking up bug reports and patches:

 *

   Series of MongoDB patches and errors GEOT-5672
   ,GEOT-5671
   ,GEOT-5670
   

 *

   With pull 

Re: [Geoserver-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on Tuesday

2017-03-21 Thread Ben Caradoc-Davies
login.live.com is having intermittent problems.

On 22/03/17 08:40, Jody Garnett wrote:
> skype is down in our region, will try once more and then switch to hangout

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on Tuesday

2017-03-21 Thread Jody Garnett
skype is down in our region, will try once more and then switch to hangout

--
Jody Garnett

On 20 March 2017 at 12:15, Ben Caradoc-Davies  wrote:

> GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday:
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=
> GeoTools+%2F+GeoServer+Meeting=2017=3=
> 21=19=30=0=1
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] Regression Accessing Styles Directory

2017-03-21 Thread sikeoka
Here is the pull request: 
https://github.com/geoserver/geoserver/pull/2174

The build exceeding the time limit doesn't appear to be related.

Steve Ikeoka



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Regression-Accessing-Styles-Directory-tp5313244p5313486.html
Sent from the GeoServer - Dev 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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


[Geoserver-devel] [JIRA] (GEOS-8043) DataUtilities.collection( collection ) always returns DefaultFeatureCollection

2017-03-21 Thread Jody Garnett [Administrator] (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Jody Garnett [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-8043  
 
 
  DataUtilities.collection( collection ) always returns DefaultFeatureCollection   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 21/Mar/17 8:04 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Jody Garnett [Administrator]  
 

  
 
 
 
 

 
 This has caused problems in  
   GEOS-8042  Open  where a list has been passed in as the collection, and the results were sorted into a treeset which was not what was expected. We have some additional FeatureCollection implementations to choose from - but prefer developers call them directly rather than rely on the DataUtilities facade. Sadly that has not worked, as although documented, developers have not discovered these implementations. Alternatives to consider: 
 
Deprecate DataUtilities.collection( collection ), and ask more strongly for developers to use the FeatureCollection implementation of their choice 
Replace DataUtilities.collection(collection) with DataUtilities.collection(list) and DataUtilities.collection( set ) so we can have an explicit javadoc. 
 We are stuck here between: 
 
violating the principle of least surprise (as shown by  
   GEOS-8042  Open  above) 
preserving backwards compatibility 
  
 

  
 
 
  
 

 
 

[Geoserver-devel] [JIRA] (GEOS-8042) WFS-T Insert FeatureIds being returned in incorrect order

2017-03-21 Thread Jody Garnett [Administrator] (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Jody Garnett [Administrator] created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-8042  
 
 
  WFS-T Insert FeatureIds being returned in incorrect order   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 2.9.4, 2.10.2, 2.11-RC1  
 
 
Assignee: 
 David Blasby  
 
 
Components: 
 WFS  
 
 
Created: 
 21/Mar/17 7:34 PM  
 
 
Environment: 
 From Dave Blasby on geoserver-devel: 

 
I was looking at the WFS-T response for Inserts (it's a list of FIDs). The spec says these should be in the same order as the features in the request's Insert elements. 
However, I'm seeing these in a "strange" order. I think I've tracked it down to the DefaultFeatureCollection implementation. This stores the features in a SortedMap, and the iterator just returns them in the text-natural-id-order (ie. "new0", "new1", "new11", "new2", "new3",... – "new11" is in the wrong order). This messes up the order of the new fids for the inserted features. 
Here's it using the DefaultFeatureCollection; https://github.com/geoserver/geoserver/blob/2.9.x/src/wfs/src/main/java/org/geoserver/wfs/InsertElementHandler.java#L98 
and the passing it (incorrectly ordered) off to the underlying datastore; https://github.com/geoserver/geoserver/blob/2.9.x/src/wfs/src/main/java/org/geoserver/wfs/InsertElementHandler.java#L189 
Here's the DefaultFeatureCollection implementation; https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/DefaultFeatureCollection.java#L330 

  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 

Re: [Geoserver-devel] SQL views and performance

2017-03-21 Thread Gabriel Vatin
Great, thanks to both of you. Now I see clearer on how to debug and 
improve this. If I get something that would be useful to all, after 
improving the queries, I'll share the trick!


Gabriel


Le 21/03/2017 à 12:58, Jonathan Moules a écrit :

Hi Gabriel,
If you turn the GeoServer logging level to Geotools-developer level, 
the log file will then include the SQL query that is sent to the 
database. This should facilitate debugging this issue.


You can then try running the query against your database's EXPLAIN 
syntax - which shows how your database thinks it will run it (or even 
better, EXPLAIN ANALYZE, which runs it and then says how it ran it). 
This will let you try and determine where the bottleneck is.
I've found this to be a fairly decent tutorial: 
https://www.depesz.com/2013/04/16/explaining-the-unexplainable/]


Between these you should hopefully be able to determine whether the 
optimisation scope is GeoServer, PostGres, your query, or some 
combination thereof.


Cheers,
Jonathan




 On Mon, 20 Mar 2017 17:34:03 + *Gabriel Vatin 
* wrote 


Thanks Andrea for the quick answer. What I can't really guess for
now, is when and how is the SQL view executed : does the BBOX
attribute of GetMap queries affect this SQL view (when no
parameter in the view definition) ?

The type of query to create a new layer is done so : I have a
whole "goi" table with attributes such as name etc., and a table
with all geometries (stored in geo_data column, which is a
Geometry,4326 with GIST index). Each layers of my GeoServer
changes with the "got_id" (layer theme ID), stored on the goi
table. Here is the whole view

SELECT id, id_ori, name, geo_data
FROM geometrie
LEFT JOIN goi USING (goi_id)
WHERE got_id = 105

I add this extra line for the 2nd version, where the POLYGON is
view parameter generated from the client :

  AND
St_Intersects(geo_data,St_Transform(ST_GeomFromText('POLYGON((808771
5420870,810771 5420870,810771 5422870,808771 5422870,808771
5420870))',3857),4326))


Le 20/03/2017 à 17:00, Andrea Aime a écrit :

Hi Gabriel,
it seems your database of choice has real trouble figuring out
a good access plan
for those queries. Hard to say if the db should be able to
just figure out that the
outer spatial index can be executed directly in the inner
query or not without seeing the query.

Normally postgis/postgresql is pretty good with planning,
while Oracle and SQL Server are
rather poor.

Some systems allow to add a place where the current "bbox" can
be expanded as a parameter
transparently (without explicit support). GeoServer could have
it too with some development effort:

https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

That said, in your case it seems it's not always a win, I
guess it's a matter of figuring out
how many zoomed in vs zoomed out requests you need to produce.
Maybe you could create two views, one with, one without, bind
them in a layer group, and use scale dependencies to
switch from one to the other.

Cheers
Andrea


On Mon, Mar 20, 2017 at 3:55 PM, Gabriel Vatin
>
wrote:

Hi all,

Some questions about Geoserver performances when using SQL
views as
layers. I've got many layers that are defined from SQL
views directly on
Geoserver (no viewson the database), from Postgres. It
seems that each
time the Geoserver receive a query (single WMS, or multi
WMS coming from
tiled queries in OpenLayers), it does the wole SQL query
for each GET.
And then return the image from the BBOX.
When I query a GetMap for a small area, the whole country
is queried
just to have a small extent.

I tried a new SQL view with a %polygon% attributes : this
adds "AND
ST_Intersects() " between the geometry from this polygon,
and the
geometry of the table. Now I have a strange change :
- for largest images (a whole city), the return time for
GetMap is
divided by 6 (6000ms -> 1000ms)
- for smallest images (a district), the return time for
GetMap is
multiplied by 3 (100ms -> 300ms)

The SQL with the ST_Intersects and the Bbox takes 300ms,
so I guess the
GetMap won't be faster than this...

Thanks for the advice !


Gabriel Vatin




[Geoserver-devel] WCS 2.0.1 with SCALESIZE

2017-03-21 Thread Rahkonen Jukka (MML)
Hi,

Is there something wrong with this GetCoverage?

localhost:8080/geoserver/wcs?service=WCS=2.0.1=GetCoverage=sf__sfdem=E(589980,59)=N(4913700,4923700)=E(200),N(200)

The error from GeoServer 2.11-RC1 is 
"ScaleAxisUndefined" locator="E">

-Jukka Rahkonen-
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


[Geoserver-devel] [JIRA] (GEOS-8041) GWC Data Security Vulnerability

2017-03-21 Thread Simon Hofer (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Simon Hofer created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-8041  
 
 
  GWC Data Security Vulnerability   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 2.10.2, 2.11-RC1  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 GWC, Vulnerability  
 
 
Created: 
 21/Mar/17 6:33 PM  
 
 
Environment: 
 Ubuntu 14.04 / Jetty  
 
 
Priority: 
  Medium  
 
 
Reporter: 
 Simon Hofer  
 

  
 
 
 
 

 
 It's possible to request data a user has not be granted to. It violates the Statement in docs "It is only possible to request a tile within a bounding box that is fully accessible." I will provide further details per mail on request.  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

Re: [Geoserver-devel] GDAL lib and imageio-ext 1.1.7 for macOS compiled succesfully - how to install ?

2017-03-21 Thread Torben Barsballe
Hello Gilles

You may also need to set the -Djava.library.path java parameter to point to
the location of the gdaljni files. Try adding the following to setenv.sh:

export JAVA_OPTS="-Djava.library.path=/usr/local/lib"


Also, as a point of comparaison, I have the following GDAL dynamic libs on
OS X (I am using GDAL 1.11.2):

libgdal.1.dylib
libgdal.dylib
libgdalconstjni.1.dylib
libgdalconstjni.dylib
libgdaljni.1.dylib
libgdaljni.dylib
libltidsdk.9.dylib
libltidsdk.dylib
libogrjni.1.dylib
libogrjni.dylib
libosrjni.1.dylib
libosrjni.dylib
libtbb.dylib

Hope this helps,

Torben

On Tue, Mar 21, 2017 at 3:56 AM, Gilles Celli  wrote:

> Hi Daniele,
>
> I made some progress:
> By checking logs of geoserver, "gdal.jar" was missing in
> "geoserver/WEB-INF/lib", I copied it then to it.
>
> And yes the dynamic libs were built by swig in the gdal/swig/java/ as you
> mentioned:
>
> #ls  gdal-2.1.3/swig/java/*.dylib
> libgdalconstjni.20.dylib libgdaljni.20.dylib libogrjni.20.dylib
> libosrjni.20.dylib
> libgdalconstjni.dylib libgdaljni.dylib libogrjni.dylib libosrjni.dylib
>
> So I copied the dynamic libs to /usr/local/lib and set the
> DYLD_LIBRARY_PATH in both "setenv.sh" and my ~/.bash_profile
>
> But I sill get:
> 21-Mar-2017 11:52:30.973 WARNING [localhost-startStop-1]
> it.geosolutions.imageio.gdalframework.GDALUtilities.loadGDAL Failed to
> load the GDAL native libs. This is not a problem unless you need to use the
> GDAL plugins: they won't be enabled.
> java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path
>
> From "catalina.out" log file:
> 21-Mar-2017 11:35:21.773 WARNING [localhost-startStop-1]
> it.geosolutions.imageio.gdalframework.GDALUtilities.loadGDAL Failed to
> load the GDAL native libs. This is not a problem unless you need to use the
> GDAL plugins: they won't be enabled.
> java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path
>
> 21-Mar-2017 11:35:11.801 INFO [localhost-startStop-2] org.geoserver.
> GeoserverInitStartupListener.contextDestroyed Unregistering Image I/O
> provider it.geosolutions.imageio.plugins.jp2kakadu.
> JP2GDALKakaduImageWriterSpi@7a22e404
> 21-Mar-2017 11:35:11.801 INFO [localhost-startStop-2] org.geoserver.
> GeoserverInitStartupListener.contextDestroyed Unregistering Image I/O
> provider it.geosolutions.imageio.stream.output.spi.
> StringImageOutputStreamSpi@35038fe5
>
>
> Any clues ?
>
> Cheers,
>
> Gilles
>
> On 21 Mar 2017, at 10:00, Daniele Romagnoli  solutions.it> wrote:
>
> Hi Gilles,
> can you check the GeoServer log and the catalina.out looking for some GDAL
> library loading related message?
> You should see one of these 2 messages (depending on loading success vs
> loading failure):
>
> When successfully loaded:
> *GDAL Native Library loaded (version: X.X.X)*
>
> When missing:
> *Failed to load the GDAL native libs. This is not a problem unless you
> need to use the GDAL plugins: they won't be enabled*
>
> Does your swig build also created *gdaljni*, *gdalconstjni*,  *ogrjni*,
> *osrjni*,... dynamic libs?
> If that is the case, are them in the same location where you have
> installed the other libs ?
>
> Being on a MacOS, you may need to configure the DYLD_LIBRARY_PATH on your
> startup scripts, referring to the path where the dynamic lib have been
> installed.
> Hopefully, some MacOS dev may chime in to provide you additional feedbacks
> on this topic.
>
> Please, let us know.
> Best Regards,
> Daniele
>
>
>
> On Mon, Mar 20, 2017 at 4:51 PM, Gilles Celli 
> wrote:
>
>> Hello Geoserver-Developers,
>>
>> Well I'm not sure if i should post that here (or on the geoserver-users
>> mailing list), but it seems related to Geoserver development, so here we go:
>>
>> We have Geoserver 2.10.1 running on macOS 10.11 but we need ENVI file
>> support, that's why I compiled the latest gdal 2.1.3 libraries manually
>> to allow compilation of the java binding file for gdal-format.
>>
>> The gdal native libraries are installed in /usr/local/lib/
>>
>> I copied the "gdal.jar" java binding file to geoserver/WEB-INF/lib/ along
>> with imageio-ext recommended .jars files, as described here
>> http://docs.geoserver.org/latest/en/user/data/raster/gdal.html
>>
>>
>> However the ENVI format in "Raster Data Sources" is not available.
>>
>> It seems that Geoserver doesn't recognize the "gdal.jar" binding file,
>> even if I rename it to "imageio-ext-gdal-bindings-1.9.2.jar"
>> ( Geo-Solutions Java Binding file it is named
>> "imageio-ext-gdal-bindings-1.9.2.jar" file in th
>>
>> So my question is:
>> Does someone know how to properly setup the gdal.jar binding file so that
>> GEOSERVER could recognize it ?
>>
>> Note that I even compiled the ImageIO-Ext 1.1.7 plugin for macOS (by
>> correcting the pom.xml files) (which I don't think it's required since the
>> .jars can be downloaded from
>> http://demo.geo-solutions.it/share/github/imageio-ext/releas
>> es/1.1.X/1.1.16/
>>
>> For compilation Info:
>> 

Re: [Geoserver-devel] Regression Accessing Styles Directory

2017-03-21 Thread sikeoka
I created a JIRA ticket https://osgeo-org.atlassian.net/browse/GEOS-8040 and
will try to submit a pull request today.  

When these images are loaded for an output format like PNG or JPEG, the
images are loaded internally by the renderer and work fine since they do not
go through StylePublisher.  For KML output, the KML IconStyle will contain a
URL like
http://localhost:8080/geoserver/styles/icons/tropical_cyclone/hurricane_north.png
so StylePublisher throws an error when a client like Google Earth tries to
load the image.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Regression-Accessing-Styles-Directory-tp5313244p5313437.html
Sent from the GeoServer - Dev 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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] SQL views and performance

2017-03-21 Thread Andrea Aime
On Mon, Mar 20, 2017 at 6:34 PM, Gabriel Vatin 
wrote:

> Thanks Andrea for the quick answer. What I can't really guess for now, is
> when and how is the SQL view executed : does the BBOX attribute of GetMap
> queries affect this SQL view (when no parameter in the view definition) ?
>
Yes, just like any other table. With a plain table the query composed is:

select  from  where 

where  comes from the OGC request, that is, the bbox, time,
elevation, and the SLD itself.

When working off a sql view it becomes:

select  from () as _gt_table where 

In other words, GeoServer uses the SQL you provided verbatim (could be a
stored procedure call too, or whatever database specific mechanism returns
a set of rows) and then applies filters on it.
This should not be interpreted as running sql view definition first and
then filtering on top of it, it's up to the database to figure out an
optimal execution order, depending on the sql involved and database
abilities the bbox filter might be run first before doing the joins in your
sql, and so on. See also https://en.wikipedia.org/wiki/Query_plan

The type of query to create a new layer is done so : I have a whole "goi"
> table with attributes such as name etc., and a table with all geometries
> (stored in geo_data column, which is a Geometry,4326 with GIST index). Each
> layers of my GeoServer changes with the "got_id" (layer theme ID), stored
> on the goi table. Here is the whole view
>
> SELECT id, id_ori, name, geo_data
> FROM geometrie
> LEFT JOIN goi USING (goi_id)
> WHERE got_id = 105
>

See Jonathan's mail about getting the full query and running an explain.
It might just well be that you have index statistics that are out of date,
too, running a "analyze" might help:
https://www.postgresql.org/docs/9.1/static/sql-analyze.html

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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] SQL views and performance

2017-03-21 Thread Jonathan Moules
Hi Gabriel,
If you turn the GeoServer logging level to Geotools-developer level, the log 
file will then include the SQL query that is sent to the database. This should 
facilitate debugging this issue.

You can then try running the query against your database's EXPLAIN syntax - 
which shows how your database thinks it will run it (or even better, EXPLAIN 
ANALYZE, which runs it and then says how it ran it). This will let you try and 
determine where the bottleneck is.
I've found this to be a fairly decent tutorial: 
https://www.depesz.com/2013/04/16/explaining-the-unexplainable/]

Between these you should hopefully be able to determine whether the 
optimisation scope is GeoServer, PostGres, your query, or some combination 
thereof.

Cheers,
Jonathan




 On Mon, 20 Mar 2017 17:34:03 + Gabriel Vatin 
gabriel.va...@kinaxia.fr wrote  

  Thanks Andrea for the quick answer. What I can't really guess for now, is 
when and how is the SQL view executed : does the BBOX attribute of GetMap 
queries affect this SQL view (when no parameter in the view definition) ?
 The type of query to create a new layer is done so : I have a whole "goi" 
table with attributes such as name etc., and a table with all geometries 
(stored in geo_data column, which is a Geometry,4326 with GIST index). Each 
layers of my GeoServer changes with the "got_id" (layer theme ID), stored on 
the goi table. Here is the whole view 
 
 SELECT id, id_ori, name, geo_data
 FROM geometrie
 LEFT JOIN goi USING (goi_id)
 WHERE got_id = 105
 I add this extra line for the 2nd version, where the POLYGON is view parameter 
generated from the client :
 
   AND St_Intersects(geo_data,St_Transform(ST_GeomFromText('POLYGON((808771 
5420870,810771 5420870,810771 5422870,808771 5422870,808771 
5420870))',3857),4326))
 
 Le 20/03/2017 à 17:00, Andrea Aime a écrit :
 
  Hi Gabriel, it seems your database of choice has real trouble figuring out a 
good access plan 
 for those queries. Hard to say if the db should be able to just figure out 
that the
 outer spatial index can be executed directly in the inner query or not without 
seeing the query.
 
 
 Normally postgis/postgresql is pretty good with planning, while Oracle and SQL 
Server are
 rather poor.
 
 
 Some systems allow to add a place where the current "bbox" can be expanded as 
a parameter
 transparently (without explicit support). GeoServer could have it too with 
some development effort:
 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
 
 
 
 That said, in your case it seems it's not always a win, I guess it's a matter 
of figuring out
 how many zoomed in vs zoomed out requests you need to produce.
 Maybe you could create two views, one with, one without, bind them in a layer 
group, and use scale dependencies to
 switch from one to the other.
 
 
 Cheers
 Andrea
 
 
 
 
 On Mon, Mar 20, 2017 at 3:55 PM, Gabriel Vatin 
gabriel.va...@kinaxia.fr wrote:
 Hi all,
 
 Some questions about Geoserver performances when using SQL views as
 layers. I've got many layers that are defined from SQL views directly on
 Geoserver (no viewson the database), from Postgres. It seems that each
 time the Geoserver receive a query (single WMS, or multi WMS coming from
 tiled queries in OpenLayers), it does the wole SQL query for each GET.
 And then return the image from the BBOX.
 When I query a GetMap for a small area, the whole country is queried
 just to have a small extent.
 
 I tried a new SQL view with a %polygon% attributes : this adds "AND
 ST_Intersects() " between the geometry from this polygon, and the
 geometry of the table. Now I have a strange change :
 - for largest images (a whole city), the return time for GetMap is
 divided by 6 (6000ms - 1000ms)
 - for smallest images (a district), the return time for GetMap is
 multiplied by 3 (100ms - 300ms)
 
 The SQL with the ST_Intersects and the Bbox takes 300ms, so I guess the
 GetMap won't be faster than this...
 
 Thanks for the advice !
 
 
 Gabriel Vatin
 
 
 --
 Check out the vibrant tech community on one of the world's most
 engaging tech sites, Slashdot.org! http://sdm.link/slashdot
 ___
 Geoserver-devel mailing list
 Geoserver-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  
 
 
 
 
 -- 
 ==
 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 

[Geoserver-devel] Build failed in Jenkins: GeoTools-Master-OpenJDK8 #417

2017-03-21 Thread jenkins
See 


Changes:

[Andrea Aime] [GEOT-5679] and [GEOT-5680], H2 and postgis distance filter fixes

--
[...truncated 8226 lines...]
[INFO] Process ... SKIPPED
[INFO] Process Feature ... SKIPPED
[INFO] Process Raster  SKIPPED
[INFO] YSLD Parser/Encoder ... SKIPPED
[INFO] Swing widgets . SKIPPED
[INFO] SWT widgets ... SKIPPED
[INFO] Process Geometry .. SKIPPED
[INFO] GeoJSON Support ... SKIPPED
[INFO] MBTiles Module  SKIPPED
[INFO] WFS client module (NG)  SKIPPED
[INFO] polylabel . SKIPPED
[INFO] ISO 19107 implementation using JTS  SKIPPED
[INFO] Geometries  SKIPPED
[INFO] Web Processing Service  SKIPPED
[INFO] Application Schema Support (Unsupported Modules) .. SKIPPED
[INFO] SOLR module ... SKIPPED
[INFO] Geobuf DataStore .. SKIPPED
[INFO] Cartographic CSS parser ... SKIPPED
[INFO] GeoJSON Datastore . SKIPPED
[INFO] CSVDataStore .. SKIPPED
[INFO] EPSG Authority Factory for Oracle . SKIPPED
[INFO] Next Generation JDBC DataStores ... SKIPPED
[INFO] SAS Matlab grid coverage readers .. SKIPPED
[INFO] Simple Feature Service store .. SKIPPED
[INFO] Aggregating DataStore . SKIPPED
[INFO] MongoDB DataStore . SKIPPED
[INFO] GeoTools Documentation  SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 9:26.533s
[INFO] Finished at: Tue Mar 21 12:26:05 CET 2017
[INFO] Final Memory: 570M/1374M
[INFO] 
Waiting for Jenkins to finish collecting data
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on 
project gt-jdbc: There are test failures.
[ERROR] 
[ERROR] Please refer to 

 for the individual test results.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :gt-jdbc
[JENKINS] Archiving 

 to org.geotools.jdbc/gt-jdbc-mysql/18-SNAPSHOT/gt-jdbc-mysql-18-SNAPSHOT.pom
[JENKINS] Archiving 

 to org.geotools/gt-wps/18-SNAPSHOT/gt-wps-18-SNAPSHOT.pom
[JENKINS] Archiving 

 to org.geotools/gt-opengis/18-SNAPSHOT/gt-opengis-18-SNAPSHOT.pom
[JENKINS] Archiving 

 to org.geotools/gt-opengis/18-SNAPSHOT/gt-opengis-18-SNAPSHOT.jar
[JENKINS] Archiving 

 to org.geotools/gt-opengis/18-SNAPSHOT/gt-opengis-18-SNAPSHOT-sources.jar
[JENKINS] Archiving 

 to org.geotools/gt-validation/18-SNAPSHOT/gt-validation-18-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.geotools/gt-app-schema-resolver/18-SNAPSHOT/gt-app-schema-resolver-18-SNAPSHOT.pom
[JENKINS] Archiving 

 to 

Re: [Geoserver-devel] GDAL lib and imageio-ext 1.1.7 for macOS compiled succesfully - how to install ?

2017-03-21 Thread Gilles Celli
Hi Daniele,

I made some progress:
By checking logs of geoserver, "gdal.jar" was missing in 
"geoserver/WEB-INF/lib", I copied it then to it.

And yes the dynamic libs were built by swig in the gdal/swig/java/ as you 
mentioned:

#ls  gdal-2.1.3/swig/java/*.dylib
libgdalconstjni.20.dyliblibgdaljni.20.dylib 
libogrjni.20.dylib  libosrjni.20.dylib
libgdalconstjni.dylib   libgdaljni.dyliblibogrjni.dylib 
libosrjni.dylib

So I copied the dynamic libs to /usr/local/lib and set the DYLD_LIBRARY_PATH in 
both "setenv.sh" and my ~/.bash_profile

But I sill get:
21-Mar-2017 11:52:30.973 WARNING [localhost-startStop-1] 
it.geosolutions.imageio.gdalframework.GDALUtilities.loadGDAL Failed to load the 
GDAL native libs. This is not a problem unless you need to use the GDAL 
plugins: they won't be enabled.
java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path

From "catalina.out" log file:
21-Mar-2017 11:35:21.773 WARNING [localhost-startStop-1] 
it.geosolutions.imageio.gdalframework.GDALUtilities.loadGDAL Failed to load the 
GDAL native libs. This is not a problem unless you need to use the GDAL 
plugins: they won't be enabled.
java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path

21-Mar-2017 11:35:11.801 INFO [localhost-startStop-2] 
org.geoserver.GeoserverInitStartupListener.contextDestroyed Unregistering Image 
I/O provider 
it.geosolutions.imageio.plugins.jp2kakadu.JP2GDALKakaduImageWriterSpi@7a22e404
21-Mar-2017 11:35:11.801 INFO [localhost-startStop-2] 
org.geoserver.GeoserverInitStartupListener.contextDestroyed Unregistering Image 
I/O provider 
it.geosolutions.imageio.stream.output.spi.StringImageOutputStreamSpi@35038fe5


Any clues ?

Cheers,

Gilles

> On 21 Mar 2017, at 10:00, Daniele Romagnoli 
>  wrote:
> 
> Hi Gilles,
> can you check the GeoServer log and the catalina.out looking for some GDAL 
> library loading related message?
> You should see one of these 2 messages (depending on loading success vs 
> loading failure):
> 
> When successfully loaded:
> GDAL Native Library loaded (version: X.X.X)
> 
> When missing:
> Failed to load the GDAL native libs. This is not a problem unless you need to 
> use the GDAL plugins: they won't be enabled
> 
> Does your swig build also created *gdaljni*, *gdalconstjni*,  *ogrjni*, 
> *osrjni*,... dynamic libs? 
> If that is the case, are them in the same location where you have installed 
> the other libs ?
> 
> Being on a MacOS, you may need to configure the DYLD_LIBRARY_PATH on your 
> startup scripts, referring to the path where the dynamic lib have been 
> installed.
> Hopefully, some MacOS dev may chime in to provide you additional feedbacks on 
> this topic.
> 
> Please, let us know.
> Best Regards,
> Daniele
> 
> 
> 
> On Mon, Mar 20, 2017 at 4:51 PM, Gilles Celli  > wrote:
> Hello Geoserver-Developers,
> 
> Well I'm not sure if i should post that here (or on the geoserver-users 
> mailing list), but it seems related to Geoserver development, so here we go:
> 
> We have Geoserver 2.10.1 running on macOS 10.11 but we need ENVI file 
> support, that's why I compiled the latest gdal 2.1.3 libraries manually
> to allow compilation of the java binding file for gdal-format.
> 
> The gdal native libraries are installed in /usr/local/lib/
> 
> I copied the "gdal.jar" java binding file to geoserver/WEB-INF/lib/ along 
> with imageio-ext recommended .jars files, as described here
> http://docs.geoserver.org/latest/en/user/data/raster/gdal.html 
> 
> 
> 
> However the ENVI format in "Raster Data Sources" is not available.
> 
> It seems that Geoserver doesn't recognize the "gdal.jar" binding file, even 
> if I rename it to "imageio-ext-gdal-bindings-1.9.2.jar"
> ( Geo-Solutions Java Binding file it is named 
> "imageio-ext-gdal-bindings-1.9.2.jar" file in th
> 
> So my question is:
> Does someone know how to properly setup the gdal.jar binding file so that 
> GEOSERVER could recognize it ?
> 
> Note that I even compiled the ImageIO-Ext 1.1.7 plugin for macOS (by 
> correcting the pom.xml files) (which I don't think it's required since the 
> .jars can be downloaded from
> http://demo.geo-solutions.it/share/github/imageio-ext/releases/1.1.X/1.1.16/ 
> 
> 
> For compilation Info:
> GDAL configure command (needed Kyng Chaos UnixImageIO, PROJ and GEOS 
> frameworks)
> #cd gdal-2.1.3
> 
> #./configure --with-threads --disable-static --without-grass 
> --with-jasper=/Library/Frameworks/UnixImageIO.framework/unix \
> --with-libtiff=/Library/Frameworks/UnixImageIO.framework/unix 
> --with-jpeg=/Library/Frameworks/UnixImageIO.framework/unix \
> --with-gif=/Library/Frameworks/UnixImageIO.framework/unix 
> --with-png=/Library/Frameworks/UnixImageIO.framework/unix \
> 

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

2017-03-21 Thread Ian Turton
+1 from me

Ian

On 21 March 2017 at 09:50, Andrea Aime  wrote:

> Thanks for the clarification
> +1 then :-)
>
> Cheers
> Andrea
>
> On Mon, Mar 20, 2017 at 6:31 PM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>> I took a look, and none of the changes are strictly backwards-compatible
>>
>> The changes to CatalogPostModifyEvent are changes to a public interface.
>> The changes to AbstractCatalogFacade are protected, but will affect
>> anything extending AbstractCatalogFacade.
>>
>> Everything else is mostly just implementing the interface changes, and
>> depends upon the changes above. I have updated the GSIP to make this
>> delineation more clear.
>>
>> Torben
>>
>> On Mon, Mar 20, 2017 at 10:15 AM, Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> Hi Torben,
>>> it would help, imho, if the proposal separated the API changes that are
>>> actual backwards incompatible ones.
>>> E.g., adding method to the event class is not an API break at all.
>>>
>>> Makes easier to argue that the changes are isolated in places that are
>>> not really meant to be implemented
>>> outside of GeoServer. Just my 2 cents.
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> On Mon, Mar 20, 2017 at 5:09 PM, Torben Barsballe <
>>> tbarsba...@boundlessgeo.com> wrote:
>>>
 This was initially proposed just prior to the 2.11-beta release, but
 did not make it in in time.
 Re-opening for discussion and voting now that the code freeze has ended.

 Refer to https://github.com/geoserver/geoserver/wiki/GSIP-157

 This proposal is to update the CatalogPostModifyEvent (and associated
 firePostModifed methods) to track changed values, similar to the current
 implementation of CatalogModifyEvent.

 This requires some API changes in a few catalog methods and interfaces.

 Ultimately, it is a useful, but relatively minor change requiring some
 not-backwards-compatible API changes to the core catalog implementation.

 Full set of proposed changes can be seen in the pull request
 .

 Torben



 
 --
 Check out the vibrant tech community on one of the world's most
 engaging tech sites, Slashdot.org! http://sdm.link/slashdot
 ___
 Geoserver-devel mailing list
 Geoserver-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geoserver-devel


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

[Geoserver-devel] Jenkins build is back to normal : GeoTools-Master-OpenJDK8 #416

2017-03-21 Thread jenkins
See 



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

2017-03-21 Thread Andrea Aime
Thanks for the clarification
+1 then :-)

Cheers
Andrea

On Mon, Mar 20, 2017 at 6:31 PM, Torben Barsballe <
tbarsba...@boundlessgeo.com> wrote:

> I took a look, and none of the changes are strictly backwards-compatible
>
> The changes to CatalogPostModifyEvent are changes to a public interface.
> The changes to AbstractCatalogFacade are protected, but will affect
> anything extending AbstractCatalogFacade.
>
> Everything else is mostly just implementing the interface changes, and
> depends upon the changes above. I have updated the GSIP to make this
> delineation more clear.
>
> Torben
>
> On Mon, Mar 20, 2017 at 10:15 AM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> Hi Torben,
>> it would help, imho, if the proposal separated the API changes that are
>> actual backwards incompatible ones.
>> E.g., adding method to the event class is not an API break at all.
>>
>> Makes easier to argue that the changes are isolated in places that are
>> not really meant to be implemented
>> outside of GeoServer. Just my 2 cents.
>>
>> Cheers
>> Andrea
>>
>>
>> On Mon, Mar 20, 2017 at 5:09 PM, Torben Barsballe <
>> tbarsba...@boundlessgeo.com> wrote:
>>
>>> This was initially proposed just prior to the 2.11-beta release, but did
>>> not make it in in time.
>>> Re-opening for discussion and voting now that the code freeze has ended.
>>>
>>> Refer to https://github.com/geoserver/geoserver/wiki/GSIP-157
>>>
>>> This proposal is to update the CatalogPostModifyEvent (and associated
>>> firePostModifed methods) to track changed values, similar to the current
>>> implementation of CatalogModifyEvent.
>>>
>>> This requires some API changes in a few catalog methods and interfaces.
>>>
>>> Ultimately, it is a useful, but relatively minor change requiring some
>>> not-backwards-compatible API changes to the core catalog implementation.
>>>
>>> Full set of proposed changes can be seen in the pull request
>>> .
>>>
>>> Torben
>>>
>>>
>>>
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>
>>
>> --
>> ==
>> 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.
>>
>> ---
>>
>
>


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

Re: [Geoserver-devel] GDAL lib and imageio-ext 1.1.7 for macOS compiled succesfully - how to install ?

2017-03-21 Thread Daniele Romagnoli
Hi Gilles,
can you check the GeoServer log and the catalina.out looking for some GDAL
library loading related message?
You should see one of these 2 messages (depending on loading success vs
loading failure):

When successfully loaded:
*GDAL Native Library loaded (version: X.X.X)*

When missing:
*Failed to load the GDAL native libs. This is not a problem unless you need
to use the GDAL plugins: they won't be enabled*

Does your swig build also created *gdaljni*, *gdalconstjni*,  *ogrjni*,
*osrjni*,... dynamic libs?
If that is the case, are them in the same location where you have installed
the other libs ?

Being on a MacOS, you may need to configure the DYLD_LIBRARY_PATH on your
startup scripts, referring to the path where the dynamic lib have been
installed.
Hopefully, some MacOS dev may chime in to provide you additional feedbacks
on this topic.

Please, let us know.
Best Regards,
Daniele



On Mon, Mar 20, 2017 at 4:51 PM, Gilles Celli  wrote:

> Hello Geoserver-Developers,
>
> Well I'm not sure if i should post that here (or on the geoserver-users
> mailing list), but it seems related to Geoserver development, so here we go:
>
> We have Geoserver 2.10.1 running on macOS 10.11 but we need ENVI file
> support, that's why I compiled the latest gdal 2.1.3 libraries manually
> to allow compilation of the java binding file for gdal-format.
>
> The gdal native libraries are installed in /usr/local/lib/
>
> I copied the "gdal.jar" java binding file to geoserver/WEB-INF/lib/ along
> with imageio-ext recommended .jars files, as described here
> http://docs.geoserver.org/latest/en/user/data/raster/gdal.html
>
>
> However the ENVI format in "Raster Data Sources" is not available.
>
> It seems that Geoserver doesn't recognize the "gdal.jar" binding file,
> even if I rename it to "imageio-ext-gdal-bindings-1.9.2.jar"
> ( Geo-Solutions Java Binding file it is named 
> "imageio-ext-gdal-bindings-1.9.2.jar"
> file in th
>
> So my question is:
> Does someone know how to properly setup the gdal.jar binding file so that
> GEOSERVER could recognize it ?
>
> Note that I even compiled the ImageIO-Ext 1.1.7 plugin for macOS (by
> correcting the pom.xml files) (which I don't think it's required since the
> .jars can be downloaded from
> http://demo.geo-solutions.it/share/github/imageio-ext/
> releases/1.1.X/1.1.16/
>
> For compilation Info:
> GDAL configure command (needed Kyng Chaos UnixImageIO, PROJ and GEOS
> frameworks)
> #cd gdal-2.1.3
>
> #./configure --with-threads --disable-static --without-grass
> --with-jasper=/Library/Frameworks/UnixImageIO.framework/unix \
> --with-libtiff=/Library/Frameworks/UnixImageIO.framework/unix
> --with-jpeg=/Library/Frameworks/UnixImageIO.framework/unix \
> --with-gif=/Library/Frameworks/UnixImageIO.framework/unix
> --with-png=/Library/Frameworks/UnixImageIO.framework/unix \
> --with-geotiff=/Library/Frameworks/UnixImageIO.framework/unix
> --with-pcraster=internal 
> --with-geos=/Library/Frameworks/GEOS.framework/unix/bin/geos-config
> --with-static-proj4=/Library/Frameworks/PROJ.framework/unix\
> --with-expat --with-python -with-java -with-jvm-lib=/Library/Java/
> JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home
> #make install
>
> #cd swig/java
> #make
>
> > it compiles and builds a "gdal.jar" binding file
>
> Any help is greatly appreciated,
>
> Gilles
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>



-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:  +39 0584 1660272

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 

Re: [Geoserver-devel] WFS-T Insert: Fids being returned in incorrect order

2017-03-21 Thread Even Rouault
On mardi 21 mars 2017 09:24:13 CET Andrea Aime wrote:
> On Tue, Mar 21, 2017 at 5:45 AM, Dave Blasby 
> 
> wrote:
> > I was looking at the WFS-T response for Inserts (it's a list of FIDs).
> > The spec says these should be in the same order as the features in the
> > request's Insert elements.
> 
> I never heard of this requirement so I went and check, indeed all 3 spec
> say so. However, it seems that at least the old
> WFS CITE test we're running did not verify that.
> 
> So, you're not seeing things, but I believe you're the first one to care
> about it enough to report the problem

Well, getting out of order IDs would certainly mess up things in the QGIS WFS 
client when 
doing multiple inserts at once, especially if doing later updates of the 
features (the wrong 
feature would be modified on the server)

I'm surprised this wasn't raised before, but I can see we have this logic :

/* Fix issue with GeoServer and shapefile feature stores when no real
   feature id are returned but new0 returned instead of the featureId*/
Q_FOREACH ( const QString , idList )
{
  if ( v.startsWith( "new" ) )
  {
reloadData();
return true;
  }
}

which makes that we don't trust such Ids and have to re-issue a GetFeature 
request. But if the 
ids do not start with "new", we would have the issue.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] WFS-T Insert: Fids being returned in incorrect order

2017-03-21 Thread Andrea Aime
On Tue, Mar 21, 2017 at 9:41 AM, Even Rouault 
wrote:

> /* Fix issue with GeoServer and shapefile feature stores when no real
>
> feature id are returned but new0 returned instead of the featureId*/
>
> Q_FOREACH ( const QString , idList )
>
> {
>
> if ( v.startsWith( "new" ) )
>
> {
>
> reloadData();
>
> return true;
>
> }
>
> }
>

Nope, this is another issue. With shapefiles our current code has no way to
know the new feature ids generated
(they are being collected before the transaction ends) so it gives back
fake results.
Well known issue, ticket here, second oldest open ticket in the system:

https://osgeo-org.atlassian.net/browse/GEOS-662

And then a repeat here with some other discussion (we should really close
one of the two):
https://osgeo-org.atlassian.net/browse/GEOS-6390

What David reports instead happens also for database backends and was not
known until today.

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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] WFS-T Insert: Fids being returned in incorrect order

2017-03-21 Thread Andrea Aime
On Tue, Mar 21, 2017 at 5:45 AM, Dave Blasby 
wrote:

> I was looking at the WFS-T response for Inserts (it's a list of FIDs).
> The spec says these should be in the same order as the features in the
> request's Insert elements.
>

I never heard of this requirement so I went and check, indeed all 3 spec
say so. However, it seems that at least the old
WFS CITE test we're running did not verify that.

So, you're not seeing things, but I believe you're the first one to care
about it enough to report the problem

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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] WFS-T Insert: Fids being returned in incorrect order

2017-03-21 Thread Dave Blasby
Thanks!


On Mar 21, 2017 12:29 AM, "Andrea Aime" 
wrote:

On Tue, Mar 21, 2017 at 5:45 AM, Dave Blasby 
wrote:

> Aside - does anyone know how to have WFS-NG preserve FIDs for inserts?  I
> havent been able to figure out how set it to use idgen=UseExisting instead
> of idgen=GenerateNew?
>

I don't know what WFS-NG does, but mind one thing, this control over index
generation is available only in WFS 1.1, it was not there in WFS 1.0, it
got removed in WFS 2.0 (and I don't believe it got wide implementation in
WFS 1.1 either, even in GeoServer if memory serves me well it works only
for JDBC data sources with a non auto-generated primary key).
So... I would not try to rely on it too much unless you're sure about the
server and target store.

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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Re: [Geoserver-devel] WFS-T Insert: Fids being returned in incorrect order

2017-03-21 Thread Andrea Aime
On Tue, Mar 21, 2017 at 5:45 AM, Dave Blasby 
wrote:

> Aside - does anyone know how to have WFS-NG preserve FIDs for inserts?  I
> havent been able to figure out how set it to use idgen=UseExisting instead
> of idgen=GenerateNew?
>

I don't know what WFS-NG does, but mind one thing, this control over index
generation is available only in WFS 1.1, it was not there in WFS 1.0, it
got removed in WFS 2.0 (and I don't believe it got wide implementation in
WFS 1.1 either, even in GeoServer if memory serves me well it works only
for JDBC data sources with a non auto-generated primary key).
So... I would not try to rely on it too much unless you're sure about the
server and target store.

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-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel