Support projection coordinates in _read_ugrid

[kjnam]

Proposed new feature or change:

The current _read_ugrid assumes the coordinate values are in longitude and latitude. and this not always true.

uxarray/uxarray/io/_ugrid.py

Lines 10 to 25 in 1c07b70

	def _read_ugrid(ds):
	"""Parses an unstructured grid dataset and encodes it in the UGRID
	conventions."""
	# Grid Topology
	grid_topology_name = list(ds.filter_by_attrs(cf_role="mesh_topology").keys())[0]
	ds = ds.rename({grid_topology_name: "grid_topology"})
	# Coordinates
	# get the names of node_lon and node_lat
	node_lon_name, node_lat_name = ds["grid_topology"].node_coordinates.split()
	coord_dict = {
	node_lon_name: ugrid.NODE_COORDINATES[0],
	node_lat_name: ugrid.NODE_COORDINATES[1],
	}

The coordinates can be projected ones. So, I think it is better to rename coordinate variables only when the standard names of those are "longitude" and "latitude" following the CF convention.
This behavior can be added easily without disturbing the current approach.

[philipc2]

I don't have a formal geoscience background, so I was wondering what the coordinates should be referred to once they are projected.

In addition to node_lon and node_lat, we have the means to store node_x node_y and node_z coordinates, which we've been using to store the Cartesian coordinate system. Should projected coordinates be stored here instead?

[kjnam]

@philipc2 I am aware of node_?, and I am using those already for my codes. An alternative way to deal with this is modifying ani input dataset to provide lat and long coordinates via the UGRID coordinate variables while copying the original data to node_?. I have not tried it, but it is doable.
Assuming the coordinate values from the UGRID dataset as lat and long, however, is still not quite safe, I think. So, the feature is suggested.
In fact, a bigger and a fundamental issue to me is that the whole uxarray and routines assume the lat and long geographical coordinate system. I wish uxarray eventually provides functions for projected coordinates as well.

[philipc2]

In fact, a bigger and a fundamental issue to me is that the whole uxarray and routines assume the lat and long geographical coordinate system. I wish uxarray eventually provides functions for projected coordinates as well.

Agreed, I'd like to prioritize this, as supporting projected coordinates also goes along with the themes of #493 and #849

[kjnam]

@philipc2 Awesome! I can use and contribute to features related to projected coordinates happily. You've got a sure user for those here. 👍

[kafitzgerald]

@philipc2, I think you're on the right track with "x" and "y", but I don't know enough about the internals of UXarray to know if overloading node_x and node_y might be problematic. These would likely be Cartesian (x, y) coordinates, but not in the way you seem to be defining / using them elsewhere in UXarray.

Happy to chat geospatial whenever if it'd be helpful.

[rljacob]

I'm also not sure what is meant by a "projected coordinate". When you project the lats and longs of sphere on to a flat surface, they're still called latitudes and longitudes.

[kjnam]

@rljacob Projected coordinates are typically in length such as meter on a plain coordinate system, if I am not mistaken.

[philipc2]

@kjnam

In addition to projections, supporting different coordinate systems (like how GeoPandas does) could also be of value.

https://geopandas.org/en/stable/docs/reference/api/geopandas.GeoSeries.crs.html

[philipc2]

@kafitzgerald

@philipc2, I think you're on the right track with "x" and "y", but I don't know enough about the internals of UXarray to know if overloading node_x and node_y might be problematic. These would likely be Cartesian (x, y) coordinates, but not in the way you seem to be defining / using them elsewhere in UXarray.

Our node_x ,node_y and node_z coordinates are used for storing Cartesian coordinates. node_lon and node_lat are reserved for spherical lat-lon coordinates.

[philipc2]

I'd like to mention that many of our algorithms are written assuming that we are working with spherical geometry, which typically involves us using normalized Cartesian (x, y, z) coordinates for the algorithms. So even if we do support projected coordinates, we'd still need to be able to convert them to the coordinates we use internally for computations.

Looping @hongyuchen1030 into this discussion if she has any thoughts or experience with this.

[hongyuchen1030]

I'd like to mention that many of our algorithms are written assuming that we are working with spherical geometry, which typically involves us using normalized Cartesian (x, y, z) coordinates for the algorithms. So even if we do support projected coordinates, we'd still need to be able to convert them to the coordinates we use internally for computations.

Looping @hongyuchen1030 into this discussion if she has any thoughts or experience with this.

Thanks, @philipc2! Indeed, all internal algorithms utilize Cartesian coordinates for geometric calculations. The use of longitude and latitude in this context is primarily for providing users with a more intuitive geologic representation.

Spherical and Cartesian coordinates can be easily converted between one another mathematically.

@kjnam, could you clarify what you mean by "projected coordinates"? Are you referring to supporting the _read_ugrid function to read Cartesian coordinates as input? I believe this functionality might already be implemented, @philipc2. I recall implementing something similar in the __from_vertice__ function.

[kjnam]

@hongyuchen1030 Yes, our dataset uses a UTM coordinate system, which is a projected coordinate system. And, yes, _read_ugrid just remap (or rename) x and y coordinates to *_lat and *_lon assuming they are already in those. This is not the case for me.
I understand that many of computational functions in uxarray already convert lat and long to x and y coordinates, though they are mostly normalized. I guess we can use those for natively projected coordinates, but it may need some work.