Open pkturner opened 4 years ago
The prototype's Map menu, and its "Set georeferencing", "Recast reference system", and "Realign map" dialogs
The latitude/longitude and declination fields show "no value" until the user sets them.
I didn't have much time to review the proposal. IMO we either need to simplify the dialog radically, or provide a separate minimal dialog: It must be usable on a mobile phone. This means there should be only two columns: labels and input fields (QFormLayout
).
With the automatism we already have, the key points are just that:
PS: Nice style and B/W icons on this screenshot, wrt to mobile usage. What enviromnent is this?
The screenshots are from KDE Plasma in the Breeze style (Linux).
I take the "Rotate map" dialog as a good example of "only two columns: labels and input fields". Is that available on mobile now? I have not found Mapper's menu bar on my 11cm x 17cm Samsung tablet.
simplify the dialog radically, or provide a separate minimal dialog
Yes! 90% of what users do with georeferencing can be simple. It's tough to get the UI right, because of the number of georeferencing parameters, and because the parameters need to be coordinated in particular ways depending on the user's intent.
It's possible to automatically generate a very adequate georeferencing just knowing the map's latitude and longitude, using an orthographic or stereographic projection with WGS84 datum, and looking up the declination online. Then for excellent accuracy the user just needs to set a CRS that matches their LiDAR template, and possibly refine the declination. The most direct path to a solid georeferencing as you mention "take from ... new template" which can provide both CRS and reference point.
I updated the branch containing these changes pkturner:georeferencing-dialog, rebasing them on the georef-state branch (#1753). Use of the Georeferencing::Geospatial
state supersedes a helper function which I had introduced in the original version of georeferencing-dialog
.
The dialog features demonstrated by the code are unchanged.
I really wanted to use std::optional<double> declination
rather than bool has_declination
and held back on that because optional
is a C++17 feature, not endorsed for use in Mapper.
This supports the georeferencing dialogs in indicating to the user when declination and/or reference point need to be set.
IMO we either need to simplify the dialog radically, or provide a separate minimal dialog: It must be usable on a mobile phone. [...] the key points are just that:
* the projected CRS by EPSG (not necessarily only by number: [...]). * the reference point, as take from some "current" source (map or new template) * the declination
I was going to upload a few updates to my prototype, when I reread these comments by @dg0yt. I agree that simplification is possible.
The reference point also need not appear in the dialog. It serves limited purposes.
purpose | dispensability |
---|---|
To locate the map coordinate axes in relation to projected coordinates. | It's rare that this makes a difference to the user. |
To help define the transformations between map and projected coordinates. | Either the map or projected coordinates of the reference point can be chosen arbitrarily, with negligible effect. |
To calculate the convergence, so the declination provided by the user can determine the grivation that orients the map. | The variation in convergence over the extent of an orienteering map is negligible. |
To calculate the declination. | The variation in declination over the extent of an orienteering map is negligible. |
I suggest that the projected and map coordinates of the reference point be set automatically, either
positioning the reference point in the vicinity of the map objects.
Steps to reproduce
another use case
Actual behaviour
The dialog is awkward for adjusting existing maps. Usually with existing maps, the geolocations of objects must be preserved. The dialog upsets this property, because its essence is to set or change the geographic coordinates that correspond to the map. Only after the user clicks OK, a careful user can restore the geolocations by handling a question that pops up, and a dialog with several options that pops up.
If the reference point coordinates are changed, the geographic coordinates of objects are affected.
Expected behaviour
A way to revise georeferencing parameters that promises not to touch the geolocations of map objects.
Configuration
Mapper Version: 0.9.4
Operating System: Gentoo Linux
Prototype
I created a prototype of user interface ideas, and have uploaded the branch pkturner:georeferencing-dialog so that others can try them out. The changes are most visible as
Defining the geolocations of map objects
Adjustments with no effect on the map, and zero or minimal effect on the geolocations of map objects
Preserving the geolocations of map objects, with corresponding rotation and scaling of the ensemble of objects on the map
There are many more details and ideas in the prototype beyond the above. I wanted to point to potential improvements rather than just describe how the georeferencing worked poorly for me when a beginner, or just suggest changes with no experience to back them up. The prototype dialogs are all implemented, so go ahead and see what they do.
I'll follow up with some screenshots from the prototype, and possibly describe common use cases or explain prototype details. I would be happy to adapt this prototype code or any small piece of it into a Mapper PR, adding tests, etc.