[Geotools-devel] Rendering slow due to FidFilterImpl
Hi. In the context of gvtools, we have a basic viewer with selection capabilities. We have followed this approach[1] to manage selection and as long as there is no selection (empty SetFeatureId), rendering is ok. However, the bigger the SetFeatureId holding the selection is, the slower the rendering goes. I've identified the problem in FidFilterImpl class which checks if a FeatureId is contained in the set of Identifiers by iterating through all the elements in the set instead of using the Set.contains method, which is much faster typically. Is it a known issue or should I provide some code to reproduce the behaviour easily? The attached patch (just for testing) makes use of Set.contains and works much faster. Quite probably there is a reason why Set.contains is not used. For example, the patch instantiates a FeatureId, while the FidFilterImpl works with Identifier interface. I wonder if instead of a HashSet it could be possible to use a TreeSet with a comparator that is independent of the concrete implementation of Identifier. Do you think this development would be possible/worth? Is there any better approach to manage selection rendering? Best regards. [1] http://docs.geotools.org/latest/userguide/tutorial/map/style.html#creating-a-style-based-on-the-selection fid-filter.patch Description: Binary data -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] (GEOT-4344) Separate general complex feature classes from gt-app-schema
Niels Charlier created GEOT-4344 Separate general complex feature classes from gt-app-schema Issue Type: Task Assignee: Niels Charlier Components: app-schema plugin Created: 11/Dec/12 5:12 AM Description: The idea is to split the app-schema module in two: The first part would contain everything that helps with complex features in general: building them, evaluating filters against them (property accessor, x-path evaluation), building complex feature types from XSD. These classes do not rely on specific schemes like GML, etc... apart form XS. The second part will contain anything that is app-schema specific: creating complex feature datastores with mapping files. The second part would continue as the gt-app-schema module. The first part would split off and become a new module 'gt-complex. gt-complex should get its own page in the GeoTools User Documentation. Project: GeoTools Priority: Major Reporter: Niels Charlier 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 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
The Proposal: http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema Please vote, or provide criticism. Kind Regards Niels Charlier -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [Hudson] Build failed in Hudson: geotools-master-docs #1850
See http://hudson.opengeo.org/hudson/job/geotools-master-docs/1850/
--
Started by upstream project geotools-master build number 4651
[INFO] Using Maven 3 installation: maven-3.0.4
[INFO] Checking Maven 3 installation environment
[workspace] $ /opt/apache-maven-3.0.4/bin/mvn --help
[INFO] Checking Maven 3 installation version
[INFO] Detected Maven 3 installation version: 3.0.4
[workspace] $ /opt/apache-maven-3.0.4/bin/mvn clean install -V -B
-Dmaven.ext.class.path=/var/lib/hudson/maven/slavebundle/resources:/var/lib/hudson/maven/slavebundle/lib/maven3-eventspy-3.0.jar:/var/lib/jetty/webapps/hudson/WEB-INF/lib/hudson-remoting-2.2.0.jar
-Dhudson.eventspy.port=42767 -f docs/pom.xml
[DEBUG] Waiting for connection on port: 42767
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+)
Maven home: /opt/apache-maven-3.0.4
Java version: 1.6.0_21, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-sun-1.6.0.21_i586/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 2.6.32-11-pve, arch: i386, family: unix
[DEBUG] Connected to remote
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.geotools:docs:jar:9-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-resources-plugin is missing. @
org.geotools:geotools:9-SNAPSHOT,
http://hudson.opengeo.org/hudson/job/geotools-master-docs/ws/pom.xml, line
1167, column 15
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-compiler-plugin is missing. @
org.geotools:geotools:9-SNAPSHOT,
http://hudson.opengeo.org/hudson/job/geotools-master-docs/ws/pom.xml, line
1144, column 15
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-surefire-plugin is missing. @
org.geotools:geotools:9-SNAPSHOT,
http://hudson.opengeo.org/hudson/job/geotools-master-docs/ws/pom.xml, line
1198, column 15
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-source-plugin is missing. @
org.geotools:geotools:9-SNAPSHOT,
http://hudson.opengeo.org/hudson/job/geotools-master-docs/ws/pom.xml, line
1255, column 15
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-jar-plugin is missing. @
org.geotools:geotools:9-SNAPSHOT,
http://hudson.opengeo.org/hudson/job/geotools-master-docs/ws/pom.xml, line
1233, column 15
[WARNING] The expression ${build.directory} is deprecated. Please use
${project.build.directory} instead.
[WARNING] 'reporting.plugins.plugin.version' for
org.apache.maven.plugins:maven-project-info-reports-plugin is missing. @
org.geotools:geotools:9-SNAPSHOT,
http://hudson.opengeo.org/hudson/job/geotools-master-docs/ws/pom.xml, line
1338, column 15
[WARNING] 'reporting.plugins.plugin.version' for
org.apache.maven.plugins:maven-jxr-plugin is missing. @
org.geotools:geotools:9-SNAPSHOT,
http://hudson.opengeo.org/hudson/job/geotools-master-docs/ws/pom.xml, line
1363, column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]
[INFO]
[INFO] Building GeoTools Documentation 9-SNAPSHOT
[INFO]
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/org/apache/maven/plugins/maven-source-plugin/maven-metadata.xml
Downloading:
http://repo.opengeo.org/org/geotools/geotools/9-SNAPSHOT/geotools-9-20121211.121527-326.pom
Downloading:
http://download.java.net/maven/2/org/geotools/gt-image/9-SNAPSHOT/gt-image-9-20121211.121742-323.pom
Downloading:
http://maven.geo-solutions.it/org/geotools/gt-image/9-SNAPSHOT/gt-image-9-20121211.121742-323.pom
Downloading:
http://download.osgeo.org/webdav/geotools/org/geotools/gt-image/9-SNAPSHOT/gt-image-9-20121211.121742-323.pom
Downloading:
http://repo.opengeo.org/org/geotools/gt-image/9-SNAPSHOT/gt-image-9-20121211.121742-323.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1:05.014s
[INFO] Finished at: Tue Dec 11 12:20:34 UTC 2012
[INFO] Final Memory: 5M/74M
[INFO]
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
on project docs: Could not resolve dependencies for project
org.geotools:docs:jar:9-SNAPSHOT: Failed to collect dependencies for
[Geotools-devel] [Hudson] Hudson build is back to normal : geotools-master-docs #1851
See http://hudson.opengeo.org/hudson/job/geotools-master-docs/1851/ -- This message is automatically generated by Hudson. For more information on Hudson, see: http://hudson-ci.org/ -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Contribution Agreement Clarity
Folks, I have been seeking to have Google sign a corporate CLA to cover contributions to the GeoTools projects so we could feed back a few existing improvements, and some future potential improvements. During internal review of the CLA we have encountered some concerns from our legal staff. From our legal representative: Google is not willing to sign the agreement as it currently stands due to how the project is currently defined in the agreement. The agreement states 'The Project is the collaborative effort known as the Geotools Project, currently described at http://www.geotools.org which initially aims to design and create an open source Java language library for the management and analysis of spatial, geographic data.' This does not actually define anything in particular, rather it seems amorphous thing that apparently can be changed (since it's only currently described). It's completely ambiguous what this is (a legal entity, a piece of software, etc). In turn, this makes it completely indefinite what terms such as solely as part of the Geotools Project mean in the patent grant, and what except where exercise of rights in the Contribution as part of the Geotools Project is not feasible without such modification or combination. means in the definition of 'licensed patents'. If these were tied to a particular software project, we'd be willing to sign it. I'm going to seek an internal suggestion of a change to the text, but I wanted to raise the issue here and get a sense of whether others have encountered similar issues and if there is any appetite for changes to the CLA. For reference, I am pursuing this matter as a Google employee. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Contribution Agreement Clarity
Thanks for contacting us Frank, we have not had any feedback to this effect previously. I am sure we can tightening up the language in the CLA, and could issue a new version of the document following our usual change procedure. Our project is open allowing you to assemble a proposal to change the wording (as outlined in the developers guide). You do not have to be a member of the project steering committee to make a proposal. This would also give your legal department something to review prior to us issuing a new copy of the document. In this particular case we will need to assemble a document, and then pass it to the OSGeo board for final approval (as OSGeo is the legal entity effected). IDEAS If we stole some of the language from here (http://geotools.org/about.html) ( or here (http://docs.geotools.org/latest/userguide/geotools.html) ) would it be appropriate? Or even just GeoTools is an open source Java library that provides tools for geospatial data. from our website. The reason the scope of our project is left open is to allow for growth. Some avenues for growth that are requested on the email list are: - Command line access to GeoTools functionality, especially recent process work - Improved demo gt-swing application showcasing GeoTools functionality Both of these directions go a bit beyond just a Java toolkit for spatial data, as in fact do the number of client implementations (wfs, wms, wps) included currently. -- Jody Garnett On Wednesday, 12 December 2012 at 3:18 AM, Frank Warmerdam wrote: Folks, I have been seeking to have Google sign a corporate CLA to cover contributions to the GeoTools projects so we could feed back a few existing improvements, and some future potential improvements. During internal review of the CLA we have encountered some concerns from our legal staff. From our legal representative: Google is not willing to sign the agreement as it currently stands due to how the project is currently defined in the agreement. The agreement states 'The Project is the collaborative effort known as the Geotools Project, currently described at http://www.geotools.org which initially aims to design and create an open source Java language library for the management and analysis of spatial, geographic data.' This does not actually define anything in particular, rather it seems amorphous thing that apparently can be changed (since it's only currently described). It's completely ambiguous what this is (a legal entity, a piece of software, etc). In turn, this makes it completely indefinite what terms such as solely as part of the Geotools Project mean in the patent grant, and what except where exercise of rights in the Contribution as part of the Geotools Project is not feasible without such modification or combination. means in the definition of 'licensed patents'. If these were tied to a particular software project, we'd be willing to sign it. I'm going to seek an internal suggestion of a change to the text, but I wanted to raise the issue here and get a sense of whether others have encountered similar issues and if there is any appetite for changes to the CLA. For reference, I am pursuing this matter as a Google employee. Best regards,-- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com (mailto:warmer...@pobox.com) light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net (mailto:GeoTools-Devel@lists.sourceforge.net) https://lists.sourceforge.net/lists/listinfo/geotools-devel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Contribution Agreement Clarity
On 12 December 2012 09:06, Jody Garnett jody.garn...@gmail.com wrote: If we stole some of the language from here ( or here ) would it be appropriate? Or even just GeoTools is an open source Java library that provides tools for geospatial data. from our website. The reason the scope of our project is left open is to allow for growth. Some avenues for growth that are requested on the email list are: - Command line access to GeoTools functionality, especially recent process work - Improved demo gt-swing application showcasing GeoTools functionality Both of these directions go a bit beyond just a Java toolkit for spatial data, as in fact do the number of client implementations (wfs, wms, wps) included currently. Hi Jody, Change library to framework in your suggested sentence and I think most people would see those items as falling easily within it. Michael -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Contribution Agreement Clarity
Good idea. I also like our traditional 'toolkit' wording. Perhaps we should ask Frank to provide an example of a project wording google is comfortable with? (This after all an agreement which wants to be specific - rather than a project tag line) We could get all technical and discuss project boundaries in terms of API, standards and so on. -- Jody Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, 12 December 2012 at 8:53 AM, Michael Bedward wrote: On 12 December 2012 09:06, Jody Garnett jody.garn...@gmail.com wrote: If we stole some of the language from here ( or here ) would it be appropriate? Or even just GeoTools is an open source Java library that provides tools for geospatial data. from our website. The reason the scope of our project is left open is to allow for growth. Some avenues for growth that are requested on the email list are: - Command line access to GeoTools functionality, especially recent process work - Improved demo gt-swing application showcasing GeoTools functionality Both of these directions go a bit beyond just a Java toolkit for spatial data, as in fact do the number of client implementations (wfs, wms, wps) included currently. Hi Jody, Change library to framework in your suggested sentence and I think most people would see those items as falling easily within it. Michael -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Rendering slow due to FidFilterImpl
Thanks for the investigation. Report the issue with patch test case. Or via pull request and we should be good to go. In many cases functionality such as this was tested with small data sets for completeness / correctness and can be revisited now that we work with larger datasets and an interactive setting. For most data stores we expect them to handle this natively based in an index - what datastore were you testing with ? -- Jody On Tuesday, 11 December 2012 at 6:59 PM, Fernando González wrote: Hi. In the context of gvtools, we have a basic viewer with selection capabilities. We have followed this approach[1] to manage selection and as long as there is no selection (empty SetFeatureId), rendering is ok. However, the bigger the SetFeatureId holding the selection is, the slower the rendering goes. I've identified the problem in FidFilterImpl class which checks if a FeatureId is contained in the set of Identifiers by iterating through all the elements in the set instead of using the Set.contains method, which is much faster typically. Is it a known issue or should I provide some code to reproduce the behaviour easily? The attached patch (just for testing) makes use of Set.contains and works much faster. Quite probably there is a reason why Set.contains is not used. For example, the patch instantiates a FeatureId, while the FidFilterImpl works with Identifier interface. I wonder if instead of a HashSet it could be possible to use a TreeSet with a comparator that is independent of the concrete implementation of Identifier. Do you think this development would be possible/worth? Is there any better approach to manage selection rendering? Best regards. [1] http://docs.geotools.org/latest/userguide/tutorial/map/style.html#creating-a-style-based-on-the-selection -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel Attachments: - fid-filter.patch -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] proposal: Separate general complex feature classes from gt-app-schema
+1. This change is long overdue and much needed. I have asked Rini and Adam to review the proposal. gt-app-schema changes should go for review to Rini as component lead. Kind regards, Ben. On 11/12/12 19:15, Niels Charlier wrote: The Proposal: http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema Please vote, or provide criticism. Kind Regards Niels Charlier -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Contribution Agreement Clarity
We could even say software as well. Should we drop Java? There might be Python, Javascript, and Scala bits, and more in the future. The Java bit is descriptive, but not definitive. We could go crazy and rewrite it in another language, like a future version of Java (I think you know who I am talking about). :-P GeoTools open source geospatial software toolkit, perhaps? Framework is a bit too generic in my opinion. I think we need to include the word software to make it clear that we are not talking about a physical thing, which I think, from my reading of Frank's email, is Google's concern. Kind regards, -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Contribution Agreement Clarity
On 12 December 2012 12:36, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au wrote: Framework is a bit too generic in my opinion. I think we need to include the word software to make it clear that we are not talking about a physical thing, which I think, from my reading of Frank's email, is Google's concern. I read their concern as being that the current wording was so open it was asking them to sign up to an undefined and possibly moving target. Probably any of software or toolkit or framework or library and utilities etc. would be an improvement. I wouldn't drop Java from the description. I like the JTS model: a reference implementation in Java with ports to other languages managed as separate projects. Seems more agile :) Michael -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Contribution Agreement Clarity
On 12/12/12 10:59, Michael Bedward wrote: I read their concern as being that the current wording was so open it was asking them to sign up to an undefined and possibly moving target. Probably any of software or toolkit or framework or library and utilities etc. would be an improvement. I wouldn't drop Java from the description. I like the JTS model: a reference implementation in Java with ports to other languages managed as separate projects. Seems more agile :) If we kept the Java part, would patent grants extend to other languages? -- Ben Caradoc-Davies ben.caradoc-dav...@csiro.au Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
