<div dir="ltr">Glad to hear you found a solution. In general, I usually favour the approach of developing a solution which works in a local coordinate system and projecting after the fact. It's usually a lot simpler and allows me to leave the "rocket science" to the rocket scientists...<div><br></div><div>One caveat you should be aware of though is that calculating positions on systems that are not cylindrical (e.g. a conical projection like albers ea), working at very high latitudes (where cylindrical projections probably aren't suitable anyway) or using images that have some sort of rotation applied etc may make things considerably more complex and even totally break your localised implementation (depending on how intelligent the solution is). I usually try to build things that are dynamic by somehow binding units/ CRS to the current map frame or similar logic, but in an instance like this it's probably better to have a hard-coded "all-or-nothing" solution.</div><div><br></div><div>There may also be other situations where things get a bit fuzzy, but I think as long as you're using UTM and images aren't rotated you should be OK (just be aware of these limitations if you plan on implementing this for users in other regions).</div><div><br></div><div>Regards</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 5 Sep 2020 at 02:58, Miguel-Ángel Fas-Millán <<a href="mailto:fas.millan@gmail.com">fas.millan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi again, <div>Thanks for your replies. Charles was right, the deviation between WGS and ETRS was not the problem. Finally I'm using UTM while moving through the dataset and only convert to geographic coordinates when I arrive at the point of interest. The previous way of doing it was quite more complex and it seems it added inaccuracies here and there. </div><div><br></div><div>Thanks again for your time, </div><div><br></div><div>Miguel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 1 sept. 2020 a las 19:59, Charles Dixon-Paver (<<a href="mailto:charles@kartoza.com" target="_blank">charles@kartoza.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I would wager that those deviations between WGS and ETRS are unlikely to be the cause of this discrepancy, unless your implementation somehow compounds the inaccuracies between them. The way it's "calculated" in a GIS is by referencing the image to a coordinate system and then returning the coordinates at a specified location (a process which is totally abstract from image pixels).<div><br></div><div>I haven't tested the code you're using, but from what I can see the most likely culprit is some abstract issue with the implementation which is difficult for us to resolve here (although a bug is certainly possible). For example, if you are using a DSM that is in geographic coordinates, the pixel sizes/ cell resolution are geographic units. That means that each cell is not a uniform distance (in meters) in size, yet the function you link to seems to require an input distance parameter in meters. Transforming units between coordinate systems is not trivial and likely requires expert advice. This may not be the case though, as I may be misunderstanding your requirements entirely.<div><br></div><div>I believe Tims response was merely an example of how to get the details of an image which has been imported into QGIS in a similar manner as what I suggested with a world file. Depending on the usage and accuracy required, you can quite easily use the pixel size and the raster extents/ origin to calculate a pixel position (although not very robust,
I find it is often useful).</div><div><br></div><div>I hope that helps somewhat rather than confusing the issue further. As I stated before, perhaps someone has an idea of where to point you in the codebase (in either QGIS or upstream projects like proj and GDAL), but I don't think you're entirely on the right path here...</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 1 Sep 2020 at 17:59, Miguel-Ángel Fas-Millán <<a href="mailto:fas.millan@gmail.com" target="_blank">fas.millan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi again, <div><br></div><div>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: "<span style="background-color:transparent;font-size:11pt;font-family:"bitstream vera sans",sans-serif;color:rgb(0,0,0)"><i>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 - <b>be aware
that the two systems deviates more than half a meter</b>.</i></span>" </div><div>But I don't know how to take that deviation into account in the function or why it seems to affect only the longitude.</div><div><br></div><div>Code of the <span style="font-family:serif;font-size:13.7291px">calculateEndingGlobalCoordinates that I'm using: </span><a href="https://github.com/mgavaghan/geodesy/blob/master/src/main/java/org/gavaghan/geodesy/GeodeticCalculator.java" target="_blank">https://github.com/mgavaghan/geodesy/blob/master/src/main/java/org/gavaghan/geodesy/GeodeticCalculator.java</a></div>
<div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 1 sept. 2020 a las 15:32, Tim Sutton (<<a href="mailto:tim@kartoza.com" target="_blank">tim@kartoza.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hi</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Also you can get the extents of the layer in the layer properties -> Information tab e.g.:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br>Name DEM_10m<br>Path /home/timlinux/gisdata/Rwanda/DEM_10m.tif<br>CRS EPSG:4326 - WGS 84 - Geographic<br>Extent 28.9592194665249139,-2.8404830825979692 : 30.8994723851809887,-1.0469841014800894<br>Unit degrees<br>Width 21524<br>Height 19896<br>Data type Int16 - Sixteen bit signed integer<br>GDAL Driver Description GTiff<br>GDAL Driver Metadata GeoTIFF<br>Dataset Description /home/timlinux/gisdata/Rwanda/DEM_10m.tif<br>Compression <br>Band 1 <br>RepresentationType=THEMATIC<br>STATISTICS_APPROXIMATE=YES<br>STATISTICS_MAXIMUM=3821<br>STATISTICS_MEAN=1697.9520539082<br>STATISTICS_MINIMUM=15<br>STATISTICS_STDDEV=341.19933119234<br>STATISTICS_VALID_PERCENT=56.38<br>More information <br>AREA_OR_POINT=Area<br>DataType=Generic<br>Dimensions X: 21524 Y: 19896 Bands: 1<br>Origin 28.9592,-1.04698<br>Pixel Size 9.01436962765319623e-05,-9.01436962765319623e-05</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Regards</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Tim<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 1, 2020 at 9:51 AM Charles Dixon-Paver <<a href="mailto:charles@kartoza.com" target="_blank">charles@kartoza.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 1 Sep 2020 at 03:31, Miguel-Ángel Fas-Millán <<a href="mailto:fas.millan@gmail.com" target="_blank">fas.millan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks for your reply. Well, let me provide more details to explain why I was asking that. <div>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: <a href="https://geodesy.noaa.gov/cgi-bin/Inv_Fwd/forward2.prl" style="background-color:transparent;color:rgb(0,0,128)" target="_blank">https://geodesy.noaa.gov/cgi-bin/Inv_Fwd/forward2.prl</a> , which takes as parameters the starting point, azimuth, distance, and returns the ending coordinates. </div><div><br></div><div>For instance, I want to calculate the coordinates of the first cell of the dataset (top left of the matrix). So I do:<br></div><div>
<p style="margin-bottom:0cm;line-height:100%;background:none 0% 0% repeat scroll transparent">
<font style="font-size:11pt"><font color="#080808"><font face="JetBrains Mono, serif">calculateEndingGlobalCoordinates(</font></font><font color="#000000"><font face="JetBrains Mono, serif">Ellipsoid</font></font><font color="#080808"><font face="JetBrains Mono, serif">.</font></font><font color="#871094"><font face="JetBrains Mono, serif"><i>WGS84</i></font></font><font color="#080808"><font face="JetBrains Mono, serif">,
</font></font><font color="#000000"><font face="JetBrains Mono, serif">start_coords</font></font><font color="#080808"><font face="JetBrains Mono, serif">,
</font></font><font color="#1750eb"><font face="JetBrains Mono, serif">0.0</font></font><font color="#080808"><font face="JetBrains Mono, serif">, nrows*cellsize</font></font><font color="#080808"><font face="JetBrains Mono, serif">) //0.0 for north</font></font></font></p><p style="margin-bottom:0cm;line-height:100%;background:none 0% 0% repeat scroll transparent">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. </p><p style="margin-bottom:0cm;line-height:100%;background:none 0% 0% repeat scroll transparent"><font style="font-size:11pt"><font color="#080808"><font face="JetBrains Mono, serif">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</font></font></font><span style="font-family:"JetBrains Mono",serif;color:rgb(8,8,8);font-size:11pt;background-color:transparent"> satellite images, they make no sense at all. </span></p><p style="margin-bottom:0cm;line-height:100%;background:none 0% 0% repeat scroll transparent"><font style="font-size:11pt"><font color="#080808"><font face="JetBrains Mono, serif">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). </font></font></font></p><p style="margin-bottom:0cm;line-height:100%;background:none 0% 0% repeat scroll transparent"><font face="JetBrains Mono, serif" color="#080808"><span style="font-size:14.6667px">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. </span></font></p><p style="margin-bottom:0cm;line-height:100%;background:none 0% 0% repeat scroll transparent"><font style="font-size:11pt"><font color="#080808"><font face="JetBrains Mono, serif"><br></font></font></font></p><p style="margin-bottom:0cm;line-height:100%;background:none 0% 0% repeat scroll transparent"><font style="font-size:11pt"><font color="#080808"><font face="JetBrains Mono, serif"><br></font></font></font></p></div>
</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 1 sept. 2020 a las 0:01, Charles Dixon-Paver (<<a href="mailto:charles@kartoza.com" target="_blank">charles@kartoza.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Playing around with the georeferencer tool in QGIS should give you a pretty clear understanding of how this "projection" works.</div><div><br></div><div>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 <span>dependant</span> 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.</div><div><br></div><div>[1] <a href="https://en.wikipedia.org/wiki/World_file" target="_blank">https://en.wikipedia.org/wiki/World_file</a> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 31 Aug 2020 at 19:57, Miguel-Ángel Fas-Millán <<a href="mailto:fas.millan@gmail.com" target="_blank">fas.millan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all, <div>New around here and as a QGIS user. I need to find something in the code, I hope you can help me. </div><div>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? </div><div><br></div><div>Regards,</div><div><br></div><div>Angel</div><div><br></div></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div style="text-align:center">------------------------------------------------------------------------------------------</div><div style="text-align:center"><div style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:small;display:inline"></div><img src="https://mail.google.com/mail/u/0/?ui=2&ik=7ebbf93252&view=fimg&th=15a9e43c0bbf93ca&attid=0.1&disp=emb&realattid=9436e64174762963_0.1.1&attbid=ANGjdJ-WL_J24nvBiYidJ0V0xpdsYqRwswi5nq5oywcJEHC7twYVMrxG0y-GNPu_ahJthV8ktXwYuHoVm5DI2FrRAtPzelTRHrsE2wweR9uu8wT-zz2hNRqFwi4SorQ&sz=s0-l75-ft&ats=1488721675176&rm=15a9e43c0bbf93ca&atsh=1" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;"><br></div><div style="text-align:center">Tim Sutton</div><div style="text-align:center"><span style="text-align:start">Visit </span><a href="http://kartoza.com/" style="text-align:start" target="_blank">http://kartoza.com</a><span style="text-align:start"> to find out about open source:</span><br style="text-align:start"><span style="text-align:start"> * Desktop GIS programming services</span><br style="text-align:start"><span style="text-align:start"> * Geospatial web development</span></div><div style="text-align:center"><span style="text-align:start">* GIS Training</span></div><div style="text-align:center"><span style="text-align:start">* Consulting Services</span></div><div style="text-align:center"><div style="text-align:center">Skype: timlinux Irc: timlinux on #qgis at <a href="http://freenode.net/" target="_blank">freenode.net</a></div><div style="text-align:start"><div style="text-align:center">Tim is a member of the QGIS Project Steering Committee</div><div style="text-align:center">-------------------------------------------------------------------------------------------</div><div style="text-align:center">Kartoza is a merger between Linfiniti and Afrispatial</div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>