Dear Paul
Alison (the manager of standard names) hasn't ruled yet on their inclusion,
but I believe that the discussion concluded with no objections to adding
the practical salinity names. It seems safe to assume they will be put in the
table in due course.
Best wishes
Jonathan
Dear all
Patrick's example is useful.
DATUM[Geocentric_Datum_of_Australia_1994,
SPHEROID[GRS 1980,6378137,298.2572221010042,
AUTHORITY[EPSG,7019]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY[EPSG,6283]],
PRIMEM[Greenwich,0],
Dear Philip, Jonathan,
1.) thanks for your helpful comments. After a little side discussion with
Philip, it appears that there is indeed a need for expressed_as phrases even
for molar quantities. Hence, my suggestion reduces to
* add mole_fraction_of_nox_in_air as an alias to
Dear all,
At the risk of repeating ourselves, because there are now (at least) three
different salinities, it is now ambiguous and confusing to call any salinity
Salinity. The Announcement of TEOS-10 that is now appearing in all 22
oceanographic journals specifically recommends that the
Hi
I agree adding something like 'datum = WGS84 is very easy for
modellers to adopt, but in geodetics terms this is very ambiguous.
While it is simple, it is simply not enough.
If you want simple, a solid approach is EPSG codes.
Take a look at the openlayers examples at:
Hi all,
If aiming for more simplicity, perhaps PROJ.4 strings would be more
interesting. http://trac.osgeo.org/proj/wiki/FAQ
The advantages or PROJ.4 is that projection and datum can be expressed
in relatively compact format, and you can alternatively plug in an
EPSG code for simplicity.
There
An additional benefit of using PROJ.4 strings is that the proj
open-source library (http://trac.osgeo.org/proj/) can be easily used
for coordinate transformations, either with a C API or with a
command-line tool (cs2cs).
For example, GDAL and mapserver use PROJ.4 for its coordinate
