<div dir="ltr">Thanks for your timely response. Well the PDF was generated at the source by different form such that I didn't face this problem, that new version of the file worked for me.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 7:20 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le lundi 14 décembre 2015 13:25:13, Rahkonen Jukka (MML) a écrit :<br>
> Hi,<br>
><br>
> There is something odd in the PDF. It is without coordinate system and<br>
> perhaps because of that the top-left coordinates are (0,0) and north<br>
> coordinate is increasing from top to bottom. Probably the "Invalid length<br>
> for GPTS object" error does not have any effect on this.<br>
<br>
</span>It does have an effect. The error messages indicates that the geospatial tags<br>
are ignored, thus the non-georeferenced coordinates which are displayed.<br>
<br>
I've looked at that file a bit and the georeferencing is unusual. It uses Adobe<br>
ISO 32000 georeferencing but with only 2 tie-points instead of 4 as usual. The<br>
spec doesn't mention the number of tie-points, but the driver assumes 4, based<br>
on test samples. It has also unusual MediaBox coordinates (non 0 lower left<br>
corner)<br>
I've removed locally the limitation and did some fiddling in the code to<br>
generalize it, but I don't manage to get a good overlay with a basemap. I can<br>
get something roughly in the target area, but there is a rotation term that is<br>
clearly missing. But with only 2 tiepoints, the solver of GCPs to geotransform<br>
cannot produce any rotation term and assumes linear stretching of coordinates.<br>
You have to make assumptions as you've the 6 coefficients of the geotransform<br>
matrix to compute, but only 4 equations. In that case, to recover rotation<br>
terms, it would probably have to make the assumption that the pixels are<br>
square instead (you'd have only 4 unknowns: x,y of top-left corner, pixel<br>
size, rotation angle). I didn't investigate further for now. But it seems<br>
unwise from the data producer to produce only 2 tiepoints because of the above<br>
mentionned ambiguity. As far as I can see, the PDF spec doesn't tell what to<br>
do in that case.<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></font></span></blockquote></div><br></div>