Clean the developers list in root pom.xml
-
Key: GEOT-1043
URL: http://jira.codehaus.org/browse/GEOT-1043
Project: GeoTools
Issue Type: Task
Components: admin
Affects Versions: 2.4.M0
Move org.geotools.coverage.io.* to its own plugin directory.
Key: GEOT-1042
URL: http://jira.codehaus.org/browse/GEOT-1042
Project: GeoTools
Issue Type: Improvement
Enviro
GridCoverage2D dispose method
-
Key: GEOT-1041
URL: http://jira.codehaus.org/browse/GEOT-1041
Project: GeoTools
Issue Type: New Feature
Components: core coverage
Environment: all
Rep
FactoryFinder, constructor injection and eclipse environment
-
Key: GEOT-1040
URL: http://jira.codehaus.org/browse/GEOT-1040
Project: GeoTools
Issue Type: Improvement
Com
add a isIndexed method to IndexedShapefile datastore so that clients can know
whether it needs to run the indexing
--
Key: GEOT-1039
URL: http://jira.c
Hi just tried to follow instructions (btw the page is dead?) but it didn't work
What I did:
>I put my test-data.zip which containa zipped ascii grids under a
directory called arcgrid in sample data
>I built sample data and I added the jar to my project.
3>I used the following code:
Hi Gabriel - I am going to do an experiment (in the jpox module) to see
how well
things can work out ...
Basically:
- make DataAccess a proper superclass of DataStore
- hack away from there ...
It is amazing what becomes possible the moment we had our Filter / Data
/ Metadata seperation
sorted
Gabriella,
your issue is fixed.
I tried your test app you gave me and it works fine. I am thinking of
how I can provide you with the updated jars without asking you to
download the code and build it yourself. It should be possible to use
maven to download jars from one of the projects' repositorie
I think we need to update our developers guide; building geotools fails
unless JAI+ImageIO is installed in BOTH the JDK and the JRE.
- Verified this on a PC yesterday.
- Looks to be an seperate report on the user list (below)
I have added a "task" to this page (so we won't forget):
- http://docs.
Gabriel Roldán wrote:
> Hi all,
>
> are the Filter and Expression implementations meant to properly implement
> equals and hashcode?
>
Are their data objects? Thinking ... I would have to assume yes. I sure
wish they were immutable (so they would not change place in a hashmap );
> If so, we ar
What a great email - I really need to make an article on expressing
GeoSpatial stuff in computer science terms fun!
Victor Mauricio Pazos wrote:
> Hi, Gabriel talked me that is possible restructure the toolkit in near
> feature, I have some suggestion for CQL parser.
>
> 1)Name change: Pa
I have brought this up before as well. Martin brought up a good point in
that unless the interface explicitly states what makes implementations
equal to one another, it is open to interpretation and best to just
compare based on implementation.
-Justin
Gabriel Roldán wrote:
> Hi all,
>
> are the
Hi all,
are the Filter and Expression implementations meant to properly implement
equals and hashcode?
If so, we are in trouble, as (almost?)none of the FunctionExpression
implementations does.
For the ones that do, should we move to comparisons based on the geoapi
interfaces rather than on co
Hi, Gabriel talked me that is possible restructure the toolkit in near
feature, I have some suggestion for CQL parser.
1)Name change: Parser is only a component of Compiler ( lex, parser,
optimization, code generation) We need produce an object and parsing process
is only part of process, per
Cory Horner ha scritto:
> Jody Garnett wrote:
>
>
>> Having a bit of fun helping someone set up trunk for mac development:
>> - rendering-styling - fatal tests
>> - espg-access - same
>>
>> I would like to set up a maven profile to at least exclude the tests if
>> we are on a mac; and at most e
15 matches
Mail list logo
