Jonathan, Regarding your question about the lateral search algorithm, a succinct way of remembering it is "search upwards to the apex, from there search across going downwards". Your suggestion about using any variable with the right name if it can't be found works well for simple trees. I don't know of an existing counterexample off-hand. However, it's easy to imagine one. For example, it would perform poorly in any tree where there are multiple coordinate variables of the same name (e.g.,`latitude`) all stored in sibling groups as is often the NASA/ESA style. Only the in-scope `latitude`s (i.e., those located beneath the apex group) will have the right `latitude` dimension. If the desired `latitude` were in a sibling group, and there were other coordinate systems in the file, then the search would often return an incorrect `latitude` variable. Here is another way to visualize the capabilities that would be lost by omitting lateral search from CF: Consider an exising NASA MLS, or ESA S5P or other dataset that places coordinates in sibling groups not ancestor groups. The dataset, `in1.nc`, would work well with your suggested simpler algorithm. However, combining that dataset with a second dataset `in2.nc` with `ncecat in1.nc in2.nc out.nc` would perform poorly with the simpler algorithm, though it would work fine with the lateral search algorithm.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/144#issuecomment-427430562
