So I eventually tracked down the failure to ReTypeFeatureReader; when it
came to comparing origional to target schemas the comparison was done
using equals; now that names are more complicated then a single string;
and types more complicated then a binding; it was very easy for uDig to
get a fa
As I go through and hunt down bugs in the DataUtilities methods for
manipulating FeatureType and Query information I am reminded of the
purpose of this class - to capture common functionality that was
"missing" from the library (or hard to implement which amounts to the
same thing).
Now back i
Jody Garnett wrote:
> The OSGeo graduation requirements have taken up a lot of time this week
> - thanks for everyone who helped out (I am sorry if we were too slow on
> some of the modules; I think we have marked everything down - perhaps we
> were slow in communicating to the incubation commit
Hi,
today I did some benchmarks again and we're pretty close
to the 2.4.x level (but we do not match, 10%-20% slower...
unfortunately I'm out of time for further improvements).
Anyway, the funny thing is that there are two feature
factories, one non validating, and the other validating.
The latter
Hi Jody, I noticed that currently a module for JPOX exist under the
trunk/unsupported/modules, but have found this to be out of date and
dependent on the 2.3.X release of GeoTools and breaks with never
releases due to the dependency on old catalog classes. Also the version
there were still referen
I have updated the http://docs.codehaus.org/display/GEOTOOLS/2.5.x page
to reflect where we are at with our goals; acceptance tests and so on.
UDig missed its acceptance test for 2.5.x; now all that means is that
uDig will not be making use of the 2.5.x branch - uDig will be forced to
stay on t
> Uh, very odd, does not match my experience. If you use GeoWebCache
> to cache the tiles you should be able to send away a pre-rendered
> tile in something like 20 to 80ms, rendering should take quite a bit
> more unless the map is very (very) simple.
You misunderstood me. The 2x performance incr
Next Tuesday is the 15th; this is the deadline for 2.5.x branching off
(so Eclesia can commit his style work).
The OSGeo graduation requirements have taken up a lot of time this week
- thanks for everyone who helped out (I am sorry if we were too slow on
some of the modules; I think we have mar
I don't think we responded to these issues quickly enough.
Today is Friday; and these issues (along with XSD, OSG and DB2) were not
being were not being sorted out. I did not see a "you have graduated
message" on the incubation list yesterday :-(
Is this a case of OSGeo involvement being too fa
Hi Saul - I noticed the ArcSDE DataStore page filling up with questions;
and the occasional answer in the comments section. Do you want to try
and capture this information somewhere?
http://docs.codehaus.org/display/GEOTDOC/ArcSDE+DataStore
---
Hi Francios - nice to meet you.
You are correct the jpox module is out of date and "abandoned" - indeed
we just removed it from trunk earlier this week. If you would like to
create a new "data nucleus" module you are welcome to the task; and I
can let you know how to get svn access and all that
Mike Bresnahan ha scritto:
...
> I thought I would get big GeoServer rendering gains by pre-tiling the
> data, but I have only been able to get a 2x increase. This increase
> does not make up for the time spent pre-tiling the data, nor does it
> make real-time rendering feasible.
Uh, very odd, doe
> Have you run the rendering inside a profiler and the actual draw part
> resulted the be the bottleneck, or you're just assuming it is?
> Data loading could be your bottleneck
> Cheers
> Andrea
>
Yes I did, but I did it more to trace the code execution than to
understand where the performance bot
Andrea Aime a écrit :
> me and Jody are seeing the same error, consistently, using java 6, no
> matter how you build, see here:
> http://jira.codehaus.org/browse/GEOT-1917
I noticed the report. According the stack trace, its look like that it may have
some relationship with the threaded factory w
RendererUtilities needs calculateEnvelopeFromOGCScale
-
Key: GEOT-1918
URL: http://jira.codehaus.org/browse/GEOT-1918
Project: GeoTools
Issue Type: New Feature
Components: core re
Andrea Aime wrote:
> Hum,
> first off, I don't see why rendering should be dealing with paging.
I assume it is so people can see on the map what rows they are looking
at in a table?
But yes I was close; it looks like I have tracked the problem down to
DataUtilities.createSubType not handling the
Cédric Briançon ha scritto:
> Hey all,
>
> I'm getting this error on the module epsg-hsql (maven 2.0.9,
> jdk1.5.0_15, linux Ubuntu) and not when I go in the
> modules/plugin/epsg-hsql directory and try building with tests :
Funny,
me and Jody are seeing the same error, consistently, using java
I had come to this conclusion myself; my concern is paging being handled
differently at different points (even within streaming renderer there
are several calls to mixQueries).
But I agree; paging does not really work when combining queries (at
least not in any efficient manner).
Jody
Andrea A
Hey all,
I'm getting this error on the module epsg-hsql (maven 2.0.9,
jdk1.5.0_15, linux Ubuntu) and not when I go in the
modules/plugin/epsg-hsql directory and try building with tests :
---
Test set: org.geotools.refer
Mike Bresnahan ha scritto:
> On 7/10/08, Jody Garnett <[EMAIL PROTECTED]> wrote:
>> Yes clipping is probably more expensive then dealing with more content; you
>> may want to pre-process your data (splitting along tile devisions) prior to
>> servering it up via geoserver?
>
> I have tried this and
Mike Bresnahan ha scritto:
> Given a WMS request for a 256x256 map tile and vector data stored in
> Oracle Spatial, I am trying to understand how GeoTools crops the
> image. Judging by some database tracing, GeoTools does not appear to
> use the sdo_intersection function. Instead it simply queries
Jody Garnett ha scritto:
> Jody Garnett wrote:
>> I am going through the code in streaming renderer; trying to see why
>> uDig is having trouble rendering features.
>>
>> Streaming renderer traditionally delegates the task of combining two
>> queries to DataUtilities.mixQueries method; when I rev
Jody Garnett ha scritto:
> I am going through the code in streaming renderer; trying to see why
> uDig is having trouble rendering features.
>
> Streaming renderer traditionally delegates the task of combining two
> queries to DataUtilities.mixQueries method; when I review the code today
> I fi
23 matches
Mail list logo
