Even, Thanks for pointing out that this GDAL 1.8.0 bug was fixed 6 months ago.
Unfortunately, GDAL 1.8.1 has not been released, no plans have been announced
for the release of GDAL 1.8.1.
The predicament is that GDAL 1.8.0 must be used to use gdallocationinfo, but
GDAL 1.7.3 (and not GDAL 1.8.0)
Terima kasih, che' Himly! This is indeed a complex situation!
Here's to hoping that support for these Hotine projections comes to
PROJ/GDAL/OGR soon!
Howard
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Michigan-GeoRef-Michigan-Oblique-Mercator-EPSG-3078-tp6517423p651
The problem is best summarised by Mikael Rittri here;
http://osgeo-org.1803224.n2.nabble.com/RSO-gamma-and-Hotine-Oblique-Mercator-Variant-A-td6256795.html
He has also created a ticket here: http://trac.osgeo.org/proj/ticket/104
Unfortunately, I'm still waiting for the issue to be resolved. A wor
Thank you for the suggestions, Steve.
The projection parameters for the list you derived are pretty much the same
as the PROJ4 format of EPSG:3078, with the exception of the display unit (m
vs ft) and the datum (NAD27 vs NAD83). I've tried most of them (but not the
NAD27 versions), and I've als
Hi Frank,
Il 26/06/2011 13:42, Frank Warmerdam ha scritto:
> On 11-06-26 06:34 AM, Antonio Valentino wrote:
>> Hi Frank,
[...]
>> Looking deeper into the ceos2 code it seems to me that the "recipe" for
>> decoding ALOS-PALSAR products do not match at all specifications I can
>> find at
>>
>> htt
Le dimanche 26 juin 2011 17:02:46, Greg Coats a écrit :
> GDAL 1.7.3, released 2010/11/10, for Mac OS X 10.6, acquired from
> http://www.kyngchaos.com/software:frameworks, properly reads geo
> referenced raster images of Type=Float32. For the example 468 MB image,
> gdalinfo properly reports Type=F
GDAL 1.7.3, released 2010/11/10, for Mac OS X 10.6, acquired from
http://www.kyngchaos.com/software:frameworks, properly reads geo referenced
raster images of Type=Float32. For the example 468 MB image, gdalinfo properly
reports Type=Float32, and Computed Min/Max=35.024,748.615.
GDAL 1.8.0, rel
I'm not sure how this works in gdal/ogr, but proj library uses the tag
before the ":" as the name of a file containing the projection data.
gdal/ogr may use an different database of projection information.
Anyway, the following show these projection definitions:
$ grep "Michigan GeoRef" /usr/s
All,
I was wondering if there has been any progress in addressing the various
problems associated with correctly projecting to and from Michigan Oblique
Mercator (EPSG:3078 and its brethren), as brought up in tickets 2475, 3038,
and 3311, among others.
As you may know, the State of Michigan, USA,
On 11-06-26 06:34 AM, Antonio Valentino wrote:
Hi Frank,
Il 18/06/2011 14:38, Frank Warmerdam ha scritto:
On 11-06-18 02:59 AM, Antonio Valentino wrote:
[CUT]
Palsar products are in CEOS format so IMHO it would be nice to setup a
general mechanism to decode CEOS records (a similar job has b
On 11-06-26 06:51 AM, Nuo wrote:
Frank, I really appreciate your reply.
I thought it was but, actually, it is a ".aux.xml" file generated by ArcGIS
9.3.1 during the georeferencing process.
http://webhelp.esri.com/arcgiSDEsktop/9.3/index.cfm?TopicName=About_auxiliary_files
So, it is impossible
Frank, I really appreciate your reply.
I thought it was but, actually, it is a ".aux.xml" file generated by ArcGIS
9.3.1 during the georeferencing process.
http://webhelp.esri.com/arcgiSDEsktop/9.3/index.cfm?TopicName=About_auxiliary_files
So, it is impossible to preserve the georeference inform
Hi Frank,
Il 18/06/2011 14:38, Frank Warmerdam ha scritto:
> On 11-06-18 02:59 AM, Antonio Valentino wrote:
[CUT]
>> Palsar products are in CEOS format so IMHO it would be nice to setup a
>> general mechanism to decode CEOS records (a similar job has been done
>> for ENVISAT records recently)
[
13 matches
Mail list logo
