Standard names: deployment_latitude and deployment_longitude

[fmanzano-pde]

Proposer's name Fernando Manzano

Date 2023-03-03

This proposal comes up from the discussion cf-conventions issue #428. The addition of these two standard names complements the solution taken.

---

- Term deployment_latitude - Description Latitude at deployment. The deployment position of a station changes after maintenance or repositioning after it drifts. It is positive northward; its units of degree_north (or equivalent) indicate this explicitly. - Units degree_north

---

- Term deployment_longitude - Description Longitude at deployment. The deployment position of a station changes after maintenance or repositioning after it drifts. It is positive eastward; its units of degree_east (or equivalent) indicate this explicitly. - Units degree_east

[JonathanGregory]

That looks fine to me, thanks. Jonathan

[ngalbraith]

I can imagine this being used for floats as well; they may have time series of positions, but may need to document the position at which they were deployed. You'd have to read beyond the first line of the definition to see that that's not what's meant; is that a problem?

[fmanzano-pde]

Dear Nan,

I'm not sure about what you mean. Could you explain it in more detail, please? In case you think the description could be extended, please, don't hesitate to make a proposal.

All the best, Fer

[ngalbraith]

Hello Fernando -

This seems self-explanitory,

_deploymentlatitude: Latitude at deployment.

but then you say

The deployment position of a station changes after maintenance or repositioning after it drifts.

Which implies to me that the term is meant to be used for an item that's more or less stationary. When we deploy drifters, Argo floats or autonomous vehicles, they usually have GPS units that collect a time series of positions that align with the measured variables. In the metadata for these floats etc, we include the deployment location and time. It can be useful in various ways, like helping determine, when you're looking at a specific time span of data, whether there's earlier data available, or how long the instrument's been in the water (with recently deployed instruments normally considered more reliable).

My question is, does this term need to be limited to stations that change after maintenance or repositioning, or would it be useful for vehicles, drifters and floats. If the latter, the description should be modified to something like

The term can be used whenever the deployment position of a station or instrument needs to be supplied along with other types of positions; nominal, or measured time series.

[fmanzano-pde]

Hello Nan,

Thank you for the explanation. To be honest, when I proposed the standard names I was thinking on fixed platforms, but I agree there's no reason to limit it.

I like the description you propose. It could be complementary.

deployment_latitude: Latitude at deployment. The deployment position of a station. The term can be used whenever the deployment position of a station or instrument needs to be supplied along with other types of positions; nominal, or measured time series.

If you consider it's redundant, I'm ok to keep just your description.

All the best, Fer

[ngalbraith]

Hi Fer -

Latitude at deployment. The deployment position of a station. The term can be used whenever the deployment position of a station or instrument needs to be supplied along with other types of positions; nominal, or measured time series.

Hmmm ... What if the deployment position is the only one available? Is there a reason to limit these terms to be sort of ancillary variables? If I have a e.g. a short-term float, without gps, deployed and recovered from a ship, where the deployment position might be the only position. Would you want to use these terms then, or just use the existing latitude and longitude standard names?

[fmanzano-pde]

Hi Nan,

It's only my opinion but, in that case, when there is no GPS position and the deployment position is the only one known, I'd use latitude and longitude.

Anyway, even if it is used deployment_latitude and deployment_longitude it's not a big deal.

As I previously mentioned, many times the nominal position coincides with the deployment position. If you only know one position, it is the nominal position for sure, although it could be the deployment position at the same time.

All the best, Fer

[ngalbraith]

It looks like there's agreement that the new terms should only be in addition to latitude and longitude, never stand-alone. That's fine with me. I'd really prefer leaving 'nominal' out of the definition if possible - it limits the way this can be used. How about ...

Latitude at deployment. The deployment position of a station or instrument. The term can be used whenever the deployment position of a station or instrument needs to be supplied along with other types of positions.

Thanks for your patience!

[fmanzano-pde]

Dear Nan,

Please, no problem at all, my pleasure.

It's OK to me with the new definition you propose. I find it clearer and simpler, I like it.

Thanks you very much.

All the best, Fer

[JonathanGregory]

Thanks for the discussion, everyone. To summarise, I believe that Fer @fmanzano-pde's proposal is now for these two standard names:

