memoryPreloadingEnabled throws exception with Postgis
-
Key: GEOT-1209
URL: http://jira.codehaus.org/browse/GEOT-1209
Project: GeoTools
Issue Type: Bug
Components: core filter
Hi Martin:
The implementation in unsupported/geometry is fine - it looks like it
will handle any CoordinateReferenceSystem at
the end of the day.
This is my first time in that code base (for some reason I thought you
were keep tack of it? Or helping? or something ).
The implementation (as menti
Since Jody is working on geometries, I have a little naming topic. Most classes
in module/unsupported/geometry end with the "Impl" suffix. I wonder: what at
the
restriction in usage of this implementation, if any? For example:
* Is module/unsupported/geometry implementation limited to the 2D ca
Students -- The GeoTools project has received very few submissions for
the summer of code. Anyone submitting a thorough application is likely
to be accepted (woot! summer job).
One day left!
Cheers,
Cory.
> A heads up to any students out there: applications for the Google
> Summer of Code clo
Jody Garnett a écrit :
> The description indicates that the returned double[] *is* the sequence
> of numbers that hold the coordinates of this position
> The @return indicates that this is "a copy of the coordinates"
>
> Based on your email I will revise the javadocs to indicate a copy is
> used
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>
>>Apparently it is not just me - Identifier.getVersion() has been removed
>>from GeoAPI (along with VERSION_KEY).
>
> I have not yet looked at the GeoAPI changes. But it seems to me that
> Identifier.getVersion() and VERSION_KEY should be @d
Aside - here is the conflicting javadocs for getCoordinates();
> * Returns the sequence of numbers that hold the coordinate of this
> * position in its reference system.
> *
> * @return A copy of the coordinates. Changes in the returned
> array will not be reflected
> *
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> Reading for an array of ordinates is done way more often; it is okay
>> to specify the array returned is not to be edited - but forcing it to
>> be a copy every time is a bit painful.
> My assumption was that reading would be performed by
>
>
Hi Paul - I do think I heard back from Julian - but I was only doing a
quick review (it was Julian's responsibility to update the file). Let me
see if I can find his email, cut and paste it into the review.txt and
carry on with life.
Jody
Paul, Michael wrote:
> Hi Jody,
>
> I am currently inv
Hi,
we're releasing Geoserver 1.5.0rc3 which references current
geotools 2.3.x branch.
If all goes well, we'd like to release the current 2.3.x
as 2.3.1 and turn gs 1.5.0rc3 into gs 1.5.0 final.
So, can I ask everybody to hold commits on the 2.3.x branch
for a week? :-)
Sorry I did not warn you be
Jody Garnett a écrit :
> Reading for an array of ordinates is done way more often; it is okay to
> specify the array returned is not to be edited - but forcing it to be a
> copy every time is a bit painful.
My assumption was that reading would be performed by
DirectPosition.getOrdinate(i)
Martin Desruisseaux ha scritto:
> The "epsg-access" module relies on the JDBC-OBDC bridge which is
> available on Windows and Linux, but not Mac-OS. ODBC was originally
> Windows-specific, but I believe that it has gained some support other
> than Microsoft on Windows.
>
> The "epsg-access" mod
Martin Desruisseaux a écrit :
> Do we have a volunter for adding a "Mac" profile and test on Mac-OS?
Sorry, I didn't noticed that an action was already taken (I was away since last
saturday and just came back). Thanks for the fix.
Martin
-
The "epsg-access" module relies on the JDBC-OBDC bridge which is available on
Windows and Linux, but not Mac-OS. ODBC was originally Windows-specific, but I
believe that it has gained some support other than Microsoft on Windows.
The "epsg-access" module should be excluded from the build on Mac-
Jody Garnett a écrit :
> Apparently it is not just me - Identifier.getVersion() has been removed
> from GeoAPI (along with VERSION_KEY).
I have not yet looked at the GeoAPI changes. But it seems to me that
Identifier.getVersion() and VERSION_KEY should be @deprecated before to be
removed in a f
Jody Garnett a écrit :
> Andrea Aime wrote:
>> Can we try another path? The issue with having many jars is that
>> without maven it's hard to deal with them... unless we provide
>> users with a list of dependencies:
Just a reminder: The Geotools JAR created by Maven contains a "Class-Path"
entry
16 matches
Mail list logo
