location-formats: Difference between revisions
(→Google) |
(→RSS) |
||
Line 56: | Line 56: | ||
* [http://earthquake.usgs.gov/recenteqsww/rss.html USGS earthquake feed] - most widely used geocoded RSS feed | * [http://earthquake.usgs.gov/recenteqsww/rss.html USGS earthquake feed] - most widely used geocoded RSS feed | ||
* [http://brainoff.com/worldkit/doc/polygon.php Polygons and lines in polygons] - A simple format for expressing polygons and lines is defined for worldKit | * [http://brainoff.com/worldkit/doc/polygon.php Polygons and lines in polygons] - A simple format for expressing polygons and lines is defined for worldKit | ||
* [http://developer.yahoo.net/maps/ Yahoo Maps API] - uses "geo" ( http://www.w3.org/2003/01/geo/wgs84_pos# ) and "ymaps" ( http://api.maps.yahoo.com/Maps/V1/AnnotatedMaps.xsd ) namespaces to spatially-reference RSS as part of its API, specifically geo:lat, geo:long, ymaps:Address, ymaps:CityState, ymaps:Zip, ymaps:Country | |||
== Address2Coordinates == | == Address2Coordinates == |
Revision as of 20:40, 6 July 2005
Location Formats
This is a list of previous efforts at location / geographic ("Geo") data formats and protocols, as background research for developing a location format.
vCard & hCard
vCard (RFC2426) and hcard includes 'adr', a way to markup addresses. There is also a field called 'geo' for lat/long.
UPU S42 & OASIS xNAL
UPU S42 is a standard for representing postal addresses. UPU, the Universal Postal Union, is the consortium of all national posts. See UPU S42 Announcement. xNAL, the XML Name and Address Language, is an earlier attempt to standardize on the components of addresses developed by OASIS, a consortium of business-process weenies. The distinction between vCard/hCard and S42/xAL/xNAL comes down to whether the address line elements themselves are decomposed. For example, in xNAL you can specify components like street number, street prefix directional, street name, street type, street postfix directional, subaddress type (Suite), subaddress number.
It is not always possible to conclusively determine these components from an address line, even in the US where addresses are more canonical than others. "A 4TH ST W STE 10" is a legal address line in the US. The street number and name are required (in the US) so this could be canonically decomposed as streetnumber="A", streetname="4TH", streettype="ST", postdirectional="W", subtype="STE", subtypenumber="10".
UPU S42 and OASIS xNAL standards are likely overkill for tagging general web content. However, they are important standards that should be considered in web-services involving both geocoding and reverse-geocoding. Perhaps standards related to decomposed addresses is something that should be placed on another page.
In addition, there should be pointers to national address standards.
USPS publishes a complete list of canonical abbreviations for both streettypes and subtypes. Their publications are self-inconsistent, but it is easy to infer the correct mappings. See USPS Acronyms & Abbreviations
New Zealand apparently adopted a variant of xNAL NZ xNAL Guidelines Release 1.0.
ICBM
Comma seperated list of lat/long <meta name="ICBM" content="XXX.XXXXX, XXX.XXXXX">
[1]
This is incorrect. It is one pair, not a list.
GeoUrl
- GeoURL
- Multimap.com provides similar functionality to GeoUrl, searching for websites and weblogs which are geotagged or ICBM tagged, and adding them to local information databases.
Flickr Geotags
- Flickr GeoTagging A Greasemonkey script for adding lat and long tags to flick pictures. He uses Google Maps to get the lat and long. Users have to enter search terms (address, etc) and then select a point on the google map. Photos are tagged with "geo:lat=xx.xxxx", "geo:lon=xx.xxxx" and "geotagged" and aggregated at [2]
- A Flickr Group related to the topic
- A visual walkthrough of the technique.
- As of today (2005-06-01), 14k photos have been geotagged on Flickr.
- mappr, mapping flickr also support these geotags.
- flickr also supports EXIF headers, which can be used for storing location.
Geotagging
A2B
A2B is a location based search engine. Lat and long only. Seems to pick stuff up from geo meta tags. Pages can either be manually entered or pinged. They support lat/long and ICBM meta tags.
RSS
Several people have tried putting geographic information into RSS.
- This site uses icbm coordinates and has plugins for several blogging packages.
- BlogMapper - appears to be adding a namespace to RSS.
- BlogMap - picks up RSS extension and meta tag values
- worldKit RSS docs - worldKit advocates and understands various flavors of geocoded RSS; particularly the "geo" namespace.
- USGS earthquake feed - most widely used geocoded RSS feed
- Polygons and lines in polygons - A simple format for expressing polygons and lines is defined for worldKit
- Yahoo Maps API - uses "geo" ( http://www.w3.org/2003/01/geo/wgs84_pos# ) and "ymaps" ( http://api.maps.yahoo.com/Maps/V1/AnnotatedMaps.xsd ) namespaces to spatially-reference RSS as part of its API, specifically geo:lat, geo:long, ymaps:Address, ymaps:CityState, ymaps:Zip, ymaps:Country
Address2Coordinates
Both of these systems are freely available sources of address to lat/long mappings (US only). I think they're based on US Census data, so they might be up to date.
- TIGER
- FIPS
- geocoder
- You can get coordinates from UK post-codes from streetmap
- Worldwide city level location data (over 4 million entries) is available from the GNS. This is accessible as a REST service from the worldkit geocoder
Plazes
Plazes is a system that does geo-info based on the network access point that the user's computer is connected to. They use tagging to identify locations.
Mapping Sites
Semantic Web
- Geosemantics Interest Group
- GeoOnion - a SW vocuabulary for relating items by distance from each other.
- RDFMap
- GeoRDF similar effort to collect prior art, for an effort in interoperability between OGC standards and various lightweight geo formats.
GML
Geographic Markup Language - a "600 page standard"
Google Earth XML
20050629 at Where 2.0 conference:
"Google Earth has an XML schema for describing a place on the earth. Will be releasing today or tomorrow." - John Hanke of Google/Keyhole.
Official KML Docs and Tutorial
KML Reverse Engineered Schema (depricated now that KML 2.0 is officially released)
Google Maps API
Yahoo Maps API
OGC
WCS
Web Coverage Service
NMEA
Standard and Proprietary NMEA Sentances
Wikipedia
Geo:Coordinates in Wikipedia Project
What People are Publishing
- links to mapping services, canonical URLs to 3rd party services like:
- Google Maps
- Map Quest
- Yahoo Maps
- human / named / legislated formats
- named places, e.g. Westin St. Francis
- addresses, including zip codes
- global/mathematical/geometrical
- Lat & Lon
- MAKE has a GeoURL button
- Geo in RSS. Means a particular blog post is associated with a specific lat/long. Not specific about whether it means the location that the post was made from or the location was the post was about.
- Lat & Lon
Other Formats
(move these into lists near top of document)
- GPX = GPS XML format
- Wikipedia markup styles
Location Tagging
At the BOF on 6/30, we discussed the idea of location tagging. What does that mean exactly? Here are some initial thoughts.
Brief summary of thoughts at the 6/30 BOF
At one point, we summarized two key axes for a potential geo microformat:
- Address vs. coordinate systems: I give a location in one of the standard human ways, for instance a street address with a town, state, province, country, etc., or I give lattitude and longitude perhaps with altitude.
- Textual vs. URL standards: An example of textual might be hCard. Textual is data fields expressed in markup that can be displayed. Our discussion of URL standards in the BOF related almost entirely to URLs that projected onto map coordinates.
If we are going to think about location tagging, we probably need to extend our thinking about how we will use URLs for locations. Also, we may want to be a little less literal in how we interpret location. The address vs. coordinate system axis is all about pinning location down to a very narrow, deterministic range.
Is that all location is?
Consider neighborhoods in San Francisco or any other city. Where does one begin and the other end? Are the boundaries the same over time or always agreed upon? Yet, we use the idea of neighborhoods all the time to refer to places that are more or less there. For instance, people more or less know the difference between "Upper Haight" and "The Sunset". They have an idea of what these mean based partially on location and partially on the atmosphere that pervades the location.
Some locations might not "exist" even at this level. Consider Poland between the world wars.
What we might mean by location tagging
Tagging is simply labeling artifacts on the web. In distributed architectures, tags resolve to URLs (see rel-tag) of pages that "define" them. The definition pages might be lists of links or even formal statements of what the tags mean.
Given all of this background (yes, Tantek), location tagging seems to have at least two main interpretations:
Labeling a web artifact as belonging to a location
Oddly enough, I think the most compelling idea is labeling things with the more amorphous locations like neighborhoods. Based on all the talk around Where 2.0 where we had the BOF, location seems to have a special status.
I suggest a very simple extension to reltag that could do this:
<a href="http://servername/tag" rel="tag geo">text</a>
The key point being the use of "geo" as a rel attribute along with "tag". I'll call this geotag. I'll leave it to others to debate whether this should all be done in the rel attribute.
Labeling a precisely defined location
This is simply adding tags to a location. For instance, labeling 16 Fuller Street, Brookline, MA with "first home", "Lily", "Felix", "Angela". You might even add a geotag of "Coolidge Corner".
I would expect that the geo microformat would take care of the precise location in this example.
How it all fits together
Geotag is attractive because it is so simple from a user perspective. No knowing coordinates, no knowing precise locations. The geo microformat, having participated in the BOF, seems oriented toward precise locations like what you would put on a map.
If we look at the evolution of mapping as presented at Where 2.0, however, mapping definitely started in the less precise mode, and in fact continues in that mode today. There is currently a google mash-up of New York burroughs with neighborhoods. Individuals define the neighborhoods (this was at Where as a last minute addition, Nat Torkington would know who these people are). The fact that there is a modern mash-up of this idea legitimizes its currency.
The question is how you marry up precision with the simple amorphous approach in geotag. I see two ways. One, geotag locations in the geo microformat. That essentially attaches a geographic label to the precise location. These can then be aggregated up in the usual tagging way as pioneered by Technorati tags. At that stage, you have a constellation of precisely determined locations defined by the tag, and you can use the constellation of geographic coordinates to define the geographic extent of the tag so that it can be mapped.
Alternatively, you could come up with a definition format for geotag and use that on the page the tag URL points to. I like the first way better because it harnesses social processes.
As for tagging precise locations with words like "first home", that can be easily accomplished by adding reltags to the geo microformat. This works for evaluative tags like "vomitous" and "great". If the tagger decides to make any tag a geotag, then the tag represents a place. One can imagine an aggregation where we have all of the "first homes" listed as places or all of the goods listed as places. This is to be expected and not all that bad (if you think it bad at all). Where geotag gets its value is when place names are socially shared. The key feature of a geotag when you apply it is that you think of it as referring to a place. If we believe all the buzz around Where 2.0, place has importance and deserves a special designator.