geo-brainstorming

From Microformats Wiki
Jump to navigation Jump to search

<entry-title>geo brainstorming</entry-title>

This page is for further brainstorming about how to better markup geo microformats, whether stand-alone, alongside/with an adr, and/or as part of an hCard. See also hcard-brainstorming.

marking up more geolocation information

Web pages with geolocation information often present a human viewable/clickable view of a latlong point on a map. e.g. Tweet permalink with hyperlinked embedded map view and city/state/country.

By publishing the lat long in a machine readable way, such pages can provide a read-only geo API to their locations, and parsers of such pages could make additional use of that location information.

We can study how existing pages link to or embed location-specific map links/views to see if there is some way we can (in preference order) :

  1. re-use existing data being published (no modification to data on pages, perhaps additional markup to help discover/parse the data)
  2. provide guidelines for making published data more easily discoverable/parseable (minor modifications to data on pages, additional markup)
  3. come up with a new format/expression for publishing/linking data on pages (likely rewrite to how data is published on the page, new markup)

existing geolocation publishing examples

Existing geolocation publishing examples to be analyzed to inform geo format/syntax improvements/iterations.

geo improvements

Possible ways to improve geo markup formats/syntaxes.

abbr geo with title lat long

One possible new format would be to wrap existing human viewable/clickable view markup of a latlong point on a map with an abbr that has the machine readable geo location information in the title attribute: 

<abbr class="geo" title="machine-readable-geo-info">
 human readable/clickable point on a map
</abbr>

But to do this we must specify a syntax for putting both the latitude and longitude into the title attribute as the machine-readable-geo-info that is still human readable/listenable.

We can try the syntax in vCard RFC 2426 3.4.2: 

   Type value: A single structured value consisting of two float values
   separated by the SEMI-COLON character (ASCII decimal 59).

   Type special notes: This type specifies information related to the
   global position of the object associated with the vCard. The value
   specifies latitude and longitude, in that order (i.e., "LAT LON"
   ordering).

...

   Type example:

        GEO:37.386013;-122.082932

Thus: 

<abbr class="geo" title="37.386013;-122.082932">
 Mountain View, CA
</abbr>

The rules for parsing a "geo" would be altered to include:

  • latitude longitude shorthand

If a "geo" property lacks explicit "latitude" and "longitude" subproperties, then the "geo" property is treated like any other string property (e.g. following rules for parsing <abbr title>, <img alt> etc.), where that string value has the same literal syntax as specified in RFC 2426 section 3.4.2: single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude, in that order.

microformats2 p-geo

With microformats2, we can achieve a similar effect simply by using a p-geo property: 

<abbr class="p-geo" title="37.386013;-122.082932">
 Mountain View, CA
</abbr>

The resulting JSON fragment from a microformats2 parser: 

"properties": {
  "geo": ["37.386013;-122.082932"] 
}

In practice these would be inside a specific microformat, e.g. h-card, h-event, h-entry, etc.

No special parsing code would be needed, and it would be up to the client application to do something with this lat;long microsyntax. For translation from h-card to vCard, or h-event to iCalendar, the value would simply pass through: 

GEO:37.386013;-122.082932

geo links

In addition, people may publish Google Maps links like this (need source citation) : 

<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>

or Yahoo! Maps links like this (need source citation) : 

<a href="http://maps.yahoo.com/#lat=37.386013&lon=-122.082932&mag=3">this spot</a>

Is it worth permitting this to be a geo as well?

First guess is NO for two reasons:

  1. No such examples in the wild have been documented or seen as of yet.
  2. It would involve additional parsing requirements which are almost certainly going to be site/domain specific, and encoding a particular site's query parameter syntax into a format seems like a bad idea (against principle of decentralization).

This could be mitigated if mapping services would simply accept the literal vCard GEO syntax "37.386013;-122.082932", e.g. http://maps.google.com/maps?q=37.386013;-122.082932 (which currently doesn't work) then we could make a simple rule such as for hyperlinks, parse the href attribute for a geo value at the end of the href, delimited before the value by a "=" (or perhaps "/" for services that use friendlier URLs).