deployment_latitude in degree_north. The latitude of deployment of a station or instrument. The term can be used whenever the deployment position of a station or instrument needs to be supplied along with other types of positions.

deployment_longitude in degree_east. The longitude of deployment of a station or instrument. The term can be used whenever the deployment position of a station or instrument needs to be supplied along with other types of positions.

If there are no further concerns or ideas contributed, this proposal should be accepted for inclusion in the standard name table in a couple of weeks.

[DocOtak]

@JonathanGregory would you support some language saying something like "These names should not be used in lieu of having coordinate variables with the latitude and longitude standard names".

[JonathanGregory]

Dear Andrew @DocOtak, Fer @fmanzano-pde, Nan @ngalbraith

To address Andrew's concern, could we add: "If the deployment position is the also the nominal position for a discrete geometry (as in Section 9.5 of the CF convention), the deployment latitude should also, or instead, be recorded in a coordinate variable with the standard name of latitude and axis ="Y"`, and correspondingly for longitude?

Jonathan

[fmanzano-pde]

Dear @JonathanGregory,

For me it's OK to add the text to clarify.

All the best, Fer

[ngalbraith]

I find Andrew's text much more clear than Jonathan's. Less is more in this case, I think.

[JonathanGregory]

Less is more in this case, I think.

Yes, fair enough. I wrote more because I think we should be clear that this restriction applies only to DSGs, whereas this description will appear in the standard name table. There's no reason why a data-writer shouldn't use deployment_latitude for a data variable or coordinate variable in some other context than a DSG. Andrew's concern is specifically that DSGs should still have a latitude - is that right?

How about "If a discrete sampling geometry (Section 9 of the CF convention) has a Y-axis of latitude, it must have a coordinate or auxiliary coordinate variable with a standard name of latitude, although it can in addition have one for deployment_latitude ."

[DocOtak]

@JonathanGregory My concern is more from chapter 4 of the conventions and not directly related to DSGs. latitude and longitude are special in that they are defined by the conventions themselves and not just the standard name table.

What it means when there is an axis attribute with a standard name that it not one defined in chapter 4 appears to be ambiguous/undefined.

[JonathanGregory]

@DocOtak, I see. Do you think someone might put deployment_latitude when they really meant latitude for the coordinate variable of a gridded field, for example? We can't prohibit it, because it is possible for deployment_latitude to be a legitimate coordinate variable, though unlikely. The data variable is a function of the coordinate variables, which could be anything - they don't have to be geolocating coordinates.

Sect 4 says that if you have a latitude coordinate variable, it must have units of degrees_north or equivalent, and it may optionally have axis Y and standard name latitude. It is not mandatory for there to be a latitude coordinate variable, except in DSGs. Furthermore, the data-writer can label any axis as Y. It doesn't have to be latitude. It might, for example, be northward distance or a north with respect to a rotated pole.

[DocOtak]

Just so it's clear, I like these names and want to see them added to the standard name table.

As far as I can tell, these are the first proposed names that are actual latitude/longitude coordinates which are not also defined in the conventions themselves. While in https://github.com/cf-convention/cf-conventions/pull/431 there is an example that contains these deployment_* names it doesn't actually define their usage, and very much shows that the variables with X and Y axis attributes use the latitude and longitude standard names.

Is the intent that "generic applications" (as the conventions call them) should be able to understand these new names as alternates to the standard names latitude or longitude when the variables have an axis attribute?

[ngalbraith]

I think Jonathan's text makes it clear that there should be a variable with the standard name latitude. Not sure if this is only true of DSG files; we will use latitude in every case because that's what most software is looking for.

Is there any reason deployment_latitude can't be given an axis attribute? It would simplify things for people who are taking data from multiple deployments at a single site (in my data sets, maybe in others'?). Section 4 doesn't prohibit this, as I read it.

[DocOtak]

My understanding of section 5 seems to prohibit any given variable from having more than one variable with the same axis attribute. So what you cannot do is have two latitude variables, one latitude the other deployment_latitude and give them both an axis attribute and attach them both via the coordinates attribute to the same data variable.

However, it is not permissible for a data variable to have both a coordinate variable and an auxiliary coordinate variable, or more than one of either type of variable, having an axis attribute with any given value e.g. there must be no more than one axis attribute for X for any data variable.

