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
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
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
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
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
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
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 :
> 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
>
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() - d
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
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
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
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 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
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
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-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
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
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
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
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
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
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
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
-
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
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
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
---
29 matches
Mail list logo
