- From: Satoru Takagi <satoru.takagi@ubin.jp>
- Date: Tue, 01 Aug 2006 13:43:12 +0900
- To: public-xg-geo@w3.org
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