I had a chance to go over the trunk set up instructions
(http://udig.refractions.net/confluence/display/ADMIN/Home) with a
customer today ..
And I got to learn first hand:
- how useful those next/previous links are
- that tracking geotools trunk *is* unstable :-D (stylevistior has some
new meth
Hi all,
I have a few issues with this patch which is supposed to address
performance with filters.
1) It causes floating point strings to be truncated to an integer. The
following simple test case illustrates:
Literal l = ff.literal("0.1");
Object o = l.evaluate(null);
assertEquals( "0.1", o.t
Please my SpellingCheckerDoesNotCheckCamelCase.
Jody
Gabriel Roldán wrote:
> Hi,
>
> note the typo in the class name SpatialCapabiltiesImpl (missing "i").
>
> afaik its a trunk only class by now. Should we just rename it or
> new->delegate->deprecate?
>
> Gabriel
>
> -
Jody Garnett ha scritto:
> Andrea Aime wrote:
>>> Sounds like that was not a complete patch then ...
>> Not at all, that's why I'm complaining in the first place
> Me 2. So what do we do ... I am a module maintainer on main and I need
> to see the copy style visitor fixed (because *so* much extend
Andrea Aime wrote:
>> Sounds like that was not a complete patch then ...
> Not at all, that's why I'm complaining in the first place
Me 2. So what do we do ... I am a module maintainer on main and I need
to see the copy style visitor fixed (because *so* much extends it).
Sounds like we need a lis
Jody Garnett ha scritto:
>
>>> Oh I see; so has the style duplicating visitor(s) been fixed up as
>>> part of GeoTools? I often extend those (and override a few specific
>>> methods in order to perform a "transform" of the origional style)...
>> Nope, it has not been fixed, as I stated in my fir
>> Oh I see; so has the style duplicating visitor(s) been fixed up as
>> part of GeoTools? I often extend those (and override a few specific
>> methods in order to perform a "transform" of the origional style)...
> Nope, it has not been fixed, as I stated in my first mail, the
> compiler has bee
Jody Garnett ha scritto:
> Andrea Aime wrote:
>>> This will be a problem we have whenever we upgrade our code to a new
>>> specification (or in this case meet the existing one). We would be
>>> better advised to have StyleVistior implemented as an abstract class;
>>> or at the very least have im
Hi,
note the typo in the class name SpatialCapabiltiesImpl (missing "i").
afaik its a trunk only class by now. Should we just rename it or
new->delegate->deprecate?
Gabriel
-
This SF.net email is sponsored by the 2008 Java
Andrea Aime wrote:
>> This will be a problem we have whenever we upgrade our code to a new
>> specification (or in this case meet the existing one). We would be
>> better advised to have StyleVistior implemented as an abstract class;
>> or at the very least have implementations get in the habit
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> I'm not complaining about the API change per se btw, this
>> seems to be covered by the raster symbolizer proposal already
>> (the new visits are there to allow visitors to handle the
>> raster symbolizer components that were missing, a necessary
>>
Andrea Aime wrote:
> I'm not complaining about the API change per se btw, this
> seems to be covered by the raster symbolizer proposal already
> (the new visits are there to allow visitors to handle the
> raster symbolizer components that were missing, a necessary
> change in order to make raster s
Update of ArcSDE layers does not work
-
Key: GEOT-1790
URL: http://jira.codehaus.org/browse/GEOT-1790
Project: GeoTools
Issue Type: Bug
Components: data arcsde
Affects Versions: 2.4.2
Hi Theodor,
I think there would be interest in having this utility in geotools
definitely. Unfortunately XSD is hard to get decent error messages out
of when you make a mistake. If you post a test case somewhere which
illustrates the issue I would be happy to look at it.
-Justin
Theodor Foers
Hi,
Some might have noticed, that I am currently trying to get something
running, which produces a XSDSchema document based on a GT featureType.
I adopted some parts of the geoserver implementation
org.geoserver.wfs.xml.FeatureTypeSchema. Unfortunately, I get only a
null Document back from the crea
On Saturday 26 April 2008 01:58:16 am Jody Garnett wrote:
> I have been a bit puzzled by some of the test failures, specifically
> FilterTest.testBBoxFilter.
and note FilterTest is out of the build, it was wrote by the guys that donated
the transaction support and was made against that custom lay
Hi,
since a few days the GeoServer build is broken due to a compile
problem. The compile problem originates in an API change in the
StyleVisitor interface.
I looked into it. GeoTools has many many of such visitors,
various of them used for things as style attribute extraction
or style duplication.
StyleVisitor API changes must be notified in the "upgrade to 2.5.x" page
Key: GEOT-1789
URL: http://jira.codehaus.org/browse/GEOT-1789
Project: GeoTools
Issue Type: Tas
StyleVisitor implementations must be changed to accomodate for the new API
--
Key: GEOT-1788
URL: http://jira.codehaus.org/browse/GEOT-1788
Project: GeoTools
Issue Type:
TXT with at the left of comparison
operations
--
Key: GEOT-1787
URL: http://jira.codehaus.org/browse/GEOT-1787
Project: GeoTools
Issue Type: Improvement
Hi!
I am currently writing a wrapper; to "convert" java beans to features, throw
the SimpleFeature interface...
But there are choices to do, and i would be happy to have your suggestions !
The idea is this :
In an application, we have a model (MVC pattern for instance), described by
some classes
21 matches
Mail list logo
