Diameter and lon/lat elements don't work correctly in a projected CRS.

[rbeyer]

I'm using circle-craters in QGIS 3.18 on a lunar polar stereographic projection map. The three-point clicking for selecting craters is very nice, but the reported values for diameter, center_lon, and center_lat are bogus.

I'm not sure if it is something I'm doing wrong (highly likely) or if there is something about QGIS that has changed in recent versions that used to allow this plugin to work properly for maps in a projected CRS.

For example, for a crater that should be between 4 and 5 m in diameter (because I can count the LROC pixels) it is reported as being 39301.81753860782 in diameter in the circle-craters reported diameter column, and similarly, the center_lon, and center_lat columns are the center X and Y coordinates in the projected CRS, not actually those coordinates converted to lon and lat, as the column headers might indicate. If I open the QGIS measure tool in its default "Ellipsoidal" setting and draw a diameter, I get a similar bogus value (so clearly circle-craters is relying on the same mechanism to gather a "diameter" that the Measure tool is), but if I change it to "Cartesian" then I get a diameter of 4.6 m, which is what I expect.

Is circle-craters only meant to operate on data with geographic coordinate systems and not on projected coordinate systems? Or is there something newly broken in QGIS that has inadvertently broken the mechanism by which the "diameter", "center_lon," and "center_lat" columns are computed?

I suppose I can always write something that just processes the geometry of the resulting GeoPackage or ShapeFile directly to calculate my own correct diameters and center lon/lat in order to create a file for craterstats, but I sure would like to just use the "Export Data" button that circle-craters provides.

[sbraden]

Hi Ross, It's very possible that something is broken. I'm currently on PTO, bit when I get back I will diagnose and repair this issue. Sarah

…

On Wed, Aug 25, 2021, 17:25 Ross Beyer ***@***.***> wrote: I'm using *circle-craters* in QGIS 3.18 on a lunar polar stereographic projection map. The three-point clicking for selecting craters is very nice, but the reported values for diameter, center_lon, and center_lat are bogus. I'm not sure if it is something I'm doing wrong (highly likely) or if there is something about QGIS that has changed in recent versions that used to allow this plugin to work properly for maps in a projected CRS. For example, for a crater that should be between 4 and 5 m in diameter (because I can count the LROC pixels) it is reported as being 39301.81753860782 in diameter in the *circle-craters* reported diameter column, and similarly, the center_lon, and center_lat columns are the center X and Y coordinates in the projected CRS, *not actually* those coordinates converted to lon and lat, as the column headers might indicate. If I open the QGIS measure tool in its default "Ellipsoidal" setting and draw a diameter, I get a similar bogus value (so clearly *circle-craters* is relying on the same mechanism to gather a "diameter" that the Measure tool is), but if I change it to "Cartesian" then I get a diameter of 4.6 m, which is what I expect. Is *circle-craters* only meant to operate on data with geographic coordinate systems and not on projected coordinate systems? Or is there something newly broken in QGIS that has inadvertently broken the mechanism by which the "diameter", "center_lon," and "center_lat" columns are computed? I suppose I can always write something that just processes the geometry of the resulting GeoPackage or ShapeFile directly to calculate my own correct diameters and center lon/lat in order to create a file for craterstats, but I sure would like to just use the "Export Data" button that *circle-craters* provides. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKFK44Z42O7SJNQGJJNRQLT6V3XJANCNFSM5C2EP4EQ> .

[BerginJay]

Hi there, I have fixed this issue in #22. @rbeyer you can test this on my branch, and hopefully Sarah would merge this PR after her PTO.

[sbraden]

Thank you Bojun. I will merge after a quick look today.

…

On Tue, Oct 5, 2021 at 9:22 PM Bojun ***@***.***> wrote: Hi there, I have fixed this issue in #22 <#22>. @rbeyer <https://github.com/rbeyer> you can test this on my branch, and hopefully Sarah would merge this PR after her PTO. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKFK4YTGJAIBNLH57CSVZLUFO6I7ANCNFSM5C2EP4EQ> .