No - that's not true :-)I see then I am confused ... let me check - adding a test method to ParserTest with the following "naked" configuration. public void testNakedXMLParse() throws Exception { // set up a parser that only has the the xml schema bindings Parser parser = new Parse
On 26/09/2009, at 12:05 AM, Andrea Aime wrote:
> Forgot one important bit: can people try out both renderers
> out of today's trunk (or later) and see how they work for them?
> Do you get similar results to mine? What discrepancies, and where?
>
> Afaik uDig already dropped the ShapefileRenderer.
> The slower case is when the shapefile to be painted is
> disproportionately bigger than the area to be painted.
> The shapefile renderer here uses a trick, it keeps a binary
> map of the pixels where anything has already been drawn,
> and any feature smaller than a pixel gets compared to it,
> an
+0 from me - I don't know enough about it to comment
Michael
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills
Not sure if we talk about the same thing. I see one renderer and one thread
for each layer fetching the data (in the case of multiple layers to render).
Especially in the case of a jdbc database, it is enough to fetch the first
feature. This is the point where the "hard" work for the database e
Hi Andrea,
comments inline ...
---
Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584 980933
fax: +39 0584 983027
mob:+39 349 8227000
http://www.geo-solutions.it
http://ge
Ok Justin,
I'll send you the patches as soon as possible.
Many thanks,
Alessio.
---
Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584 980933
fax: +39 0584 983027
mob
I guess so It would be a good thing. My 2 c.
Alessio.
---
Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584 980933
fax: +39 0584 983027
mob:+39 349 8227000
http://www.geo
Andrea Aime ha scritto:
> Hi,
> first off, sorry for cross posting, yet the topic is
> of interest of both communities.
>
> During the last couple of months I've been working in the
> background to make the streaming renderer + shapefile
> datastore work at a similar level of performance as the sh
Justin Deoliveira ha scritto:
> Hi all,
>
> So as discussed it was more or less agreed to move
> "modules/unsupported/ogc" to directly under "modules/ogc".
>
> Shall I proceed? I think some folks are working on a release? The move
> should not affect any of the pom references but I thought I be
Hi,
first off, sorry for cross posting, yet the topic is
of interest of both communities.
During the last couple of months I've been working in the
background to make the streaming renderer + shapefile
datastore work at a similar level of performance as the shapefile renderer.
The reason for that
Hi all,
So as discussed it was more or less agreed to move
"modules/unsupported/ogc" to directly under "modules/ogc".
Shall I proceed? I think some folks are working on a release? The move
should not affect any of the pom references but I thought I better check
first.
-Justin
--
Justin Deol
Shapefile datastore should avoid reading geometries whose bbox is smaller than
the current screen resolution
Key: GEOT-2736
URL: http://jira.codehaus.org/
Make StreamingRenderer use a faster, rendering oriented bbox operation
---
Key: GEOT-2735
URL: http://jira.codehaus.org/browse/GEOT-2735
Project: GeoTools
Issue Type: Impro
Christian we cheat to get the same effect in uDig; multiple threads
each with their own streaming renderer - and a shared label cache.
Andrea has already ranted about the danger/direction of scheduling
such threads in order to control disk load etc...
Jody
On Fri, Sep 25, 2009 at 6:15 PM, Andrea
Another parsing error on WPS DescribeProcessRequest
Key: GEOT-2734
URL: http://jira.codehaus.org/browse/GEOT-2734
Project: GeoTools
Issue Type: Bug
Affects Versions: 2.6-M2
Jody Garnett schrieb:
>>> The default bindings handle things like xs:int and know enough to turn
>>> that into an Integer. The default binding for an a complex type (at least
>>> for an earlier version of the parser!) would produce a java.util.Map with
>>> the keys as the element name and the value
> Is that my name being taken in vain?
Not at all; we just finally have a friend for you has also found the
limits of what can be done.
Taking your name is almost never in vain - you are very good about answering.
All the best,
Jody
---
>> The default bindings handle things like xs:int and know enough to turn
>> that into an Integer. The default binding for an a complex type (at least
>> for an earlier version of the parser!) would produce a java.util.Map with
>> the keys as the element name and the value as appropriate.
>
> I see
Hi Rob!
Rob Atkinson schrieb:
> Hi
>
> Is that my name being taken in vain? I think you mean Matthias. I'm
> not at all suprised though that complex data type support requirements
> are coming out of the wild, and being blamed on me :-)
>
> Matthias - will you be at the OGC meeting in Darmstadt
Hi
Is that my name being taken in vain? I think you mean Matthias. I'm
not at all suprised though that complex data type support requirements
are coming out of the wild, and being blamed on me :-)
Matthias - will you be at the OGC meeting in Darmstadt next week by
any chance? I'll be there, then
Christian Müller ha scritto:
> I think you are right here. Instead of collection prefetching, we should
> use multiple Threads for fetching data for multiple layers. Each layer
> fetches its data in an own thread.
> We had a short discussion about this, seems to be a matter of your
> resources.
Hi Jody,
Jody Garnett schrieb:
>> I don't understand what you mean with using an java.util.Map to store
>> the complex information.
>
> The default bindings handle things like xs:int and know enough to turn
> that into an Integer. The default binding for an a complex type (at
> least for an ea
I think you are right here. Instead of collection prefetching, we should use
multiple Threads for fetching data for multiple layers. Each layer fetches
its data in an own thread.
We had a short discussion about this, seems to be a matter of your
resources.
Andrea Aime writes:
> Hi,
> as
Labels are not rendered anymore due to changes in the textsymbolizer behaviour
--
Key: GEOT-2733
URL: http://jira.codehaus.org/browse/GEOT-2733
Project: GeoTools
Iss
Hi,
as you know I've been working on these idea of having
a feature iterator that does pre-fetch data over a separate
thread allowing some overlap between data reading and
data processing (be it gml encoding, rendering).
I've done various tests with them and whilst in some
cases there was a speed
26 matches
Mail list logo
