Mauricio Pazos wrote:
> On Wednesday 04 June 2008 21:32:56 Adrian Custer wrote:
>
>> Also there are two files
>> /modules/library/main/modified-src/org/geotools/filter/parser/Node.java
>> modules/library/main/modified-src/org/geotools/filter/parser/SimpleNode.jav
>> a with no header but with a f
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/669/changes
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforg
On Wednesday 04 June 2008 21:32:56 Adrian Custer wrote:
> Also there are two files
> /modules/library/main/modified-src/org/geotools/filter/parser/Node.java
> modules/library/main/modified-src/org/geotools/filter/parser/SimpleNode.jav
>a with no header but with a first line that is apparently suppo
Hey all,
A heads up and some questions.
We are starting in on the header work in earnest. Tonight I just
committed a bunch of cleanup to help the script do its work. Tomorrow we
will probably start in on the core library in earnest running the script
initially against metadata and referencing and
On Wed, Jun 4, 2008 at 5:53 PM, Simone Giannecchini <[EMAIL PROTECTED]>
wrote:
> On Wed, Jun 4, 2008 at 5:38 PM, Martin Desruisseaux
> <[EMAIL PROTECTED]> wrote:
> > So:
> >
> > * We have seen a dependency toward "imageio-ext" and assumed that
> > it was about GDAL bindings. We were wrong, there
On Wed, Jun 4, 2008 at 5:38 PM, Martin Desruisseaux
<[EMAIL PROTECTED]> wrote:
> So:
>
> * We have seen a dependency toward "imageio-ext" and assumed that
> it was about GDAL bindings. We were wrong, there is no dependency
> toward GDAL, sorry about that.
>
> * We still have this dependency towar
So:
* We have seen a dependency toward "imageio-ext" and assumed that
it was about GDAL bindings. We were wrong, there is no dependency
toward GDAL, sorry about that.
* We still have this dependency toward "imageio-ext" in a library
module. Its scope will be changed to "test", thanks.
*
To clarify once again:
- the grid coverage renderer code does NOT depend in anyway on the
arcgrid module, I just use the arcgrid reader to load some test data
when testing the colormap creation -
Now if you are getting so nervous about this, we can load the
test-data in a different way, we'll op
Daniele Romagnoli a écrit :
> +- it.geosolutions.imageio-ext:imageio-ext-arcgrid:jar:1.0-SNAPSHOT:compile
> | \-
> it.geosolutions.imageio-ext:imageio-ext-customstreams:jar:1.0-SNAPSHOT:compile
Yes you are right this is a dependency to the "arcgrid" module of "imageio-ext"
only, not the GDAL mo
imageio-ext dependency in render module should be a test dependency instead of
having compile scope
---
Key: GEOT-1842
URL: http://jira.codehaus.org/browse/GEOT-1842
Andrea Aime a écrit :
>> ReferencedEnvelope reference(ReferencedEnvelope)
>
> Yep, it is a sort of a copy constructor, but with a check for null
> before doing so.
Renaming it as "copy(ReferencedEnvelope)" would make its intend clear and avoid
confusion with other "reference" methods, which are
Martin Desruisseaux ha scritto:
> Andrea Aime a écrit :
>> This is a bug in the dependencies of the renderer module that has to be
>> fixed, but suggesting the removal of the gdal based module from GeoTools
>> as a cure is an exageration. The deps must be fixed instead.
>
> Yes I agree. If the sug
Hello all,
On Wed, Jun 4, 2008 at 3:09 PM, Simone Giannecchini <[EMAIL PROTECTED]>
wrote:
> On Wed, Jun 4, 2008 at 2:51 PM, Martin Desruisseaux
> <[EMAIL PROTECTED]> wrote:
> > Hello all
> >
> > Just to brings my 2 cents. We have see with the "JAXB in metadata" topic
> > that managing dependencie
Martin Desruisseaux ha scritto:
> I had a look (by accident) to ReferencedEnvelope. I noticed 3 "reference"
> methods, which are inconsistent with each other:
>
> ReferencedEnvelope reference(ReferencedEnvelope)
>
> Had no documentation, but lookin
Andrea Aime a écrit :
> This is a bug in the dependencies of the renderer module that has to be
> fixed, but suggesting the removal of the gdal based module from GeoTools
> as a cure is an exageration. The deps must be fixed instead.
Yes I agree. If the suggested cure was the complete removal of G
On Wed, Jun 4, 2008 at 2:51 PM, Martin Desruisseaux
<[EMAIL PROTECTED]> wrote:
> Hello all
>
> Just to brings my 2 cents. We have see with the "JAXB in metadata" topic
> that managing dependencies is not an easy task, and we are still looking for
> a solution to this JAXB issue (I have some idea al
Martin Desruisseaux ha scritto:
> Hello all
>
> Just to brings my 2 cents. We have see with the "JAXB in metadata" topic that
> managing dependencies is not an easy task, and we are still looking for a
> solution to this JAXB issue (I have some idea along the line of splitting the
> GeoTools pr
Hello all
Just to brings my 2 cents. We have see with the "JAXB in metadata" topic that
managing dependencies is not an easy task, and we are still looking for a
solution to this JAXB issue (I have some idea along the line of splitting the
GeoTools project is a number of sub-projects).
If I'm
Saul Farber ha scritto:
> Hey gabriel, jody (and others interested in the arcsde datastore!)
>
> I've been working through a local fire here on my end with a partially
> successful upgrade from sde 9.1 to sde 9.2, and I've run into a few
> weirdnesses with the latest geoserver 1.6.x (geotools 2.
johann sorel ha scritto:
> We raise this issue because we are working as you know on a new Java2D
> renderer.
> This one depends on the render module but not on imageio-ext. We believe
> there is a need to create
> a render module independent so that multiple renderers may use it.
I agree on th
On Wed, Jun 4, 2008 at 1:07 PM, johann sorel <[EMAIL PROTECTED]> wrote:
> Hello,
>
>
> We would like to start a discussion around JNI.
>
we == who?
> As you have seen in the past months some work has be done on GDAL.
> This work is great and can be useful to handle more raster formats, but
> the
Hello,
We would like to start a discussion around JNI.
As you have seen in the past months some work has be done on GDAL.
This work is great and can be useful to handle more raster formats, but
the problem is that GeoTools is getting tightly linked to those JNI
classes.
It seem's that the app
I had a look (by accident) to ReferencedEnvelope. I noticed 3 "reference"
methods, which are inconsistent with each other:
ReferencedEnvelope reference(ReferencedEnvelope)
Had no documentation, but looking at the code it the create a new instance o
hello,
The go module is out of the build for a few weeks (perhaps months).
Most of the modules in unsupported are pending or archive.
Is there any recent changes that need this kind of action ?
Could you give us more reasons ?
Jody Garnett a écrit :
> My turn for a rant (see Saul I learn from
24 matches
Mail list logo
