[QGIS-Developer] Use of NE(SW) in the showing of (ordered) coordinates within QGIS

[Greg Troxel]

Richard Duivenvoorde <rdmailings at duif.net> writes:

> I think we should never copy the characters, only numbers ( well,
> except when using W/S/E/N :-) )..

Having thought a bit more this seems very tricky.

> I also understood from somebody that when using latlon coordinates the
> minus sign is actually redundant, as you should use the WSEN?

I don't think it's that simple, and looking at EPSG I'm sure it's not!
(qgis should not be tied to EPSG; it should follow any defined CRS,
custom or proj-provided but I understand most are from EPSG.)

Sometimes people write any of the following

  (42, -71)
  (-71, 42)
  42N 71W

for geographic.  And sometimes DM, DMS.  If we are going to try to align
with EPSG:4326, I think that means the first form.  But looking at

  https://epsg.org/crs_4326/WGS-84.html

it says that the parameter is in degrees [supplier to define
representation], and that latitude it positive north, longitude positive
east.

Degrees are given as

  https://epsg.org/unit_9122/degree-supplier-to-define-representation.html

which means that formally, we must define a representation among the
example choices of decimal, DMSH.  Other degree formats are just numbers
and numbers with hemispheres:

  https://epsg.org/unit_9102/degree.html
  https://epsg.org/unit_9116/degree-hemisphere.html

So I guess that means qgis could choose any of

  D DH DM DMH DMS DMSH

where H means no negative sign and N/S E/W, lack of H means numbers that
could be negative and no N/S/E/W.

It is pretty obvious which representation is chosen by how it's
printed.  It's clear that for cut/paste for computer use, 42,-71 is
best, and for human use it depends.

Looking beyond WGS84, I picked ITRF2014 and that is also EPSG:9122
(which I find surprising):

  https://epsg.org/crs_7912/ITRF2014.html

>> Part of the underlying trouble is that in qgis/proj we blur:
>>   datum
>>   projection
>> into
>>   CRS
>> except that some CRS are datum only, and some are datum+projection.
>
> But isn't that the 'difference' in what QGIS (in the CRS dialog) calls
> 'Geographic Coordinate Systems' vs 'Projected Coordinate Systems'?

Yes, but in opening a project and clicking around this is really not
obvious.  I know which are which, but it's really subtle.


Someone commented about in US usage Northing preceding Easting, and I
think meant for UTM, but might have also meant for State Plane
Coordinates.  I just checked a survey plan (MA SPC Mainland, which is
LCC) and sure enough N is given before E.  That doesn't mean it's right
in all cases; GIS, geodesy, surveying are all distinct subcultures.

Looking up Mass SPC, I find:

  https://epsg.org/crs_6491/NAD83-2011-Massachusetts-Mainland.html

and that is clear:

  Cartesian 2D CS. Axes: easting, northing (X,Y). Orientations: east,
  north. UoM: m.

which means easting has to come first, and the use of E and N is
non-compliant with the EPSG definition.  Use of E/N to label those also
is fundamentally different than N/S in latitude: it's a label for whcih
coordinate is which, not a replacement for a sign bit.

My impression is that while people often write xxx.xxxN, xxx.xxxE, it is
always easting, northing when used as a coordinate in a machine-readable
way.

> So: that would make (?): if crs.isGeographic() [0] we should/could use
> WSEN, and if not then we should NOT use WSEN (and optionally x/y if
> that is more clear)... except when copying coordinates, because that
> would mess up parsers :-)

It comes back to the purpose of this.  I would say:

  - By default the rules in the CRS should be followed.  That means N/S
    can be used only if the underlying degree reference is EPSG:9122.
    But then it's optional.

  - Copy coordinate is intended to produce something machine-readable.
    That means just numbers, to the extent that is reasonable.

  - The display format should match what is copied, to follow the
    Principle of Least Astonishment.

  - If someone wants a richer display of coordinates in many formats,
    that should perhaps be another right-click menu item.

My vote is for just numbers, like we have now, so the only thing
changing is making the axes compliant with the CRS definition.

And, perhaps either a preference to select a degree represenation (6
choices!), or multiple entries in the menu.  But default should be plain
decimal degrees, IMHO.

I would be ok with the chosen degree representation being used even if
the CRS specifies 9102 instead of 9122.

I would also be ok with a preference to add E/N letters to coordinates
that are defined to mean Easting and Northing by the CRS.   Default off.

Hope this helps....


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20220412/156ff74b/attachment.sig>