Deegree Server does not like BBOX parameter
---
Key: GEOT-1856
URL: http://jira.codehaus.org/browse/GEOT-1856
Project: GeoTools
Issue Type: Bug
Components: data wfs
Affects Versions: 2.5-
2.4 is over and done; it is limited to Java 1.4.
Jody
> I too had the problem on geotools 2.4, not on trunk. (Using Java 1.5)
>
> Its in a hardcoded unit test, so the developer has no way of "sorting"
> anything - it simply needs to pass reliably :-0
>
> what is the officieal position on what ver
I too had the problem on geotools 2.4, not on trunk. (Using Java 1.5)
Its in a hardcoded unit test, so the developer has no way of "sorting"
anything - it simply needs to pass reliably :-0
what is the officieal position on what versions of java work for 2.4? Is it
limited to 1.4 still?
RA
On T
I had problems with this as well recently; I seem to recall that the
instance of DatatypeConverter changes if you are using Java 6? Are you
using Java 6?
I placed try/catch code around this section of code but Justin did not
accept my patch ...
Java used to let us get away with not having a nam
Its look like that there is not much more than import statements after all (I
was wrong about the Converter change; at a first look it doesn't seem to have
any except name change). So I would like to call for a vote:
http://docs.codehaus.org/display/GEOTOOLS/Switch+from+JSR-108+to+JSR-275+for+Un
Jody Garnett a écrit :
>> There is one additional change related to Converter. I will document
>> it in this page when I will make this change in GeoTools. Since I
>> don't think that many use Converter directly, it will probably impact
>> few peoples.
> Can you document it now? Ie the point of
I have narrowed this problem down to one line of code in the
XSQNameBinding.java file. For some reason if the variable 'value' does not
start with "foo" then the code crashes when the QName is initialized. Can
someone please assist me with this. I have pasted the function with the
crashing line
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> Martin I wrote a quick proposal based on your JSR-275 email; can you
>> look it over; make any corrections needed and then call a vote?
>> -
>> http://docs.codehaus.org/display/GEOTOOLS/Switch+from+JSR-108+to+JSR-275+for+Units
>>
>>
>>
>> S
Both this week and last week we have been trying to nail down the
release timeline for GeoTools 2.5.x. First of all this release
represents one of the largest chunks of work since GeoTools 2.0 and
everyone should be congratulated. New feature model; move to Java 5; the
list goes on ...
In both
Jody Garnett a écrit :
> Martin I wrote a quick proposal based on your JSR-275 email; can you
> look it over; make any corrections needed and then call a vote?
> -
> http://docs.codehaus.org/display/GEOTOOLS/Switch+from+JSR-108+to+JSR-275+for+Units
>
> So far the minimal change I could see is to
Martin I wrote a quick proposal based on your JSR-275 email; can you
look it over; make any corrections needed and then call a vote?
-
http://docs.codehaus.org/display/GEOTOOLS/Switch+from+JSR-108+to+JSR-275+for+Units
So far the minimal change I could see is to the dependency; and changing
of a
Jody Garnett wrote:
>> 75% of the case we have a single band raster when we want to use the
>> categorize function. So rasterData is fine. It just looks like they
>> have forgotten the 25% left. Or perhaps they assume we choose a single
>> band in the selectedChannel. that's possible too. If tha
johann sorel wrote:
>>> What is a problem ? This :
>>> lookupExpression.evaluate(object, classType);
>>>
>>> --> First problem :
>>> The lookupExpression have the value "rasterData",
>>> This is non sens because a raster is composed of several bands,
>>> lookupExpression should have a value like :
13 matches
Mail list logo
