Jacob - sounds right.<br>
<br>
With respect to affine and sheared registrations - the situation is
that it isn't possible to store them in the header of an ECW file (the
file header stores world origin and world cell size rather than affine
values). There is nothing to stop an application such as ArcGIS
from reading the raster data and applying an affine transformation to
it based on some other content - such as a world file - or creating an
auxiliary file when saving a working set out to ECW. But a
problem can then arise if the dataset gets separated from the metadata
file.<br>
<br>
Cheers<br>
<br>
Tom.<br><br>On 6/10/05, Jacob Delfos <<a href="mailto:jacob.delfos@maunsell.com">jacob.delfos@maunsell.com</a>> wrote:<br>> <br>> Hi Tom, <br>> <br>> Thanks for that explanation. Now I understand where the WGS84/LOCAL info
<br>> keeps coming from. So probably ArcGIS doesn't like that dataset, because the<br>> SDK (or Gdal) didn't put this fake coordinate system in it. It could be<br>> because of the inverted Y sign, but if I copy the .tfw (of the original TIF)
<br>> to a .eww, ArcGIS reads and registers the ECW fine. <br>> <br>> Regarding rotated and sheared registrations: ArcGIS allows you to<br>> georeference an ECW, and as long as you use an affine projection, it will
<br>> create a .eww file for it (with rotation or shear if applicable). So is this<br>> technically incorrect? <br>> <br>> regards, <br>> <br>> Jacob<br>> <br>> <br>> <br>> <br>>
<br>> -----Original Message-----<br>> From: Tom Lynch [mailto:<a href="mailto:tflynch@gmail.com">tflynch@gmail.com</a>] <br>> Sent: 10 June 2005 09:43<br>> To: Delfos, Jacob<br>> Cc: <a href="mailto:gdal-dev@remotesensing.org">
gdal-dev@remotesensing.org</a><br>> Subject: Re: [Gdal-dev] ECW registration information not recognised in ESRI <br>> <br>> On 6/10/05, Delfos, Jacob <<a href="mailto:jacob.delfos@maunsell.com">jacob.delfos@maunsell.com
</a>> wrote:<br>> > <br>> > <br>> > Hi All, <br>> > <br>> > Have a bit of a mystery: <br>> > <br>> > I am translating some geotiffs to ecw. These geotiffs have their<br>> geographic
<br>> > information internally in the headers, as well as in a tfw file. They all<br>> > translate fine, and the coordinate information in the ecw file is<br>> recognised<br>> > in ESRI ArcGIS. <br>> <snip>
<br>> <br>> Hi Jacob, <br>> <br>> There are some subtleties in ECW georeferencing, which I can explain<br>> for you. I think the issue you're seeing is probably a minor flaw in<br>> GDAL, though I haven't checked this.
<br>> <br>> ER Mapper uses a proprietary georeferencing system called GDT (which<br>> AFAIK predates the popularisation of EPSG) in which a dataset is<br>> referenced by a projection string, a datum string, and registration
<br>> information. <br>> <br>> This data is embedded in a binary header of an ECW file, and includes<br>> x and y origins, x and y cell sizes, and cell size units, as well as<br>> the projection and datum. For example, "WGS84/GEODETIC" is one of the
<br>> most common datum/projection pairs, corresponding to EPSG code 4326. <br>> <br>> ER Mapper supports importing datasets with EPSG codes using an<br>> in-built correspondence between EPSG and GDT. Usually non-geographic
<br>> rasters are stored with RAW/RAW as their projection/datum. However,<br>> if a raster marked RAW/RAW also contains embedded georeferencing<br>> information (such as you might find in a TFW) indicating it has a
<br>> geographical purpose, it is imported into ER Mapper software with a<br>> "fake" projection/datum "WGS84/LOCAL" allowing it to be world-aligned<br>> with datasets in other map layers. <br>
> <br>> There are several flaws in the system. One of them is that the<br>> EPSG<-->GDT correspondence is not 1-1, so converting between a GeoTIFF<br>> and an ECW file and back again may lose or change the referencing.
<br>> Another is that ECW does not support the storage of rotated or sheared<br>> registrations (only origin and pixel scale are supported). Finally,<br>> non-EPSG coordinate system information embedded in a GeoTIFF will
<br>> usually be ignored by ER Mapper software at this point in time. <br>> <br>> As far as registration is concerned, the ECW JPEG 2000 SDK is fairly<br>> "blind" concerning the binary values stored in the registration area
<br>> of an ECW file, so third party applications may store invalid data in<br>> this location. ArcGIS is one application that has problems if (for<br>> example) the sign of the y cellsize is inverted. So that's probably
<br>> the reason you can't view the GDAL-translated file in ArcGIS with the<br>> ECW plug-in. <br>> <br>> -- <br>> Tom Lynch<br>> Development, ER Mapper<br>> Phone: +61 8 93882900<br>> Fax: +61 8 93882901
<br>> Email: <a href="mailto:tom.lynch@ermapper.com">tom.lynch@ermapper.com</a><br>> Web: <a href="http://www.ermapper.com">http://www.ermapper.com</a><br>> Forums: <a href="http://forum.ermapper.com">
http://forum.ermapper.com</a><br>> <br>> <br>> _______________________________________________<br>> Gdal-dev mailing list<br>> <a href="mailto:Gdal-dev@xserve.flids.com">Gdal-dev@xserve.flids.com</a><br>
> <a href="http://xserve.flids.com/mailman/listinfo/gdal-dev">http://xserve.flids.com/mailman/listinfo/gdal-dev</a><br>> <br>> <br>> <br><br><br>-- <br>Tom Lynch<br>Development, ER Mapper<br>Phone: +61 8 93882900
<br>Fax: +61 8 93882901<br>Email: <a href="mailto:tom.lynch@ermapper.com">tom.lynch@ermapper.com</a><br>Web: <a href="http://www.ermapper.com">http://www.ermapper.com</a><br>Forums: <a href="http://forum.ermapper.com">
http://forum.ermapper.com</a><br>