-OttoOtto 12:51, 6 Sep 2007 (PDT)


latitude longitude shorthand and geo link

The idea is a mixture of using latitude longitude shorthand and geo link which could be represented by: 

<a href="http://www.geonames.org/6077243" title="45.5140800;-73.6111000"
class="geo">Montréal, Quebec, Canada</a>

This is an existing publishing practice:

Some of this is covered in this mailing list thread: http://microformats.org/discuss/mail/microformats-discuss/2009-December/013167.html

-Sarven Capadisli 11:19, 31 December 2009 (UTC)


There are a few things interesting about this example.

  • It's prime for marking up as an adr - a structured address, since it has locality, region, country-name semantics.
    • I acknowledge that adr can be used here, but example is minimized for geo. -Sarven Capadisli 13:55, 15 January 2010 (UTC)
      • Need complete example. It's better to work with a complete real-world example rather than one that has been minimized, so that all the relevant content/markup/context can be considered. Tantek 20:37, 8 February 2010 (UTC)
  • Using the title attribute for semicolon separated lat-long may not be the user-friendliest thing to do.
    • I'd presume that this is similar to the general public comprehending the full ISO8601 format, but much harder. So, I can agree with that. For this geo minimization though, it had to go somewhere. -Sarven Capadisli 13:55, 15 January 2010 (UTC)
      • However, we must avoid presenting the user with content that is not human readable/listenable. If it "has to go somewhere", we must figure out a human readable/listenable way to do so. Tantek 20:37, 8 February 2010 (UTC)
  • Given microformats experience with various uses of the the title attribute - a good rule of thumb is to check to make sure that the content you are putting into the title attribute is both reasonably human readable and listenable.

Here is some better markup that could be applied to the example today: 

<a class="adr" href="http://www.geonames.org/6077243">
 <span class="locality">Montréal</span>, 
 <span class="region">Quebec<span>, 
 <span class="country-name">Canada</span>
 (<span class="geo">lat:<span class="latitude">45.5140800</span>; 
    long <span class="longitude">-73.6111000</span></span>)
</a>

- Tantek 15:08, 31 December 2009 (UTC)

That is changing the example. Could you explain how 

(<span class="geo">lat:<span class="latitude">45.5140800</span>; 
long <span class="longitude">-73.6111000</span></span>)

is more user friendly than 

title="45.5140800;-73.6111000"

-Sarven Capadisli 13:55, 15 January 2010 (UTC)


When the two examples are rendered, the first:

  • lat:45.5140800; long:-73.6111000

is more user friendly than

  • 45.5140800;-73.6111000

by the simple fact that at least the user is given labels which provide context for the numbers.

-Tantek 20:37, 8 February 2010 (UTC)

altitude

Some folks have asked for "altitude" as an extension to GEO. See geo-extension-elevation . Currently we are rejecting all property/value extensions to hCard/vCard.

radius/zoom

Kevin Marks has asked for "radius" or "zoom" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.

ISO 19136

When it comes to anything geospatial, any unadorned / simple encoding must remain upwardly-compatible with the more sophisticated GML schema (Geography Markup Language ) which is also known as ISO 19136. This is so that all the fundamental nuances underpinning geocoding ( different datums, different projections, elevation, etc etc ) can ultimately ( or sooner ? ) be completely accounted for.

If you don't know/supply your Coordinate Reference System CRS identifier, your location could fall 100s of metres away from the position intended ie plot in the wrong location on a map. Appendix B of draft ISO/DIS 6709 highlights the variation among three commonly used systems.

ISO 6709

The Geo field in the vCard format seems to be based on ISO 6709:1983.

The International Standard is being updated, ISO/DIS 6709, to allow for depths as well as heights and to include Coordinate Reference System (CRS) identification. Voting on the revised standard finishes on the 15th February 2007.

Section 6.3 of ISO/DIS 6709 notes the elements required required for geographic point location:

