[Gdal-dev] SRS not properly defined
Frank Warmerdam
warmerdam at pobox.com
Sat Dec 17 15:01:30 EST 2005
On 12/17/05, Petteri Packalen <packalen at cs.joensuu.fi> wrote:
> I tested morphFromESRI but it didn't correct the problem. I solved the
> issue using OGRSpatialReference::importFromEPSG and
> OGRSpatialReference::exportToWkt methods. First I imported valid WKTs
> using EPSG codes, then I printed valid WKTs and pasted these into my code.
Petteri,
Ah, no need for morphToESRI() if the source of the WKT is the
importFromEPSG() method.
> I want to avoid additional dependencies in this particular program and
> therefore I don't want to include GDAL data directory into this project.
> That's the reason why I don't want to use importFromEPSG() in the final
> version.
I tried assigning EPSG:2391 to a .tif and a .img file with gdal_translate
and it worked fine for me. But then, the gdal/data files were findable.
I see in the case of TIFF, the actual EPSG authority code gets stored in
the TIFF file, and this can only be expanded again on reading if the
epsg support csv files are available.
I am not sure how it did work for you for the one coordinate system.
I also tried it for Erdas Imagine (.img) format and that too seemed to
work OK. In that case there *should* be no dependence on the .csv
files. I looked at EPSG:2391 and it is a pretty vanilla transverse mercator
projection, so there isn't anything "hard" about storing it.
If I get a chance, I'll try and reproduce the problem with your code.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the Gdal-dev
mailing list