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" <[EMAIL PROTECTED]>
To: "Simone" <[EMAIL PROTECTED]>
Cc: "Geotools-Devel list" <geotools-devel@lists.sourceforge.net>
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
> 


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to