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...
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.
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).
Regards
On Sat, 5 Sep 2020 at 02:58, Miguel-Ángel Fas-Millán
wrote:
> Hi again,
> 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.
>
> Thanks again for your time,
>
> Miguel
>
> El mar., 1 sept. 2020 a las 19:59, Charles Dixon-Paver (<
> char...@kartoza.com>) escribió:
>
>> 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).
>>
>> 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.
>>
>> 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).
>>
>> 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...
>>
>> On Tue, 1 Sep 2020 at 17:59, Miguel-Ángel Fas-Millán <
>> fas.mil...@gmail.com> wrote:
>>
>>> 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 ()
>>> escribió:
>>>
Hi
Also you can get
