Martin Tomko a écrit :
> DOes that mean that the epsg-hsql jar of GT2 contians an incorrect WKT
> specification of the projection? That should probably be fixed there too...
No, epsg-hsql is correct. The WKT that I posted yesterday was produced by
epsg-hsql...
Martin
Martin Tomko a écrit :
> very strange, I used the snapshot hsql and I got the results I was
> sending you. What epsg number did the wkt that you use have?
I have queried for EPSG:21781 (if my memory serve me right - the actual number
should be in the "AUTHORITY" statement at the end of the WKT) us
jdbc-ng is not guaranteed to work with the JDBC 4.0 Specification
-
Key: GEOT-2216
URL: http://jira.codehaus.org/browse/GEOT-2216
Project: GeoTools
Issue Type: Bug
Com
possible memory leak in GeoTiffReader
-
Key: GEOT-2217
URL: http://jira.codehaus.org/browse/GEOT-2217
Project: GeoTools
Issue Type: Bug
Affects Versions: 2.5.2, 2.4.4
Environment: linux 64-bit
Hi,
I've been looking at the directory data store again and
the more I delve into it, the more I believe a rewrite
is the only way to go.
The current one tries to delegate to secondary data stores,
relies on those datastore factories to implement
a specific interface, does not support namespaces (
On Thursday 11 December 2008 01:44:32 Jody Garnett wrote:
> Mauricio Pazos wrote:
> > I am with Andrea Aime proposal: "ECQL"
>
> That is cool - some reference to CQL is good ... CQL+ :-)
>
> That said we may wish to propose the FeatureID extensions to CQL as part
> of the next revision of CSW speci
Sounds like a good idea to me. Additional thoughts and comments inline.
Andrea Aime wrote:
> Hi,
> I've been looking at the directory data store again and
> the more I delve into it, the more I believe a rewrite
> is the only way to go.
>
> The current one tries to delegate to secondary data stor
[
http://jira.codehaus.org/browse/GEOT-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Roldán reopened GEOT-2182:
--
reopening sine a wrong assumption in JDBCFeatureSource that filter == preFilter
makes the defect still ap
I've put together another release of the GPX 2 module with some small
changes. Mostly house cleaning stuff. You can now download that JAR
file with the library, the supporting docs, and the dependencies for
the library from this page:
http://www.redefinedhorizons.com/resources.html
You'll note th
>
> The FileDataStoreSpi is badly designed for a number of reasons:
> - it assumes you deal with certain extensions. This is overrated, the
> datastore could operate by inspecting magic numbers in the file header
> instead of using extensions
> - it assumes you can create a datastore with a u
Add a unit test for arcsde NString reading and writing
--
Key: GEOT-2218
URL: http://jira.codehaus.org/browse/GEOT-2218
Project: GeoTools
Issue Type: Test
Components: data arcsde
[
http://jira.codehaus.org/browse/GEOT-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Roldán reopened GEOT-2024:
--
> ArcSDE NStrings
> ---
>
> Key: GEOT-2024
> URL: http://jira.
Mauricio Pazos ha scritto:
> On Thursday 11 December 2008 01:44:32 Jody Garnett wrote:
>> Mauricio Pazos wrote:
>>> I am with Andrea Aime proposal: "ECQL"
>> That is cool - some reference to CQL is good ... CQL+ :-)
>>
>> That said we may wish to propose the FeatureID extensions to CQL as part
>> o
Justin Deoliveira ha scritto:
>
>>
>> The FileDataStoreSpi is badly designed for a number of reasons:
>> - it assumes you deal with certain extensions. This is overrated, the
>> datastore could operate by inspecting magic numbers in the file header
>> instead of using extensions
>> - it assume
Justin Deoliveira ha scritto:
> Sounds like a good idea to me. Additional thoughts and comments inline.
>
> Andrea Aime wrote:
>> Hi,
>> I've been looking at the directory data store again and
>> the more I delve into it, the more I believe a rewrite
>> is the only way to go.
>>
>> The current one
Andrea Aime ha scritto:
> Can we hit a compromise of any kind so that something can be done
> on 2.5.x? My enthusiasm on this directory datastore remake has
> suddenly dropped below zero, as I've seen this movie already...
Hum... datastore dispose wise I was probably thinking too much.
If we have
Andrea Aime wrote:
> Andrea Aime ha scritto:
>
>> Can we hit a compromise of any kind so that something can be done
>> on 2.5.x? My enthusiasm on this directory datastore remake has
>> suddenly dropped below zero, as I've seen this movie already...
>
> Hum... datastore dispose wise I was probably
Andrea Aime wrote:
> Hi,
> I've been looking at the directory data store again and
> the more I delve into it, the more I believe a rewrite
> is the only way to go.
>
Please just rewrite in place :-P
> The current one tries to delegate to secondary data stores,
> relies on those datastore factor
18 matches
Mail list logo
