Re: [OSSIM] Coordinates nightmare

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Julien,

Our base rpc models tested/scrutinized pretty thoroughly.  I have one 
Pléiades  dataset.  So I did some snooping.  This looks correct.  Note 
the image coordinates are "one" based in the xml doc and are being 
converted to zero based:

ossimPleiadesDimapSupportData::parseDatasetContent
// Correctly convert one based coords to zero based:
         xpath = "ROW";
          (*node)->findChildNodes(xpath, sub_nodes);
          if (sub_nodes.size() == 0)
          {
             setErrorStatus();
             return false;
          }
          ipt.line = sub_nodes[0]->getText().toDouble() - 1.0;

          sub_nodes.clear();
          xpath = "COL";
          (*node)->findChildNodes(xpath, sub_nodes);
          if (sub_nodes.size() == 0)
          {
             setErrorStatus();
             return false;
          }
          ipt.samp = sub_nodes[0]->getText().toDouble() - 1.0;

 From the support data:

DIM_PHR1A_PMS-N_201211030749010_SEN_582332101-001.XML

I see:

<Vertex>
             <LON>42.76410603898648</LON>
             <LAT>11.6752404633316</LAT>
             <COL>1</COL>
             <ROW>1</ROW>
          </Vertex>
          <Vertex>
             <LON>42.85594154647721</LON>
             <LAT>11.67782408645142</LAT>
             <COL>20124</COL>
             <ROW>1</ROW>
          </Vertex>
          <Vertex>
             <LON>42.8558853650386</LON>
             <LAT>11.58519941725167</LAT>
             <COL>20124</COL>
             <ROW>19546</ROW>
          </Vertex>
          <Vertex>
             <LON>42.76406436594095</LON>
             <LAT>11.58285731446637</LAT>
             <COL>1</COL>
             <ROW>19546</ROW>
          </Vertex>

And:

<Raster_Dimensions>
          <NROWS>19546</NROWS>
          <NCOLS>20124</NCOLS>

So given the above one can assume that the image coordinates are "ONE" 
based.

// Snip from test app:

$ ossim-image-geometry-test 
IMG_PHR1A_PMS-N_201211030749010_SEN_582332101-001_R1C1.TIF
ul.ipt:       (0,0)
ul.wpt: (11.6752436050574,42.7641077263937,-11.3152091413429,WGE)
ul.rpt:       (-0.000287487184323254,-0.000280536774880602)
ul.delta:     (0.000287487184323254,0.000280536774880602)

  <Vertex>
             <LON>42.76410603898648</LON>
             <LAT>11.6752404633316</LAT>
             <COL>1</COL>
             <ROW>1</ROW>
          </Vertex>

Not exact but close...

Take care,
Dave

