Re: lat/long as float

The definition of the data type of ISO6709 is difficult in XML Schema.
However, XML is only a kind of the notation of data. Of course, it is a
very important notation.
In RDF, Notation3 and other non-XML notations are defined. Microformats
might be those kinds. And, classic CSV was published as RFC4180 last year.

Therefore, I think that it should examine without doing focus to XML,
especially to huge XML Schema specifications only.

Moreover, the data notations by Degrees-Minutes-Seconds are still used
with a lot of indigenous use cases. It is at least so in my surroundings.
In addition, it exists also in the open specifications.
For instance, Wikipedia:WikiProject Geographical coordinates :
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates

And, I built the ISO6709(/1983) parser by way of experiment on java and
VBA. It will be able to be achieved by a realistic number of steps.


About ISO6709:
A more concrete specification is necessary to achieve a realistic
interoperability by a less number of program steps. Therefore, the
abstraction of latitude longitude notation (ISO6709) might be undesirable.

In XML (schema), the data type is given to ISO8601 as a peculiar
notation. It is W3CDTF as subset of ISO8601.
Such a way might be applicable for the latitude longitude notation; like
W3CLLF (W3C Latitude Longitude Format) as subset of ISO6709.

See also:
(RDF) Geo Metadata and embedding it in SVG:
http://esw.w3.org/topic/GeoMetadataOverSvg

Position paper that relates to ubiquitous web and spatial informations:
http://www.w3.org/2006/02/UbiquitousWebUNL.pdf

Regards

Carl Reed OGC Account wrote:
> Takagi -
>  
> The use of 6709 has been discussed in various non-ISO forums, such as 
> the IETF, OASIS, and the OGC. While aspects of 6709 are valid for the 
> expression of coordinates in XML or other serializations (see below my 
> signature), the OGC membership has identified some issues with 6709 in 
> terms of implementation reality. The OGC sent the following comments to 
> ISO WRT 6709:
>  
> /OGC has an objection regarding ISO 6709 entering the enquiry stage./
> // 
> /The proposed DIS for 6709 (TC211 N-doc 1939) contains these annexes:/
> / Annex F (informative) - Utilization of Geographic Point Locations /
> / Annex G (informative) - Examples of XML representation./
> 
> //
> /Annexes F and G of ISO 6709 will be confusing as ISO members are 
> currently considering XML encoding of geographic points in GML (ISO 19136)./
> 
> //
> /Previously it was concluded that no GML examples can be given in 6709 
> because GML uses decimal degrees only for all geographic coordinate./
> 
> //
> /Although ISO 6709 uses a Degrees-Minutes-Seconds representation 
> of coordinates in an XML exchange, we question the usefulness of 
> the examples, since they are arbitrary instance examples and there is no 
> schema for such coordinates./
> 
> //
> /Thus, OGC recommends that Annex G and Annex F be removed from ISO 6709 
> before it is sent to the ISO Central Secretariat for publication as DIS./
>  
> That said, if one considers the snippet from the 6709 document (below my 
> name), we find that GeoRSS, GML, the OASIS work using lat/long, and the 
> IETF use of lat/long for points all adhere to the stated clauses.
>  
> Regards
> 
> Carl Reed
> OGC
>  
> The following from 6709  is valid for any and all work related to 
> encoding of lat/long:
>  
> Clause
> 2.1.1, 2.2.1 in action:
> 
> 2.1 Latitude
> 2.1.1 Latitudes north of the equator shall
> be designated by use of the plus sign (+),
> latitudes south of the equator shall be
> designated by use of the minus sign (-).
> The equator shall be designated by use
> of the plus sign (+).
> ...
> 2.2 Longitude
> 2.2.1 Longitudes east of Greenwich shall be
> designated by use of the plus sign (+),
> longitudes west of Greenwich shall be
> designated by use of the minus sign (-).
> The Prime Meridian shall be designated
> by use of the plus sign (+). The 180th
> meridian shall be designated by use of
> the minus sign (-). 2.4 Format
> ...
> 2.4 Format
> 2.4.1 Elements shall be combined in a point location string in the
> sequence :
> a) latitude;
> b) longitude;
> c) altitude, if represented.
> ----- Original Message -----
> From: "Satoru Takagi" <satoru.takagi@ubin.jp <mailto:satoru.takagi@ubin.jp>>
> To: <public-xg-geo@w3.org <mailto:public-xg-geo@w3.org>>
> Sent: Thursday, July 27, 2006 9:45 PM
> Subject: Re: lat/long as float
> 
>  >
>  >>All coordinates in this profile shall, as a default, be expressed as
>  > Latitude Longitude (in that order) as decimal degrees white space 
> separated.
>  >
>  > Quite a lot of notations for latitude longitude (and altitude , crs)
>  > information exist in the world.
>  > There might be each advantage and a disadvantage respectively.
>  > However, I think that it is desirable that they are few. For the
>  > improvement of the interoperability.
>  > I think that it can settle to the following two notations by simply
>  > thinking.
>  >
>  > Methods of separately describing latitude and longitude. Methods of
>  > description as one character string.
>  >
>  > In a lot of usages, latitude and the longitude will be considered to be
>  > inseparable one resource.
>  > Casual use cases such as microformats (geo improvements), WikiProject
>  > Geographical coordinates, and geoRSS might be the examples.
>  > Though they are all different formats.
>  > #Methods of divided description as a different attribute are omitted
>  > because there are a lot of examples.
>  >
>  > Well, I think that it is necessary to consider ISO6709/1983 as an
>  > important candidate in such a situation for one character string format.
>  >
>  >
>  >

Received on Tuesday, 1 August 2006 08:19:17 UTC