Subject: [Geopriv] [GETOAGS Drafts] - Simple Description, Use Case Scenarios and advantages of the two proposed drafts

From: "Felix Kaegi" <[email-masked]>
Date: Wed, 20 Apr 2005 09:21:11 +0200

Closer Description, Use Case Scenarios and advantages of the two proposed
drafts: 
[draft-daviel-kaegi-html-geo-tag-07.txt] and
[draft-daviel-kaegi-http-geo-header-05.txt]
If you have ever asked yourself what it needs if you enter "Pizza" into a
search engine (like google for example) and want the results to have sorted
according to the distance of your actual geographic point, then this will
describe it:

For easy geographically searching documents with search engines two things
are necessary:

1) The Author must add some sort of Geographic Met information to a
document.  For HTML Document Metainformation is generally given in HTML meta
tags called META. Unfortunately the HTML standard describes lots of Metatags
but none for Geo enabling. The paper
[draft-daviel-kaegi-html-geo-tag-07.txt] describes a simple HTML META Tag
syntax for geo enabling HTML Documents. Search engines interpret META tags.
The geo relevant metainformation can be use to associate a HTML Document to
the described Point of Interests. Searching for documents with given
keywords and a given geocoordinate (for example place of interest or the
home place) enables now to sort the relevant search result according to the
distance. Entering "Pizza" and the geo coordinate (or a lookup from an
address) returns a result list with documents/websites that contain the
keyword "pizza" in order to their distance of the search point.

Advantage of this solution to googles "Local Search" solution:

The local based service from google
<BLOCKED::http://www.google.com/lochp?hl=en&tab=wl&q=>
http://www.google.com/lochp?hl=en&tab=wl&q= lacks the possibility to work
with scalable and language independent geo coordinates. Google uses a method
of finding Geographic Addresses in a document and geo coding them in their
search engine. This method may be ok for the USA where everybody speaks
English and addresses are given in one format. The method will hardly work
properly in Europe unless all possible address name translations are
implemented. Think about Belgium or Switzerland where more than three or
four official languages are spoken and Address Names like
(Genf/Geneve/Geneva) are written in many valid Languages and even more in
different Lanugagesmapping with special characters and so... Further the
googles solution is locked down to postal addresses. One will never be able
to find a document that describes a geographic point out in nature. For
example a wreck, an interesting Mountain or a hut without an official postal
address. The here describes solution is scalable to what ever magnitude the
author of a document wants to.

2) When searching for information with a search engine or requesting any
other location based http-service sometimes the user wants his actual
position/address to be send to the search engine or the http server to sort
the answers relevant to his actual request  position/address. Nowadays this
is possible based on different communication layers: The user might type in
the address manually or define it in a map GUI on the website. (I don't know
of  any web service that accepts geo coordinates in any standard form.) Then
the web service might store this information in a cookie for the next visit.
But if the users geographical point of Interests change (mobile device) he
always has to retype the address for every local based service request. And
even worse it might be that he even does not has a postal address because he
is on the road and only geographic coordinates (from a GPS) would describe
accurate enough his actual point.

The paper [draft-daviel-kaegi-http-geo-header-05.txt] describes a simple
http standard add on to send the geo information in a http request based on
the browser settings. The user may define in the web browser whether or not
he wants to send the geographic address of his actual point to a web server
or not. The browser may detect this information at installation time, from a
GPS device or from an ISP/mobile cellular provider. The user is always aware
if or if not he wants to send this information to a web service. Also for
implementing an E911 service this protocol ehancement would fit.

Felix

----------------------------------------------------------------------------
------------
Felix A. Kaegi                     
Dipl.Inf.Ing.ETH (MSc)                 mobile   +41 79 625 27 41
eXception handler Ltd.                 fix         +41 61 383 10 02
Friedensgasse 51                       fax        +41 61 383 10 03
CH-4056 Basel                           skype     <callto://felix_kaegi/>
felix_kaegi 
Switzerland                                www.exceptionhandler.com
<http://www.exceptionhandler.com/> 

----------------------------------------------------------------------------
-------------

May The Source Be With You!

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 20 Apr 2005 21:18:11 -0500 (EST)

Sorry if I am jumping into the middle of this discussion. I need to read
the drafts more closely.
However, in terms of Google, please be aware that the underlying engines
for geocoding and application independent and region/language independent.
These capabilities are not exposed at the current user interaction level.
Further, the most recent underlying geocoding and search engine for Google
Maps - called the DrillDown Server - has been enhanced to incoporate the
OGC OpenLS Interfaces, including geocoding and routing. These interfaces
reference abstract data types that are geography and language neutral.
They will work in the US, Canada, Belgium, Spain and so forth (although I
am not sure about languages that use 16 bit characters). These interfaces
work in http, Java, and more recently Soap land. The OpenLS interface
suite also includes an interface for a directory service( to deal with
your pizza case ). The OGC OpenLS interfaces are publicly available and
can be found at www.opengeospatial.org under Specifications in the
document pulldown
Also, in the geotechnology world there is an application operation called
"gazetteer". A gazetteer functions allows the user/application to enter a
name, such as a city, town, or business name, and returns the coordinate
(geometry) as well as the properties of the coordinate (if these have been
databased).
Having said all this, I need to read all the documents more closely and
then provide more detailed responses.
Regards

Carl Reed
CTO
OGC

