Re: [Geotools-devel] Crash in ArcSDE plugin

2015-10-19 Thread Robert Ward 
Jody,

Whilst I accept ArcSDE is now no longer supplied as part of ArcGIS 10.3, we 
have introduced GeoServer into a solution for a customer and would like to make 
its introduction as smooth as possible. We can demonstrate GeoServer's 
capabilities to customers with ArcSDE geodatabases very quickly without having 
to migrate any data, although obviously that will need to happen in the future. 

I have a fix which treats the empty sdeLayer extent the same as the case where 
the geometry collection is completely outside the extent of the layer, all 
contained within the GeometryEncoderSDE.addSpatialFilter() method.

What is the best way of progressing this?
Do you want to see the fix?
Do I need to raise a JIRA ticket?

Rob

From: Jody Garnett [mailto:jody.garn...@gmail.com] 
Sent: 16 October 2015 17:46
To: Robert Ward
Cc: GeoTools Developers
Subject: Re: [Geotools-devel] Crash in ArcSDE plugin

We should be able to return an Empty ReferencedEnvelope.

The ArcSDE DataStore is going to become rapidly unsupported as ESRI is stopping 
making that product available (as I understand it).

I expect we are going to have to round up "interested parties" and make a new 
datastore using the GSR API.



--
Jody Garnett

On 16 October 2015 at 03:30, Robert Ward  wrote:
Hi All,

I've found a problem in the ArcSDE plugin and I'm not sure the best way
of fixing it.
If using ArcSDE SDK 10.0 or ArcSDE SDK 10.2.2 a feature class in an
Oracle database has an empty extent (i.e. the feature class has been
created and has never contained any features), any calls to
SeShape.generateRectangle with an empty extent cause a crash.
It is easy to detect because SeExtent.isEmpty is true.

The crash is happening in GeometryEncoderSDE.addSpatialFilter at line
260    extent.generateRectangle(seExtent);

There are a several options to fix this:
1) After line 244 if seExtent.isEmpty() == true then fiddle the extent,
e.g. create a valid extent in the middle of the feature class coordinate
reference system
2) After line 244 if seExtent.isEmpty() == true then bail out, not sure
to where
3) Earlier on the in process if it is known that the extent is empty and
there will be no features returned then don't bother with getting data
from the feature class.

Regards

Robert Ward


SCISYS UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.

Before printing, please think about the environment.


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5256) CLONE - Implement DataStore.removeSchema on MemoryDataStore