I think I like @JonathanGregory 's original recommended text to my concern:

If the deployment position is the also the nominal position for a discrete geometry (as in Section 9.5 of the CF convention), the deployment latitude should also, or instead, be recorded in a coordinate variable with the standard name of latitude and axis ="Y"

I would make it stronger for DSGs and recommend the practice in other contexts[^1], bold only to show the differences:

If the deployment position is the also the nominal position for a discrete geometry (as in Section 9.5 of the CF convention), the deployment latitude must also, or instead, be recorded in a coordinate variable with the standard name of latitude and axis ="Y". For non discrete geometries, when deployment position is the only position available it is recommended to use the standard name latitude for maximum compatibility.

[^1]: I'm rather used to RFC2119 so tend to look for these keywords.

[JonathanGregory]

Dear Andrew and Nan

It would be permissible for a coordinate variable of deployment_latitude to be labelled with axis="Y", but it is not allowed for more than coordinate variable of a given data variable to have axis="Y", as Andrew says.

In this text

If the deployment latitude is also the nominal latitude for a discrete geometry (as in Section 9.5 of the CF convention), the deployment latitude should also, or instead, be recorded in a coordinate variable with the standard name of latitude and axis="Y".

I don't think we can say "must" instead of "should", because the axis and the standard_name attribute are both optional in Sect 9.5, as they are in general in the convention. The only mandatory attribute for latitude is its units. In the convention, "should" means a recommendation, and the CF checker will give a warning if it can detect that a recommendation has not been followed. At the moment, this doesn't happen for DSGs because we haven't yet added text for Sect 9 to the conformance document, but that will be done, I hope in the next release.

I have changed the text slightly from what I said before by replacing "position" with "latitude". This is because, although all DSGs currently defined require a Y-coordinate, they don't require it to be latitude. It could be northward distance (on a grid), for instance. Section 9.1 says, "the spatial coordinates x and y typically refer to longitude and latitude but other horizontal coordinates could also be used."

Andrew suggests a second sentence for non-DSG situations. I tend to think that this is already covered by the first part of the description text discussed earlier. We could, however, strengthen it a bit. How would this be:

deployment_latitude. The latitude of deployment of a station or instrument. The term can be used whenever the deployment position of a station or instrument needs to be supplied along with other types of positions. If a data variable has only one latitude coordinate variable, the standard name of latitude should generally be preferred to deployment_latitude, because latitude is recognised by generic software. If the deployment latitude is also the nominal latitude for a discrete geometry (as in Section 9.5 of the CF convention), the deployment latitude should also, or instead, be recorded in a coordinate variable with the standard name of latitude and axis="Y".

and of course correspondingly for longitude.

Cheers

Jonathan

[DocOtak]

@JonathanGregory I like your revised proposed definition.

[fmanzano-pde]

@JonathanGregory, @DocOtak, @ngalbraith, thank you very much for this fine tuning discussion. I've been following it very closely, unfortunately I've not been able to contribute. Anyway, I find the last description provided by Jonathan very accurate and sufficiently clear. I could be wrong and some other exception could come up, but we should be careful and not going too far to keep a good balance between usability and complexity. In conclusion, I support the last definition given.

All the best, Fer

[feggleton]

Thanks all for the proposal and discussion. I've added this to the editor and added the positive northward phrase back in too.

The latitude of deployment of a station or instrument. The term can be used whenever the deployment position of a station or instrument needs to be supplied along with other types of positions. If a data variable has only one latitude coordinate variable, the standard name of latitude should generally be preferred to deployment_latitude, because latitude is recognised by generic software. If the deployment latitude is also the nominal latitude for a discrete geometry (as in Section 9.5 of the CF convention), the deployment latitude should also, or instead, be recorded in a coordinate variable with the standard name of latitude and axis="Y". Latitude is positive northward; its units of "degree_north" (or equivalent) indicate this explicitly.

And same for longitude too.

If there are no further comments in the next 7 days, then tis can be accepted.

[japamment]

@fmanzano-pde @feggleton

Both the names in this issue will be included in V82 of the standard name table, currently in preparation.

Best wishes

Alison

[japamment]

I am closing this issue as the names have been published in V82 of the standard name table.