Hi,
I'm using geotools 2.1 M4 to parse a GML file with the
WFSFeatureReader.getFeatureReader method and I'm not able to define a
directory that contains the schema. I've to copy the schema to my main
project directory to parse the file. It is possible to define a schemas
directory?
Regar
Cory Horner wrote:
Chris Holmes wrote:
Jesse said the thing that the Filter splitter did better was
functions, but looking at the code I'm not sure how that's happening?
All I can find is one more FUNCTION capability, that isn't granular at
all, and seems to only test the geometryType func
Chris Holmes wrote:
> Jesse said the thing that the Filter splitter did better was
> functions, but looking at the code I'm not sure how that's happening?
> All I can find is one more FUNCTION capability, that isn't granular at
> all, and seems to only test the geometryType function. I would
[ http://jira.codehaus.org/browse/GEOT-895?page=all ]
Cory Horner reopened GEOT-895:
--
going for a more complete solution, to replace all instances of SQLUnpacker
> Unsupported filters should not be sent to Postgis
> ---
Andrea Aime a écrit :
> I've just added a couple of caches more and modified an sql statement to
> use a subquery. For the extensive test, down from 2 minutes to 35 seconds. :-)
This is an impressive improvement! Thanks a lot.
Should we keep the "extensive.tests" hack, or should I remove all thi
Cory Horner wrote:
Jody Garnett wrote:
Cory Horner wrote:
In PostGIS and WFS such code was certainly broken or incomplete. We
will take a closer look, and rewrite as necessary.
It worked the last time I looked into it ... check with the module
maintainer Justin for a sanity check.
Je
So all of the required tasks for the 2.2.0 release are finished.
http://docs.codehaus.org/display/GEOTOOLS/Tasks+for+2.2.0+release
Jesse wants to get some WFS bug fixes in for the release, so I am going
to wait until Friday and then push the release out, unless anyone else
has anything else tha
Martin Desruisseaux ha scritto:
> Andrea Aime a écrit :
>> Well, just to try out, maybe it's better to just setup a cache in the
>> FactoryUsingSQL and think about changing all the rest if the results
>> show there is a noticeable improvement.
>
> Actually, after a second though, I'm following exac
Jody Garnett wrote:
> Cory Horner wrote:
>
>> In PostGIS and WFS such code was certainly broken or incomplete. We
>> will take a closer look, and rewrite as necessary.
>
> It worked the last time I looked into it ... check with the module
> maintainer Justin for a sanity check.
Jesse had a
Cory Horner wrote:
>> But yeah, your new patch is _more_ likely to send unsupported filters
>> to PostGIS, since it will do so when there's no GEOS present, in
>> addition to adding unnecessary cruft to the already crowded
>> PostGISDataStore when we've already decomposed it nicely to different
I've checked in the changes to the 22x branch. It would be very helpful if
someone could check if the PostGIS DataStore still works before I move
these changes into trunk.
-
Using Tomcat but need to do more? Need to supp
Chris Holmes wrote:
> Huh? What is going on? JDBC, which PostGIS inherits from, already
> does pre and post filter processing based on capabilities, by way of
> SQLUnpacker (yes somewhat poorly named). That was the whole reason
> filter capabilities were invented, to do pre and post filter s
Chris Holmes wrote:
> We could probably just move the deprecated GML stuff to GeoServer, as we
> still rely on it. Though if you can't find when deprecation tags were
> present, why do you think that they were actually deprecated?
>
> The stuff is maintained though, is the new xml/gml stuff goi
Jody Garnett wrote:
> Hi guys, you are all committters for the image module so you get tagged.
>
> The good news is the IP check seems just fine :-) Richard I thought you
> dragged the first cut of this code from some old CS image thing in
> GeoTools 2.0 ... can you confirm that?
Correct
>
> Bu
JDBC1DataStore doesn't use database schema names for underlying tables.
---
Key: GEOT-896
URL: http://jira.codehaus.org/browse/GEOT-896
Project: GeoTools
Issue Type: Bug
On 7/15/06, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
> Hello all
>
> I noticed that two new experimental modules, "arcgrid" and "ArcGrid_ImageIO"
> have been commited to
> trunk. Thanks for commiting them on trunk; it make easier for me to take a
> look at them soon (I tend
> to look at bra
The coordinate system axis are not cached as of revision 20566 (on trunk), but
we didn't get any
speed improvement. This is not really surprising since CoordinateSystemAxis are
usually created only
in the context of CoordinateSystem creation, and the later are cached.
Tried to reduces the test
Andrea Aime a écrit :
> Well, just to try out, maybe it's better to just setup a cache in the
> FactoryUsingSQL and think about changing all the rest if the results
> show there is a noticeable improvement.
Actually, after a second though, I'm following exactly this path (because
turning the priv
Martin Desruisseaux ha scritto:
> Good idea. We need to keep trace of the index creation however, if we don't
> want to lost them the next time we will update the EPSG database (the
> database
> provided in epsg-hsql is supposed to be created from the SQL scripts
> downloaded
> from the EP
Andrea Aime a écrit :
> First I noticed there were no indexes on the db, and created them, then
> noticed a few queries may haven't been optimal, but go only a handful of
> seconds improvements (around 6 seconds improvement over 2 minutes...)
Good idea. We need to keep trace of the index creation
Andrea Aime a écrit :
> Martin, anything against removing the super constructor calls? Waiting
> for the clover update and the subsequent maven plugin dependency update
> may take long.
Yes, feel free to remove this line.
Martin.
-
21 matches
Mail list logo