2015-10-19 Thread Frank Gasdorf (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frank Gasdorf created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5256 
 
 
 
  CLONE - Implement DataStore.removeSchema on MemoryDataStore  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 19/Oct/15 12:48 PM 
 
 
 

Priority:
 
  Low 
 
 
 

Reporter:
 
 Frank Gasdorf 
 
 
 
 
 
 
 
 
 
 
With [https://jira.codehaus.org/browse/GEOT-2333" title="Implement removeSchema in JDBCDataStore" class="issue-link" data-issue-key="

GEOT-2333
">

GEOT-2333
, removeSchema has been added to JDBC datastore. Default implementation throws an UnsupportedOperationException. We need to add the specific implementation for the shapefile datastore. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 

[Geotools-devel] [JIRA] (GEOT-5255) Harden ProjectHandler query envelope extraction against CRS without a valid area

2015-10-19 Thread Andrea Aime [Administrator] (JIRA) 
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andrea Aime [Administrator] created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5255 
 
 
 
  Harden ProjectHandler query envelope extraction against CRS without a valid area  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 
 Andrea Aime [Administrator] 
 
 
 

Components:
 

 render 
 
 
 

Created:
 

 19/Oct/15 12:38 PM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Andrea Aime [Administrator] 
 
 
 
 
 
 
 
 
 
 
The getQueryEnvelope method tries hard to reproject envelopes back to the source CRS using area restrictions based on the source CRS and its valid area (if available), but can still fail if the source CRS is not in the EPSG database. Harden it to check if there is a projection handler for the source CRS that could provide a valid area for it. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 

Re: [Geotools-devel] Crash in ArcSDE plugin

2015-10-19 Thread Andrea Aime 
On Mon, Oct 19, 2015 at 10:09 AM, Robert Ward 
wrote:

> Jody,
>
> Whilst I accept ArcSDE is now no longer supplied as part of ArcGIS 10.3,
> we have introduced GeoServer into a solution for a customer and would like
> to make its introduction as smooth as possible. We can demonstrate
> GeoServer's capabilities to customers with ArcSDE geodatabases very quickly
> without having to migrate any data, although obviously that will need to
> happen in the future.
>
> I have a fix which treats the empty sdeLayer extent the same as the case
> where the geometry collection is completely outside the extent of the
> layer, all contained within the GeometryEncoderSDE.addSpatialFilter()
> method.
>
> What is the best way of progressing this?
>

Pull request following these rules:
https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md


> Do you want to see the fix?
>

Yep!


> Do I need to raise a JIRA ticket?
>

Yes, your commit message should be referencing the ticket number and title,
here is an example:
https://github.com/geotools/geotools/commit/f1c541fb34627e829aa9addb7abda7c62b041c77

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 Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



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

---
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] RasterSymbolizerHelper: 16-bit raster content, change proposal

2015-10-19 Thread Ville Karppinen 

Ciao Simone,

This change would give 16-bit target images only for GS queries that use 
GS style similar to =raster and =image/tiff or geotiff or 
png. So, this should only have an effect on tiff/geotiff/png image 
formats and only if GS style uses RasterSymbolizer without ColorMap. 
Then, the decision between 8-bit and 16-bit is defined by 
 with values tiff8 vs. tiff, geotiff8 vs. geotiff or 
png8 vs png. I am not sure if this change will cover all use cases. But, 
hopefully it is adequate for now.


I have build GT (mvn clean install -Dall) and all tests pass. Notice, I 
have made some changes also to test cases.


But, it seems that I have made newbie mistake related to testing with 
GS. I only build GT and run test cases there. Then, tested prebuild GS 
only with my own test URLs after copying GT jar-file to lib-folder. Now, 
that I built the GS master branch and used my own version of GT, there 
seems to be at least one GS test case that fails.

-- clip -->
Tests in error:
  testInterpolations(org.geoserver.wms.map.GIFMapResponseTest)
testInterpolations(org.geoserver.wms.map.RenderedImageMapOutputFormatTest)
..
[INFO] Web Map Service Module  FAILURE
<-- clip --

So, it seems that I need to study also GS source related to the GT 
change before making the GT pull request. And, most likely some GS pull 
request is also needed to make tests pass. I let you know when I know 
more about this. So, let's see about the pull request after that.


Best regards,

Ville Karppinen
ville.karppi...@fmi.fi

On 10/18/2015 01:49 PM, Simone Giannecchini wrote:


Ciao Ville,
I have recently reviewed work on the rastersymbolizer to enhance 
contrast stretch capabilities (more should come shortly) and I also 
tried to hack in again the support for 16 bits in a comprehensive way.


You change is ok but of my memory serves me right is not enough.

Couple of questions:
- have you run a full build of GT?
- have you run a full byld of GS?

If I remember correctly, this change would not cover all use cases. At 
least we would need some code GS wise to decide the bit depth prior to 
rendering.


If all test passes, move ahead with a PR and I will make sure we look 
into it next with Daniele or Andrea.


Simone.

Il 14/Ott/2015 12:56, "Ville Karppinen" > ha scritto:


Hi,

I have a change proposal for you on how GeoTools should handle 16-bit
raster content.

At the moment, geotools rescales 16-bit (ushort) source raster content
to 8-bit. In case of 16-bit source raster data, this may result to
target image that has lost valuable information, which in some use
cases
may not be acceptable. Therefore, I propose that geotools would pass
16-bit source raster content as 16-bit target image unless 8-bit
target
image is explicitly requested. The change required to the source
code is
really simple and can be viewed here:
https://github.com/TheKarppinen/geotools/tree/fix_16bit_raster
I have included in the commit also necessary changes to test cases.

I think 16-bit target image would be good feature also from the
GeoServer use case points of view. At the moment, GeoServer
queries may
define image format in URL. 8-bit images can be explicitly
queried, for
example geotiff8, tiff8, or png8 (FORMAT=image/geotiff8 vs
FORMAT=image/geotiff). But, if FORMAT=image/geotiff is used with
raster
style, the target image bit-accuracy should correspond the source
data,
instead of always being 8-bit.

Also, GeoServer and GeoTools have provided 16-bit target content when
16-bit raster data was queried in previous versions. This behavior has
changed at some point after GeoServer 2.5 that included GeoTools
version
11.0. So, in that sense the change to provide 16-bit target images
would
actually provide same behavior that has already been there before.

I was thinking to make a pull request for this change. But, wanted to
ask about additional comments here first. So, do you think that I may
make the pull request and this change will be included to GeoTools
master branch at some point?

The change is quite small and I am not sure if contribution license is
required for this. Anyway, I am working for Finnish Meteorological
Institute and our team has already signed the license. Personally
for me
this pull request would be the first one. So, I am newbie with the
process.


Here are still some example results when 16-bit raster content has
been
queried from GeoServer and target image content is checked by using
identify-program:

GeoServer query for 16-bit source content by using
format=image/geotiff
current GeoTools implementation gives:
  TIFF 485x768 485x768+0+0 8-bit Grayscale DirectClass 373KB
vs. fixed implementation gives:
  TIFF 485x768 485x768+0+0 16-bit Grayscale

Re: [Geotools-devel] Slow inserts in DB

2015-10-19 Thread Patrick Valsecchi 
I've been progressing a bit on that optimization. My work in progress can
be found here:
https://github.com/pvalsecc/geotools/tree/batch_inserts

My status is:

   - All offline tests I can run are green:
  - Postgis
  - H2
  - Mysql
  - Oracle
   - geogig Oracle export of a table with 17000 records (4 simple
   attributes and a single point geometry) without sequence is run in:
  - 640 seconds without my modifs
  - 13 seconds with my modifs
   - Stuff I want to improve:
  - don't do a select for every records we want to insert if there is a
  sequence.

If a main contributor could have a look at my modifs and tell me if I'm on
a good track, I would be very happy.

Thanks and CU.

On Mon, Oct 5, 2015 at 2:30 PM, Andrea Aime 
wrote:

> On Mon, Oct 5, 2015 at 2:12 PM, Patrick Valsecchi <
> patrick.valsec...@camptocamp.com> wrote:
>
>> Is there any reason for not using batch inserts in JDBCDataStore#insert?
>> What do you think of changing this area in order to use batch inserts (same
>> for deletes and updates, too, I guess)?
>>
>
> No objection, it simply has not been done so far because the main driver
> for writes in GeoTools
> stores today has been manual editing of small amounts of data, both in
> uDig and GeoServer,
> for which the current approach works fine
>
> 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 Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The 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.
>
> ---
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] new repository please test

