[Geotools-devel] JDBCAccessPGRaster - updating mosaic extent/resolutions table
Hi Christian, I'm playing with the ImageMosaicJDBC using PGRaster. I have noticed that the JDBCAccessPGRaster class does some initialization steps where it looks for overviews (ImageLevelInfo) extents and resolutions. Then it setup values for preparedStatement to do updates of resolutoins and extent within the MOSAIC table (which contains the name of the coverage, the name of the table containing a specific level, extent and resolution). However, I see that line 116 contains a con.commit(); being commented-out. Therefore, no fields are updated into the DB since no commit occurs.(moreover, line 109 set autocommit fo talse). Is there any reason for this or it's a simple oversight (Maybe you have commented out during tests and then forgot to restore it)? Please, let me know. Cheers, Daniele == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Daniele Romagnoli Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] base directory for file datastores
On Wed, Jul 10, 2013 at 12:23 AM, Niels Charlier ni...@scitus.be wrote: Jody, There is an additional issue. A lot of unit tests use paths with the property data store, relative to the start-up directory rather than the data directory. We need to avoid having to edit all those tests. I have found another solution working only from geoserver. Justin pointed me to this place: https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L615 So this is what I propose: https://github.com/NielsCharlier/geoserver/commit/aec803994b82d2cbaa1d58e1d9f56f1ade2204bb Seems reasonable to me. So I guess findDataFile actually also finds directories, yes? Cheers Andrea -- == Our support, Your Success! Visit http://opensdi.geo-solutions.it 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 --- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] JDBCAccessPGRaster - updating mosaic extent/resolutions table
Hi Daniele Strange, I see the rollback is out-commented too. Please remove the comments for rollback and commit and check the result. Another question: There is a new API supporting multiple coverages for a reader. This is the way the imagemosaic-jdbc module should work, but I have no time left at the moment. At the end of the day, merging the jdbc module into your module(s) would be nice. Are there any intentions ? Cheers Christian 2013/7/10 Daniele Romagnoli daniele.romagn...@geo-solutions.it Hi Christian, I'm playing with the ImageMosaicJDBC using PGRaster. I have noticed that the JDBCAccessPGRaster class does some initialization steps where it looks for overviews (ImageLevelInfo) extents and resolutions. Then it setup values for preparedStatement to do updates of resolutoins and extent within the MOSAIC table (which contains the name of the coverage, the name of the table containing a specific level, extent and resolution). However, I see that line 116 contains a con.commit(); being commented-out. Therefore, no fields are updated into the DB since no commit occurs.(moreover, line 109 set autocommit fo talse). Is there any reason for this or it's a simple oversight (Maybe you have commented out during tests and then forgot to restore it)? Please, let me know. Cheers, Daniele == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Daniele Romagnoli Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- DI Christian Mueller MSc (GIS), MSc (IT-Security) OSS Open Source Solutions GmbH -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4507) Easiest way to setup imageMosaicJDBC-PGRaster
Daniele Romagnoli created GEOT-4507 Easiest way to setup imageMosaicJDBC-PGRaster Issue Type: Improvement Assignee: Unassigned Components: imagemosaic-jdbc plugin Created: 10/Jul/13 11:11 AM Description: Right now, in order to config an imageMosaic JDBC against PGRaster DB there are several steps to be performed: 1) use gdal_retile to create tiles for images 2) insert tiled data as new table (one for level) into PGRaster using raster2pgsql scripts invokation 3) create a table containing level information (reference table, envelope, resolutions) 4) create 3 XML config files with JDBC mapping, coverage properties, table mapping 5) configure the mosaic. It would be good to have some automagic way to do steps 2 through 5 with minimal user intervention. As an instance, it would be great if we could just provide the location of the folder containing tiled images (levels), as well as a set of some additional parameters (table name prefix, mosaic name, coverage name, DB credentials) and let the imageMosaicJDBC do all these steps automatically. Project: GeoTools Priority: Minor Reporter: Daniele Romagnoli This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [jira] (GEOT-4507) Easiest way to setup imageMosaicJDBC-PGRaster
A few notes about this JIRA.
I would like to do something like this:
1) specify basic parameters (maybe as Hints or as a ConfigurationBean):
- tablename_prefix
- mosaic_table_name
- mosaic_name
- db properties (host, user, password, db, schema)
2) configure an ImageMosaicJDBC against a folder contained data prepared
with gdal_retile.
Automatic steps performed by new code:
i) insert each level using raster2pgsql into the proper
${tablename_prefix}_level table into the proper $db.$schema
ii) create a new ${mosaic_table_name} and insert new rows using
${mosaic_name} as value for the name column and previously created
tablename_prefix_level tables as values for tiletable column.
iii) create the XML file starting from a template and replace postgis
connection parameter entries, mastertable name entry, and coverage name.
iv) open the reader on top of the configuration.
About point #1, I would like to work with wickets to allow specifying these
parameters at configuration time when using it from GeoServer.
What do you think about it?
Cheers,
Daniele
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Daniele Romagnoli
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
---
On Wed, Jul 10, 2013 at 6:12 PM, Daniele Romagnoli (JIRA) j...@codehaus.org
wrote:
Daniele
Romagnolihttps://jira.codehaus.org/secure/ViewProfile.jspa?name=dany111created
[image:
Improvement] GEOT-4507 https://jira.codehaus.org/browse/GEOT-4507
*Easiest way to setup
imageMosaicJDBC-PGRaster*https://jira.codehaus.org/browse/GEOT-4507
*Issue Type:* [image: Improvement] Improvement *Assignee:*
Unassigned
*Components:* imagemosaic-jdbc plugin *Created:* 10/Jul/13 11:11 AM
*Description:*
Right now, in order to config an imageMosaic JDBC against PGRaster DB
there are several steps to be performed:
1) use gdal_retile to create tiles for images
2) insert tiled data as new table (one for level) into PGRaster using
raster2pgsql scripts invokation
3) create a table containing level information (reference table, envelope,
resolutions)
4) create 3 XML config files with JDBC mapping, coverage properties, table
mapping
5) configure the mosaic.
It would be good to have some automagic way to do steps 2 through 5 with
minimal user intervention.
As an instance, it would be great if we could just provide the location of
the folder containing tiled images (levels), as well as a set of some
additional parameters (table name prefix, mosaic name, coverage name, DB
credentials) and let the imageMosaicJDBC do all these steps automatically.
*Project:* GeoTools https://jira.codehaus.org/browse/GEOT *
Priority:* [image: Minor] Minor *Reporter:* Daniele
Romagnolihttps://jira.codehaus.org/secure/ViewProfile.jspa?name=dany111
This
message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] geopackage unsupported module
Hi all, Some folks may have heard of the geopackage spec that is currently being developed by the OGC. For those that haven't the short of it is that it is a SQLite based format capable of housing vector and raster datasets, as well as pre rendered tile sets (inspired by mbtiles). We've been working on an implementation for geotools and would like to push it in as an supported module. The code is currently on a branch in my github repo. https://github.com/jdeolive/geotools/compare/geopkg Some additional technical information about the implementation. It uses the same xerial sqlite driver we use for the spatialite datastore, although geopackage has no requirement for spatialite so we just use the base driver without any of the spatialite dependencies. For the vector support the module contains a datastore (jdbc based). The raster support is currently somewhat lame. In general i am not sure how useful the raster bits of the geopackage spec will be. It is actually an optional part of the spec but we implemented a rough initial version of it. Basically the format gives back a coverage reader for blobs stored in the database. It currently supports world images and geotiffs. The tile stuff is pretty straight forward and given a tile index the format will give back an image blob stored in the database, or given a range will give back an iterator. For those interested here is the latest version of the spec. https://dl.dropboxusercontent.com/u/1663985/12-128r7_OpenGIS_GeoPackage_Implementation_Specification_accept_changes.pdf -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] geopackage unsupported module
This is much more exciting then your low key delivery Justin :) So as a supported module we need to do the code review thing, check headers and code coverage, and I need one page of docs ( as small as a single code example you can inline in from a test case ). So what can I do? Vote +1 And check the headers once it is in. Can you round up volunteers for doc page and test coverage? -- Jody Garnett On 11/07/2013, at 3:19 AM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi all, Some folks may have heard of the geopackage spec that is currently being developed by the OGC. For those that haven't the short of it is that it is a SQLite based format capable of housing vector and raster datasets, as well as pre rendered tile sets (inspired by mbtiles). We've been working on an implementation for geotools and would like to push it in as an supported module. The code is currently on a branch in my github repo. https://github.com/jdeolive/geotools/compare/geopkg Some additional technical information about the implementation. It uses the same xerial sqlite driver we use for the spatialite datastore, although geopackage has no requirement for spatialite so we just use the base driver without any of the spatialite dependencies. For the vector support the module contains a datastore (jdbc based). The raster support is currently somewhat lame. In general i am not sure how useful the raster bits of the geopackage spec will be. It is actually an optional part of the spec but we implemented a rough initial version of it. Basically the format gives back a coverage reader for blobs stored in the database. It currently supports world images and geotiffs. The tile stuff is pretty straight forward and given a tile index the format will give back an image blob stored in the database, or given a range will give back an iterator. For those interested here is the latest version of the spec. https://dl.dropboxusercontent.com/u/1663985/12-128r7_OpenGIS_GeoPackage_Implementation_Specification_accept_changes.pdf -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] geopackage unsupported module
On Wed, Jul 10, 2013 at 3:33 PM, Jody Garnett jody.garn...@gmail.comwrote: This is much more exciting then your low key delivery Justin :) So as a supported module we need to do the code review thing, check headers and code coverage, and I need one page of docs ( as small as a single code example you can inline in from a test case ). I am asking for an unsupported module. So what can I do? Vote +1 And check the headers once it is in. Can you round up volunteers for doc page and test coverage? I was under the impression these were things typically worried about when one wants to push the module from unsupported into the main library. -- Jody Garnett On 11/07/2013, at 3:19 AM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi all, Some folks may have heard of the geopackage spec that is currently being developed by the OGC. For those that haven't the short of it is that it is a SQLite based format capable of housing vector and raster datasets, as well as pre rendered tile sets (inspired by mbtiles). We've been working on an implementation for geotools and would like to push it in as an supported module. The code is currently on a branch in my github repo. https://github.com/jdeolive/geotools/compare/geopkg Some additional technical information about the implementation. It uses the same xerial sqlite driver we use for the spatialite datastore, although geopackage has no requirement for spatialite so we just use the base driver without any of the spatialite dependencies. For the vector support the module contains a datastore (jdbc based). The raster support is currently somewhat lame. In general i am not sure how useful the raster bits of the geopackage spec will be. It is actually an optional part of the spec but we implemented a rough initial version of it. Basically the format gives back a coverage reader for blobs stored in the database. It currently supports world images and geotiffs. The tile stuff is pretty straight forward and given a tile index the format will give back an image blob stored in the database, or given a range will give back an iterator. For those interested here is the latest version of the spec. https://dl.dropboxusercontent.com/u/1663985/12-128r7_OpenGIS_GeoPackage_Implementation_Specification_accept_changes.pdf -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] geopackage unsupported module
Definitely should be unsupported, since the specification itself isn't even supported. Hopefully by end of September it'll be ratified - I've been going to most all the meetings, it's come along pretty nicely. And Justin helped a lot with this early coding of it. On Wed, Jul 10, 2013 at 5:52 PM, Justin Deoliveira jdeol...@opengeo.orgwrote: On Wed, Jul 10, 2013 at 3:33 PM, Jody Garnett jody.garn...@gmail.comwrote: This is much more exciting then your low key delivery Justin :) So as a supported module we need to do the code review thing, check headers and code coverage, and I need one page of docs ( as small as a single code example you can inline in from a test case ). I am asking for an unsupported module. So what can I do? Vote +1 And check the headers once it is in. Can you round up volunteers for doc page and test coverage? I was under the impression these were things typically worried about when one wants to push the module from unsupported into the main library. -- Jody Garnett On 11/07/2013, at 3:19 AM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi all, Some folks may have heard of the geopackage spec that is currently being developed by the OGC. For those that haven't the short of it is that it is a SQLite based format capable of housing vector and raster datasets, as well as pre rendered tile sets (inspired by mbtiles). We've been working on an implementation for geotools and would like to push it in as an supported module. The code is currently on a branch in my github repo. https://github.com/jdeolive/geotools/compare/geopkg Some additional technical information about the implementation. It uses the same xerial sqlite driver we use for the spatialite datastore, although geopackage has no requirement for spatialite so we just use the base driver without any of the spatialite dependencies. For the vector support the module contains a datastore (jdbc based). The raster support is currently somewhat lame. In general i am not sure how useful the raster bits of the geopackage spec will be. It is actually an optional part of the spec but we implemented a rough initial version of it. Basically the format gives back a coverage reader for blobs stored in the database. It currently supports world images and geotiffs. The tile stuff is pretty straight forward and given a tile index the format will give back an image blob stored in the database, or given a range will give back an iterator. For those interested here is the latest version of the spec. https://dl.dropboxusercontent.com/u/1663985/12-128r7_OpenGIS_GeoPackage_Implementation_Specification_accept_changes.pdf -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] geopackage unsupported module
We've been working on an implementation for geotools and would like to push it in as an supported module. The code is currently on a branch in my github repo. Sorry answering email before coffee, in that case a simple +1 will suffice! -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [ExternalEmail] GeoTools / GeoServer Meeting 2013-07-08
Thanks, Justin, i can confirm this failure. My bad (or rather, POSIX's perversity); the POSIX for is MDT+6 not MDT-6 (yes, hours west). (Aren't you in DST until November?) I can see all the failures you report with (POSIX): TZ=MDT+6 mvn -o -Dtest=TimeSeries*Test test and also with the positive-east Java system property: mvn -o -Duser.timezone=GMT-6 -Dtest=TimeSeries*Test test Kind regards, Ben. On 10/07/13 21:15, Justin Deoliveira wrote: Here is the bug report. https://jira.codehaus.org/browse/GEOS-5884 On Mon, Jul 8, 2013 at 9:07 PM, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote: Justin, I am building in an environment with export TZ=MDT-6 to see if I can replicate the failures you reported. Please report bugs for any failures you find. No developer should have to change their timezone to get tests to pass! Here are the awful hacks required to get PostGIS tests to work in Western Australia: https://www.seegrid.csiro.au/__wiki/Infosrvices/__JenkinsGeoserverMasterTechnica__lNotes#PostGIS_timezone_fix___for_Western_Australia https://www.seegrid.csiro.au/wiki/Infosrvices/JenkinsGeoserverMasterTechnicalNotes#PostGIS_timezone_fix_for_Western_Australia Kind regards, Ben. On 08/07/13 21:36, ben.caradoc-dav...@csiro.au wrote: - Time sensitive tests? Bleck - ACTION: Justin to complain bitterly -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
