From: Adrian C. <ac...@gm...> - 2008-01-30 21:21:05
|
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. |
From: Chris H. <ch...@op...> - 2008-01-30 21:59:58
Attachments:
cholmes.vcf
|
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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4005,47a0ea5064701849620573! > |
From: Andrea A. <aa...@op...> - 2008-01-30 22:14:41
|
Chris Holmes ha scritto: > 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) Hem, we're using epsg-extension for that, not epsg-wkt :) Cheers Andrea |
From: Adrian C. <ac...@gm...> - 2008-01-30 22:17:27
|
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 > > Geo...@li... > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > !DSPAM:4005,47a0ea5064701849620573! > > |
From: Chris H. <ch...@op...> - 2008-01-30 22:59:53
Attachments:
cholmes.vcf
|
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 >>> Geo...@li... >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> > > > !DSPAM:4005,47a0f77e85622143011171! > |