Rob Atkinson a écrit :
> disreagrd that - the error is in Resample test - thats just an ugly
> warning that dumps a pointless stack trace (can we stop that?)
Unfortunatly not (as far as I known). This is a warning emitted by JAI itself.
Martin
---
Build Failure of JDK1.6.0_06 with no JAI or ImageIO
---
Key: GEOT-1862
URL: http://jira.codehaus.org/browse/GEOT-1862
Project: GeoTools
Issue Type: Bug
Components: core referencing, c
coverage fails tests in
org.geotools.coverage.grid.ResampleTest
Caused by:
org.geotools.referencing.operation.projection.ProjectionException:
Transformation doesn't convergence.
at
org.geotools.referencing.operation.projection.StereographicUSGS.inverseTransformNormalized(StereographicUSGS.jav
Rob Atkinson wrote:
> I can no longer build this without JAI ( i could a while back).
> I though we'd established that we didnt need native JAI?
Checking the developers guide- it still lists JAI and ImageIO as needed.
- http://docs.codehaus.org/display/GEOT/1+Java+Install
-
Rob Atkinson wrote:
> I can no longer build this without JAI ( i could a while back).
> I though we'd established that we didnt need native JAI?
I am pretty sure we did establish that we don't need JAI; but I am
coming to the conclusion that to use it is fatal...it it looks like
GeoTools is only
disreagrd that - the error is in Resample test - thats just an ugly warning
that dumps a pointless stack trace (can we stop that?)
Rob A
On Tue, Jun 24, 2008 at 12:34 PM, Rob Atkinson <[EMAIL PROTECTED]>
wrote:
> I can no longer build this without JAI ( i could a while back).
>
> I though we'd e
I can no longer build this without JAI ( i could a while back).
I though we'd established that we didnt need native JAI?
Rob A
[INFO] Surefire report directory:
C:\repos\geotools\trunk\modules\library\covera
ge\target\surefire-reports
---
T E
Martin Desruisseaux wrote:
> I tried the same (Java 5, Maven 2.0.9, GeoAPI built locally, did "mvn
> clean install") and got a successful build. I got the same last Friday
> before I commited. Hudson seems to built coverage fine too (the
> compilation failure was elsewhere). For now I have no i
Martin Desruisseaux wrote:
> Where
> - type is the interface (not the implementation class) to instantiate
>(e.g. Citation.class, OnLineResources.class, etc.).
> - attributes is a map of (attribute name, attribute value). Example
>for Citation.class:
>
> attributes.put("title", "t
See http://gridlock.openplans.org:8080/hudson/job/geotools-2.4.x/109/changes
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforg
See http://gridlock.openplans.org:8080/hudson/job/geotools-2.4.x/108/changes
Changes:
[saul.farber] logging message spelling fixes
fix for NCLOB/CLOB/NSTRING/STRING attribute reading/writing
zero-length propertyName queries are now treated as "ALL" rather than a query
for no properties
FIDReader
johann.sorel wrote:
> I added the check code, but it looks like I shouldn't have done it this
> way, so I removed it. If you can explain me how works the factory system I
> guess I'll be able
> to fix the function correctly.
>
Okay I think I understand; the Factory SPI system uses the no argu
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/748/changes
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforg
Martin Desruisseaux a écrit :
> Okay, I will do a factory. A basic one should be easy enough to make, but I
> don't know how useful it will be (because setters are provided only in
> implementation classes). I will try and we will see.
There is a simple proposal, but I don't know if it would fi
Jody Garnett a écrit :
> I saw the following comment go by:
>
>> r30783 | johann.sorel | 2008-06-22 03:41:45 -0700 (Sun, 22 Jun 2008) |
>> 1 line
>>
>> removed parameters lenght check at categorize function creation, this
>> makes the factory go crazy.
>>
> Can you please be more specific
Martin Desruisseaux wrote
> I'm not well aware of the roadmap for styling, so my words may not be
> pertinent.
> But as far as consistency is concerned in names of methods returning a
> collection, I think that it depends if the collection is intented to be
> "live"
> or immutable.
>
Agreed
Martin right now people need to know the metadata classes by name;
because we don't hava a Factory. Can you introduce a Factory and then
change the name? We had this conversation some months ago when you were
working on marking up this implementation to support JAXB.
Is adding a factory an optio
I am not sure I like backwards compatibility over consistency. Ie if we
are going to break people let's at least do it with a usability goal in
mind.
The other alternative is:
GeoTools 2.5.x:
- getRulesArray() - returns an array
- getRules() - deprecated
GeoTools 2.6.x
- getRulesArray() - retu
I saw the following comment go by:
> r30783 | johann.sorel | 2008-06-22 03:41:45 -0700 (Sun, 22 Jun 2008) |
> 1 line
>
> removed parameters lenght check at categorize function creation, this
> makes the factory go crazy.
Can you please be more specific? Which factories any why? Chances are
the fa
> Jody Garnett a écrit :
>> I am not sure I like backwards compatibility over consistency. Ie if
>> we are going to break people let's at least do it with a usability
>> goal in mind.
>>
>> The other alternative is:
>>
>> GeoTools 2.5.x:
>> - getRulesArray() - returns an array
>> - getRules() - d
Query Attributes of FeatureCollection gets missing in StreamingRenderer
Key: GEOT-1861
URL: http://jira.codehaus.org/browse/GEOT-1861
Project: GeoTools
Issue Type: Bug
Jody Garnett a écrit :
> I am not sure I like backwards compatibility over consistency. Ie if
> we are going to break people let's at least do it with a usability
> goal in mind.
>
> The other alternative is:
>
> GeoTools 2.5.x:
> - getRulesArray() - returns an array
> - getRules() - deprecated
>
Jody Garnett a écrit :
> I get a failure here:
>> Test set: org.geotools.coverage.grid.OperationsTest
>
> I am doing nothing too strange:
> 1. Using Java 5
> 2. Maven 2.0.9
> 3. I did build geoapi locally; but then again I always do
I tried the same (Java 5, Maven 2.0.9, GeoAPI built locally, di
Jody Garnett a écrit :
> Martin right now people need to know the metadata classes by name;
> because we don't hava a Factory. Can you introduce a Factory and then
> change the name? We had this conversation some months ago when you were
> working on marking up this implementation to support JAX
Distinction between static and dynamic styles in SLDStyleFactory
Key: GEOT-1860
URL: http://jira.codehaus.org/browse/GEOT-1860
Project: GeoTools
Issue Type: Bug
Compo
The naming schema between GeoAPI implementation classes is inconsistent between
metadata and referencing module. I would like to rename the metadata classes
for
consistency, replacing "Impl" suffix by "Default" or "Abstract" prefix. I
realize that this is a very cosmetic issue (absolutly no cha
Hello,
Proposal : http://docs.codehaus.org/display/GEOTOOLS/Upgrading+styles
We have a found a solution to upgrade GeoTools style interface without
breaking backward compatibility.
The problem we had was "Array versus Collection" :
-In GeoTools we have : Rule[] getRules();
-In GeoAPI we have
Improve Styles using Dynamic Graphics that is attribute dependent
-
Key: GEOT-1859
URL: http://jira.codehaus.org/browse/GEOT-1859
Project: GeoTools
Issue Type: Improvement
Hi,
Martin Desruisseaux a écrit :
> Graham Davis a écrit :
>
>> This would be the \extension\xsd\xsd-wps\ module, but I'm not sure what
>> the problem is in the pom file. I don't see anything refering to 2.4,
>> but maybe I'm looking for the wrong thing? Martin, what should I be
>> looking
29 matches
Mail list logo
