Bill, thanks for taking the time to review the document. Comments inline. > Section 2. Introduction > [use of WGS84 reference system] > > I wonder if it might be more forward thinking to allow for > the optional > specification of the reference system being used. Perhaps > this could be one > of the "URI parameters" mentioned in section 4.7 We had a long discussion about that when we started work on this document. From the standpoint of a geographer, it would of course be beneficiary to have multiple reference systems. However, from the standpoint of a common user, reference systems "do not exist" (excuse te pun). "Coordinates" is what they read from the display of their GPSr, or what pops up on <name favourite web mapping service> when they click on a location. For the sake of simplicity, we therefore decided to go for a single reference system, and use the most predominant one. I know that especially in the US, many maps are in NAD83 - however, i think that WGS84 is by far the most common one in the applications that we have in mind. Many other geo-formats mandate WGS84 as well (eg. RFC 1876). We could, of course, add a parameter to indicate the reference system. But: - If parameters are optional (as we intend them to be), a parameter must not change the meaning of the base URI components. An unknown (or ignored) reference system might lead to interpretation of the lat/lon components in a completely wrong way (eg. NAD83 vs WGS84 can be a couple of 100 meters, which led to stranded cargo ships) We could work around this if we require an application to ignore a URI with parameters unknown to the application. However, there might be two classes of parameters then: "important" ones that change the meaning of the URI completely (like reference system), or "optional" ones that only provide more information (like a label, uncertainty, etc..) [ok, i don't want to go down the rathole whether "uncertainty" changes the core meaning of the coordinates] Our conclusion was that we'd only go for more reference systems once there is strong opinion that this is really needed. I've not seen much use of other reference systems in other geo-formats on the internet - essentially everybody uses WGS 84. We'd of course appreciate comments on this. > Section 4.4.1 Component Description > The number of decimal places indicates the precision of the value. > One degree equals 111.319,45m at the equator (40.075,004km / 360 > degree). Five decimal places (0.00001 degree) seem to imply a for > civil use sufficient accuracy. hm.. This part of the document seems to be a leftover. We decided that a "point is a point is a point", and any interpretation of numbers of digits is flawed (for reference, check the "binary lci" discussions around revision of RFC 3825). We'll probably remove that text in the next revision, unless there are strong opinions that the number of digits should be interpreted to represent ... uhm.. something. > Section 6. GML Mappings > > There seems to be no explanation of what GML is, not even a Reference > document. Will add. I was busy with printing it out (450 pages) so that i forgot the reference. > Section 9.1. Invalid Locations > > Is there a recommended way to represent the poles? Dare I > suggest <geo:90> > and <geo:-90>? If that is too much of a special case, should > the longitude > always be zero or can it be anything between -180.00000 and 180.00000? Good point. We will think about it. I'm a bit biased towards not changing the ABNF, and adding text like "The poles SHOULD be represented with the longitude component set to 0, however, applications SHOULD accept URI instances with longitude component set to any value between -180 and 180"... (be conservative in what you send, and liberate in what you accept). Opinions? > Section 9.2. Location Privcay > > Typo: .................Privacy Thanks - will change. Alex _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf