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

2022-04-12 Thread Greg Troxel via Qgis-user

Richard Duivenvoorde  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




signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user


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

2022-04-11 Thread Richard Duivenvoorde via Qgis-user

On 2022-04-11 14:38, Greg Troxel via QGIS-Developer wrote:

Thanks Greg,

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


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



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'?


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 :-)


Regards,

Richard

[0] 
https://qgis.org/pyqgis/master/core/QgsCoordinateReferenceSystem.html?#qgis.core.QgsCoordinateReferenceSystem.isGeographic

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user


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

2022-04-11 Thread Greg Troxel via Qgis-user

Richard Duivenvoorde via QGIS-Developer 
writes:

> In 3.24 you will see something like "WGS84 5.2 52,3"
> While in master it shows: "WGS84 52.3N 5.2E"  (note the N and E)
>
> For WGS84 I think this is normal (to show WSEN), but for other crs's I
> think it is overkill?
>
> In 3.24: "EPSG:28992 (15,45)"
> In master now I see: "EPSG:28992 (150702E,466216N)"

I think the real question is if these are expected to be useful for
humans to look at, or if they are expected to be machine-processable
somehow.

And if they are for humans, what are the humans doing with them?

And if they are hints for what will be copied, but the copied string has
just numbers and a comma so that copied string is machine procesable.
Or if it's a mini geojson point object (just kidding; that seems a bit
much).

As for x and y, those are projection concepts, and for WGS84:

  using x for latitude and y for longitude is basically declaring a
  projection, and for 4326, that isn't so even that's what people often
  choose to do when displaying 4326 for nerds

  WGS84 ECEF has axes, and they aren't the same as how you are using
  them.  WGS84 geographic does not have x and y axes.

For UTM/LCC sorts of CRSes, the axes are (usually) easting and northing
and I don't see then written x and y.


There is some messiness in that if one sets a project CRS to 4326, then
the display is x=lon, y=lat, which is a projection.  Basically if you
have have a project CRS that isn't a projection, then there is further
step to relate the CRS axes to display x and y, and that's implicit.
For many things, given the dominance of north up, there is an obvious
answer, but it's still an assumption.


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.



signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user