From: Christopher Barker [mailto:pyth...@gmail.com
>>For each cell in the grid we can calculate the edge length
>> (lets assume a 1D grid for simplicity) from the co-ordinates of the
>> node at each end. Except, this can't be done for the edge between the
>> last node and the first node, i.e. the wrap-around.
>> Thus we are left not knowing how long the wrap-around edge is.
> Got it. I've delt with this in program logic. On a globe,
> there are two great circle distances between two points. If you can
> assume the one you want is the shorter one, which it would invariably
> be in this case, then you have ugly logic, but the result is well
That is true for a globe where you can assume 360degrees around a circle. However we are dealing with a biperiodic Cartesian domain. In other words it is size 'n' by 'm' which wraps around at all edges. It is the surface of a 3D torus but has 2D coordinates, if that makes sense.
>>The question is, how do we utilise a UGRID file so this
>> information is available.
> So you may want to avoid the expensive logic in your program
> code. And when you write the file, you have extra information.
That is the case. Our mesh generator knows how big the wrap around cells are. We just need to communicate that information to our model via the UGRID file.
> For instance, I think this is an unsolved problem in the
> various GIS conventions.
If this is true then we can invent something. I just find it hard to believe that we are the only group in the world using this kind of grid.
If I tackle your two suggestions in reverse order:
> 2) you store the size of the edges, faces etc. so they don't
> need to be computed.
This is the obvious solution but we don't like this because it means that for most nodes you have two sources of truth regarding the length of an edge. You have the stored value and the value computed from end point coordinates. We would rather avoid this duplication so as to avoid the possibility of them disagreeing and for reasons of file bloat.
> 1) You store a flag on the edge, or face, or ... indicating
> that it crosses the wrap-around.
This, then, is the next obvious option. The question is how to achieve it.
The UGRID standard document talks about "boundary_node_connectivity" and the ability to tag this boundary as either "open" or "closed". Do either of these refer to wrap-around? If so it continues to talk about associating "edge_coordinates" with the boundary and how these coordinates may be associated with "bounds". If this describes what I think it does then those bounds would describe the length of the edge.
> But if you want to only store info on the parts of the grid
> that overlap the wrap around, you can do that with a "location index
This looks like it might be simpler than what I describe above. However the "boundary_node_connectivity" approach looks like it might be the method which was intended for this purpose. We want to avoid misappropriating things in non-standard ways.
> As there are multiple ways to handle this, perhaps we should
> establish a recommended way in the convention.
Given how common biperiodic Cartesian domains are it seems like a worthwhile thing to standardise. After all "Spacewar!" was doing this on a PDP-1 in 1962. :-)
> But I'd say we start with looking at other conventions-- this
> isn't a UGRID specific issue. Is this addressed in CF at all? In any of
> the osgeo conventions?
I assume you are referring to the NetCDF climate and forecast metadata convention. In which case, no, they seem to deal exclusively with latitude/longitude. I had a quick look at the Open Source Geospatial Foundation's web page but couldn't find any obvious conventions to look at.