Hello all
I noticed that two new experimental modules, "arcgrid" and "ArcGrid_ImageIO"
have been commited to
trunk. Thanks for commiting them on trunk; it make easier for me to take a look
at them soon (I tend
to look at branches much least frequently than trunk). I would like to share
the fo
Simone Giannecchini a écrit :
> I am trying to build and install trunk but GML keeps failing with a
> connection timeout error.
>
> Is anyone else experiencing this test failure?
I just tried and it worked for me:
http://maven.geotools.fr/reports/gml/surefire-report.html
Martin.
Frank Warmerdam a écrit :
> It doesn't alter Martin's main point, but I have very hopeful that we
> can put all C/C++ portions of GDAL bindings in the GDAL repository so that
> Geotools just needs to implement it's own adapter classes based on the GDAL
> SWIG generated Java api. Likewise for PROJ.
Richard Gould a écrit :
> Also these methods appear to be un-deprecated:
>
> org.geotools.gui.swing.CoordinateChooser.getAccessory()
>Depracated together with
> CoordinateChooser.setAccessory(javax.swing.JComponent).
Right. After some experience, I realized that the proposed replacem
I have started removing the deprecated items, but I have run into some
issues:
org.geotools.gml.GMLHandlerFeature
org.geotools.gml.GMLHandlerGeometry
org.geotools.gml.GMLHandlerJTS
org.geotools.gml.producer.FeatureTransformer
org.geotools.gml.producer.FeatureTypeTransformer
org.geotools.gml.produ
Huh? What is going on? JDBC, which PostGIS inherits from, already does
pre and post filter processing based on capabilities, by way of
SQLUnpacker (yes somewhat poorly named). That was the whole reason
filter capabilities were invented, to do pre and post filter splitting
with SQLUnpacker.
Unsupported filters should not be sent to Postgis
-
Key: GEOT-895
URL: http://jira.codehaus.org/browse/GEOT-895
Project: GeoTools
Type: Bug
Components: data postgis
Versions: 2.2.M0
Reporter: Cory Horne
Attached is the deprecated list from GeoTools 2.0.x ... anything on this
list should be removed from GeoTools 2.2.x before release...
All in all not very much ...
Jody
Title:
Deprecated List (geotools-2.0.x build 2.0.x API)
Overview
Package
Class
U
Martin Desruisseaux wrote:
> This issue may become more accute if for some reason we wish to host
> C/C++ code in the Geotools project for GDAL or Proj.4 bindings for example (I
> realize that GDAL
> bindings already exists, but if we use more C/C++ code in Geotools, there is
> also some chance
Hi list,
I am trying to build and install trunk but GML keeps failing with a connection timeout error.
Is anyone else experiencing this test failure?
Simone.-- °°Simone GiannecchiniSoftware EngineerFreelance Consultanthttp://simboss.wordpress.com/
°°°
Jody Garnett a écrit :
> That reminds me, can you place your description of module structure into
> the developers guide? Right now our instructions say something like copy
> "graph" and delete the parts you do not want. If you don't mind I will
> try to set up the "ext/mappane" module up with t
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> Can I ask if after all this we can use JScience more smoothly with
>> geotools? I am quite fond on their Measure and Units constructs.
>> Measure saves me *tones* of grief right now ...
> * The JScience implementation requires Java 5. I'm a
Chris Holmes a écrit :
> +1 here.
Since we now have 6 votes from the PMC, the relicensing is accepted. Thanks to
all :). I have sent
the 3 classes to Jean-Marie, so he can integrate them in JScience at his
convenance. For info:
https://jscience.dev.java.net/issues/show_bug.cgi?id=37
(My o
Jody Garnett a écrit :
> Can I ask if after all this we can use JScience more smoothly with
> geotools? I am quite fond on their Measure and Units constructs. Measure
> saves me *tones* of grief right now ...
The clash comes from the fact that Geotools still uses the (dead) JSR-108,
while JScie
Bryce L Nordgren a écrit :
> I guess I'd be in favor of retaining this package as one-or-more
> "extensions". (Note this should not prevent us from forking it to JScience
> under a different license if they want it.) My main concern is that we
> retain a package within Geotools within which commo
Adrian Custer a écrit :
> I would like there to be two (2) javadoc links on the website,
> one for users which would be the last stable release (i.e.
> 2.2.RC4 when that is released)
> and
> the current one related to trunk, which I have moved into the
> "Develop"
Hi Andy,
One of the things I have been trying to accomplish is the integration of
additional libraries into uDig beyond the base GeoTools implementations
we are working with. While I am excited about the possibilities of
working with OSSIM I have not heard of much progress - seemly due to the
Martin Desruisseaux wrote:
> This change would not be performed immediately. We would probably need
> to merge all branches first. No date is scheduled; I'm only bringing
> this topic for discussion purpose. I openned a JIRA task for that:
>
> http://jira.codehaus.org/browse/GEOT-887
>
> If t
Daniele Romagnoli a écrit :
> I'm Daniele Romagnoli, the Summer Of Code student working on the
> ImageIO-GDAL integration proposal, having Simone Giannecchini as my Mentor.
This very interresting project may bring an issue that I would like to point
out. Our current
Geotools directory structure
Jody Garnett ha scritto:
> In talking with Acuster the inability to grab the JMapPane code as a
> maven dependency is cutting into the ability to write demos. Ian you
> mentioned the idea of where JMapPane might live, and the answer was as
> in the "ext" directory - aka code that is not core to
+1
Simone.
On 7/13/06, Jody Garnett <[EMAIL PROTECTED]> wrote:
In talking with Acuster the inability to grab the JMapPane code as amaven dependency is cutting into the ability to write demos. Ian you
mentioned the idea of where JMapPane might live, and the answer was asin the "ext" directory - a
Andy Turner wrote:
> Hi Everyone,
>
> I plan to go to FOSS4G and am looking forward to meeting you there and
> learning more about what you are doing.
>
Yeah - and there there were two...
> I put in an abstract (http://indico.epfl.ch/userAbstracts.py?confId=1)
> titled "Grids 1.0 beta and beyond
Sweet thanks for the feedback ... going to try again this evening.
As for the Joel reference I actually use his painless software schedules
and test for software maturity articles. Did not try his user interface
book yet ...
> Hey Jody,
>
> While you think and organize in generics (subjects) it
23 matches
Mail list logo
