Difference between revisions of "geo-brainstorming"
m (Added intro to question)
|Line 110:||Line 110:|
- [[User:Tantek|Tantek]] 15:08, 31 December 2009 (UTC)
- [[User:Tantek|Tantek]] 15:08, 31 December 2009 (UTC)
is changing the example. Could you explain how
Revision as of 14:13, 15 January 2010
- 1 Geo brainstorming
- 1.1 Geo improvements
- 1.2 Geo implementations
- 1.3 Other use cases
- 1.4 Related pages
I (Tantek) have seen examples of where there is a human viewable/clickable presentation of a point on a map, and the desire to include the machine readable geo information with the same element, e.g. something like:
<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.
Fortunately, there already is a syntax for that, 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
<abbr class="geo" title="37.386013;-122.082932"> Mountain View, CA </abbr>
I think this is pretty much a no-brainer, because the rules for parsing "geo" are simply altered to:
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
<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.
In addition, people may publish Google Maps links like this:
<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>
or Yahoo! Maps links like this:
<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?
I'm raising this to make sure it is considered.
However, my first guess is NO for two reasons.
- No such examples in the wild have been documented or seen as of yet (I certainly haven't seen any).
- 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).
- consider also <a href="http://www.rhaworth.myby.co.uk/oscoor_a.htm?SJ870099_region:GB_scale:25000" title="52.6866;-2.1937">SJ870099</a> which is widely used (so far without geo-title attribute) (Wikipedia, et al). Perhaps we should also support title="various maps of 52.6866;-2.1937" so that the title attribute can be used as was originally intended.
- While the given google maps link does not work, these do: http://maps.google.com/maps?q=37.386013,-122.082932 http://maps.yahoo.com/?q1=37.386013,-122.082932 Most mapping services do have a way to do it, but they tend to only accept commas, not semicolons.
-OttoOtto 12:51, 6 Sep 2007 (PDT)
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:
- Potentially, publicly documented sites at http://status.net/wiki/ListOfServers on update.
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)
- 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)
- 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
-Sarven Capadisli 13:55, 15 January 2010 (UTC)
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.
Kevin Marks has asked for "radius" or "zoom" as an extension to GEO. Currently we are rejecting all property/value extensions to hCard/vCard.
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.
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.1 Elements shall be combined in a point location string in the following sequence:
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
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: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.
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/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
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
Other use cases
Please add your suggestions!
Geo microformats could be used to:
- Generate GPX files
- hCard Brainstorming
- Geo cheatsheet
- Geo examples
- geo formats - previous/other attempts at geo related formats
- Geo brainstorming - brainstorms and other explorations relating to Geo (and Geo in hCard).
- see also hCard brainstorming
- Geo advocacy - encourage others to use Geo.
- Geo examples in the wild
- Geo forms part of hCard 1.0, so please use:
- location-formats - research which led to the development of Geo.
- proposed extensions
- Geo profile - draft