On 07/07/2014 09:43 AM, Julien Michel wrote:
> Hi,
>
> Thanks to both of you for your answers. In fact, I think I was mixing 
> two different things here : correctly interpreting the pixel 
> convention (area or points) of a GeoTiff file when tags are available. 
> This is what your answers are mostly about, and this handled in gdal 
> and ossim (and in OTB now), and mainly applies to images that are 
> already georeferenced.
>
> But now I realise my real problem is in fact with RPCs models. They 
> give you (l,L) = f(r, c, h) but there is nothing said about how r 
> (rows) and c (columns) coordinates should be understood. Whatever the 
> pixel convention (area or point), we should know which reference has 
> been used to compute those RPCs (if I understand well NITF is not 
> specifying anything here). For instance, I now know for a fact that 
> Pléiades RPCs are estimated by considering that the coordinate of the 
> center of the upper-left pixel is (1,1). I also assume from my tests 
> that DigitalGlobe RPCs are estimated by considering that the 
> coordinate of the center of the upper-left pixel is (0,0), but I would 
> need someone to confirm, since documentation [1] is not precise enough.
>
> This information is very important and should be taken into account or 
> compensated in sensor modelling. In the end, everything should be 
> consistent with what :
>
> virtual void 	lineSampleToWorld 
> <http://trac.osgeo.org/ossim/doxygen/classossimSensorModel.html#5ca6b05925443ecbed79f6a89309dfab> 
> (const ossimDpt 
> <http://trac.osgeo.org/ossim/doxygen/classossimDpt.html> &image_point, 
> ossimGpt <http://trac.osgeo.org/ossim/doxygen/classossimGpt.html> 
> &world_point) const
> virtual void 	worldToLineSample 
> <http://trac.osgeo.org/ossim/doxygen/classossimSensorModel.html#f50426766ba0b0e425bfb3eaa11ef1b9> 
> (const ossimGpt 
> <http://trac.osgeo.org/ossim/doxygen/classossimGpt.html> &world_point, 
> ossimDpt <http://trac.osgeo.org/ossim/doxygen/classossimDpt.html> 
> &image_point) const
> virtual void 	lineSampleHeightToWorld 
> <http://trac.osgeo.org/ossim/doxygen/classossimSensorModel.html#4955de247d2e25ca429a5ebabe7fdb9a> 
> (const ossimDpt 
> <http://trac.osgeo.org/ossim/doxygen/classossimDpt.html> &lineSampPt, 
> const double &heightEllipsoid, ossimGpt 
> <http://trac.osgeo.org/ossim/doxygen/classossimGpt.html> &worldPt) 
> const =0
>
>
> await or give as ossimDpt (David you might be able to tell ?). The 
> least we know now is that Pléiades and other RPC models in OSSIM are 
> not consistent with each other, and that at least one of them need a 
> fix, but the picture is still too blurry to know exactly what to do.
>
> Thanks for your help,
>
> Regards,
>
> Julien
>
> [1]  p. 11 of 
> http://www.digitalglobe.com/sites/default/files/ISD_External_0.pdf
>
> Le 07/07/2014 12:48, David Burken a écrit :
>> Hi Julien,
>>
>> On 07/07/2014 05:00 AM, Julien Michel wrote:
>>> Hi Ossim users and developers,
>>>
>>> In OTB/ITK, we use centered pixel coordinates (meaning that the
>>> coordinate of a pixel is attached to its center, not its upper-left
>>> corner), but we recently discoved that gdal is using a different
>>> convention (the ul one). We therefore fixed our code so that when gdal
>>> reports a ul corner at (0,0) and a gsd of (1,1), we in fact set the
>>> origin of the image (coordinate of the upper-left pixel) to (0.5,0.5).
>>> But when we started digging, things only got worst.
>>>
>>> Appart from the fact that nobody accurately describes the convention in
>>> their software or metadata, we are facing the following problem :
>>>
>>> - It seems that DigitalGlobe RPC metadata consider that the coordinate
>>> of the center of the upper-left pixel is (0,0). Since we now have
>>> (0.5,0.5) because of gdal convention, we are in trouble here ...
>>> - It seems that Pleiades RPC metadata consider that the cooridnate of
>>> the center of the upper-left pixel is (1,1). We were in trouble before,
>>> but our half pixel shift does not help here.
>>>
>>> Because half a pixel shift in RPC metadata results in an error smaller
>>> than the model accuracy in most cases, it is really hard to validate all
>>> these with GCP for instance. What we did was to manually compare
>>> pansharpening results with the different conventions, in which case the
>>> half pixel shift in the XS image results in sharpening artifacts.
>>>
>>> So my questions are :
>>> - What pixel coordinate convention is in use in OSSIM (my guess is the
>>> centered one) ? Did you already consider this problem, and the
>>> interoperability with other software like gdal for instance ?
>> Under the hood ossim is center pixel(point) based. If the point type is
>> known, we will adjust the tie if needed.  For instance if you have a
>> geotiff tagged "area" the tie will get adjusted. I believe the gdal
>> plugin also applies a shift.
>>> - Depending on the answer to the previous question, do we need to fix
>>> Pleiades and/or other RPC models so that they are at least consistent
>>> with each other ?
>> I would say yes if the support data -> ossim is transformed wrong.
>>> - Do you know any source of information (data providers or software
>>> documents) that explicitly defines the used convention ?
>> Not explicitly.  Years ago I've pinged Lizard Tech(mrsid) and Erdas
>> imagine on the issue and they both came back with default being point.
>> This was a long time ago though.  I think now most formats tag this.
>>   From a resampling standpoint it makes sense that you resample about a
>> point.  From a human standpoint I think edge to edge is more clear.
>>
>> Take care,
>> Dave
>>
>>> Many thanks for your help,
>>>
>>> Regards,
>>>
>>> Julien
>>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> www.ossim.org
>> Ossim-developer mailing list
>> Oss...@li...
>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>
>>
>
>
> -- 
> Julien MICHEL
> CNES - DCT/SI/AP - BPI 1219
> 18, avenue Edouard Belin
> 31401 Toulouse Cedex 09 - France
> Tel: +33 561 282 894 - Fax: +33 561 283 109
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> Oss...@li...
> https://lists.sourceforge.net/lists/listinfo/ossim-developer