Hi all,
I have been working my way through the release and all is going
relatively well. I hit a snitch when trying to generate javadocs.
Nothing seems to generate. I tried grepping for errors in the javadoc
logs but to no avail. I thought it might be a mac issue but i also tried
on windows an
Martin Desruisseaux wrote:
> Justin Deoliveira a écrit :
>
>> Doing the 2.5.0 release i ran into a minor issue with the newly added
>> imagemosaic-jdbc module. It depends on gt-coverageio which is
>> unsupported. So to include it in the release we would have to include
>> coverageio... which
Justin Deoliveira a écrit :
> * remove references to coverageio in the javadocs ... (not sure how hard
> this one will be)
Adding "org.geotools.coverage.io:*org.geotools.image.io*" in the (or
something similar) section of the javadoc configuration in pom.xml should be
suffisient. I'm not sure
Good news! With the help of Simone it appears that the coverageio
dependency is actually not needed. So simply removing it does the trick
nicely.
Justin Deoliveira wrote:
> Hi Martin,
>
> Thanks for clarifying. So I think long term we should upgrade the parts
> coverageio that are used to supp
Hi Martin,
Thanks for clarifying. So I think long term we should upgrade the parts
coverageio that are used to supported... given that they are relatively
static.
However I think for the short term relaxing our policy about including
"private" modules in the build is a compromise for a few re
Justin Deoliveira a écrit :
> Doing the 2.5.0 release i ran into a minor issue with the newly added
> imagemosaic-jdbc module. It depends on gt-coverageio which is
> unsupported. So to include it in the release we would have to include
> coverageio... which goes against our plan of excluding uns
Hi all,
Doing the 2.5.0 release i ran into a minor issue with the newly added
imagemosaic-jdbc module. It depends on gt-coverageio which is
unsupported. So to include it in the release we would have to include
coverageio... which goes against our plan of excluding unsupported modules.
So... tw
Mauricio Pazos wrote:
> Hi
> I am working to extend cql. Now it parses bbox sentences like:
>
> BBOX(the_geom, 10.0, 20.0, 30.0, 40.0)
>
> The idea is extend it to allow to write a sentence like
>
> BBOX(buffer( the_geom , 10), 10.0, 20.0, 30.0, 40.0)
>
> The FilterFactory2 has bbox(Expression,
Hi
I am working to extend cql. Now it parses bbox sentences like:
BBOX(the_geom, 10.0, 20.0, 30.0, 40.0)
The idea is extend it to allow to write a sentence like
BBOX(buffer( the_geom , 10), 10.0, 20.0, 30.0, 40.0)
The FilterFactory2 has bbox(Expression, double, )
That signature is enoug
Hi Gabriel,
It seems in the Temporal Schema ISO 19108 doc that we have the following
Values for relative positions
(for the case if both TM_Primitive are TM_Instants)
the operation shall return a value for TM_RelativePosition as follows:
Returns : if:
BEFORE
Hello Gabriel
Gabriel Roldan a écrit :
> I found what I guess is a bug in the temporal module but I'm not sure if
> it actually is or it just seems counter intuitive to me but its correct.
> The thing is with the compareTo implementation in
> DefaultTemporalPrimitive, which seems to return inver
11 matches
Mail list logo
