search

mpetroff / qgsazimuth

Fork of http://sourceforge.net/projects/qgsazimuth/
7 stars 3 forks source link

Broken with QGIS 3.24 #28

Closed musicMan77 closed 2 years ago

musicMan77 commented 2 years ago

Seems that the coordinates are all backwards. When you create a new polygon using the from map button to start a point, and then followed by vertexes, the resulting shape is nowhere even close to the map point.

This same problem was seen in the Geo Raster but fixed. I don't know if its an issue with the plugin or someone needs to modify things on the QGIS side but definitely a problem with QGIS 3.24.

mpetroff commented 2 years ago

Hmm, there's nothing in the list of backward-incompatible API changes to suggest something would have changed.

Can you link to the "Geo Raster" issue and fix? I'm not sure what plugin you're referring to. Seeing what was done to fix it should make fixing the present issue easier.

musicMan77 commented 2 years ago

So it's the QGIS Georeferencer that had the issue in 3.20 and it was fixed in 3.24. It displayed exactly the same behavior at that time. I had found a set of correspondence that was taking about the issue then, I believe it was in the github site issues section, before they fixed it I was about to return to 3.16. Here is a Stackexchange reference: https://gis.stackexchange.com/questions/424843/qgis-georeferencing-leads-to-wrong-position. I'll keep looking for the conversation. It definitely had the developers name who was working on the issue, who should be familiar with it.

jayjaybillings commented 2 years ago

Any update on this? I believe I'm seeing the same problem because when I input my calls I get lines of the wrong length, which changes the shape of the area substantially. So far it looks like it only draws 77.5% of the distance in either meters or feet, which I determined by inputting calls of N 135d 0' 0'' W 100 and N 180d 0' 0'' E and measuring the difference from the expected distances.

musicMan77 commented 2 years ago

I'm not sure if its an actual error, the lengths that are used in the calculations are Cartesian, and most of us are using Ellipsoidal coordinate systems. I actually modified my plugin to do a linear approximation between the coordinate systems for small distances (about 1 mile) it works. That way I can get the correct lengths. The line to convert a length is X2 = 1.445105* X1 +0.006713013 in feet. Where X1 is your Cartesian length. This is for WGS 84 / Pseudo-Mercator. You can convert your distances when you enter your bearings to get the correct results.

mpetroff commented 2 years ago

I finally had a chance to look at this, and I can't find any regressions running the plugin in QGIS 3.26.

The plugin uses Euclidean geometry and will not work with an ellipsoidal CRS. Based on the most recent comments, I assume you're using an ellipsoidal CRS, meaning that there is no regression and that this issue is a duplicate of #26. Based on that, I'm closing this issue, but feel free to reopen it if my assumptions are incorrect.

As adding support for ellipsoidal CRSs is a lot of work, I have no intention of doing so (but would accept a PR that does). The plugin should at least throw a warning when used with ellipsoidal CRSs, but that's also more work than I have time for.

No development on the plugin happens beyond fixing regressions in newer versions of QGIS. I took over maintenance close to a decade ago when I needed the plugin for a project I was working on, but that project was completed many years ago, and I rarely use the plugin these days.