Oh, my bad, I didn't realize we were using epsg-extensions. I guess I'd
still prefer to have it unsupported, but if it doesn't build at all and
there have been proper warnings I suppose it may be ok.
C
Adrian Custer wrote:
Hey Chris,
As I understand it, the epsg-extensions module exists *exactly* to
enable a way for users to define CRS's other than those defined by EPSG.
Does this module not work for you?
You are right, perhaps my desire to cleanup is misplaced. I merely note
the regular user questions which arise because it's easy to have both
wkt and epsg in the distribution and that causes user problems. And
keeping an outdated text version of the EPSG database seems like a
really bad idea: any user who needs it would be better off getting the
newest parameters from EPSG and regenerating the best current
parameters.
The cleanup comes in 2.5 (trunk) since the factory class has been
deprecated in 2.4. Users get a full cycle to change their code (although
with the great factory system it's true they may not know if we don't
warn them LOUDLY in the 2.5 release notes.
--adrian
On Wed, 2008-01-30 at 16:59 -0500, Chris Holmes wrote:
You're deleting the epsg-wkt module entirely? I think it's great that
the whole codebase works with epsg-hsql, but I don't think that's reason
to remove epsg-wkt.
We're primarily on epsg-hsql on GeoServer, but we actively use epsg-wkt
to allow people to add custom projections. Doing so is close to
impossible with epsg-hsql. See
http://docs.codehaus.org/display/GEOSDOC/Custom+projection+definition+in+Geoserver+1.5.0+(onwards)
vs.
http://docs.codehaus.org/display/GEOSDOC/Hacking+the+EPSG+hsql+database+directly
I also don't understand this 'clean-up' desire, it's pretty dangerous to
just delete things that geotools users may rely upon. We have an
'unsupported' module to move things that we don't want to support any
more, I think it'd be fine to move epsg-wkt there, but deleting it
entirely seems a bit much. Just because you're no longer using it
doesn't mean that no one else is. We have no desire to switch to epsg
only, wkt is a much better way for users to add projections.
Chris
Adrian Custer wrote:
Hey all,
I spent the afternoon trying Geotools with epsg-hsql only. Seems like
everything works! We have a minor test failure against a method in the
WMS module but that method is actually wrong *and* inefficient so I
imagine we'll fix it.
What's the feeling of switching trunk over?
We could change all the pom's and hammer the result for a week then
delete epsg-wkt (trunk only)!
Would doing this next week work without interfering with your schedules?
Hopefully, we can confirm this at the IRC but if you are not going to be
there, let us know if this could interfere with your releases or other
work.
--adrian
Jody, was going to answer you but Martin beat me to it. Good thing too,
since he is your man for all your referencing module questions.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:4005,47a0f77e85622143011171!
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
