From: Simone <sim...@gm...> - 2007-03-01 12:25:23
|
Ciao Andrea, The problem is subtle hence there is no easy way to solve it, especially because even if OGC and ISO are trying to convince us that coverages are feature, 99% of people that use them tend to use them quite differently, at least IMHO, hence having real consistency tends to be difficult. Usually people see features that always contain geographic information. Sometimes the CRS is missing but it is not because the data is not gelocated but just because some assumed that all the world would guess or understand the CRS anyway. Therefore it makes sense to force a feature source to a certain CRS. We are making the implicit assumption that the features are always geolocated and 99% of the time this is correct. When it comes to coverage things are quite different, at least IMHO. Sometimes it happens that the people behave the same way they behave with features, that is they just forget about the CRS and assume the word will come along and guess it on its own. Most part of the time, things are different; when there is no spatial CRS it means that there is no spatial CRS not that we are asksing someone else to guess it. To give an example, these days I am working with some remote sensing data from MODIS-AQUA (sea suface temp, chlora and other things I don't even know the name...). This data does not have associated a CRS because it has not been georectified yet. It has some GCP that one could use to geolocate and then georectify this data set. Should I force this dataset to have some spatial CRS? The answer is no since we got to preserve the geolocation information. Someone would be tempted to say, ok, this is not of bing interest since we want serve this data using OWS services. Wrong, WCS explicitly support serving coverages using an ImageCRS for non georeferenced data. I have always found WCS spec more reasonable than ISO 19123 or GC IS, and this time is no exception. I like consistency when it is an added value, I don't like it when it is requested to help non-experienced users but it adds confusion for experienced users. For the moment me and Alessio decided just to ignore this problem since the solution must be well-thought and to be honest we didn't have much time to spend on this :-). Just sharing some spare thoughts. Ciao, Simone. ------------------------------------------------------- Eng. Simone Giannecchini President/CEO GeoSolutions http://www.geo-solutions.it Via Carignoni 51 550141 Camaiore (LU) Italy Mobile: +39 333 81 28928 ------------------------------------------------------- ----- Original Message ----- From: "Andrea Aime" <aa...@op...> To: "Simone" <sim...@gm...> Cc: "Geotools-Devel list" <geo...@li...> Sent: Thursday, March 01, 2007 9:14 AM Subject: Handling data with no CRS > From a geotools-users thread: > >>> This can cause some griefs >>> > since as of now <ArcGridReader is assuming WGS84 if no CRS is >>> > provided. >> >> I've seen this in world images as well. I do believe the correct >> behavior would be not to assume anything, and return a null CRS. >> That's what vector datastore do, so it would be consistent. >> (it may be my fault if in origin they did return WGS84... well, >> I guess I was wrong :-) ) > > > Simone ha scritto: >> Ciao Andrea, >> actually I was thinking that when we change this, since I agree that we >> need to change this, we should defaul to ImageCRS because it could the >> case of having an image without CRS or an image which is no georectified >> but only geolocated by a certain numbers of Ground Control Points or the >> like. This might be non-consistent with Feature but >> that's hwo people expect things to be hande, IMHO at least :-). > > Hmmm... it makes sense, but I like consistency. Following this approach, > on the vector side we would have to use DefaultEngineeringCRS instead of > null. > > I was considering this from the Geoserver angle too. If an image has > an ImageCRS we should force onto it the CRS declared on the > configuration panel (that is, have a way to make the in memory grid > coverage assume that CRS, and thus influence reprojection during > rendering and data serving accordingly). > > Cheers > Andrea > |