<div dir="ltr"><div><div><div><div><div><div><div>Jukka, Richard,<br><br></div>        firstly, ESRI contracted the late John P Snyder, from USGS, to design and initially implement their projection tools.  The team now maintaining and developing this code has a highly respected pedigree.  Whilst mistakes *do* happen, I think the ESRI code will most likely be reliable.  There may, of course, be issues of usage.<br><br></div>        There are a number of potential factors that also require consideration - some PC chipsets, for example, are still reputably unreliable for floating point maths!  I would, however, expect such to affect both approaches equally and so, effectively, to cancel out.<br><br></div>         I am intrigued by the choice of Second Order polynomial.  The vast majority of users do not need to consider such usage, so I guess a question for Richard is why - and whether he has bibliography (or a suitable DEM) supporting this choice for his context.  Back in the days when it was deemed necessary for me to teach students the projection maths, I used to give them a 3rd order equation and an aerial photograph for which one specific area had just one GCP: the result was that this area was extruded from the main image in a rather dramatic fashion (it was visually fine with a First Order and nothing like as dramatic with a Second Order polynomial.  To 'lose' data, as you describe, suggests that this portion is computing to NODATA: possibly indicating a GCP coding error.  I think it would be sensible to back off this part of the specification for now, to see what impact it is having.<br><br></div>        Lastly, for now, how are your GCPs arranged?  Do you have the 'standard five' of some introductory texts (eg four corners and centre)?  Or do you have a more dense pattern?  Are you using elevation control?  If so, how does this relate to your GCPs (do your GCPs define breaks of slope, for example)?<br><br></div>        An excellent text, with well explained equations, for your purposes may be "Map Projection Transformation: Principles and Applications" by Qihe Yang, John P Snyder and Waldo R Tobler and published by Taylor & Francis in 2000.   Snyder's introductions to map projections are generally available for download from USGS.<br><br></div>Enjoy!<br><br></div>Peter<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 April 2016 at 08:27, Jukka Rahkonen <span dir="ltr"><<a href="mailto:jukka.rahkonen@maanmittauslaitos.fi" target="_blank">jukka.rahkonen@maanmittauslaitos.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bischof, Richard <Richard.Bischof <at> <a href="http://lgln.niedersachsen.de" rel="noreferrer" target="_blank">lgln.niedersachsen.de</a>> writes:<br>
<br>
><br>
> Hi Jukka,<br>
><br>
> you're correct. ArcMap is doing the on-the-fly transformation with the<br>
dataset, I applied the gcps using<br>
> gdal_translate to.<br>
> With both gdal_warp and ArcMap Rectify I use second order polynomial.<br>
><br>
> I also found, that some areas of my source image are cut out from the<br>
gdal_warp destination dataset.<br>
><br>
<br>
Hi,<br>
<br>
I can't really help you but because I do not understand warping algorithms.<br>
If ArcMap and GDAL makes different output with 2nd order polynomial and with<br>
the same gcp set I can see three alternatives:<br>
<br>
1) GDAL is wrong<br>
2) ArcMap is wrong<br>
3) There are different interpretations about what should happen and both are<br>
right, or wrong.<br>
<br>
I suppose that what GDAL is doing is written in<br>
<a href="https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdaltransformer.cpp" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdaltransformer.cpp</a><br>
I fear we do not have the code used by ArcMap available for making a comparison.<br>
<br>
Can you simplify the case into a question like:<br>
With this gcp set, applied to an image of sixe xxx(W) by yyy(H) pixels,<br>
after 2nd order polynomial transformation with GDAL the source pixel (x1,<br>
y1) is moved into location (x2, y2) in pixel space, and (xxx(E), yyy(N)) in<br>
projected cooordinates in EPSG:xxxx.<br>
<br>
ArcMap moves this pixel into (x2', y2') (xxx'(E), yyy'(N)) and I think than<br>
one or the other is wrong. What do warping specialists think?<br>
<br>
-Jukka Rahkonen-<br>
<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></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">----------------------------------------------------------------------------------------------------------------<br>Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit (PRDU),<br>                      University of York<br><br>Snail mail: PRDU, Derwent College, University of York,<br>                Heslington, York YO10 5DD<br>This message has the status of a private and personal communication<br>----------------------------------------------------------------------------------------------------------------</div>
</div>