[QGIS-Developer] Coordinates of a pixel

Tue Sep 1 08:59:10 PDT 2020

Hi again,

Charles > I checked that, but no. The deviation is not so high. I suspect
that the way it's calculated in QGIS is taking something into account that
the function I'm using (and the web, both return same result) is not.
Maybe this? My DSM is in ETRS89: "*Note that the World Geodetic System
WGS84 and the European Reference System ETRS89 are virtually identical and
that coordinate transformation between the two systems in practical
navigation is unnecessary. However, for high-precision surveying work - be
aware that the two systems deviates more than half a meter.*"
But I don't know how to take that deviation into account in the function or
why it seems to affect only  the longitude.

Code of the calculateEndingGlobalCoordinates that I'm using:
https://github.com/mgavaghan/geodesy/blob/master/src/main/java/org/gavaghan/geodesy/GeodeticCalculator.java

Tim > Good to know. Not sure how could I leverage those data. I called
pixels  to the DSM cells but really I'm not interested in the graphical
part, just in how is calculating the coordinates of those cells from the
xllcenter and yllcenter correctly.

El mar., 1 sept. 2020 a las 15:32, Tim Sutton (<tim at kartoza.com>) escribió:

> Hi
>
> Also you can get the extents of the layer in the layer properties ->
> Information tab e.g.:
>
>
> Name DEM_10m
> Path /home/timlinux/gisdata/Rwanda/DEM_10m.tif
> CRS EPSG:4326 - WGS 84 - Geographic
> Extent 28.9592194665249139,-2.8404830825979692 :
> 30.8994723851809887,-1.0469841014800894
> Unit degrees
> Width 21524
> Height 19896
> Data type Int16 - Sixteen bit signed integer
> GDAL Driver Description GTiff
> GDAL Driver Metadata GeoTIFF
> Dataset Description /home/timlinux/gisdata/Rwanda/DEM_10m.tif
> Compression
> Band 1
> RepresentationType=THEMATIC
> STATISTICS_APPROXIMATE=YES
> STATISTICS_MAXIMUM=3821
> STATISTICS_MEAN=1697.9520539082
> STATISTICS_MINIMUM=15
> STATISTICS_STDDEV=341.19933119234
> STATISTICS_VALID_PERCENT=56.38
> More information
> AREA_OR_POINT=Area
> DataType=Generic
> Dimensions X: 21524 Y: 19896 Bands: 1
> Origin 28.9592,-1.04698
> Pixel Size 9.01436962765319623e-05,-9.01436962765319623e-05
>
> Regards
>
> Tim
>
>
> On Tue, Sep 1, 2020 at 9:51 AM Charles Dixon-Paver <charles at kartoza.com>
> wrote:
>
>> I took a cursory glance at the calculator you used and the description
>> you've given, and I think there's a possibility you're simply using an
>> easting value in the calculator. You could try multiplying your input
>> longitude by -1 for a quick fix (although I haven't tested this will work
>> at all).
>>
>> On Tue, 1 Sep 2020 at 03:31, Miguel-Ángel Fas-Millán <
>> fas.millan at gmail.com> wrote:
>>
>>> Thanks for your reply. Well, let me provide more details to explain why
>>> I was asking that.
>>> I have a DSM, with its xllcenter/yllcenter coordinates and I need to
>>> know the coordinates of the (in this case) center of any of the
>>> squares/cells (which, maybe wrongly, I called pixels) represented by this
>>> dataset. To that I've been using a function equivalent to the provided by
>>> this calculator: https://geodesy.noaa.gov/cgi-bin/Inv_Fwd/forward2.prl ,
>>> which takes as parameters the starting point, azimuth, distance, and
>>> returns the ending coordinates.
>>>
>>> For instance, I want to calculate the coordinates of the first cell of
>>> the dataset (top left of the matrix). So I do:
>>>
>>> calculateEndingGlobalCoordinates(Ellipsoid.*WGS84*, start_coords, 0.0,
>>> nrows*cellsize) //0.0 for north
>>>
>>> The problem is that it returns a value with a latitude that seems ok,
>>> but a wrong longitude. When I place that coordinate in QGIS, it is out of
>>> the image, quite at left of the top left corner.
>>>
>>> Unsurprisingly, if I place the coordinates obtained with this method (or
>>> with the online calculator mentioned) in google maps, to check if it makes
>>> sense looking at what's there in the satellite images, they make no
>>> sense at all.
>>>
>>> However, if I take the coordinates appearing in QGIS when I hover one of
>>> the cells, and place them in google maps, it makes perfect sense. With a
>>> few meters of difference, but well, at least it is on the right track. (I
>>> am that sure because I took as reference a ATC tower, which is the highest
>>> element in a wide area).
>>>
>>> That's why I wanted to check what's the difference between the mentioned
>>> method I was using and whatever is made in the code to return those quite
>>> correct coordinates.
>>>
>>>
>>>
>>>
>>> El mar., 1 sept. 2020 a las 0:01, Charles Dixon-Paver (<
>>> charles at kartoza.com>) escribió:
>>>
>>>> Someone can correct me if I'm wrong, but I think there's a
>>>> misunderstanding here of how this raster data is handled in a GIS. From my
>>>> understanding of the question, I don't know that what you're asking for is
>>>> available "in the code" the way you expect.
>>>>
>>>> The coordinates are showing the position of the cursor relative to the
>>>> origin of the assigned coordinate reference system. The raster data is
>>>> "projected" onto that reference system, which assigns positions to some
>>>> points on the image and stretches, rotates or distorts the image in
>>>> accordance with the images affine parameters that ensure all the different
>>>> parts of the image remain spatially correct. How the GIS knows where to get
>>>> these parameters varies between data types and file formats.
>>>>
>>>> Playing around with the georeferencer tool in QGIS should give you a
>>>> pretty clear understanding of how this "projection" works.
>>>>
>>>> There are ways to get the coordinates of a position or pixel within an
>>>> image programmatically, the easiest of which that I can think of is using
>>>> values from a world file [1] with an xy position (in pixels) of the pixel
>>>> of interest. The code required for achieving this, however, is probably
>>>> going to be dependant on a wide variety of factors (not least of all
>>>> the CRS units and pixel size). Alternatively, you could likely grab the
>>>> coordinate position of a pixel from within a QGIS project, but that doesn't
>>>> seem to be what you're after. Perhaps a developer familiar with the GDAL or
>>>> QGIS code bases can point you in the direction of some wizardry that will
>>>> achieve what it is you are looking for without a clearer understanding of
>>>> your use case though.
>>>>
>>>> [1] https://en.wikipedia.org/wiki/World_file
>>>>
>>>> On Mon, 31 Aug 2020 at 19:57, Miguel-Ángel Fas-Millán <
>>>> fas.millan at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>> New around here and as a QGIS user. I need to find something in the
>>>>> code, I hope you can help me.
>>>>> When you open a DSM and place the mouse on any pixel, you can see the
>>>>> coordinates of that point. Could someone tell me where in the code is made
>>>>> the calculation of those coordinates?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Angel
>>>>>
>>>>> _______________________________________________
>>>>> QGIS-Developer mailing list
>>>>> QGIS-Developer at lists.osgeo.org
>>>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>
>>>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
>
> ------------------------------------------------------------------------------------------
> 
>
> Tim Sutton
> Visit http://kartoza.com to find out about open source:
>  * Desktop GIS programming services
>  * Geospatial web development
> * GIS Training
> * Consulting Services
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> Tim is a member of the QGIS Project Steering Committee
>
> -------------------------------------------------------------------------------------------
> Kartoza is a merger between Linfiniti and Afrispatial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200901/11cdbba2/attachment.html>