[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] RE: [Geotools-devel] Re: Geotools 2.0 rc1
|
I think use it just to load some test data in arcsde datastore. So I'll
remove the dependency as soon as I get svn working (at home, since at office
I have proxy problems).
So, by my side, just go for it, will remove the dependency this afternoon.
-----Mensaje original-----
De: cholmes@xxxxxxxxxxxxx [mailto:cholmes@xxxxxxxxxxxxx]
Enviado el: viernes, 14 de mayo de 2004 10:11
Para: jgarnett@xxxxxxxxxxxxxxx; udig-devel@xxxxxxxxxxxxxxxxxxxxx;
geotools-devel@xxxxxxxxxxxxxxxxxxxxx
Asunto: [Geotools-devel] Re: Geotools 2.0 rc1
> For the last several IRC sessions I have tried to start a discussion
on
> the feature set we would like for our 2.0 release. I have been
shooting
> for a release candidate at the end of June.
>
> The feature set I am looking for for Geotool 2.0 rc1 is:
> - exactly what we have now
> - DataSource retired (or at least deprecated)
> - requires GridCoverageExchange as a replacement for ArcGrid
> - requires GMLDataSource to have an exit strategy
I'd say just get rid of GMLDataSource. It's really pretty bad, I don't
imagine anyone's actually using it. Which is to say, speak now or
forever hold your peace, unless anyone says they _need_ it in 2.0 rc1 I
say we kill it.
> I am not sure if we will have a geotool2.0rc1 available in time for
our
> uDig Milestone 1 deadline:
> - The GCE Echange should be ready (richard/jessie have some time
booked)
> - IanS/David's gml work is promising -- I would like to wait until we
> can replace the GMLDataSource
>
> One suggestion is that we could go ahead anyways. Remove the
> GMLDataSource - as far as I know GeoServer is the only client code
using
> our GML handling (and it has forked the parsing code to do so). I will
> ask chris to confirm this (if he is around/catches up with his email.
Finally starting to catch up on email. Was supposed to get started
earlier, but some nasty sickness has hit me the past week, which is
still bouncing around, but as soon as that's done I plan to spend a few
days catching up and getting some geotools/geoserver fixes in. I would
still like the gml module around, but you can get rid of
org.geotools.data.gml, just keep everything in org.geotools.gml. This
just turns it into a bunch of useful utils for gml. Some of which
should be redone, obviously, with the new gml parser work, which I
still need to check out, but yeah, there is definitely useful stuff
there. The Filter module also makes use of the gml filters.
Yes, I've forked some of the code, but not all the code I use is forked,
I still rely on the geotools classes for everything but the transaction
stuff. So I think my only completely forked class is GMLFilterFeature,
oh wait, but for some reason I have my TransactionFeatureHandler
extending that class, so don't kill it.
Chris
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
Geotools-devel mailing list
Geotools-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/geotools-devel
