 |
 |
.. thanks for the credit in strawman (& spelling my name right !) I'm less concerned about the L/L format now. It seems that naked numbers are taken by GIS professionals as long-lat (elevation), and other formats can mostly be decoded by identifying the field delimiters. Software e.g. the PROJ.4 distribution is able to do this. Would the scheme default to free text, allowing e.g. <META name="dc.Coverage (type=spatial)" content="British Columbia"> <META name="dc.Coverage (type=temporal)" content="19th Century"> ? I still feel that the datum needs defining, perhaps as part of the schema e.g. <META name="dc.Coverage (type=spatial, scheme=LongLat.UTM)" <META name="dc.Coverage (type=spatial, scheme=LongLat.WGS84)" as otherwise the position can be hundreds of metres in error and I think we need to allow elevation to optionally define a volume, such as a room in a building, a gallery in a mine, etc. that cannot be adequately described in only two dimensions. Extending the example from the 1.1 strawman from -120.503 -118.334 80.167 79.834 to -120.503 -118.334 80.167 79.834 10.0 40.0 is unambiguous as long as we have specified the datum and units (here, degrees and meters). One can unambiguously collapse the volume to a 3D point -120.503 80.167 10.0 or 2D point -120.503 80.167 if that is sufficient (the location of a utility pole or network router, perhaps). Andrew Daviel