> Just to clarify, setCRS only exists for the builder API. And the only > thing it does is mark down what > the current CRS is for the builder, that current CRS will be used > whenever a GeometryDescriptor is > created. Correction, it will be used whenever a geometry descriptor is created and a crs was not set *explicitly*. ie. In this case it will be used:
builder.setCRS( crs1 ); builder.add( "geometry", Point.class ); In this case it will not: builder.setCRS( crs1 ); builder.crs( crs2 ).add( "geometry", Point.class ); >> We suggest therefore that a user be allowed to set a CRS to null, e.g. >> via a call .setCRS(null). That would allow the user to use geometries >> for which they do not know the CRS but force them to set that >> explicitly. Once the CRS is set to null (or to any other value), no >> WARNING would be emitted. >> >> Does that work for you? Perhaps this is already the case. >> > That is a good move guys; it shows that the user is FORCING the CRS to > be null. I am sure we have a static constant for a cartisian crs that > would also work (say ImageCRS?) - but yes as long as the user tells us > explicitly that the crs is unknown then we should be good. Well I think null should be the default, as well as being able to set it explicitly. Setting a crs when the user has not specified is just bad practice imho... i dont see it as something you can come up with a "sensible" default for. > > (so warning rather than IllegalStateException if a Geometry is added > when no CRS has been provided) >> Note also I changed the Simple example your page: >> http://docs.codehaus.org/display/GEOTDOC/Feature+Model+Guide >> to set the CRS before adding the geometry because I figured we wanted to >> encourage 'good practice' in the doc. We should add, in one of the >> alternative sections, .setCRS(null) if and when such functionality >> exists. >> > Okay I will add that now. Also added setCRS to the simple case example. > > Jody >> --adrian >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > !DSPAM:4007,46f2a28e134773668746562! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