2015-10-19 Thread Frank Gasdorf 
FWIW : Today I build library/data locally without a full build from
root-checkout and git the following WARNINGS :

Downloaded:
http://repo.boundlessgeo.com/main/org/geotools/gt-main/15-SNAPSHOT/maven-metadata.xml
(160
B at 0.1 KB/sec)
[WARNING] The metadata
/Users/fgdrf/Entwicklung/data/m2-repository/org/geotools/gt-main/15-SNAPSHOT/maven-metadata-boundless.xml
is invalid: end tag name  must match start tag name  from line 5
(position: TEXT seen ...\r\n... @6:8)

the content of file looks like this:


302 Found

302 Found
nginx/1.8.0




How I started the build:

mvn clean package -U

"-U" and deletion of local metadata-file does't help very much. After
another build the files is present again with the same html content than
before. Strange thing is, if I download the file directly it looks almost
good (last upload timestamp is 15-20151006)

Last but not least: If I build this submodul against an empty local
repository (-Dmaven.repo.local=/another/path/

the following error occurs:

Downloaded:
http://repo.boundlessgeo.com/main/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
(160
B at 0.3 KB/sec)
[ERROR] Invalid extension descriptor for
org.apache.maven.wagon:wagon-webdav:1.0-beta-2: error in opening zip file
[...]
Downloaded:
http://repo.boundlessgeo.com/main/org/apache/maven/plugins/maven-source-plugin/2.2.1/maven-source-plugin-2.2.1.pom
(160
B at 0.4 KB/sec)
[WARNING] The POM for
org.apache.maven.plugins:maven-source-plugin:jar:2.2.1 is invalid,
transitive dependencies (if any) will not be available, enable debug
logging for more details

And the build is broken then

HTH to investigate
- Frank

2015-10-05 20:53 GMT+02:00 Jody Garnett :

> Going to try and switch ares over to this mirror, if that goes well we
> will update the DNS registry this afternoon.
>
> --
> Jody Garnett
>
> On 29 September 2015 at 16:36, Jody Garnett 
> wrote:
>
>> Sorry, URL corrected below:
>>
>>   
>> 
>>   boundlessgeo
>>   Boundless Cloud Repository
>>   https://boundless.artifactoryonline.com/boundless/main
>>   boundless
>> 
>>   
>>
>>
>> --
>> Jody Garnett
>>
>> On 29 September 2015 at 16:20, Jody Garnett 
>> wrote:
>>
>>> We are setting up a replacement repository (cloud hosting for PMC
>>> access).
>>>
>>> Can I ask geotools developers to try out the repo using the following
>>> settings (before we change the DNS entry over):
>>>
>>> 1. Edit .m2/settings.xml with the following
>>>
>>>   
>>> 
>>>   boundlessgeo
>>>   Boundless Cloud Repository
>>>   
>>> https://boundless.artifactoryonline.com/boundless/ext-release-local
>>> 
>>>   boundless
>>> 
>>>   
>>>
>>> 2. Rename your .m2/repository cache to repository2 (to force download)
>>>
>>> 3. Build! And reply to this email thread with pass fail.
>>>
>>> We have synchronized with repo.boundlessgeo.com so I do not expect
>>> trouble.
>>> --
>>> Jody
>>>
>>
>>
>
>
> --
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

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

2015-10-19 Thread Ben Caradoc-Davies 
GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+%2F+GeoServer+Meeting=2015=10=20=19=30=0=1

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

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Jenkins build is back to normal : geotools-master-online #282

2015-10-19 Thread monitor 
See 


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Slow inserts in DB

2015-10-19 Thread Jody Garnett 
Patrick you may of seen a meeting reminder go out for a Skype meeting.
Would you like to drop in to this meeting and chat? This looks to be very
important work, thank you for taking it on.

--
Jody Garnett

On 19 October 2015 at 07:01, Patrick Valsecchi <
patrick.valsec...@camptocamp.com> wrote:

> I've been progressing a bit on that optimization. My work in progress can
> be found here:
> https://github.com/pvalsecc/geotools/tree/batch_inserts
>
> My status is:
>
>- All offline tests I can run are green:
>   - Postgis
>   - H2
>   - Mysql
>   - Oracle
>- geogig Oracle export of a table with 17000 records (4 simple
>attributes and a single point geometry) without sequence is run in:
>   - 640 seconds without my modifs
>   - 13 seconds with my modifs
>- Stuff I want to improve:
>   - don't do a select for every records we want to insert if there is
>   a sequence.
>
> If a main contributor could have a look at my modifs and tell me if I'm on
> a good track, I would be very happy.
>
> Thanks and CU.
>
> On Mon, Oct 5, 2015 at 2:30 PM, Andrea Aime 
> wrote:
>
>> On Mon, Oct 5, 2015 at 2:12 PM, Patrick Valsecchi <
>> patrick.valsec...@camptocamp.com> wrote:
>>
>>> Is there any reason for not using batch inserts in JDBCDataStore#insert?
>>> What do you think of changing this area in order to use batch inserts (same
>>> for deletes and updates, too, I guess)?
>>>
>>
>> No objection, it simply has not been done so far because the main driver
>> for writes in GeoTools
>> stores today has been manual editing of small amounts of data, both in
>> uDig and GeoServer,
>> for which the current approach works fine
>>
>> 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 Poggio alle Viti 1187
>> 55054  Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The 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.
>>
>> ---
>>
>
>
>
> --
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel