Simone Giannecchini wrote:
> +0, not because I am against, but because I have not personally had
> any interaction with him and his group, while I have been able to
> follow the progresses they have made.
Yes you have, I bagged you for breaking the build (in coverage). ;-)
--
Ben Caradoc-Davies
A couple of comments
- Having an interface to allow geotools to look up something in the
geoserver catalog is the he point of the repository interface. So if
geoserver has changed we need to ensure this interface is updated so
geotools code can hook into it.
- I do not really want the repository in
Hi Landon,
you talked with Simone :)
On Wed, May 13, 2009 at 5:18 PM, Sunburned Surveyor <
sunburned.surve...@gmail.com> wrote:
> Someone on the OSGeo discuss list pointed out that Geotools has
> support for ECW images in a round-about way. I have been taking a look
> at the Javadoc and had a q
Someone on the OSGeo discuss list pointed out that Geotools has
support for ECW images in a round-about way. I have been taking a look
at the Javadoc and had a question or two.
- I see that I can use the ECWReader to obtain a GridCoverage2D
object. I didn't see a way to immediately pass a GridCove
+0, not because I am against, but because I have not personally had
any interaction with him and his group, while I have been able to
follow the progresses they have made.
Simone.
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software
Christian Müller ha scritto:
> I wanted to use the org.geotools.data.Repository (life would be easier) but
> this would not work for geoserver.
Wondering if it's not possible to make a GeoServer plugin that wraps
the GeoServer catalog into a Repository interface?
Cheers
Andrea
--
Andrea Aime
O
I wanted to use the org.geotools.data.Repository (life would be easier) but
this would not work for geoserver.
So I introduced the DataStoreLookup interface.
I did a special implementation for the geoserver catalog, look here. Perhaps
we have to do something similar for UDIG.
https://svn.cod
Hi Simone,
2009/5/13 Simone Giannecchini wrote:
> modules/library/coverage none sg: I can take it, maybe mb wants to
> help out
I am working with the coverage classes quite a lot in my own projects
and (soon I hope) on the 2.6.x_jaitools branch. So, yes, I'd be happy
to help you with
> Out of curiosity, what prevents you to use the maven-ant-task
> based on 2.0.10 series?
I have downloaded it and will give it a go.
> I would believe you use maven-ant-task
> only if your primary build enviroment is Ant anyways?
uDig has a script that uses maven-ant-tasks to download geotools
Ciao all,
just finished editing the document. Here is a summary:
Module Current/Proposed maintaner Notes, suggested action
modules/library/api jgarnettsg: am I the only one who thinks that
this should kill geoapi?
modules/library/coverage nonesg: I can take it, mayb
You can do it as in this example I think...
http://www.mail-archive.com/us...@maven.apache.org/msg66139.html
Michael
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environm
Christian Müller ha scritto:
> I have to set some system properties for new junit test in jdbc-ng.
>
> 1)
> Trying to use
> System.setProperty("java.naming.factory.initial",
> "org.osjava.sj.SimpleContextFactory")
>
> in the test case works within eclispe, but NOT with a "mvn clean install".
I have to set some system properties for new junit test in jdbc-ng.
1)
Trying to use
System.setProperty("java.naming.factory.initial",
"org.osjava.sj.SimpleContextFactory")
in the test case works within eclispe, but NOT with a "mvn clean install".
2)
mvn -Djava.naming.factory.initial=org.os
13 matches
Mail list logo
