Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
Hi again; Can you give an example of what you mean by above? What is an example of a data format and how does a data format specify its CRS. Sure - a shapefile is a common data format that is made up of the following files: - file.shp - holds the geometry (we parse these into a JTS Geometry and you can get it out as the default geometry) - file.shpx - some kind of index - file.dbf - the attributes stored as a dbase3 dbf file - file.prj - a little text file with the projection information stored in WKT; this is turned into a CRS For PostGIS the information comes from: - any old table - holds the attributes; including geometry attributes - geometry_columns table - holds a list of all the geometry columns used; and records the SRID - spatial_ref_sys table - holds a table of SRID numbers and the WKT definitions of the CoordinateReferneceSystem for each SRID Does that help? Each spatial data format has a different way of holding this kind of information. This (udig) was a great visual example to make your point that features from different sources using different CRS can all be used in the same map. How does udig determine what CRS to use for each feature set loaded from a shape file? Where in the code is that determination done? uDig does not really know what kind of data it is working with; it trusts the FeatureType.getDefaultGeometry().getCoordinateReferenceSystem(). Behind the scenes shapefile and postgis handle things differently. All the best, Jody - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
[Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
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. What are these fields set to when a JTS Geometry is stored after being mapped from a GML geomtery? 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? Is there a userObject always specified to stored the srsName? Does the srid and srsName refer to the CRS used by GML representation? Why do we need need to store both srid and srsName? Thanks for any guidance. -- 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/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
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? 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.) 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 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. 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. Jody - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
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/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
Farrukh Najmi wrote: I was looking at trunk/modules/library/main/src/main/java/org/geotools/gml/SubHandlerPolygon.java and other classes there. I think that is the SAX parser; it does GML2 as I understand it. 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? correct 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. Yes. The JTS Geometry (and its coordiantes) don't care; it is the Feature that cares about the CRS. 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.). No they are not; what is stored is the data as it was read in. And the FeatureType stores the CRS. Those two bits of information is enough for you to do your work. You cannot use a Geometry on its own. If so what is that CRS and where in the code is the conversion between Feature specific CRS and normalized CRS? Let me try writing a code example from memory FeatureType schema = feature.getFeatureType(); Geometry geometry = (Geometry) feature.getDefaultGeometry(); CoordianteReferenceSystem crs = schema .getDefaultGeometry().getCoordianteReferenceSystem(); My apologies for asking some pretty low level questions and with a relatively limited knowledge of the code base. Heh; so lets focus on getting you going; no more appologizes on either side - we need to make it work for you. 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. I hope the above clarification helps; the geometries are stored as is; the data about what they mean (the CRS) is stored in the FeatureType. 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. that is the wrong assumption. 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. That is close but also not the right assumption. Geometries are stored in a CRS according to their data format; the application can transform from this representation to what the application is using 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 does not; the application knows enough to modify its request into the data CRS and make the query. Can you download the following application that I am working on and give it a go; http://udig.refractions.net/ You can load up shapefiles and WFS from different locations with different CoordinateReferenceSystems and see how it works. 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. Not to worry; we need these conversations in order to get our user guide in order. Jody - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-gt2-users mailing list Geotools-gt2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping
Jody Garnett wrote: Farrukh Najmi wrote: I was looking at trunk/modules/library/main/src/main/java/org/geotools/gml/SubHandlerPolygon.java and other classes there. I think that is the SAX parser; it does GML2 as I understand it. 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? correct 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. Yes. The JTS Geometry (and its coordiantes) don't care; it is the Feature that cares about the CRS. 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.). No they are not; what is stored is the data as it was read in. And the FeatureType stores the CRS. Those two bits of information is enough for you to do your work. You cannot use a Geometry on its own. If so what is that CRS and where in the code is the conversion between Feature specific CRS and normalized CRS? Let me try writing a code example from memory FeatureType schema = feature.getFeatureType(); Geometry geometry = (Geometry) feature.getDefaultGeometry(); CoordianteReferenceSystem crs = schema .getDefaultGeometry().getCoordianteReferenceSystem(); My apologies for asking some pretty low level questions and with a relatively limited knowledge of the code base. Heh; so lets focus on getting you going; no more appologizes on either side - we need to make it work for you. 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. I hope the above clarification helps; the geometries are stored as is; the data about what they mean (the CRS) is stored in the FeatureType. 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. that is the wrong assumption. 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. That is close but also not the right assumption. I am almost getting it now thanks to your help :-) Geometries are stored in a CRS according to their data format; Can you give an example of what you mean by above? What is an example of a data format and how does a data format specify its CRS. the application can transform from this representation to what the application is using when needed. Rest of your explanation is very clear. This possibility seems to be questionable because it prevents the ability to do global spatial queries across data from different feature types. It does not; the application knows enough to modify its request into the data CRS and make the query. Can you download the following application that I am working on and give it a go; http://udig.refractions.net/ You can load up shapefiles and WFS from different locations with different CoordinateReferenceSystems and see how it works. This (udig) was a great visual example to make your point that features from different sources using different CRS can all be used in the same map. How does udig determine what CRS to use for each feature set loaded from a shape file? Where in the code is that determination done? Thanks again. 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. Not to worry; we need these conversations in order to get our user guide in order. Jody -- Regards, Farrukh Najmi Web: http://www.wellfleetsoftware.com - This SF.net email is sponsored by: Microsoft Defy all challenges.
