Ciao Adrian,
thanks for the fixes...

On Jan 31, 2008 12:44 AM, Adrian Custer <[EMAIL PROTECTED]> wrote:
> Hey Simone,
>
> 1) committed the removal of the CRS output as of rev. 29003.
>
> 2) can I do the same in the image module, gce.image.WorldImageReader
> line 630, which has the same kind of CRS output, for WGS84 (DD) this
> time?

+1

>
> 3) I'm not touching the throws clause because that seems serious and I
> don't want to delve into this code as much as I would require of myself
> to do that.
>
> 4) Don't overestimate the frequency of WGS84, lots of people digitize
> maps. :-)
>
> 5) The code block I really didn't understand was:
>
> /**
>  * Default [EMAIL PROTECTED] CoordinateReferenceSystem} used by all the 
> plugins.
>  */
> private static CoordinateReferenceSystem crs;
> static {
>        try {
>                crs = CRS.decode("EPSG:4326", true);
>        } catch (NoSuchAuthorityCodeException e) {
>                crs = DefaultGeographicCRS.WGS84;
>        } catch (FactoryException e) {
>                crs = DefaultGeographicCRS.WGS84;
>        }
> }
>
> in AbstractGridFormat, which seems like a lot of work if all you want is
> the static WGS84 and looks like catching the FactoryException the first
> time is not going to do much good.
>

Sorry, but I am pretty tired hence I did not get your point here.
The code is trying to instantiate an EPSG:4326  CRS first, failing
that (which is quite unlikely to happen) is tries with
DefaultGeographicCRS.WGS84.


Ciao,
Simone.

> good night,
> adrian
>
>
>
> On Thu, 2008-01-31 at 00:16 +0100, Simone Giannecchini wrote:
> > Ciao Adrian,
> > I checked the code a bit and I would suggest to remove (I don't have
> > the *actual* code here now) the second part of the stringbuffer so
> > that w don't get the wkt of wgs84 if that is causing headaches. About
> > the level of the exception, I think that INFO is appropriate, probably
> > warning would be better, since not having a propoer CRs could cause
> > problems afterwards.
> >
> > About how this piece of code works, here is the explanation:
> >
> > 1> look for a file_name.prj file, if found go to 2 else goto 4
> > 2> try to parse the prj file if an error occurs goto 4 else goto 3
> > 3> use the parse CRS and exit
> > 4> use a default CRS and exit
> >
> > Of course one coudl wonder why we used WGS84 as the standard CRS. The
> > answer is easy. 99% of the time people forget the prj when data is
> > WGS84; I would 'have preferred using an engineering coordinate
> > reference system, like the image crs, but then things would get much
> > worse (I tried that approach hence I know :-) ) when putting data
> > inside geoserver.
> >
> > It would be great if you could apply the change your self,
> > Simone.
> >
> > On Jan 30, 2008 11:48 PM, Adrian Custer <[EMAIL PROTECTED]> wrote:
> > > Hey Simone,
> > >
> > > Found it!
> > >
> > > At the end of
> > >  ArcGridReader.getCoordinateReferenceSystem()
> > > you have:
> > > if (crs == null) {
> > >        crs = AbstractGridFormat.getDefaultCRS();
> > >        LOGGER.info(new StringBuffer(
> > >                        "Unable to find crs, continuing with default WGS4 
> > > CRS")
> > >                        /*.append("\n").append(crs.toWKT()).toString()*/);
> > > }
> > > with the comment markers my own.
> > >
> > > 1) does this need to be at the info level?
> > >
> > > 2) Since you create the crs in a static initialization structure in
> > > AbstractGridFormat don't you know what it is? Why do you want to see it
> > > again?
> > >        (I'm not exactly sure how your code works since you are doing
> > >        the same thing twice, the second time in response to a
> > >        FactoryException your first try could have caused. Won't the
> > >        second attempt cause exactly the same exception? Why are you
> > >        even trying the decode?)
> > >
> > > Thanks for any clarification,
> > > --adrian
> > >
> > >
> > >
> >
> >
> >
>
>



-- 
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041  Camaiore (LU)
Italy

phone: +39 0584983027
fax:      +39 0584983027
mob:    +39 333 8128928


http://www.geo-solutions.it

-------------------------------------------------------

-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to