Jody Garnett wrote: > Farrukh Najmi wrote: >> Dear colleagues, >> >> Looking at geotools GML code its not clear to me how it uses the srid >> and userData fields of the com.vividsolutions.jts.geom.Geometry class. >> > Which GML code did are you looking at specifically? > - SAX parser? I think it sets the srsName to the userData object > - DOM parser? > - XDO parser? > - XSD-XML parser?
I was looking at trunk/modules/library/main/src/main/java/org/geotools/gml/SubHandlerPolygon.java and other classes there. > > In general I don't know what these parsers do for a JTS Geometry > object; because the CRS information is stored at the Feature level in > GeoTools right now (there is no set convention for how to handle JTS > Geometry srid name and userData object; because that convention would > be for a specific application.) In other words its left up to the application? >> What are these fields set to when a JTS Geometry is stored after >> being mapped from a GML geomtery? >> > GML Geometry comes back as a JTS Geometry with the correct coordinates This is where my mental block is. What CRS are these "correct coordinates" in? I am assuming in the CRS for the Feature in question. Based on a past thread I recall you saying that geometries are stored in a normalized CRS (ie. all stored geometries are in the same CRS.). If so what is that CRS and where in the code is the conversion between Feature specific CRS and normalized CRS? >> What are these fields set to when a JTS Geometry is read back before >> being converted to a GML Geometry? >> >> Specifically: >> >> Does the persistent JTS Geomtery object's always have srid defined? >> > no it does not. >> Is there a userObject always specified to stored the srsName? >> > no it does not. >> Does the srid and srsName refer to the CRS used by GML representation? >> > The GML specification only talks about srsName; we have chosen to > convert this information into a CoordinateReferenceSystem and hold it > as part of the FeatureType information. >> Why do we need need to store both srid and srsName? >> > We don't need to store either. >> Thanks for any guidance. >> > I am sorry this is such a muddle for your; JTS Geometry is defined by > the Simple Feature for SQL specification and does not really line up > with GML in any way (literally they are a different model at a very > technical level; JTS has LineStrings, GML has Curves made up of > LineStrings). We are faking this mapping for you because JTS is > available now and works - some information (like GML srsName) is lost > along the way. My apologies for asking some pretty low level questions and with a relatively limited knowledge of the code base. > > Now if you would like the srsName to be saved as the userData object > by each and every parser; that may be a good idea - and we can take it > up with the developers list. First we need to determine if that is necessary. I though it was necessary because I cannot see how else one could store geometry instances in a normalized CRS and read it back in an app specific (or is that feature-type specific?) CRS. I suspect I have a fundemental lack of undertstanding still of how geometries are stored and read back. Just to be clear. I am (most likely incorrectly) assuming that all geometries for all features are stored in a normalize CRS and that when they are read as part of reading of features they are converted to an app-specific CRS. A different possibility could be that geometries are stored in app-specific CRS and it is up to the app to convert it to whatever app-specific crs when needed. This possibility seems to be questionable because it prevents the ability to do global spatial queries across data from different feature types. It would go a long way if you could clear up some of these fundamental understanding issues perhaps by way of a simple example. I am very aware and grateful for the time it takes for you and other dev team members to clear up these understanding issues. Once my understanding is clear I could write some content for consideration in the manual. Thanks again. -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com ------------------------------------------------------------------------- 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-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
