On Thu, 2007-09-20 at 08:31 -0700, Justin Deoliveira wrote: > Ok, let me make sure I am getting this right. So the following code > should generate a warning: > > SimpleFeatureTypeBuilder b = new ...(); > b.setName( "foo" ); > b.add( "geometry", Point.class ); > SimpleFeatureType type = b.buildFeatureType(); > > But the following code should not: > > SimpleFeatureTypeBuilder b = new ...(); > b.setName( "bar" ); > b.setCRS( null ); > b.add( "geometry", Point.class ); > SimpleFeatureType type = b.buildFeatureType();
Absolutely. The user is showing they are aware there is no CRS rather than unaware CRS's even exist. > > > > Does that work for you? Perhaps this is already the case. > > > The way the builder is written now it is ok for the crs to be set to > null, and there is no default. By default geometries would have CRS's of null. You are saying the Feature itself would not have a CRS? I thought we decided that we didn't understand what the feature having a CRS actually meant and so decided to drop it. > Looking at that page I do have one issue with > one of the code examples. Its the the "Multiple CRS for Geometries". The > setCRS(..) method is not meant to be called twice. It is setting > "global" state so it should really be called once. When setting "per > attribute state" the crs(..) method should be used. > > For instance, until recently feature types themselves had a crs. This > has been removed now but the setCRS would map to that crs, the one of > the feature type itself. And actually in implementation one thing we > might actually want to do is set the crs as user data. By using setCRS > to set the global context for each attribute that is added you are > clobbering it each time. > > Is that making sense? No, sorry. I don't see the difference. What does the .crs(..) call do? It returns the builder in its new state right? How is that different than setting the global state? > > I also think that in the first example, the "chaining" alternative > should be removed. The intent of chaining is to provide a nice way to > differentiate between global and per attribute state, not to make the > code sample less lines of code. Again, I don't get the distinction. > So I suggest we remove it as its just > one less thing for the user to see, and stick to using chaining where > there is an actual need for it. passing the $ to jody... --avc ------------------------------------------------------------------------- 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
