Here is link to GeoPDF which is inverted when converted to GeoTIFF
https://drive.google.com/file/d/0B4shTM1bPS5TNHBDVG45RzdWYjA/view?usp=sharing
Is it a problem in PDF or something with the PDF driver rotation.
Thanks
Gane
___
gdal-dev mailing list
g
Hi,
There is something odd in the PDF. It is without coordinate system and perhaps
because of that the top-left coordinates are (0,0) and north coordinate is
increasing from top to bottom. Probably the "Invalid length for GPTS object"
error does not have any effect on this.
gdalinfo loopmap.
Le lundi 14 décembre 2015 13:25:13, Rahkonen Jukka (MML) a écrit :
> Hi,
>
> There is something odd in the PDF. It is without coordinate system and
> perhaps because of that the top-left coordinates are (0,0) and north
> coordinate is increasing from top to bottom. Probably the "Invalid length
> f
Hello,
I'm implementing a gdal raster driver for an internal file format and am
getting results I do not understand. The output is a binary raster of
32-bit floating point data, but the resulting file contains single bytes of
value 0x0D at seemingly random intervals throughout the data.
Within my
0x0d is a carriage return. Someone is using character I/O somewhere. It’s
possible they are appearing after ‘nul’ characters 0x00 bytes or some such.
George Watson
Principal, Sierra Computing
wat...@sierracmp.com
> On Dec 14, 2015, at 10:52 AM, Jerry Tol wrote:
>
> Hello,
> I'm implementing
Thank you - interesting theory but none of the carriage returns occur after
a null, and I'm using gdalwarp to test the driver, so I see no reason for
character io to occur on the output.
Another useful bit of info: the problem does not occur if I specify -ot
Int16. I get random carriage returns on
Problem Solved.
Mr. G Watson provided the solution. Specifically, I had specified "w" in my
call to VSIFOpen. The carriage returns rightfully disappeared
after changing the mode to "wb".
What threw me off was the fact that the problem did not occur when using
Int16 output. Ugh, another beginner m