escription, Use Case Scenarios and advantages of the two
> proposed drafts:
> If you have ever asked yourself what it needs if you enter "Pizza" into
> a search engine (like google for example) and want the results to have
> sorted according to the distance of your actual geographic point, then
> this will describe it:
>
> For easy geographically searching documents with search engines two
> things are necessary:
>
> document.  For HTML Document Metainformation is generally given in HTML
> meta tags called META. Unfortunately the HTML standard describes lots
> of Metatags but none for Geo enabling. The paper
> [draft-daviel-kaegi-html-geo-tag-07.txt] describes a simple HTML META
> Tag syntax for geo enabling HTML Documents. Search engines interpret
> META tags. The geo relevant metainformation can be use to associate a
> HTML Document to the described Point of Interests. Searching for
> documents with given keywords and a given geocoordinate (for example
> place of interest or the home place) enables now to sort the relevant
> search result according to the distance. Entering "Pizza" and the geo
> coordinate (or a lookup from an address) returns a result list with
> documents/websites that contain the keyword "pizza" in order to their
> distance of the search point.
>
> http://www.google.com/lochp?hl=en&tab=wl&q= lacks the possibility to
> work with scalable and language independent geo coordinates. Google
> uses a method of finding Geographic Addresses in a document and geo
> coding them in their search engine. This method may be ok for the USA
> where everybody speaks English and addresses are given in one format.
> The method will hardly work properly in Europe unless all possible
> address name translations are implemented. Think about Belgium or
> Switzerland where more than three or four official languages are spoken
> and Address Names like
> (Genf/Geneve/Geneva) are written in many valid Languages and even more
> in different Lanugagesmapping with special characters and so... Further
> the googles solution is locked down to postal addresses. One will never
> be able to find a document that describes a geographic point out in
> nature. For example a wreck, an interesting Mountain or a hut without
> an official postal address. The here describes solution is scalable to
> what ever magnitude the author of a document wants to.
>
> 2) When searching for information with a search engine or requesting
> any other location based http-service sometimes the user wants his
> actual position/address to be send to the search engine or the http
> server to sort the answers relevant to his actual request
> position/address. Nowadays this is possible based on different
> communication layers: The user might type in the address manually or
> define it in a map GUI on the website. (I don't know of  any web
> service that accepts geo coordinates in any standard form.) Then the
> web service might store this information in a cookie for the next
> visit. But if the users geographical point of Interests change (mobile
> device) he always has to retype the address for every local based
> service request. And even worse it might be that he even does not has a
> postal address because he is on the road and only geographic
> coordinates (from a GPS) would describe accurate enough his actual
> point.
>
> The paper [draft-daviel-kaegi-http-geo-header-05.txt] describes a
> simple http standard add on to send the geo information in a http
> request based on the browser settings. The user may define in the web
> browser whether or not he wants to send the geographic address of his
> actual point to a web server or not. The browser may detect this
> information at installation time, from a GPS device or from an
> ISP/mobile cellular provider. The user is always aware if or if not he
> wants to send this information to a web service. Also for implementing
> an E911 service this protocol ehancement would fit.
>
> Felix
>
> ----------------------------------------------------------------------------> ------------
> Felix A. Kaegi
> CH-4056 Basel                           skype
> <callto://felix_kaegi/> felix_kaegi
> ----------------------------------------------------------------------------> -------------
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 21 Apr 2005 15:35:09 -0400

<co-chair hat="off"/>

comments in-line:

On Apr 20, 2005, at 3:21 AM, Felix Kaegi wrote:
> document.  For HTML Document Metainformation is generally given in 
> HTML meta tags called META. Unfortunately the HTML standard describes 
> lots of Metatags but none for Geo enabling. The paper 
> Switzerland where more than three or four official languages are 
> spoken and Address Names like (Genf/Geneve/Geneva) are written in many 
> valid Languages and even more in different Lanugagesmapping with 
> special characters and so... Further the googles solution is locked 
> down to postal addresses. One will never be able  to find a document 
> that describes a geographic point out in nature. For example a wreck, 
> an interesting Mountain or a hut without an official postal address. 
> The here describes solution is scalable to what ever magnitude the 

Perhaps the "web search" use case is a distracting example.  A less 
distracting use case might be: in browsing a web page, the HTML is 
embedded with structured, machine parsable geo-location data so that 
the web browser may provide extra function.  Unless I've misunderstood 
what is being said here.

I tend to disagree with James Polk's earlier comment regarding privacy 
considerations.  Embedding geo-location data in a public web page is 
the same as placing it in the DNS, the Yellow Pages, on a bill-board, 
or on the bathroom wall.  There is no expectation of privacy.  I do 
agree with his other comments regarding this draft, but those seem 
fixable.

> service request. And even worse it might be that he even does not has 
> a postal address because he is on the road and only geographic 

This, on the other hand, seems no different and deserving of no less 
attention to privacy considerations as we have done with PIDF-LO.  What 
is being described here is a situation where the rule maker, the 
location server, and the target are the web browser and the location 
recipient and watcher are the web server.  This scenario is no 
different than a SIP client passing along PIDF-LO in a phone call or 
IM.  Privacy data about the end user is being given to a third party.

This is not say that the act of passing geo-location data from the web 
browser to the web server in the act of web browsing is not important 
or the same as simply using HTTP as an application substrate for 
PIDF-LO (in fact, I believe they are very much different).  However, it 
deserves the same careful attention to privacy constraints as has been 
done with PIDF-LO (and would be nice if it used PIDF-LO if possible).

-andy