On Tue, 22 Mar 2005, James M. Polk wrote:
> comments on draft-daviel-kaegi-html-geo-tag-07.txt
>
> - someone needs to clean up the template used to be appropriate
yes, I think the templates have changed a bit since the original version
>
> - I don't believe I like the applicability section that limits the tags to
> fixed, non-moving objects, and "...may not be used for multinational
> companies...". I think this will be misunderstood to be used for "where's
> the nearest Pizza Hut?", which is disallowed because it is multinational,
> but "where's Bob's Ace Hardware store?" is fine because it is magically
> local in nature.
The intent is to say that the geographic location of "Fermat's
Theorem" or "Ford Motor Company" is meaningless, and to suggest that
the geographic data space not be polluted with, for instance, every
document that Joe User wrote after he added his office location to
his default template. Suggestions for better examples or wording are
welcome.
A position for a moving object is certainly reasonable, though using HTML
to publish it may not be the best method. The HTML metadata was intended
to provide primarily an interface for a search engine, which typically has
an update cycle of several weeks.
>
> - the ID mentions this is for "where a river is", yet that is not going to
> be given in a single coordinate pair (x,y); thus making this specific
> reference highly ambiguous in use;
"river" is a counter-example, of an object that is ill-suited to
being described by a single co-ordinate pair.
>
> - I also don't like the ambiguity about datums (none is specified), and the
> lack of a definition of what is meant by altitude. The text seems to point
> out some of the problems, but not really deal with how to address them.
The draft specifies WGS84, if position is specified with sufficient
accuracy for this to make a difference. The draft deliberately
does not include a datum field - allowing users to specify alternate
datums would increase the burden on search engines to provide conversion
routines from multiple datums and formats to the internal datum,
canonically WGS84.
Altitude is defined as elevation above WGS84 datum, with the caveat that
this may not be what a user expects in terms of "metres above ground
level". Altitude is, I believe, difficult to deal with. Elevations
shown by regular GPS sets are less accurate than horizontal measurements,
while the scale of human structures in terms of floor level is
more sensitive to altitude errors than horizontal errors - a 3 metre
error in altitude when you are trying to find your car in a multi-storey
car park is more serious than a 3 metre error North.
Even if an altitude were specified accurately wrt. some well-defined
datum, that doesn't easily translate into levels in the car park.
The only reason for including an altitude field is that it shows up
on a GPS display and if a user wants to include it, they can. Sometimes
it may be useful - "this photo was taken at 2300m".
>
> - the draft raises no security issues by not dealing with privacy and
> revelation according to anyone who may believe they have the right to
> provide a location of a thing.
>
> Thus, I object to this effort if privacy cannot be adequately addressed as
> to who is allowed to associate a location with a tag.
Privacy issues must be handled offline through common courtesy or legal
proceedings. There is nothing that one can put in a public web page that
will prevent an agent from retrieving it. This is same situation
as someone publishing telephone numbers or email addresses.
The HTML metadata is an embodiment of the KISS principle enabling Web
authors to add simple location data to a public page. In terms of
RFC3693, it is not an instance of a "publication interface" or
a "notification interface", but an interface between a Location Recipient
(the process that has published the location data into the public domain
on a webserver) and a search engine. A structured privacy query system
is only valid over an authenticated, preferably encrypted, channel - the
location generator and location server authenticate each other, then apply
the rules to determine what location data is exchanged. The public Web is,
almost by definition, not such a secure channel. In fact, security
considerations dictate that information about scope, credentials etc.
NOT be published on a public page - such information may give an attacker
clues as to the fact that more sensitive data exists, and the methods
that may be used to obtain it.
> comments on draft-daviel-kaegi-http-geo-header-05.txt
>
> - the example section chose a poor example. If my laptop doesn't know where
> it is, it cannot supply enough information to know which weather map is
> which URI. This seems to be an attempt to get around a tunneling search for
> where a user is to learn information to is available if the person
> identifies what they want.
I don't follow this.
If the laptop does not know where it is, either by live feed or stored
location, then it is true that the method cannot work.
>
> - section 2 says
> "In cases where the object being described is an area, such as a lake
> or a building, the position of the object should not in general be
> given to greater precision than the width of the object."
>
> then how would Lake Michigan be described? Or how would the Mississippi
> River be described?
"44;-87". It's not intended to replace a GML polygon, or to convey a
statistical measure of accuracy, just to suggest normal engineering-type
usage of not giving the answer to 10 places of decimal if the original
measurement is "50 paces North"
This sentence should probably not be in the HTTP draft, only the HTML one.
> - section 4 - where are all these values (and their hierarchies) assigned?
> CA-ON is Ontario, Canada to you, having spent time in Southern California
> (it washed off BTW) I misunderstood CA-ON for Ontario, California very quickly.
ISO3166.
ISO-3166-1 is in most cases the Internet country code (top-level-domain)
ISO-3166-2 is, for the USA and Canada, the well-known state/province
abbreviations e.g. WA, BC.
It's pretty unambiguous in most cases, e.g. US = United States, FR =
France, DE = Deutchland = Germany, though there are a few differences.
GB = Great Britain, while the top level domain is UK = United Kingdom
>
> BTW - at the site http://geotags.com/geo/DMS3.html I typed in CA for the
> country code, and ON for the region code, and got a failure - I did not get
> Canada anything, nor did I get California anything. This may be a function
> of the website, or it may be a function of ISO3166-2 not being specific
> enough. I'm not sure, but this error has be questioning what would we use
> that works?
The page is confusing, I agree. It wants a country selected first, which
changes the drop-down list for the region. When a state/province is
selected, it fills in the region code (e.g. US-AL for Alabama) which can
then be converted to a meta tag. If the two-element region code is known,
it can be entered directly, bypassing these steps.
>
> - there is no normative text discussing security, privacy or other such
> considerations. I think that is bad.
>
There is a section 8, "Security Considerations", which I understood to be
normative at the time the draft was originally submitted.
> Therefore, I have strong concerns with this effort moving forward until
> these issues can be addressed in direction first, specifics later.
>
Andrew Newton writes:
> It would seem the disconnect between these drafts and the work-to-date
> within GEOPRIV centers on the use cases - given the regard to privacy
> GEOPRIV has taken.
I know that there is somewhat of a disconnect. These drafts were
originally referred to this WG by the RFC editor, because they both dealt
with geographic data and the Internet.
If the scope of these drafts (operating on publicly published data)
is outside the purview of the geopriv WG, then perhaps the WG could
state this and the reworked drafts could be resubmitted to the RFC editor.
I still feel there is a need for something like this - schemes such as WML
are essentially too complex for amateurs - Joe Blogger with his camera and
GPS , though they may be excellent for professionals to exchange GIS
information.
> Perhaps we could get a list of places where these drafts have been
> implemented so we can better understand the uses to which these specs
> are being put.
The HTML metadata is used in the geotags.com demonstration search engine
and in the small number (hundreds) of pages submitted to it. There has
been some interest from the blogging community.
The HTTP headers have, as far as I know, been used only in
proof-of-concept code interfacing to this search engine.
Potential use includes wireless PDAs, in-car navigation systems etc.
An interface has been described (http://gmap.glenmurphy.com/)
to Google maps using a GPS. GPS interface to laptops is common
in wardriving using e.g. NetStumbler. High-speed wireless
Internet service to a laptop is available in limited areas
(http://www.fido.ca/portal/en/support/ifido.shtml), and moderate-speed
data services (GPRS, EDGE) are widely available.
So the pieces are in place to make this work.
I would probably now add a geo.postcode element. Although it has been
stated that postcode is totally unsuited as a geographic description
(irregular shaped postal boundaries, orders of magnitude differences in
size between rural and urban postal areas), nevertheless it is being used
by search engines (Google) and is, at least, well-defined and
well-understood in modern urban society.
Andrew Daviel
Vancouver Webpages
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 23 Apr 2005 10:55:20 -0700 (PDT)
This archive was generated by hypermail 2.1.8 : Mon Apr 25 2005 - 07:02:58 EDT