In this International Standard, geographic point location shall be represented by five elements:

  • a coordinate reference system identification;
  • coordinate representing “x” horizontal position such as latitude;
  • coordinate representing “y” horizontal position such as longitude;
  • for three-dimensional point locations, a value representing vertical position through either height or depth;
  • metadata associated with geographic point location(s) (ISO 19115)

The CRS identifier is important otherwise your location could fall 100s of metres away from the position intended.

Annex H details the ISO standard for text string representation of point location.

H.6 Format

H.6.1 Elements shall be combined in a point location string in the following sequence:

a) Latitude

b) Longitude

c) if represented, height or depth

d) Coordinate Reference System identifier


H.6.2 The number of digits for latitude, longitude and height (depth) shall indicate the precision of available data.


H.6.3 There shall be no separator between the elements for latitude, longitude, height (depth) and CRS. NOTE The use of designators "+", "-" and "CRS" preceding the value part of each element permits the recognition of the start of each element and the termination of the previous one.


H.6.4 The point location string shall be terminated. The terminator character shall be a solidus (/), unless otherwise specified in the documentation associated with interchange.

A small explanation can be found in Wikipedia.

It differs from the notation of vCard, for example.

If ISO6709 is used, it is likely to be able to write as follows. 

examples
<abbr class="geo" title="+40-075CRSxxxx/">
 Point represented as Degrees
</abbr>

<abbr class="geo" title="+401213.1-0750015.1+2.79CRSxxxx/">
 Point represented as Degrees, minutes, seconds and decimal seconds, with +2.79 a height or depth as defined through the CRS.
</abbr>

A C# library to read and write ISO 6709 coordinates from/to xml can be found in Codeplex

Geo Encodings

It is important that whenever location is described that it is achieved in the most openly interoperable manner. A relatively small number of encodings is needed that will meet the needs of a wide range of information communities and users. At http://www.georss.org/ two relatively simple schema have been published; one for WGS84 latitude/longitude ( termed 'simple'), and the other provisions for this AND coordinate reference systems other than WGS84 latitude/longitude ... of which there are a multitude - so this an argument for simple encodings to be upwardly-compatible with the more sophisticated GML schema (Geography Markup Language ).

ISO 19115

ISO 19115:2003 defines the schema required for describing geographic information and services. It provides information about the identification, the extent, the quality, the spatial and temporal schema, spatial reference, and distribution of digital geographic data.

Categorising locations

Perhaps categorsing locations would enable map mashups of microformatted information ? For example, show me a map of the nearest 'place of worship'. This fragment from an application schema illustrates a range of place categories http://www.linz.govt.nz/resources/esa-appl-schema-v1-9-5/esa-46.html#1804

UN/LOCODEs

UN/LOCODE is a geographic coding scheme developed and maintained by United Nations Economic Commission for Europe, a unit of the United Nations. It provides a unified way to identify interesting points through definition of functions. It may be useful if the geo microformat could support it. http://en.wikipedia.org/wiki/UN/LOCODE

RFC 5870

Quite recently an the RFC 5870 document has been published that describes a URI format for geographic locations. The draft for vCard version 4.0 establishes new GEO parameter format with reference to that RFC. You can find more information related to the RFC at http://geouri.org/ . With this RFC at hand a reference to a geographic position in microformats (and in HTML generally) should look as simple as: 

<a href="geo:51.511233,-0.128317">Leicester Square, London</a>

Geo implementations

GPX

Parsers might convert Geo to GPX ("GPS eXchange Format"), an XML schema designed for transferring GPS data between software applications (and GPS devices), which can be used to describe waypoints, tracks, and routes. See GPX on Wikipedia. Andy Mabbett 11:44, 3 Apr 2007 (PDT)

Great circle distance

A parser might offer the option to select two Geo-uFs from a page, or the single Geo on each of two pages, and calculate the distance between them. Andy Mabbett 04:36, 18 Apr 2007 (PDT)

  • Example on-line calculators: [1], [2]

Other use cases

Please add your suggestions!

Geo microformats could be used to:

  • Generate GPX files
  • ...


Related pages

Retrieved from "http://microformats.org/wiki/index.php?title=geo-brainstorming&oldid=47090"