Re: [Geotools-gt2-users] Use of JTS Geometry srid and userData in GML to JTS mapping

[Farrukh N. <fa...@we...>]

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