One anecdotal point about lat-lon grids and GIS: ArcGIS 9.3 now can read NetCDF data natively -- *IF* the NetCDF file is fully CF-compliant and the projection is properly specified. That can be harder to do than you might think; there are many fiddly little details that are irrelevant from a modeling perspective but matter greatly for importing to GIS, and the implementation itself is imperfect (parameters specified as floats instead of doubles don't get read in properly, not every projection scheme has been implemented yet, etc.).
There's no argument that we want the map projection to be specified properly, but providing the lat-lons *in addition* is valuable because it provides a fallback in case of error: if, for some reason, a GIS client can't understand the projection information to import the data as raster, it's still possible to import it as a set of point features. It may be clunky to work with that way, but it's a lot better than nothing. Likewise, there are a lot of homebrew systems out there that do GIS-like things without having a full suite of sophisticated projection tools behind them. Allowing the users of those systems to figure out where the grid-cells are located without needing to research and implement the relevant coordinate transformations by hand is a big win for usability. Cheers, --Seth McGinnis Associate Scientist NARCCAP Data & User Community Manager ISSE / NCAR > Just a word about GIS clients, picking up on one of Steve's > comments - many GIS clients would prefer to have the > coordinate system properly specified (as a CRS code or > Well-Known Text) rather than by listing the lat-lons > exhaustively. (Another conversation could be started to > discuss the value of including these as optional attributes, > since most of the CF projections are commonly used in GIS.) _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
