[Seavox] Vertical CRS Datums (length dimension)
Eric MOUSSAT
Eric.Moussat at ifremer.fr
Thu Mar 1 16:49:37 GMT 2007
Dear Roy,
first of all thank you to promote me as a specialist...
I would like to ensure me that we share the same definitions in order to
make a correct mapping between EPSG codes and your list.
A VERTICAL CRS uses the direction of gravity to define the concepts of
height (H) above or depth below a VERTICAL DATUM. VERTICAL CRS and
VERTICAL DATUM have not the same EPSG code ( in my previous E_mail I
gave vertical CRS codes for elevation in France not vertical datum codes)
As mentionned by Woolf, accordindly to ISO19111," a CRS consists of:
(0) general CRS attributes, e.g. CRS name
(1) a "Coordinate System" (consisting of CS name etc. and an ordered
list of {axis name, axis units, axis direction} triples, one per CS
axis) - for a vertical CS we only have one axis
(2) a "Datum" tying the CS to the real world. In conventional geodesy
gives the parameters of a reference ellipsoid for example (so a lat,lon
then has an actual position in space), but for our vertical CRS it would
be things like 'zero at LAT'. Of course LAT then needs definition, and
the whole question of how to deal with parametric vertical coordinates
is the subject of a new revision of ISO 19111. Until it's resolved, I
think an ad-hoc treatment of Datum for such CRS is perfectly reasonable
(and probably wise).
So in your example below, we'd have:
* CS:
- name not explicit, could be autogenerated (e.g. DepthCS)
- one vertical axis (implied)
- axis name: 'Depth'
- axis units (measuredIn): metres
- axis direction (directionIs): down
* CRS:
- general attributes (e.g. name) are not explicit, a name could be
autogenerated (e.g. DepthFromMeanSeaLevelCRS)
- CS is implied ('DepthCS')
- Datum (datumIs): mean_sea_level "
You have a guidance note (7 part 1) on the OGP site
(http://www.epsg.org/) precising this with detailed
definitions (see attached document).
1/Definition of the list
In the list 111 only vertical datums seem to be mentionned assuming that
vertical axis is depth. But :
- I have the feeling that several datums mentionned in the list 111 are
datum used for heights and not directly for depth. Indeed a depth
usually refers to another datum : usually the hydrographic zero which
has an offset related to the Zero of height.
- you can have, for example on shore, vertical positions expressed as
heights.
So :
- it would be better to maintain a list of vertical CRS and not only a
list of datum to ensure us that vertical coordinates of a dataset are
correctly defined.
- the EPSG code (when available) associated to a key of your list will
change depends on the adopted definition .
2/Contents of the list
"Mean sea level" is not a real datum as it is not tied unambiguously
tied to the Earth.
Offshore, you cannot do it otherwise so such an entry must exist.
But in coastal waters, datums known as "hydrographic zeros"
(conventionnal level for the safety of the navigation derived from the
level of the lowest astronomical tide) for measuring "depth" are well
defined as a specific level marked on tide gauge in harbours of
reference with the offset with the 0 of heights of the legal CRS on
land. You have as numerous hydrographic zeros as
harbours of reference and are identified by the name of the harbour at a
given epoch.
So vertical datums should be described with :
- the description and the origin of the datum. For depth for example :
"hydrographic zero at harbour XXXX".
-(when available) the relationships with the legal reference
datum for height on shore ;
- the datum epoch (I already mentionned the case of Brest harbour the
zero of which was shifted of 50cm in 1996)
- the source (French HO for example with possible link to the HO pages
as prefered by SHOM for example)
See example of a CRS (5739)for depth sent by OGP with datum information.
This raises several difficulties:
- there are as numerous hydrographic datum as ports of reference.
- entries have to be added to take into account not well defined datums
(this is the case you mention with EDIOS : what can you do if you want
to merge elevation with depth ?).
So the question are : what is the purpose of the 111 list ? should we
keep it ?
Will this list be used only to map the horizontal locations of
observations? In this case, the vertical CRS is not of key importance
and 111 list can be dropped (but we should recommand to keep this
information somewhere with datasets)
Will this list be used to evaluate the possibility and to allow the
transformation of vertical coordinate in another CRS to merge various
sources of data : sea level (tide gauges, ...), bathymetry, ... ? In
this case, an accurate definition of list 111 is necessary, compatible
with ISO 19111 and EPSG standards. That includes also for France as for
the other countries (such as UK) the necessity of defining all datum
and more especially all reference harbours and CRS related to these datums.
These datum are available in Hydrographic off. or equivalent
organizations of the different partners. For our part, we can supply
them for France.
3/ Mapping datum/CRS with EPSG codes.
Codes are missing in the EPSG DB especially for hydrography. It seems
difficult to get an EPSG code for all datums we have to coop with.
Indeed, OGP that I contacted agrees with the introduction of new codes
but prefers that we create our own list.
It is not sure that this initiative will be supported by the
Hydrographic Offices. The French HO has not envisionned to introduce
its own datum in the EPSG DB at present for safety consideration (but
this could change).
So what we can do is only to add EPSG code when available in your list
and introduce as numerous entries in the 111 list as they are
hydrographic zeros.
Nevertheless, I will supply what I found as EPSG codes as soon as I know
the definitive need and definition of 111 list. But I think that each
partner has to check the list and complete it as they are in a better
place to ask this information to their national institution .
Regards
Eric
>
> coy Lowry a écrit:
>> Hello Eric,
>>
>> If you give me a spreadsheet of entries that you wish to be added
>> (name abbreviation and definition) then I will add them - easily done.
>>
>> I am also not a specialist (to the level that I did not know there
>> was an EPSG vertical CRS datum list) and so depend upon help from
>> people like yourself. Using EPSG codes for keys where possible would
>> have been a nice idea, but unfortunately I have already loaded the
>> vocabulary into the system and the one thing the system is designed to
>> do is stop me changing keys. However, it does allow me to change
>> definitions so I could add EPSG references to the appropriate
>> definitions. Could you possibly let me have a map along the lines of
>> EPSG code against the key I've used (the Dnn) numbers and I'll do this.
>>
>> The 'French Naval Chart Datum' came from the EDIOS database as the
>> vertical datum label for one dataset located between 33.75 and 34.83N,
>> 35.25 to 35.92 east (Lebanese Hydrobiology Monitoring Programme) . The
>> actual description for the datum on the MIF was 'French
>> Navy-Navigation Maps'. If you can give me a better description to use
>> for this in the vocabulary then I will use it.
>>
>> I will leave it to Pieter to answer the question on the definition for
>> ED50/EPSG4230 in the L101 list.
>>
>> I hadn't really considered the maintenance issue as I assumed that
>> EPSG entries were stable. If new entries are made to EPSG that we
>> feel are relevant to our work then they can be added. No matter what,
>> for anything linked to EPSG I would consider them to be the
>> authoritative governance. Having what is effectively a SeaDataNet
>> subset to EPSG has been done in attempt to simplify vocabulary usage
>> for partners (I find EPSG impossible to use as a non-specialist) and
>> to provide users with a single uniformly managed source for all
>> vocabularies used in SeaDataNet metadata.
>>
>> Cheers, Roy.
>>
>>>>> Eric MOUSSAT <Eric.Moussat at ifremer.fr> 2/16/2007 1:09 pm >>>
>>>>
>> Dear Roy
>>
>> sorry for my long silence (too much busy)
>>
>> I have some comments relazted to CRS lists ( 110 and 111).
>>
>> 1/111
>> Vertical French CRS are missing in your list. So they should be added.
>>
>> For example, elevations above sea level in French mainland, even on
>> nautic charts refer to IGN69 vertical CRS and in Corsica to IGN78
>> .
>>
>> 2/EPSG codes for vertical CRS
>> Among the vertical CRS, they are vertical system which are used for
>> elevation which have EPSG code.
>>
>> For France
>> IGN69 vertical CRS = EPSG code 5720
>> IGN78 with EPSG code = 5721
>>
>> They are other CRS for oversea territories that I will transmit to you
>> later as I don't have the whole list at present.
>>
>> Anyway I think we should have some consistency in the way we described
>> the CRS in list 110 and 111 as we mention EPSG code with (partial)
>> EPSG defintion in the first one and not in the second.
>>
>> 3/Naval chart datum
>> It is not enough to mention "naval chart datum" .
>>
>> France is divided in tide zone (see attached document from French HO).
>> When some body has to correct water height to depth, he has to use the
>> tide correction of the nearest refering port of the zone where
>> measurements were carried out. These correction relates to an
>> hydrographic "zero" level specific to the zone and to the port within
>> the zone.
>>
>> From one zone to another you may have an offset of several tens of cm.
>>
>> This is due to the evolution of method and technology used to define
>> the 0, to the fact that it is a conventionnal (and not an observed)
>> level to ensure the safety of navigation, to the fact that some
>> references are very old (first one definesd in Brest 200 y ago) and to
>> the sea level rise.
>>
>> As a consequence, you have to mention :
>> - the refering port used when mentionning the naval chart datum (this
>> is done in our Environment Dpt)
>>
>> - the date of definition of the zero. In Brest, the present 0 (defined
>> in 1996) is 50cm above the previous one . In St Nazaire, 40 cm below
>> the previous one.
>>
>> This is probably somewhat which concerns other countries with high
>> tides or/and old datum.
>>
>>
>> 3/11O list
>> I gave a look to the description of CRS and noticed , at least for
>> ED50 (4230 EPSG code) that the definition does not fit completiley the
>> EPSG one. The original defintion precises that ED50 was used for
>> French hydrographic chart. This should be mentionned as numerous data
>> still refer to this system in spite of the fact that RGF 93 is the new
>> legal ref.system.
>>
>> This raise the question of the maintenance of these information ,
>> already avalilable in EPSG DB. How it is planed to do it ?
>>
>> I am going to leave for one week due to the holidays of my children. I
>> will see your reply not before the 26th. I hope this mail be helpfull
>> and I thank you for your understanding
>>
>> Regards
>>
>> Eric
>>
>> -----------------------------
>>
>> Roy Lowry a écrit:
>>
>>> Dear All,
>>>
>>> Another draft vocabulary for comment, covering CRS datums assuming
>>> the dimension of 'length'. Further lists (L112, L113 etc.) will
>>> eventually be set up for other non-length based CRS (pressure,
>>> density etc.).
>>> I appreciate that the content is currently very Euro-centric.
>>> Relevant additions for the USA (including definitions please) welcome.
>>>
>>> Cheers, Roy.
>>>
>>>
>>>
------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Seavox mailing list
>>> Seavox at mailman.nerc-liv.ac.uk
>>> http://mailman.nerc-liv.ac.uk/mailman/listinfo/seavox
>>
>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GN07-1 Use of EPSG Geodetic Dataset.doc
Type: application/msword
Size: 431616 bytes
Desc: not available
Url : http://mailman.nerc-liv.ac.uk/pipermail/seavox/attachments/20070301/6f561615/attachment-0001.doc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpt Vertical CRS 5739.rtf.rtf
Type: application/msword
Size: 7994 bytes
Desc: not available
Url : http://mailman.nerc-liv.ac.uk/pipermail/seavox/attachments/20070301/6f561615/attachment-0001.dot
More information about the Seavox
mailing list