http://microformats.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=Eron+WrightMicroformats Wiki - User contributions [en]2026-05-05T07:27:34ZUser contributionsMediaWiki 1.38.4http://microformats.org/wiki/index.php?title=listing-formats&diff=5491listing-formats2006-02-13T19:54:12Z<p>Eron Wright: </p>
<hr />
<div>= Listing Formats =<br />
<br />
This is an exploratory page to document current and previous listing formats.<br />
<br />
== Authors ==<br />
<br />
* Trevor O'Reilly<br />
* Emiliano Martínez Luque<br />
<br />
== Formats ==<br />
<br />
* eBay<br />
** http://developer.ebay.com/DevZone/XML/docs/WSDL/index.htm<br />
** http://pages.ebay.com/help/sell/export-structure.html <br />
<br />
* Amazon<br />
** http://www.amazon.com/gp/aws/sdk/?v=2005%2d07%2d26&s=AWSEcommerceService<br />
<br />
* Micropayment Markup<br />
** http://www.w3.org/TR/Micropayment-Markup/<br />
<br />
* FOAF-Shop <br />
** http://rdfweb.org/people/danbri/rdfweb/danbri-foafshop.rdf<br />
<br />
* Froogle<br />
** http://www.google.com/froogle/merchants/advanced_feed_instructions.html <br />
<br />
* Yahoo Shopping<br />
** http://productsubmit.adcentral.yahoo.com/sspi/us/spec/ <br />
<br />
* Become.com <br />
** http://www.become.com/merchant/Product_Feed_Specification_5_05_05.pdf<br />
<br />
* MySimon<br />
** http://shopper.cnet.com/html/partners/a_feed.html#guidelines<br />
<br />
* LinkShare Datafeeds <br />
** http://www.linkshare.com/rc/sample_mfile.shtml (Example Feed)<br />
<br />
== Initiatives ==<br />
<br />
The following is a list of related e-business initiatives. While the scope of these projects is much larger than the problem addressed here, they may provide good reference points for property and process naming conventions. Included primarily for completeness.<br />
<br />
* [http://www.w3.org/ECommerce/ W3C Electronic Commerce Interest Group] <br />
** The role of W3C is to focus on core infrastructure technologies for Electronic Commerce and identify common infrastructure needed in this area. <br />
<br />
* [http://www.commerce.net CommerceNet] <br />
** CommerceNet is a non-profit membership organization meeting the evolving needs of companies doing electronic commerce. <br />
<br />
* [http://www.ebxml.org ebXML] <br />
** ebXML (Electronic Business using eXtensible Markup Language), is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet.<br />
<br />
* [http://xml.coverpages.org/ecml.html ECML] <br />
** The Electronic Commerce Modeling Language provides a simple set of guidelines for web merchants that will enable digital wallets from multiple vendors to automate the exchange of information between users and merchants.<br />
<br />
* [http://www.iotp.org IOTP] <br />
** The Open Trading Protocol was developed by a number of organizations, working cooperatively to make widespread Internet trading a convenient and secure reality.<br />
<br />
* [http://www.udef.org UDEF] <br />
** The Universal Data Element Framework is a cross-industry metadata identification strategy designed to facilitate convergence and interoperability among e-business and other standards. <br />
<br />
* [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl UBL] <br />
** UBL, the Universal Business Language, is the product of an international effort to define a royalty-free library of standard electronic XML business documents such as purchase orders and invoices. <br />
<br />
* [http://www.rosettanet.org RosettaNet] <br />
** A self-funded, non-profit organization, RosettaNet is a consortium of major Computer and Consumer Electronics, Electronic Components, Semiconductor Manufacturing, Telecommunications and Logistics companies working to create and implement industry-wide, open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis.<br />
<br />
* [http://www.rets.org/ Real Estate Transaction Standard (RETS)]<br />
** The Real Estate Transaction Standard (RETS) is the open standard for exchanging real estate transaction information. Consisting of a transaction specification and a standard Extensible Markup Language (XML) Document Type Definition (DTD), RETS is being implemented by many real estate industry leaders in their next generation of real estate information systems.<br />
<br />
== See Also ==<br />
<br />
* [[listing-examples]]<br />
* [[listing-brainstorming]]<br />
* [[listing-formats]]</div>Eron Wrighthttp://microformats.org/wiki/index.php?title=last-modified-brainstorming&diff=31499last-modified-brainstorming2006-02-13T19:43:45Z<p>Eron Wright: </p>
<hr />
<div>= "Last-modified" Brainstorming =<br />
<br />
== Purpose == <br />
To specify the date of publication and the date of modification of a web page (or a part thereof) in a way that is both readable for humans and machines.<br />
<br />
== Authors ==<br />
* [[User:RobertBachmann|Robert Bachmann]]<br />
* [[User:RyanKing|Ryan King]]<br />
<br />
== Semantics ==<br />
Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time. --RyanKing<br />
<br />
== Possible class names ==<br />
<br />
=== Class name considerations ===<br />
==== Class names for the date of publication ====<br />
* “date”: Dublin Core<br />
* “published”: Atom<br />
* “dtpublished”: As suggested by Paul Bryson for [[hatom|hAtom]]. See http://microformats.org/discuss/mail/microformats-discuss/2005-December/002520.html<br />
<br />
==== Class names for the date of the last modification ====<br />
* “last-modified”: “Last-Modified” used by HTTP 1.0 and 1.1, hCalendar<br />
* “modified”: Dublin Core <br />
* “updated”: Atom 1.0 syndication specification<br />
<br />
=== Different class name for page specific and item specific dates? ===<br />
<br />
For example “page-last-modified” is used to indicate the last modification date of a page and “last-modified” for the last modification date of a specific item*.<br />
However, this seems to be not a good idea. Other microformats leave it to the parser to pick the scope of the element, e.g. [[rel-tag]].<br />
<br />
See http://microformats.org/discuss/mail/microformats-discuss/2005-August/000726.html for a related discussion.<br />
<br />
<nowiki>*</nowiki> This specific item is marked-up with a microformat, e.g: a microformat to describe blog posts may use “last-modified” to indicate when a blog post was last modified.<br />
<br />
== Possible date formats ==<br />
<br />
See [[datetime-design-pattern]].<br />
<br />
== Issues ==<br />
* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]<br />
*# ''Last-modified dates are unsuitable as version numbers. As the HTTP 1.1 spec mentions, dates lack fidelity and are difficult to generate for dynamic content. A better solution is to use an opaque string, as HTTP does with the ETag header. Indeed, If-Modified-Since is deprecated.''<br />
<br />
<!-- --><br />
<span id="proposal"> </span><br />
<br />
= Proposal (2nd, strawman) =<br />
== Purpose ==<br />
<br />
Many web pages (and parts thereof) state their publication and/or modification date in a human readable way. This proposed microformat specifies how this can be done in a fashion that is both human- and machine-readable.<br />
<br />
=== Specifying the date of publication ===<br />
<br />
The date of publication is enclosed by <code>&lt;abbr class="date-published<sup>[[#footnote1|1]]</sup>" title="''Date in ISO format''"&gt;''Date in arbitrary format''&lt;/abbr&gt;</code>, e.g:<br />
<br />
<code>&lt;p&gt;Published on &lt;abbr class="date-published<sup>[[#footnote1|1]]</sup>" title="2005-12-29T14:39:12+0100"&gt;Thursday, December 29, 2005 02:39:12 a.m.&lt;/abbr&gt;.&lt;/p&gt;</code>.<br />
<br />
=== Specifying the date of modification ===<br />
<br />
The date of modification is enclosed by <code>&lt;abbr class="date-modified<sup>[[#footnote1|1]]</sup>" title="''Date in ISO format''"&gt;''Date in arbitary format''&lt;/abbr&gt;</code>, e.g:<br />
<br />
<code>&lt;p&gt;Last modified on &lt;abbr class="date-modified<sup>[[#footnote1|1]]</sup>" title="2005-12-29T14:39:12+0100"&gt;Thursday, December 29, 2005 02:39:12 a.m.&lt;/abbr&gt;.&lt;/p&gt;</code>.<br />
<br />
If no date of modification is present the parsers MAY use the date of publication as the date of the last modification.<br />
<br />
==== &lt;del&gt; and &lt;ins&gt; ====<br />
Authors MAY also use <code>&lt;del&gt;</code> and <code>&lt;ins&gt;</code> to denote the date of<br />
modification, e.g:<br />
<code>&lt;del class="date-modified<sup>[[#footnote1|1]]</sup>" datetime="2005-12-29T14:39:12+0100"&gt;wrong words&lt;/del&gt;</code>.<br />
The class value "date-modified<sup>[[#footnote1|1]]</sup>" is implied for every <code>&lt;del&gt;</code> and <code>&lt;ins&gt;</code><br />
element which has a <code>datetime</code> attribute.<br />
<br />
=== Multiple dates in a page (or a part thereof) ===<br />
<br />
If multiple dates of publication are present on a page (or a part thereof)<br />
the ''youngest'' date SHOULD be interpreted as the date of publication.<br />
<br />
If multiple dates of modification are present on a page (or a part thereof)<br />
the ''oldest'' date SHOULD be interpreted as the date of modification.<br />
<br />
<br />
<br />
<sup id="footnote1">1</sup> This class name is just a placeholder which will be replaced once we know a suitable name.<br />
<br />
== Related ==<br />
* &larr;[[last-modified-formats]]<br />
* [[datetime-design-pattern]]</div>Eron Wrighthttp://microformats.org/wiki/index.php?title=hash-examples&diff=4985hash-examples2006-02-13T19:36:01Z<p>Eron Wright: </p>
<hr />
<div>= Hash Examples =<br />
A microformat for MD5 and SHA-1 hashes.<br />
<br />
== The Problem ==<br />
Checksums (MD5 & SHA-1 hashes) are offered for files to prove they haven't been tampered with and to uniquely identify them. They are very useful, but they are not used as much as they could be. The current method involves a manual process of hashing the downloaded file (with programs that are not installed by default on all operating systems) and then comparing the value to the one listed. An easy and automatic way to use them would be preferrable to present methods.<br />
== Participants ==<br />
* Ant Bryan<br />
== Real-World Examples ==<br />
Currently, MD5 and SHA-1 checksums are either listed on a webpage or email (see Example #1) or stored in a separate file such as (filename.ext.md5 or filename.ext.sha1) (see Example #2). There is no standard or automatic way to use them. Verifying a file after you have the hash is not complex, but it is more than the average user is used to doing (see [http://www.openoffice.org/dev_docs/using_md5sums.html OpenOffice.org: Using MD5 sums]). MD5 checksums are 32 digit hexadecimal numbers, while SHA-1 checksums are 40, and SHA-256 checksums are 64.<br />
<br />
== Who offers MD5/SHA-1 checksums with software ==<br />
This is only a small sampling.<br />
*[http://httpd.apache.org/ Apache HTTP Server] in .md5 file from web.<br />
*[http://www.cisco.com/ Cisco] MD5 for versions of IOS from Software Center on Cisco website.<br />
*[http://developer.apple.com/darwin/ Darwin] MD5 on web.<br />
*[http://fedora.redhat.com/ Fedora Project] SHA-1 on web and SHA1SUM file on ftp.<br />
*[http://www.freebsd.org/ FreeBSD] on web and in CHECKSUM.MD5 and CHECKSUM.SHA256 files.<br />
*[http://gcc.gnu.org/ GCC] on ftp as md5.sum file.<br />
*[http://www.gentoo.org/ Gentoo] as .md5 file on ftp.<br />
*[http://www.gnome.org/ GNOME] as MD5SUMS-for-gz and MD5SUMS-for-bz2 files on ftp.<br />
*[http://www.gnupg.org/ GnuPG] SHA-1 on web.<br />
*[http://www.kde.org/ KDE] on web and on ftp as MD5SUMS file.<br />
*[http://www.knoppix.org/ Knoppix] in .md5 and .sha1 file.<br />
*[http://www.mysql.com/ MySQL] MD5 on web.<br />
*[http://www.openoffice.org/ OpenOffice.org] MD5 on web.<br />
*[http://www.openssh.com/ OpenSSH] SHA-1 in release announcement.<br />
*[http://www.openssl.org/ OpenSSL] .md5 and .sha1 files linked to from web.<br />
*[http://www.perl.org/ Perl] link to .md5 on web.<br />
*[http://www.postgresql.org/ PostgreSQL] in a .md5 file.<br />
*[http://www.python.org/ Python] MD5 on web<br />
*[http://www.ubuntu.com/ Ubuntu] as MD5SUMS on ftp.<br />
*[http://www.x.org/ X.org] md5sums file on ftp.<br />
<br />
=== Example #1: [http://download.openoffice.org/2.0.1/md5sums.html OpenOffice.org MD5 sums] ===<br />
<pre><br />
English Application Binaries<br />
<br />
e0d123e5f316bef78bfdf5a008837577 OOo_2.0.1_LinuxIntel_install.tar.gz<br />
35d91262b3c3ec8841b54169588c97f7 OOo_2.0.1_LinuxIntel_install_wJRE.tar.gz<br />
cc273fe9d442850fa18c31c88c823e07 OOo_2.0.1_SolarisSparc_install.tar.gz<br />
ff6626c69507a6f511cc398998905670 OOo_2.0.1_SolarisSparc_install_wJRE.tar.gz<br />
ce099d7e208dc921e259b48aadef36c1 OOo_2.0.1_Solarisx86_install.tar.gz<br />
4fb319211b2e85cace04e8936100f024 OOo_2.0.1_Solarisx86_install_wJRE.tar.gz<br />
66bd00e43ff8b932c14140472c4b8cc6 OOo_2.0.1_Win32Intel_install.exe<br />
2d86c4246f3c0eb516628bf324d6b9a3 OOo_2.0.1_Win32Intel_install_wJRE.exe<br />
</pre><br />
<br />
=== Example #2: [http://mirrors.csol.org/knoppix/ Knoppix MD5 and SHA-1 sums in separate files ] ===<br />
<pre><br />
KNOPPIX_V4.0.2CD-2005-09-23-EN.iso.md5:<br />
<br />
1188f67d48c9f11afb8572977ef74c5e *KNOPPIX_V4.0.2CD-2005-09-23-EN.iso<br />
<br />
KNOPPIX_V4.0.2CD-2005-09-23-EN.iso.sha1:<br />
<br />
56857cfc709d3996f057252c16ec4656f5292802 *KNOPPIX_V4.0.2CD-2005-09-23-EN.iso<br />
<br />
</pre><br />
Note: This directory also contains filename.ext.md5.asc and filename.ext.sha1.asc files containing the same checksums and PGP signatures in one file.<br />
<br />
== Existing Practices ==<br />
As described above, I believe almost all solutions are manual (see [http://www.openoffice.org/dev_docs/using_md5sums.html OpenOffice.org: Using MD5 sums]), an 8 step process on Windows and 3 steps on Linux. [http://mdhashtool.mozdev.org/lfinfo.html Link Fingerprints] which are used by [http://mdhashtool.mozdev.org/index.html MD Hash Tool], a Firefox extension, is one exception. Here is a Link Fingerprint example:<br />
<br />
<pre><br />
http://example.org/OOo_2.0.1_LinuxIntel_install.tar.gz#!md5!e0d123e5f316bef78bfdf5a008837577<br />
</pre><br />
A Link Fingerprint begins with a traditional URL, then #!md5!, then the MD5 hash.<br />
<br />
Brad Fitzpatrick also [http://brad.livejournal.com/2162507.html suggested referring to "files/patches/changesets" by their unique digest.]<br />
<br />
Some HTTP server applications compute a hash over the response body to serve as an effective ETag. The server must still compute the body but can benefit from reduced network utilization and reduced downstream cache thrashing. Such applications must be willing to risk a hash collision, albeit scoped to a single URL.<br />
<br />
Including a hash in a URL can lead to great cacheability, since the TTL can likely be set to an infinite value. Such URLs are often referred to as ''versioned URLs''.<br />
<br />
== Proposal ==<br />
A microformat for MD5 and SHA-1 hashes could make them more usable. [http://mdhashtool.mozdev.org/index.html MD Hash Tool], another extension, or download managers could be modified to use them automatically.<br />
<br />
<pre><br />
<span class="download"><br />
<a rel="bookmark" href="http://example.com/OOo_2.0.1_.tar.gz">Download OpenOffice.org</a><br />
<span class="hash-md5">e0d123e5f316bef78bfdf5a008837577</span><br />
</span><br />
</pre></div>Eron Wrighthttp://microformats.org/wiki/index.php?title=hash-examples&diff=4928hash-examples2006-02-13T19:32:24Z<p>Eron Wright: </p>
<hr />
<div>= Hash Examples =<br />
A microformat for MD5 and SHA-1 hashes.<br />
<br />
== The Problem ==<br />
Checksums (MD5 & SHA-1 hashes) are offered for files to prove they haven't been tampered with and to uniquely identify them. They are very useful, but they are not used as much as they could be. The current method involves a manual process of hashing the downloaded file (with programs that are not installed by default on all operating systems) and then comparing the value to the one listed. An easy and automatic way to use them would be preferrable to present methods.<br />
== Participants ==<br />
* Ant Bryan<br />
== Real-World Examples ==<br />
Currently, MD5 and SHA-1 checksums are either listed on a webpage or email (see Example #1) or stored in a separate file such as (filename.ext.md5 or filename.ext.sha1) (see Example #2). There is no standard or automatic way to use them. Verifying a file after you have the hash is not complex, but it is more than the average user is used to doing (see [http://www.openoffice.org/dev_docs/using_md5sums.html OpenOffice.org: Using MD5 sums]). MD5 checksums are 32 digit hexadecimal numbers, while SHA-1 checksums are 40, and SHA-256 checksums are 64.<br />
<br />
== Who offers MD5/SHA-1 checksums with software ==<br />
This is only a small sampling.<br />
*[http://httpd.apache.org/ Apache HTTP Server] in .md5 file from web.<br />
*[http://www.cisco.com/ Cisco] MD5 for versions of IOS from Software Center on Cisco website.<br />
*[http://developer.apple.com/darwin/ Darwin] MD5 on web.<br />
*[http://fedora.redhat.com/ Fedora Project] SHA-1 on web and SHA1SUM file on ftp.<br />
*[http://www.freebsd.org/ FreeBSD] on web and in CHECKSUM.MD5 and CHECKSUM.SHA256 files.<br />
*[http://gcc.gnu.org/ GCC] on ftp as md5.sum file.<br />
*[http://www.gentoo.org/ Gentoo] as .md5 file on ftp.<br />
*[http://www.gnome.org/ GNOME] as MD5SUMS-for-gz and MD5SUMS-for-bz2 files on ftp.<br />
*[http://www.gnupg.org/ GnuPG] SHA-1 on web.<br />
*[http://www.kde.org/ KDE] on web and on ftp as MD5SUMS file.<br />
*[http://www.knoppix.org/ Knoppix] in .md5 and .sha1 file.<br />
*[http://www.mysql.com/ MySQL] MD5 on web.<br />
*[http://www.openoffice.org/ OpenOffice.org] MD5 on web.<br />
*[http://www.openssh.com/ OpenSSH] SHA-1 in release announcement.<br />
*[http://www.openssl.org/ OpenSSL] .md5 and .sha1 files linked to from web.<br />
*[http://www.perl.org/ Perl] link to .md5 on web.<br />
*[http://www.postgresql.org/ PostgreSQL] in a .md5 file.<br />
*[http://www.python.org/ Python] MD5 on web<br />
*[http://www.ubuntu.com/ Ubuntu] as MD5SUMS on ftp.<br />
*[http://www.x.org/ X.org] md5sums file on ftp.<br />
<br />
=== Example #1: [http://download.openoffice.org/2.0.1/md5sums.html OpenOffice.org MD5 sums] ===<br />
<pre><br />
English Application Binaries<br />
<br />
e0d123e5f316bef78bfdf5a008837577 OOo_2.0.1_LinuxIntel_install.tar.gz<br />
35d91262b3c3ec8841b54169588c97f7 OOo_2.0.1_LinuxIntel_install_wJRE.tar.gz<br />
cc273fe9d442850fa18c31c88c823e07 OOo_2.0.1_SolarisSparc_install.tar.gz<br />
ff6626c69507a6f511cc398998905670 OOo_2.0.1_SolarisSparc_install_wJRE.tar.gz<br />
ce099d7e208dc921e259b48aadef36c1 OOo_2.0.1_Solarisx86_install.tar.gz<br />
4fb319211b2e85cace04e8936100f024 OOo_2.0.1_Solarisx86_install_wJRE.tar.gz<br />
66bd00e43ff8b932c14140472c4b8cc6 OOo_2.0.1_Win32Intel_install.exe<br />
2d86c4246f3c0eb516628bf324d6b9a3 OOo_2.0.1_Win32Intel_install_wJRE.exe<br />
</pre><br />
<br />
=== Example #2: [http://mirrors.csol.org/knoppix/ Knoppix MD5 and SHA-1 sums in separate files ] ===<br />
<pre><br />
KNOPPIX_V4.0.2CD-2005-09-23-EN.iso.md5:<br />
<br />
1188f67d48c9f11afb8572977ef74c5e *KNOPPIX_V4.0.2CD-2005-09-23-EN.iso<br />
<br />
KNOPPIX_V4.0.2CD-2005-09-23-EN.iso.sha1:<br />
<br />
56857cfc709d3996f057252c16ec4656f5292802 *KNOPPIX_V4.0.2CD-2005-09-23-EN.iso<br />
<br />
</pre><br />
Note: This directory also contains filename.ext.md5.asc and filename.ext.sha1.asc files containing the same checksums and PGP signatures in one file.<br />
<br />
=== Example #3: Hash as ETag ===<br />
Some HTTP server applications compute a hash over the response body to serve as an effective ETag. The server must still compute the body but can benefit from reduced network utilization and reduced downstream cache thrashing. Such applications must be willing to risk a hash collision, albeit scoped to a single URL.<br />
<br />
== Existing Practices ==<br />
As described above, I believe almost all solutions are manual (see [http://www.openoffice.org/dev_docs/using_md5sums.html OpenOffice.org: Using MD5 sums]), an 8 step process on Windows and 3 steps on Linux. [http://mdhashtool.mozdev.org/lfinfo.html Link Fingerprints] which are used by [http://mdhashtool.mozdev.org/index.html MD Hash Tool], a Firefox extension, is one exception. Here is a Link Fingerprint example:<br />
<br />
<pre><br />
http://example.org/OOo_2.0.1_LinuxIntel_install.tar.gz#!md5!e0d123e5f316bef78bfdf5a008837577<br />
</pre><br />
A Link Fingerprint begins with a traditional URL, then #!md5!, then the MD5 hash.<br />
<br />
Brad Fitzpatrick also [http://brad.livejournal.com/2162507.html suggested referring to "files/patches/changesets" by their unique digest.]<br />
<br />
== Proposal ==<br />
A microformat for MD5 and SHA-1 hashes could make them more usable. [http://mdhashtool.mozdev.org/index.html MD Hash Tool], another extension, or download managers could be modified to use them automatically.<br />
<br />
<pre><br />
<span class="download"><br />
<a rel="bookmark" href="http://example.com/OOo_2.0.1_.tar.gz">Download OpenOffice.org</a><br />
<span class="hash-md5">e0d123e5f316bef78bfdf5a008837577</span><br />
</span><br />
</pre></div>Eron Wrighthttp://microformats.org/wiki/index.php?title=hcard-issues&diff=5010hcard-issues2006-02-13T19:01:13Z<p>Eron Wright: /* Issues */</p>
<hr />
<div>= hCard issues =<br />
<br />
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/log/ Tantek]<br />
<br />
See related [[hcalendar-issues]].<br />
<br />
== Issues ==<br />
<br />
* 2005-06-21 raised by Hixie<br />
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?<br />
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.<br />
<br />
* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.<br />
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''<br />
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code>&lt;abbr title="Middle Name" class="additional-name"&gt;M&lt;/abbr&gt;</code>. Honorific Suffixes in the RFC include Jr. Esq. and other inherited suffixes, so i would just use <code>&lt;span class="honorific-suffix"&gt;Jr.&lt;/span&gt;</code> etc.<br />
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''<br />
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:<br />
<pre><nowiki><br />
&lt;span class="adr"&gt;<br />
&lt;span class="type"&gt;work&lt;/span&gt;:<br />
...<br />
&lt;/span&gt;<br />
</nowiki></pre><br />
<pre><nowiki><br />
&lt;span class="tel"&gt;<br />
&lt;span class="type"&gt;work&lt;/span&gt;:<br />
&lt;span class="value"&gt;123.456.7890&lt;/span&gt;<br />
&lt;/span&gt;<br />
</nowiki></pre><br />
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400<br />
<br />
* 2005-07-22 raised by DanConnolly<br />
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''<br />
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:<br />
*#*# Set "fn" and "org" to the same value. E.g. <code>&lt;span class="fn org"&gt;W3C&lt;/span&gt;</code> (recommended)<br />
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code>&lt;span class="fn"&gt;&lt;/span&gt;&lt;span class="org"&gt;W3C&lt;/span&gt;</code> or<br />
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"<br />
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code><br />
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:<br />
*#** Address Book / MacOSX.3:<br />
*#*** Export (e.g. drag & drop to desktop, view in text editor)<br />
*#**** Sets "FN" and "ORG" to the name of the company<br />
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code><br />
*#*** Import (e.g. edit in text editor, drag & drop from desktop)<br />
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)<br />
*#**** And removing any proprietary properties (e.g. X-ABShowAs)<br />
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person<br />
*#** Address Book MacOSX.4:<br />
*#*** same results as above -RyanKing<br />
*#** The Danger Hiptop (aka T-Mobile Sidekick) addressbook:<br />
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])<br />
*#**** Sets "FN" to the empty string and puts the company name in "ORG".<br />
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.<br />
*#** Contacts / Outlook 2003 Windows<br />
*#*** Export (e.g. Highlight contact, File, Save As, vcard)<br />
*#**** Sets "N" and "ORG to the name of the company<br />
*#**** Sets "FN" to value in "File as:"<br />
*#** Add another vCard app here.<br />
<br />
* 2005-07-23 raised by DanConnolly<br />
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''<br />
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.<br />
*# ''...but I find example data with class="Given-Name"''<br />
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.<br />
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.<br />
*# ''..and code that supports it [data with class="Given-Name"].''<br />
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.<br />
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.<br />
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)<br />
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.<br />
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.<br />
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''<br />
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.<br />
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''<br />
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.<br />
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.<br />
<br />
* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.<br />
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailto's. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''<br />
*#* A: ACCEPTED FAQ. Type value.<br />
<br />
* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].<br />
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implemenations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.<br />
*#* REJECTED VAGUE. Which implementations? And which examples?<br />
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''<br />
<br />
* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].<br />
*# ''The specification gives no way to to declare a telephone extention, as in (800) 234-5678 ext. 101''<br />
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).<br />
<br />
* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].<br />
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''<br />
<br />
* 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]<br />
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html ''<br />
<br />
* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]<br />
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''<br />
<br />
== Template ==<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].<br />
*# ''Issue 1: Here is the first issue I have.''<br />
*# ''Issue 2: Here is the second issue I have.''</div>Eron Wrighthttp://microformats.org/wiki/index.php?title=location-formats&diff=6449location-formats2006-02-13T18:50:00Z<p>Eron Wright: /* What People are Publishing */</p>
<hr />
<div>= Location Research =<br />
This is a list of previous efforts at location / geographic ("Geo") data formats and protocols, as background research for developing a location format.<br />
__TOC__<br />
<br />
== Authors ==<br />
<br />
* Tantek Çelik<br />
* Bud Gibson<br />
* Ryan King<br />
* Eron Wright<br />
* ...<br />
* please add yourself if you help(ed) with this document.<br />
<br />
= Location Examples =<br />
<br />
== What People are Publishing ==<br />
<br />
* links to mapping services, canonical URLs to 3rd party services like:<br />
** Google Maps<br />
** Map Quest<br />
** Yahoo Maps<br />
<br />
* human / named / legislated formats<br />
** named places, e.g. Westin St. Francis<br />
** addresses, including zip codes<br />
<br />
* global/mathematical/geometrical<br />
** Latitude / Longitude / Altitude<br />
*** MAKE has a GeoURL button<br />
*** 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.<br />
*** Most systems do not contemplate or support the altitude component of a coordinate. As 3D terrain mapping grows in popularity (Google Earth), expect geocoding systems to provide the altitude.<br />
<br />
= Location Formats =<br />
<br />
== vCard & hCard ==<br />
vCard (RFC2426) and [[hcard]] include 'adr', a way to markup addresses. They also have a field called 'geo' for lat/long.<br />
<br />
== UPU S42 & OASIS xNAL ==<br />
UPU S42 is a standard for representing postal addresses. UPU, the Universal Postal Union, is the consortium of all national posts. See [http://xml.coverpages.org/ni2003-06-17-a.html UPU S42 Announcement]. xNAL, the XML Name <br />
and Address Language, is an earlier attempt to standardize on the components of addresses developed by OASIS, <br />
a consortium of business-process weenies. The distinction between vCard/hCard and S42/xAL/xNAL comes down to <br />
whether the address line elements themselves are decomposed. For example, in xNAL you can specify components like<br />
street number, street prefix directional, street name, street type, street postfix directional, subaddress type (Suite), subaddress number.<br />
<br />
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". <br />
<br />
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<br />
related to decomposed addresses is something that should be placed on another page.<br />
<br />
In addition, there should be pointers to national address standards.<br />
<br />
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 [http://www.usps.com/ncsc/lookups/usps_abbreviations.htm USPS Acronyms &amp; Abbreviations]<br />
<br />
New Zealand apparently adopted a variant of xNAL [http://www.e-government.govt.nz/docs/xnal-guidelines-1-0/index.html NZ xNAL Guidelines Release 1.0].<br />
<br />
== ICBM ==<br />
One comma seperated pair of lat/long <code><meta name="ICBM" content="XXX.XXXXX, XXX.XXXXX"></code><br />
[http://www.catb.org/~esr/jargon/html/I/ICBM-address.html]<br />
<br />
== GeoUrl ==<br />
* [http://geourl.org/ GeoURL]<br />
** This seems to have a decent amount of geeky adoption, though there are lots of typical invisible metadata problems, coordinates reversed, postive instead of negative etc.<br />
* [http://www.multimap.com/ 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.<br />
<br />
== Flickr Geotags ==<br />
* [http://steeev.f2o.org/mt/2005/05/geotagging_flickr_with_google_maps_and_greasemonkey_part_2.html 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 [http://geobloggers.com/]<br />
* [http://flickr.com/groups/geotagging/ A Flickr Group related to the topic]<br />
* [http://txfx.net/2005/05/17/flickr-google-maps-geobloggers/ A visual walkthrough of the technique.]<br />
* As of today (2005-06-01), 14k photos have been geotagged on Flickr.<br />
* [http://mappr.com mappr], [http://brainoff.com/worldkit/flick mapping flickr] also support these geotags.<br />
* flickr also supports [http://www.flickr.com/services/api/flickr.photos.getExif.html EXIF headers], which can be used for storing location.<br />
* [http://beta.plazes.com plazes] also allows flickr photos to be tagged with geotags<br />
<br />
This is somewhat of a problem though, as mechanically generated "tags" are not really tags. Including/setting Flickr "Geotags" could be considered pollution of truly user entered text, since the text of geotags is merely an encoding for a point on a map.<br />
<br />
== Geotagging ==<br />
* Geotagging has been employed in other hosted services: [http://brainoff.com/worldkit/delicious/ delicious], [http://worldkit.typepad.com/ Typepad], [http://blog.360.yahoo.com/blog-yRZQpvY8cq2kWXBO5ZrxEmrwsg--?p=9 Yahoo 360], [http://www.zoto.com/users/geotags/ Zoto]<br />
<br />
But what do these references to "geotagging" mean?<br />
<br />
== RSS ==<br />
Several people have tried putting geographic information into RSS.<br />
* [http://postneo.com/icbm/ This site] uses icbm coordinates and has plugins for several blogging packages.<br />
* [http://www.blogmapper.com/ BlogMapper] - appears to be adding a namespace to RSS.<br />
* [http://www.feedmap.net/BlogMap/ BlogMap] - picks up RSS extension and meta tag values<br />
* [http://brainoff.com/worldkit/doc/rss.php worldKit RSS docs] - worldKit advocates and understands various flavors of geocoded RSS; particularly the "geo" namespace.<br />
* [http://earthquake.usgs.gov/recenteqsww/rss.html USGS earthquake feed] - most widely used geocoded RSS feed<br />
* [http://brainoff.com/worldkit/doc/polygon.php Polygons and lines in polygons] - A simple format for expressing polygons and lines is defined for worldKit<br />
* [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<br />
<br />
== RDF ==<br />
* [http://www.geosemantics.org/ Geosemantics Interest Group]<br />
* [http://esw.w3.org/topic/GeoOnion GeoOnion] - a SW vocuabulary for relating items by distance from each other.<br />
* [http://www.mapbureau.com/rdfmap1.0/index.html RDFMap]<br />
* [http://esw.w3.org/topic/GeoRDF GeoRDF] similar effort to collect prior art, for an effort in interoperability between OGC standards and various lightweight geo formats.<br />
<br />
== GML ==<br />
[http://www.opengeospatial.org/docs/02-023r4.pdf Geographic Markup Language] provides the most complete XML descriptiono of geographic information available. Fortunately, it is also in wide-spread use, so a commonly-used subset of the 600-page specification has emerged. GML is used in the OGC WFS payload described below.<br />
<br />
<blockquote style="background: white; border: 1px solid black; padding: 1em;"><br />
== Open Geospatical Consortium - OGC ==<br />
Since 1994, [http://www.opengeospatial.org/ Open Geospatial Consortium] has been developing open specifications to enable the exchange of geographic information between applications. While some GIS vendors opposed OGC initially, essentially all commercial GIS software companies have broken down their proprietary "stovepipes" by embracing OGC specifications. The recent groundswell of ajax mapping applications can benefit tremendously from using OGC specs.<br />
<br />
=== WMS ===<br />
The [http://portal.opengeospatial.org/files/?artifact_id=5316 OGC Web Map Service (WMS) specification] makes it easy to request map images from a map rendering engine, such as the [http://mapserver.gis.umn.edu/ UMN Map Server]. It is straightforward to build dynamic tiling ("slippy map") ajax applications that pull in OGC map tiles. At Where 2.0, [http://www.metacarta.com MetaCarta] demonstrated such an OGC-capable ajax GIS client. The portal map providers (yahoo/gmaps/msn/map quest) do not yet offer WMS interfaces, so someone should wrap their proprietary interfaces in a WMS wrapper to encourage them :-)<br />
<br />
=== WCS ===<br />
<br />
Web Coverage Service extends WMS to enable attribute information about large area overview maps.<br />
<br />
<br />
=== WFS ===<br />
The [https://portal.opengeospatial.org/files/?artifact_id=8339 OGC Web Feature Service (WFS) specification] is the best way to express geographic information about Web content. It is more complex than the <i>ad hoc</i> geoURL syntax, and for good reason: it can be loaded directly into any OGC-capable GIS even if the coordinate information is in a different projection/datum or is more complex than just a point.<br />
<br />
WFS provides a robust means of querying for geographic entities, such as points, polygons, and more complex feature types. One can define new feature types simply by describing them. One can even specify the visual appearance of the geographic features using the [https://portal.opengeospatial.org/files/?artifact_id=1188 OGC Styled Layer Description (SLD) specification]. <br />
<br />
WFS is to vector map data, as WMS is to raster map data.<br />
<br />
Geographic search results, such as the yellow page information from the portals, could be presented in WFS. John Battelle commented that RSS forces publishers to attach their business model to their content, instead of to the web site holding the content, so that they can make money no matter where their content flows. The search portals will probably be forced to do the same, e.g. putting click-through ads in the RSS search results or WFS yellow page results, so that even when you display them in your customized ajax mapping application, the portal publishing the search results can still make money.<br />
<br />
</blockquote><br />
<br />
== Google ==<br />
=== Google Earth XML ===<br />
20050629 at Where 2.0 conference:<br />
"Google Earth has an XML schema for describing a place on the earth. Will be releasing today or tomorrow." <br />
- John Hanke of Google/Keyhole.<br />
Official KML [http://www.keyhole.com/kml/kml_doc.html Docs] and [http://www.keyhole.com/kml/kml_tut.html Tutorial]<br />
<br />
[http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/16076/an/khGlobe/page/0#16076 Reverse-Engineered KML Schema] (deprecated now that KML 2.0 is officially released)<br />
<br />
Note that KML supports the ''altitude'' component of a coordinate to support 3D terrain.<br />
<br />
== NMEA ==<br />
<br />
[http://www.gpsinformation.org/dale/nmea.htmhttp://www.gpsinformation.org/dale/nmea.htm Standard and Proprietary NMEA Sentances]<br />
<br />
== Wikipedia ==<br />
<br />
[http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Geo:Coordinates in Wikipedia Project]<br />
<br />
== Other Formats ==<br />
<br />
* GPX = GPS XML format<br />
* [http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Wikipedia markup styles]<br />
* [http://openguides.org/ OpenGuides] and [http://b.evnt.org evnt] are both looking into real-world/folksonomic location name mappings<br />
<br />
= Location APIs =<br />
<br />
== Google Maps API ==<br />
* [http://www.google.com/apis/maps/ Google Maps API documentation]<br />
<br />
== Yahoo Maps API ==<br />
* [http://developer.yahoo.net/maps/ Yahoo Maps API documentation]<br />
<br />
= Location Data, Tools and Sites =<br />
<br />
== Address2Coordinates ==<br />
These systems are freely available sources of address to lat/long mappings (US only). The first few are based on US Census data, so they might be up to date.<br />
* [http://www.census.gov/geo/www/tiger/ TIGER]<br />
* [http://www.itl.nist.gov/fipspubs/55new/nav-top-fr.htm FIPS]<br />
* [http://geocoder.us/ geocoder]<br />
* You can get coordinates from UK post-codes from [http://www.streetmap.co.uk streetmap]<br />
* Worldwide city level location data (over 4 million entries) is available from the [http://earth-info.nga.mil/gns/html/ GNS]. This is accessible as a REST service from the [http://brainoff.com/geocoder/ worldkit geocoder]<br />
* [http://www.mysociety.org/?p=83 mysociety.org] is providing an interesting name-based location look-up services. The results are returned as a CSV file! &nbsp; For instance, the query [http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale] returns <br />
<br />
<pre><br />
"Name","In","Near","Latitude","Longitude","State","Score"<br />
"Sunnyvale","Santa Clara County","","37.36889","-122.03528","CA","100"<br />
</pre><br />
but with a mime-type (text/csv) that browsers don't understand.<br />
<br />
== A2B ==<br />
[http://www.a2b.cc/ 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 [http://www.a2b.cc/help-searching-addurl-blogping.a2b pinged]. They support lat/long and ICBM meta tags.<br />
<br />
<br />
== Plazes ==<br />
[http://plazes.com 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.<br />
<br />
== Mapping Sites ==<br />
* [http://www.multimap.com Multimap]<br />
* [http://maps.google.com Google Maps]<br />
* [http://www.mapquest.com MapQuest]<br />
* [http://maps.yahoo.com Yahoo Maps]<br />
* [http://www.mapblast.com MapBlast]<br />
* [http://mapufacture.com mapufacture]<br />
<br />
= Location Brainstorming =<br />
<br />
A lot of was discussed and figured out at the Geo Microformat BOF at O'Reilly's Where 2.0 conference.<br />
<br />
See the [[geo-bof-2005-06-30]] minutes/notes.<br />
<br />
One of the thoughts that came out of BOF was the idea of [[location-tagging]].<br />
<br />
== Conclusions on new microformats ==<br />
<br />
The consensus conclusions from the Geo Microformat BOF at Where 2.0 was to define two new microformats to reflect the two kinds of most commonly published geo data.<br />
<br />
* [[adr]] - for representing / marking-up / publishing address location information. "adr" is simply the [[hcard|hCard]] "adr" property and all its sub-properties.<br />
* [[geo]] - for representing / marking-up / publishing latitude longitude location information. "geo" is simply the [[hcard|hCard]] "geo" property and all its sub-properties, with the explicitly specified datum of WGS84.</div>Eron Wrighthttp://microformats.org/wiki/index.php?title=location-formats&diff=4925location-formats2006-02-13T18:46:43Z<p>Eron Wright: /* Authors */</p>
<hr />
<div>= Location Research =<br />
This is a list of previous efforts at location / geographic ("Geo") data formats and protocols, as background research for developing a location format.<br />
__TOC__<br />
<br />
== Authors ==<br />
<br />
* Tantek Çelik<br />
* Bud Gibson<br />
* Ryan King<br />
* Eron Wright<br />
* ...<br />
* please add yourself if you help(ed) with this document.<br />
<br />
= Location Examples =<br />
<br />
== What People are Publishing ==<br />
<br />
* links to mapping services, canonical URLs to 3rd party services like:<br />
** Google Maps<br />
** Map Quest<br />
** Yahoo Maps<br />
<br />
* human / named / legislated formats<br />
** named places, e.g. Westin St. Francis<br />
** addresses, including zip codes<br />
<br />
* global/mathematical/geometrical<br />
** Lat & Lon<br />
*** MAKE has a GeoURL button<br />
*** 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.<br />
<br />
= Location Formats =<br />
<br />
== vCard & hCard ==<br />
vCard (RFC2426) and [[hcard]] include 'adr', a way to markup addresses. They also have a field called 'geo' for lat/long.<br />
<br />
== UPU S42 & OASIS xNAL ==<br />
UPU S42 is a standard for representing postal addresses. UPU, the Universal Postal Union, is the consortium of all national posts. See [http://xml.coverpages.org/ni2003-06-17-a.html UPU S42 Announcement]. xNAL, the XML Name <br />
and Address Language, is an earlier attempt to standardize on the components of addresses developed by OASIS, <br />
a consortium of business-process weenies. The distinction between vCard/hCard and S42/xAL/xNAL comes down to <br />
whether the address line elements themselves are decomposed. For example, in xNAL you can specify components like<br />
street number, street prefix directional, street name, street type, street postfix directional, subaddress type (Suite), subaddress number.<br />
<br />
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". <br />
<br />
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<br />
related to decomposed addresses is something that should be placed on another page.<br />
<br />
In addition, there should be pointers to national address standards.<br />
<br />
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 [http://www.usps.com/ncsc/lookups/usps_abbreviations.htm USPS Acronyms &amp; Abbreviations]<br />
<br />
New Zealand apparently adopted a variant of xNAL [http://www.e-government.govt.nz/docs/xnal-guidelines-1-0/index.html NZ xNAL Guidelines Release 1.0].<br />
<br />
== ICBM ==<br />
One comma seperated pair of lat/long <code><meta name="ICBM" content="XXX.XXXXX, XXX.XXXXX"></code><br />
[http://www.catb.org/~esr/jargon/html/I/ICBM-address.html]<br />
<br />
== GeoUrl ==<br />
* [http://geourl.org/ GeoURL]<br />
** This seems to have a decent amount of geeky adoption, though there are lots of typical invisible metadata problems, coordinates reversed, postive instead of negative etc.<br />
* [http://www.multimap.com/ 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.<br />
<br />
== Flickr Geotags ==<br />
* [http://steeev.f2o.org/mt/2005/05/geotagging_flickr_with_google_maps_and_greasemonkey_part_2.html 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 [http://geobloggers.com/]<br />
* [http://flickr.com/groups/geotagging/ A Flickr Group related to the topic]<br />
* [http://txfx.net/2005/05/17/flickr-google-maps-geobloggers/ A visual walkthrough of the technique.]<br />
* As of today (2005-06-01), 14k photos have been geotagged on Flickr.<br />
* [http://mappr.com mappr], [http://brainoff.com/worldkit/flick mapping flickr] also support these geotags.<br />
* flickr also supports [http://www.flickr.com/services/api/flickr.photos.getExif.html EXIF headers], which can be used for storing location.<br />
* [http://beta.plazes.com plazes] also allows flickr photos to be tagged with geotags<br />
<br />
This is somewhat of a problem though, as mechanically generated "tags" are not really tags. Including/setting Flickr "Geotags" could be considered pollution of truly user entered text, since the text of geotags is merely an encoding for a point on a map.<br />
<br />
== Geotagging ==<br />
* Geotagging has been employed in other hosted services: [http://brainoff.com/worldkit/delicious/ delicious], [http://worldkit.typepad.com/ Typepad], [http://blog.360.yahoo.com/blog-yRZQpvY8cq2kWXBO5ZrxEmrwsg--?p=9 Yahoo 360], [http://www.zoto.com/users/geotags/ Zoto]<br />
<br />
But what do these references to "geotagging" mean?<br />
<br />
== RSS ==<br />
Several people have tried putting geographic information into RSS.<br />
* [http://postneo.com/icbm/ This site] uses icbm coordinates and has plugins for several blogging packages.<br />
* [http://www.blogmapper.com/ BlogMapper] - appears to be adding a namespace to RSS.<br />
* [http://www.feedmap.net/BlogMap/ BlogMap] - picks up RSS extension and meta tag values<br />
* [http://brainoff.com/worldkit/doc/rss.php worldKit RSS docs] - worldKit advocates and understands various flavors of geocoded RSS; particularly the "geo" namespace.<br />
* [http://earthquake.usgs.gov/recenteqsww/rss.html USGS earthquake feed] - most widely used geocoded RSS feed<br />
* [http://brainoff.com/worldkit/doc/polygon.php Polygons and lines in polygons] - A simple format for expressing polygons and lines is defined for worldKit<br />
* [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<br />
<br />
== RDF ==<br />
* [http://www.geosemantics.org/ Geosemantics Interest Group]<br />
* [http://esw.w3.org/topic/GeoOnion GeoOnion] - a SW vocuabulary for relating items by distance from each other.<br />
* [http://www.mapbureau.com/rdfmap1.0/index.html RDFMap]<br />
* [http://esw.w3.org/topic/GeoRDF GeoRDF] similar effort to collect prior art, for an effort in interoperability between OGC standards and various lightweight geo formats.<br />
<br />
== GML ==<br />
[http://www.opengeospatial.org/docs/02-023r4.pdf Geographic Markup Language] provides the most complete XML descriptiono of geographic information available. Fortunately, it is also in wide-spread use, so a commonly-used subset of the 600-page specification has emerged. GML is used in the OGC WFS payload described below.<br />
<br />
<blockquote style="background: white; border: 1px solid black; padding: 1em;"><br />
== Open Geospatical Consortium - OGC ==<br />
Since 1994, [http://www.opengeospatial.org/ Open Geospatial Consortium] has been developing open specifications to enable the exchange of geographic information between applications. While some GIS vendors opposed OGC initially, essentially all commercial GIS software companies have broken down their proprietary "stovepipes" by embracing OGC specifications. The recent groundswell of ajax mapping applications can benefit tremendously from using OGC specs.<br />
<br />
=== WMS ===<br />
The [http://portal.opengeospatial.org/files/?artifact_id=5316 OGC Web Map Service (WMS) specification] makes it easy to request map images from a map rendering engine, such as the [http://mapserver.gis.umn.edu/ UMN Map Server]. It is straightforward to build dynamic tiling ("slippy map") ajax applications that pull in OGC map tiles. At Where 2.0, [http://www.metacarta.com MetaCarta] demonstrated such an OGC-capable ajax GIS client. The portal map providers (yahoo/gmaps/msn/map quest) do not yet offer WMS interfaces, so someone should wrap their proprietary interfaces in a WMS wrapper to encourage them :-)<br />
<br />
=== WCS ===<br />
<br />
Web Coverage Service extends WMS to enable attribute information about large area overview maps.<br />
<br />
<br />
=== WFS ===<br />
The [https://portal.opengeospatial.org/files/?artifact_id=8339 OGC Web Feature Service (WFS) specification] is the best way to express geographic information about Web content. It is more complex than the <i>ad hoc</i> geoURL syntax, and for good reason: it can be loaded directly into any OGC-capable GIS even if the coordinate information is in a different projection/datum or is more complex than just a point.<br />
<br />
WFS provides a robust means of querying for geographic entities, such as points, polygons, and more complex feature types. One can define new feature types simply by describing them. One can even specify the visual appearance of the geographic features using the [https://portal.opengeospatial.org/files/?artifact_id=1188 OGC Styled Layer Description (SLD) specification]. <br />
<br />
WFS is to vector map data, as WMS is to raster map data.<br />
<br />
Geographic search results, such as the yellow page information from the portals, could be presented in WFS. John Battelle commented that RSS forces publishers to attach their business model to their content, instead of to the web site holding the content, so that they can make money no matter where their content flows. The search portals will probably be forced to do the same, e.g. putting click-through ads in the RSS search results or WFS yellow page results, so that even when you display them in your customized ajax mapping application, the portal publishing the search results can still make money.<br />
<br />
</blockquote><br />
<br />
== Google ==<br />
=== Google Earth XML ===<br />
20050629 at Where 2.0 conference:<br />
"Google Earth has an XML schema for describing a place on the earth. Will be releasing today or tomorrow." <br />
- John Hanke of Google/Keyhole.<br />
Official KML [http://www.keyhole.com/kml/kml_doc.html Docs] and [http://www.keyhole.com/kml/kml_tut.html Tutorial]<br />
<br />
[http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/16076/an/khGlobe/page/0#16076 Reverse-Engineered KML Schema] (deprecated now that KML 2.0 is officially released)<br />
<br />
Note that KML supports the ''altitude'' component of a coordinate to support 3D terrain.<br />
<br />
== NMEA ==<br />
<br />
[http://www.gpsinformation.org/dale/nmea.htmhttp://www.gpsinformation.org/dale/nmea.htm Standard and Proprietary NMEA Sentances]<br />
<br />
== Wikipedia ==<br />
<br />
[http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Geo:Coordinates in Wikipedia Project]<br />
<br />
== Other Formats ==<br />
<br />
* GPX = GPS XML format<br />
* [http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Wikipedia markup styles]<br />
* [http://openguides.org/ OpenGuides] and [http://b.evnt.org evnt] are both looking into real-world/folksonomic location name mappings<br />
<br />
= Location APIs =<br />
<br />
== Google Maps API ==<br />
* [http://www.google.com/apis/maps/ Google Maps API documentation]<br />
<br />
== Yahoo Maps API ==<br />
* [http://developer.yahoo.net/maps/ Yahoo Maps API documentation]<br />
<br />
= Location Data, Tools and Sites =<br />
<br />
== Address2Coordinates ==<br />
These systems are freely available sources of address to lat/long mappings (US only). The first few are based on US Census data, so they might be up to date.<br />
* [http://www.census.gov/geo/www/tiger/ TIGER]<br />
* [http://www.itl.nist.gov/fipspubs/55new/nav-top-fr.htm FIPS]<br />
* [http://geocoder.us/ geocoder]<br />
* You can get coordinates from UK post-codes from [http://www.streetmap.co.uk streetmap]<br />
* Worldwide city level location data (over 4 million entries) is available from the [http://earth-info.nga.mil/gns/html/ GNS]. This is accessible as a REST service from the [http://brainoff.com/geocoder/ worldkit geocoder]<br />
* [http://www.mysociety.org/?p=83 mysociety.org] is providing an interesting name-based location look-up services. The results are returned as a CSV file! &nbsp; For instance, the query [http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale] returns <br />
<br />
<pre><br />
"Name","In","Near","Latitude","Longitude","State","Score"<br />
"Sunnyvale","Santa Clara County","","37.36889","-122.03528","CA","100"<br />
</pre><br />
but with a mime-type (text/csv) that browsers don't understand.<br />
<br />
== A2B ==<br />
[http://www.a2b.cc/ 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 [http://www.a2b.cc/help-searching-addurl-blogping.a2b pinged]. They support lat/long and ICBM meta tags.<br />
<br />
<br />
== Plazes ==<br />
[http://plazes.com 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.<br />
<br />
== Mapping Sites ==<br />
* [http://www.multimap.com Multimap]<br />
* [http://maps.google.com Google Maps]<br />
* [http://www.mapquest.com MapQuest]<br />
* [http://maps.yahoo.com Yahoo Maps]<br />
* [http://www.mapblast.com MapBlast]<br />
* [http://mapufacture.com mapufacture]<br />
<br />
= Location Brainstorming =<br />
<br />
A lot of was discussed and figured out at the Geo Microformat BOF at O'Reilly's Where 2.0 conference.<br />
<br />
See the [[geo-bof-2005-06-30]] minutes/notes.<br />
<br />
One of the thoughts that came out of BOF was the idea of [[location-tagging]].<br />
<br />
== Conclusions on new microformats ==<br />
<br />
The consensus conclusions from the Geo Microformat BOF at Where 2.0 was to define two new microformats to reflect the two kinds of most commonly published geo data.<br />
<br />
* [[adr]] - for representing / marking-up / publishing address location information. "adr" is simply the [[hcard|hCard]] "adr" property and all its sub-properties.<br />
* [[geo]] - for representing / marking-up / publishing latitude longitude location information. "geo" is simply the [[hcard|hCard]] "geo" property and all its sub-properties, with the explicitly specified datum of WGS84.</div>Eron Wrighthttp://microformats.org/wiki/index.php?title=location-formats&diff=4924location-formats2006-02-13T18:46:29Z<p>Eron Wright: /* Google Earth XML */</p>
<hr />
<div>= Location Research =<br />
This is a list of previous efforts at location / geographic ("Geo") data formats and protocols, as background research for developing a location format.<br />
__TOC__<br />
<br />
== Authors ==<br />
<br />
* Tantek Çelik<br />
* Bud Gibson<br />
* Ryan King<br />
* ...<br />
* please add yourself if you help(ed) with this document.<br />
<br />
= Location Examples =<br />
<br />
== What People are Publishing ==<br />
<br />
* links to mapping services, canonical URLs to 3rd party services like:<br />
** Google Maps<br />
** Map Quest<br />
** Yahoo Maps<br />
<br />
* human / named / legislated formats<br />
** named places, e.g. Westin St. Francis<br />
** addresses, including zip codes<br />
<br />
* global/mathematical/geometrical<br />
** Lat & Lon<br />
*** MAKE has a GeoURL button<br />
*** 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.<br />
<br />
= Location Formats =<br />
<br />
== vCard & hCard ==<br />
vCard (RFC2426) and [[hcard]] include 'adr', a way to markup addresses. They also have a field called 'geo' for lat/long.<br />
<br />
== UPU S42 & OASIS xNAL ==<br />
UPU S42 is a standard for representing postal addresses. UPU, the Universal Postal Union, is the consortium of all national posts. See [http://xml.coverpages.org/ni2003-06-17-a.html UPU S42 Announcement]. xNAL, the XML Name <br />
and Address Language, is an earlier attempt to standardize on the components of addresses developed by OASIS, <br />
a consortium of business-process weenies. The distinction between vCard/hCard and S42/xAL/xNAL comes down to <br />
whether the address line elements themselves are decomposed. For example, in xNAL you can specify components like<br />
street number, street prefix directional, street name, street type, street postfix directional, subaddress type (Suite), subaddress number.<br />
<br />
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". <br />
<br />
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<br />
related to decomposed addresses is something that should be placed on another page.<br />
<br />
In addition, there should be pointers to national address standards.<br />
<br />
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 [http://www.usps.com/ncsc/lookups/usps_abbreviations.htm USPS Acronyms &amp; Abbreviations]<br />
<br />
New Zealand apparently adopted a variant of xNAL [http://www.e-government.govt.nz/docs/xnal-guidelines-1-0/index.html NZ xNAL Guidelines Release 1.0].<br />
<br />
== ICBM ==<br />
One comma seperated pair of lat/long <code><meta name="ICBM" content="XXX.XXXXX, XXX.XXXXX"></code><br />
[http://www.catb.org/~esr/jargon/html/I/ICBM-address.html]<br />
<br />
== GeoUrl ==<br />
* [http://geourl.org/ GeoURL]<br />
** This seems to have a decent amount of geeky adoption, though there are lots of typical invisible metadata problems, coordinates reversed, postive instead of negative etc.<br />
* [http://www.multimap.com/ 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.<br />
<br />
== Flickr Geotags ==<br />
* [http://steeev.f2o.org/mt/2005/05/geotagging_flickr_with_google_maps_and_greasemonkey_part_2.html 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 [http://geobloggers.com/]<br />
* [http://flickr.com/groups/geotagging/ A Flickr Group related to the topic]<br />
* [http://txfx.net/2005/05/17/flickr-google-maps-geobloggers/ A visual walkthrough of the technique.]<br />
* As of today (2005-06-01), 14k photos have been geotagged on Flickr.<br />
* [http://mappr.com mappr], [http://brainoff.com/worldkit/flick mapping flickr] also support these geotags.<br />
* flickr also supports [http://www.flickr.com/services/api/flickr.photos.getExif.html EXIF headers], which can be used for storing location.<br />
* [http://beta.plazes.com plazes] also allows flickr photos to be tagged with geotags<br />
<br />
This is somewhat of a problem though, as mechanically generated "tags" are not really tags. Including/setting Flickr "Geotags" could be considered pollution of truly user entered text, since the text of geotags is merely an encoding for a point on a map.<br />
<br />
== Geotagging ==<br />
* Geotagging has been employed in other hosted services: [http://brainoff.com/worldkit/delicious/ delicious], [http://worldkit.typepad.com/ Typepad], [http://blog.360.yahoo.com/blog-yRZQpvY8cq2kWXBO5ZrxEmrwsg--?p=9 Yahoo 360], [http://www.zoto.com/users/geotags/ Zoto]<br />
<br />
But what do these references to "geotagging" mean?<br />
<br />
== RSS ==<br />
Several people have tried putting geographic information into RSS.<br />
* [http://postneo.com/icbm/ This site] uses icbm coordinates and has plugins for several blogging packages.<br />
* [http://www.blogmapper.com/ BlogMapper] - appears to be adding a namespace to RSS.<br />
* [http://www.feedmap.net/BlogMap/ BlogMap] - picks up RSS extension and meta tag values<br />
* [http://brainoff.com/worldkit/doc/rss.php worldKit RSS docs] - worldKit advocates and understands various flavors of geocoded RSS; particularly the "geo" namespace.<br />
* [http://earthquake.usgs.gov/recenteqsww/rss.html USGS earthquake feed] - most widely used geocoded RSS feed<br />
* [http://brainoff.com/worldkit/doc/polygon.php Polygons and lines in polygons] - A simple format for expressing polygons and lines is defined for worldKit<br />
* [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<br />
<br />
== RDF ==<br />
* [http://www.geosemantics.org/ Geosemantics Interest Group]<br />
* [http://esw.w3.org/topic/GeoOnion GeoOnion] - a SW vocuabulary for relating items by distance from each other.<br />
* [http://www.mapbureau.com/rdfmap1.0/index.html RDFMap]<br />
* [http://esw.w3.org/topic/GeoRDF GeoRDF] similar effort to collect prior art, for an effort in interoperability between OGC standards and various lightweight geo formats.<br />
<br />
== GML ==<br />
[http://www.opengeospatial.org/docs/02-023r4.pdf Geographic Markup Language] provides the most complete XML descriptiono of geographic information available. Fortunately, it is also in wide-spread use, so a commonly-used subset of the 600-page specification has emerged. GML is used in the OGC WFS payload described below.<br />
<br />
<blockquote style="background: white; border: 1px solid black; padding: 1em;"><br />
== Open Geospatical Consortium - OGC ==<br />
Since 1994, [http://www.opengeospatial.org/ Open Geospatial Consortium] has been developing open specifications to enable the exchange of geographic information between applications. While some GIS vendors opposed OGC initially, essentially all commercial GIS software companies have broken down their proprietary "stovepipes" by embracing OGC specifications. The recent groundswell of ajax mapping applications can benefit tremendously from using OGC specs.<br />
<br />
=== WMS ===<br />
The [http://portal.opengeospatial.org/files/?artifact_id=5316 OGC Web Map Service (WMS) specification] makes it easy to request map images from a map rendering engine, such as the [http://mapserver.gis.umn.edu/ UMN Map Server]. It is straightforward to build dynamic tiling ("slippy map") ajax applications that pull in OGC map tiles. At Where 2.0, [http://www.metacarta.com MetaCarta] demonstrated such an OGC-capable ajax GIS client. The portal map providers (yahoo/gmaps/msn/map quest) do not yet offer WMS interfaces, so someone should wrap their proprietary interfaces in a WMS wrapper to encourage them :-)<br />
<br />
=== WCS ===<br />
<br />
Web Coverage Service extends WMS to enable attribute information about large area overview maps.<br />
<br />
<br />
=== WFS ===<br />
The [https://portal.opengeospatial.org/files/?artifact_id=8339 OGC Web Feature Service (WFS) specification] is the best way to express geographic information about Web content. It is more complex than the <i>ad hoc</i> geoURL syntax, and for good reason: it can be loaded directly into any OGC-capable GIS even if the coordinate information is in a different projection/datum or is more complex than just a point.<br />
<br />
WFS provides a robust means of querying for geographic entities, such as points, polygons, and more complex feature types. One can define new feature types simply by describing them. One can even specify the visual appearance of the geographic features using the [https://portal.opengeospatial.org/files/?artifact_id=1188 OGC Styled Layer Description (SLD) specification]. <br />
<br />
WFS is to vector map data, as WMS is to raster map data.<br />
<br />
Geographic search results, such as the yellow page information from the portals, could be presented in WFS. John Battelle commented that RSS forces publishers to attach their business model to their content, instead of to the web site holding the content, so that they can make money no matter where their content flows. The search portals will probably be forced to do the same, e.g. putting click-through ads in the RSS search results or WFS yellow page results, so that even when you display them in your customized ajax mapping application, the portal publishing the search results can still make money.<br />
<br />
</blockquote><br />
<br />
== Google ==<br />
=== Google Earth XML ===<br />
20050629 at Where 2.0 conference:<br />
"Google Earth has an XML schema for describing a place on the earth. Will be releasing today or tomorrow." <br />
- John Hanke of Google/Keyhole.<br />
Official KML [http://www.keyhole.com/kml/kml_doc.html Docs] and [http://www.keyhole.com/kml/kml_tut.html Tutorial]<br />
<br />
[http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/16076/an/khGlobe/page/0#16076 Reverse-Engineered KML Schema] (deprecated now that KML 2.0 is officially released)<br />
<br />
Note that KML supports the ''altitude'' component of a coordinate to support 3D terrain.<br />
<br />
== NMEA ==<br />
<br />
[http://www.gpsinformation.org/dale/nmea.htmhttp://www.gpsinformation.org/dale/nmea.htm Standard and Proprietary NMEA Sentances]<br />
<br />
== Wikipedia ==<br />
<br />
[http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Geo:Coordinates in Wikipedia Project]<br />
<br />
== Other Formats ==<br />
<br />
* GPX = GPS XML format<br />
* [http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Wikipedia markup styles]<br />
* [http://openguides.org/ OpenGuides] and [http://b.evnt.org evnt] are both looking into real-world/folksonomic location name mappings<br />
<br />
= Location APIs =<br />
<br />
== Google Maps API ==<br />
* [http://www.google.com/apis/maps/ Google Maps API documentation]<br />
<br />
== Yahoo Maps API ==<br />
* [http://developer.yahoo.net/maps/ Yahoo Maps API documentation]<br />
<br />
= Location Data, Tools and Sites =<br />
<br />
== Address2Coordinates ==<br />
These systems are freely available sources of address to lat/long mappings (US only). The first few are based on US Census data, so they might be up to date.<br />
* [http://www.census.gov/geo/www/tiger/ TIGER]<br />
* [http://www.itl.nist.gov/fipspubs/55new/nav-top-fr.htm FIPS]<br />
* [http://geocoder.us/ geocoder]<br />
* You can get coordinates from UK post-codes from [http://www.streetmap.co.uk streetmap]<br />
* Worldwide city level location data (over 4 million entries) is available from the [http://earth-info.nga.mil/gns/html/ GNS]. This is accessible as a REST service from the [http://brainoff.com/geocoder/ worldkit geocoder]<br />
* [http://www.mysociety.org/?p=83 mysociety.org] is providing an interesting name-based location look-up services. The results are returned as a CSV file! &nbsp; For instance, the query [http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale] returns <br />
<br />
<pre><br />
"Name","In","Near","Latitude","Longitude","State","Score"<br />
"Sunnyvale","Santa Clara County","","37.36889","-122.03528","CA","100"<br />
</pre><br />
but with a mime-type (text/csv) that browsers don't understand.<br />
<br />
== A2B ==<br />
[http://www.a2b.cc/ 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 [http://www.a2b.cc/help-searching-addurl-blogping.a2b pinged]. They support lat/long and ICBM meta tags.<br />
<br />
<br />
== Plazes ==<br />
[http://plazes.com 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.<br />
<br />
== Mapping Sites ==<br />
* [http://www.multimap.com Multimap]<br />
* [http://maps.google.com Google Maps]<br />
* [http://www.mapquest.com MapQuest]<br />
* [http://maps.yahoo.com Yahoo Maps]<br />
* [http://www.mapblast.com MapBlast]<br />
* [http://mapufacture.com mapufacture]<br />
<br />
= Location Brainstorming =<br />
<br />
A lot of was discussed and figured out at the Geo Microformat BOF at O'Reilly's Where 2.0 conference.<br />
<br />
See the [[geo-bof-2005-06-30]] minutes/notes.<br />
<br />
One of the thoughts that came out of BOF was the idea of [[location-tagging]].<br />
<br />
== Conclusions on new microformats ==<br />
<br />
The consensus conclusions from the Geo Microformat BOF at Where 2.0 was to define two new microformats to reflect the two kinds of most commonly published geo data.<br />
<br />
* [[adr]] - for representing / marking-up / publishing address location information. "adr" is simply the [[hcard|hCard]] "adr" property and all its sub-properties.<br />
* [[geo]] - for representing / marking-up / publishing latitude longitude location information. "geo" is simply the [[hcard|hCard]] "geo" property and all its sub-properties, with the explicitly specified datum of WGS84.</div>Eron Wrighthttp://microformats.org/wiki/index.php?title=location-formats&diff=4923location-formats2006-02-13T18:44:36Z<p>Eron Wright: /* Google Earth XML */</p>
<hr />
<div>= Location Research =<br />
This is a list of previous efforts at location / geographic ("Geo") data formats and protocols, as background research for developing a location format.<br />
__TOC__<br />
<br />
== Authors ==<br />
<br />
* Tantek Çelik<br />
* Bud Gibson<br />
* Ryan King<br />
* ...<br />
* please add yourself if you help(ed) with this document.<br />
<br />
= Location Examples =<br />
<br />
== What People are Publishing ==<br />
<br />
* links to mapping services, canonical URLs to 3rd party services like:<br />
** Google Maps<br />
** Map Quest<br />
** Yahoo Maps<br />
<br />
* human / named / legislated formats<br />
** named places, e.g. Westin St. Francis<br />
** addresses, including zip codes<br />
<br />
* global/mathematical/geometrical<br />
** Lat & Lon<br />
*** MAKE has a GeoURL button<br />
*** 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.<br />
<br />
= Location Formats =<br />
<br />
== vCard & hCard ==<br />
vCard (RFC2426) and [[hcard]] include 'adr', a way to markup addresses. They also have a field called 'geo' for lat/long.<br />
<br />
== UPU S42 & OASIS xNAL ==<br />
UPU S42 is a standard for representing postal addresses. UPU, the Universal Postal Union, is the consortium of all national posts. See [http://xml.coverpages.org/ni2003-06-17-a.html UPU S42 Announcement]. xNAL, the XML Name <br />
and Address Language, is an earlier attempt to standardize on the components of addresses developed by OASIS, <br />
a consortium of business-process weenies. The distinction between vCard/hCard and S42/xAL/xNAL comes down to <br />
whether the address line elements themselves are decomposed. For example, in xNAL you can specify components like<br />
street number, street prefix directional, street name, street type, street postfix directional, subaddress type (Suite), subaddress number.<br />
<br />
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". <br />
<br />
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<br />
related to decomposed addresses is something that should be placed on another page.<br />
<br />
In addition, there should be pointers to national address standards.<br />
<br />
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 [http://www.usps.com/ncsc/lookups/usps_abbreviations.htm USPS Acronyms &amp; Abbreviations]<br />
<br />
New Zealand apparently adopted a variant of xNAL [http://www.e-government.govt.nz/docs/xnal-guidelines-1-0/index.html NZ xNAL Guidelines Release 1.0].<br />
<br />
== ICBM ==<br />
One comma seperated pair of lat/long <code><meta name="ICBM" content="XXX.XXXXX, XXX.XXXXX"></code><br />
[http://www.catb.org/~esr/jargon/html/I/ICBM-address.html]<br />
<br />
== GeoUrl ==<br />
* [http://geourl.org/ GeoURL]<br />
** This seems to have a decent amount of geeky adoption, though there are lots of typical invisible metadata problems, coordinates reversed, postive instead of negative etc.<br />
* [http://www.multimap.com/ 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.<br />
<br />
== Flickr Geotags ==<br />
* [http://steeev.f2o.org/mt/2005/05/geotagging_flickr_with_google_maps_and_greasemonkey_part_2.html 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 [http://geobloggers.com/]<br />
* [http://flickr.com/groups/geotagging/ A Flickr Group related to the topic]<br />
* [http://txfx.net/2005/05/17/flickr-google-maps-geobloggers/ A visual walkthrough of the technique.]<br />
* As of today (2005-06-01), 14k photos have been geotagged on Flickr.<br />
* [http://mappr.com mappr], [http://brainoff.com/worldkit/flick mapping flickr] also support these geotags.<br />
* flickr also supports [http://www.flickr.com/services/api/flickr.photos.getExif.html EXIF headers], which can be used for storing location.<br />
* [http://beta.plazes.com plazes] also allows flickr photos to be tagged with geotags<br />
<br />
This is somewhat of a problem though, as mechanically generated "tags" are not really tags. Including/setting Flickr "Geotags" could be considered pollution of truly user entered text, since the text of geotags is merely an encoding for a point on a map.<br />
<br />
== Geotagging ==<br />
* Geotagging has been employed in other hosted services: [http://brainoff.com/worldkit/delicious/ delicious], [http://worldkit.typepad.com/ Typepad], [http://blog.360.yahoo.com/blog-yRZQpvY8cq2kWXBO5ZrxEmrwsg--?p=9 Yahoo 360], [http://www.zoto.com/users/geotags/ Zoto]<br />
<br />
But what do these references to "geotagging" mean?<br />
<br />
== RSS ==<br />
Several people have tried putting geographic information into RSS.<br />
* [http://postneo.com/icbm/ This site] uses icbm coordinates and has plugins for several blogging packages.<br />
* [http://www.blogmapper.com/ BlogMapper] - appears to be adding a namespace to RSS.<br />
* [http://www.feedmap.net/BlogMap/ BlogMap] - picks up RSS extension and meta tag values<br />
* [http://brainoff.com/worldkit/doc/rss.php worldKit RSS docs] - worldKit advocates and understands various flavors of geocoded RSS; particularly the "geo" namespace.<br />
* [http://earthquake.usgs.gov/recenteqsww/rss.html USGS earthquake feed] - most widely used geocoded RSS feed<br />
* [http://brainoff.com/worldkit/doc/polygon.php Polygons and lines in polygons] - A simple format for expressing polygons and lines is defined for worldKit<br />
* [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<br />
<br />
== RDF ==<br />
* [http://www.geosemantics.org/ Geosemantics Interest Group]<br />
* [http://esw.w3.org/topic/GeoOnion GeoOnion] - a SW vocuabulary for relating items by distance from each other.<br />
* [http://www.mapbureau.com/rdfmap1.0/index.html RDFMap]<br />
* [http://esw.w3.org/topic/GeoRDF GeoRDF] similar effort to collect prior art, for an effort in interoperability between OGC standards and various lightweight geo formats.<br />
<br />
== GML ==<br />
[http://www.opengeospatial.org/docs/02-023r4.pdf Geographic Markup Language] provides the most complete XML descriptiono of geographic information available. Fortunately, it is also in wide-spread use, so a commonly-used subset of the 600-page specification has emerged. GML is used in the OGC WFS payload described below.<br />
<br />
<blockquote style="background: white; border: 1px solid black; padding: 1em;"><br />
== Open Geospatical Consortium - OGC ==<br />
Since 1994, [http://www.opengeospatial.org/ Open Geospatial Consortium] has been developing open specifications to enable the exchange of geographic information between applications. While some GIS vendors opposed OGC initially, essentially all commercial GIS software companies have broken down their proprietary "stovepipes" by embracing OGC specifications. The recent groundswell of ajax mapping applications can benefit tremendously from using OGC specs.<br />
<br />
=== WMS ===<br />
The [http://portal.opengeospatial.org/files/?artifact_id=5316 OGC Web Map Service (WMS) specification] makes it easy to request map images from a map rendering engine, such as the [http://mapserver.gis.umn.edu/ UMN Map Server]. It is straightforward to build dynamic tiling ("slippy map") ajax applications that pull in OGC map tiles. At Where 2.0, [http://www.metacarta.com MetaCarta] demonstrated such an OGC-capable ajax GIS client. The portal map providers (yahoo/gmaps/msn/map quest) do not yet offer WMS interfaces, so someone should wrap their proprietary interfaces in a WMS wrapper to encourage them :-)<br />
<br />
=== WCS ===<br />
<br />
Web Coverage Service extends WMS to enable attribute information about large area overview maps.<br />
<br />
<br />
=== WFS ===<br />
The [https://portal.opengeospatial.org/files/?artifact_id=8339 OGC Web Feature Service (WFS) specification] is the best way to express geographic information about Web content. It is more complex than the <i>ad hoc</i> geoURL syntax, and for good reason: it can be loaded directly into any OGC-capable GIS even if the coordinate information is in a different projection/datum or is more complex than just a point.<br />
<br />
WFS provides a robust means of querying for geographic entities, such as points, polygons, and more complex feature types. One can define new feature types simply by describing them. One can even specify the visual appearance of the geographic features using the [https://portal.opengeospatial.org/files/?artifact_id=1188 OGC Styled Layer Description (SLD) specification]. <br />
<br />
WFS is to vector map data, as WMS is to raster map data.<br />
<br />
Geographic search results, such as the yellow page information from the portals, could be presented in WFS. John Battelle commented that RSS forces publishers to attach their business model to their content, instead of to the web site holding the content, so that they can make money no matter where their content flows. The search portals will probably be forced to do the same, e.g. putting click-through ads in the RSS search results or WFS yellow page results, so that even when you display them in your customized ajax mapping application, the portal publishing the search results can still make money.<br />
<br />
</blockquote><br />
<br />
== Google ==<br />
=== Google Earth XML ===<br />
20050629 at Where 2.0 conference:<br />
"Google Earth has an XML schema for describing a place on the earth. Will be releasing today or tomorrow." <br />
- John Hanke of Google/Keyhole.<br />
Official KML [http://www.keyhole.com/kml/kml_doc.html Docs] and [http://www.keyhole.com/kml/kml_tut.html Tutorial]<br />
<br />
[http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/16076/an/khGlobe/page/0#16076 Reverse-Engineered KML Schema] (deprecated now that KML 2.0 is officially released)<br />
<br />
== NMEA ==<br />
<br />
[http://www.gpsinformation.org/dale/nmea.htmhttp://www.gpsinformation.org/dale/nmea.htm Standard and Proprietary NMEA Sentances]<br />
<br />
== Wikipedia ==<br />
<br />
[http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Geo:Coordinates in Wikipedia Project]<br />
<br />
== Other Formats ==<br />
<br />
* GPX = GPS XML format<br />
* [http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Wikipedia markup styles]<br />
* [http://openguides.org/ OpenGuides] and [http://b.evnt.org evnt] are both looking into real-world/folksonomic location name mappings<br />
<br />
= Location APIs =<br />
<br />
== Google Maps API ==<br />
* [http://www.google.com/apis/maps/ Google Maps API documentation]<br />
<br />
== Yahoo Maps API ==<br />
* [http://developer.yahoo.net/maps/ Yahoo Maps API documentation]<br />
<br />
= Location Data, Tools and Sites =<br />
<br />
== Address2Coordinates ==<br />
These systems are freely available sources of address to lat/long mappings (US only). The first few are based on US Census data, so they might be up to date.<br />
* [http://www.census.gov/geo/www/tiger/ TIGER]<br />
* [http://www.itl.nist.gov/fipspubs/55new/nav-top-fr.htm FIPS]<br />
* [http://geocoder.us/ geocoder]<br />
* You can get coordinates from UK post-codes from [http://www.streetmap.co.uk streetmap]<br />
* Worldwide city level location data (over 4 million entries) is available from the [http://earth-info.nga.mil/gns/html/ GNS]. This is accessible as a REST service from the [http://brainoff.com/geocoder/ worldkit geocoder]<br />
* [http://www.mysociety.org/?p=83 mysociety.org] is providing an interesting name-based location look-up services. The results are returned as a CSV file! &nbsp; For instance, the query [http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale] returns <br />
<br />
<pre><br />
"Name","In","Near","Latitude","Longitude","State","Score"<br />
"Sunnyvale","Santa Clara County","","37.36889","-122.03528","CA","100"<br />
</pre><br />
but with a mime-type (text/csv) that browsers don't understand.<br />
<br />
== A2B ==<br />
[http://www.a2b.cc/ 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 [http://www.a2b.cc/help-searching-addurl-blogping.a2b pinged]. They support lat/long and ICBM meta tags.<br />
<br />
<br />
== Plazes ==<br />
[http://plazes.com 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.<br />
<br />
== Mapping Sites ==<br />
* [http://www.multimap.com Multimap]<br />
* [http://maps.google.com Google Maps]<br />
* [http://www.mapquest.com MapQuest]<br />
* [http://maps.yahoo.com Yahoo Maps]<br />
* [http://www.mapblast.com MapBlast]<br />
* [http://mapufacture.com mapufacture]<br />
<br />
= Location Brainstorming =<br />
<br />
A lot of was discussed and figured out at the Geo Microformat BOF at O'Reilly's Where 2.0 conference.<br />
<br />
See the [[geo-bof-2005-06-30]] minutes/notes.<br />
<br />
One of the thoughts that came out of BOF was the idea of [[location-tagging]].<br />
<br />
== Conclusions on new microformats ==<br />
<br />
The consensus conclusions from the Geo Microformat BOF at Where 2.0 was to define two new microformats to reflect the two kinds of most commonly published geo data.<br />
<br />
* [[adr]] - for representing / marking-up / publishing address location information. "adr" is simply the [[hcard|hCard]] "adr" property and all its sub-properties.<br />
* [[geo]] - for representing / marking-up / publishing latitude longitude location information. "geo" is simply the [[hcard|hCard]] "geo" property and all its sub-properties, with the explicitly specified datum of WGS84.</div>Eron Wrighthttp://microformats.org/wiki/index.php?title=location-formats&diff=4922location-formats2006-02-13T18:42:23Z<p>Eron Wright: /* Google Earth XML */</p>
<hr />
<div>= Location Research =<br />
This is a list of previous efforts at location / geographic ("Geo") data formats and protocols, as background research for developing a location format.<br />
__TOC__<br />
<br />
== Authors ==<br />
<br />
* Tantek Çelik<br />
* Bud Gibson<br />
* Ryan King<br />
* ...<br />
* please add yourself if you help(ed) with this document.<br />
<br />
= Location Examples =<br />
<br />
== What People are Publishing ==<br />
<br />
* links to mapping services, canonical URLs to 3rd party services like:<br />
** Google Maps<br />
** Map Quest<br />
** Yahoo Maps<br />
<br />
* human / named / legislated formats<br />
** named places, e.g. Westin St. Francis<br />
** addresses, including zip codes<br />
<br />
* global/mathematical/geometrical<br />
** Lat & Lon<br />
*** MAKE has a GeoURL button<br />
*** 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.<br />
<br />
= Location Formats =<br />
<br />
== vCard & hCard ==<br />
vCard (RFC2426) and [[hcard]] include 'adr', a way to markup addresses. They also have a field called 'geo' for lat/long.<br />
<br />
== UPU S42 & OASIS xNAL ==<br />
UPU S42 is a standard for representing postal addresses. UPU, the Universal Postal Union, is the consortium of all national posts. See [http://xml.coverpages.org/ni2003-06-17-a.html UPU S42 Announcement]. xNAL, the XML Name <br />
and Address Language, is an earlier attempt to standardize on the components of addresses developed by OASIS, <br />
a consortium of business-process weenies. The distinction between vCard/hCard and S42/xAL/xNAL comes down to <br />
whether the address line elements themselves are decomposed. For example, in xNAL you can specify components like<br />
street number, street prefix directional, street name, street type, street postfix directional, subaddress type (Suite), subaddress number.<br />
<br />
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". <br />
<br />
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<br />
related to decomposed addresses is something that should be placed on another page.<br />
<br />
In addition, there should be pointers to national address standards.<br />
<br />
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 [http://www.usps.com/ncsc/lookups/usps_abbreviations.htm USPS Acronyms &amp; Abbreviations]<br />
<br />
New Zealand apparently adopted a variant of xNAL [http://www.e-government.govt.nz/docs/xnal-guidelines-1-0/index.html NZ xNAL Guidelines Release 1.0].<br />
<br />
== ICBM ==<br />
One comma seperated pair of lat/long <code><meta name="ICBM" content="XXX.XXXXX, XXX.XXXXX"></code><br />
[http://www.catb.org/~esr/jargon/html/I/ICBM-address.html]<br />
<br />
== GeoUrl ==<br />
* [http://geourl.org/ GeoURL]<br />
** This seems to have a decent amount of geeky adoption, though there are lots of typical invisible metadata problems, coordinates reversed, postive instead of negative etc.<br />
* [http://www.multimap.com/ 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.<br />
<br />
== Flickr Geotags ==<br />
* [http://steeev.f2o.org/mt/2005/05/geotagging_flickr_with_google_maps_and_greasemonkey_part_2.html 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 [http://geobloggers.com/]<br />
* [http://flickr.com/groups/geotagging/ A Flickr Group related to the topic]<br />
* [http://txfx.net/2005/05/17/flickr-google-maps-geobloggers/ A visual walkthrough of the technique.]<br />
* As of today (2005-06-01), 14k photos have been geotagged on Flickr.<br />
* [http://mappr.com mappr], [http://brainoff.com/worldkit/flick mapping flickr] also support these geotags.<br />
* flickr also supports [http://www.flickr.com/services/api/flickr.photos.getExif.html EXIF headers], which can be used for storing location.<br />
* [http://beta.plazes.com plazes] also allows flickr photos to be tagged with geotags<br />
<br />
This is somewhat of a problem though, as mechanically generated "tags" are not really tags. Including/setting Flickr "Geotags" could be considered pollution of truly user entered text, since the text of geotags is merely an encoding for a point on a map.<br />
<br />
== Geotagging ==<br />
* Geotagging has been employed in other hosted services: [http://brainoff.com/worldkit/delicious/ delicious], [http://worldkit.typepad.com/ Typepad], [http://blog.360.yahoo.com/blog-yRZQpvY8cq2kWXBO5ZrxEmrwsg--?p=9 Yahoo 360], [http://www.zoto.com/users/geotags/ Zoto]<br />
<br />
But what do these references to "geotagging" mean?<br />
<br />
== RSS ==<br />
Several people have tried putting geographic information into RSS.<br />
* [http://postneo.com/icbm/ This site] uses icbm coordinates and has plugins for several blogging packages.<br />
* [http://www.blogmapper.com/ BlogMapper] - appears to be adding a namespace to RSS.<br />
* [http://www.feedmap.net/BlogMap/ BlogMap] - picks up RSS extension and meta tag values<br />
* [http://brainoff.com/worldkit/doc/rss.php worldKit RSS docs] - worldKit advocates and understands various flavors of geocoded RSS; particularly the "geo" namespace.<br />
* [http://earthquake.usgs.gov/recenteqsww/rss.html USGS earthquake feed] - most widely used geocoded RSS feed<br />
* [http://brainoff.com/worldkit/doc/polygon.php Polygons and lines in polygons] - A simple format for expressing polygons and lines is defined for worldKit<br />
* [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<br />
<br />
== RDF ==<br />
* [http://www.geosemantics.org/ Geosemantics Interest Group]<br />
* [http://esw.w3.org/topic/GeoOnion GeoOnion] - a SW vocuabulary for relating items by distance from each other.<br />
* [http://www.mapbureau.com/rdfmap1.0/index.html RDFMap]<br />
* [http://esw.w3.org/topic/GeoRDF GeoRDF] similar effort to collect prior art, for an effort in interoperability between OGC standards and various lightweight geo formats.<br />
<br />
== GML ==<br />
[http://www.opengeospatial.org/docs/02-023r4.pdf Geographic Markup Language] provides the most complete XML descriptiono of geographic information available. Fortunately, it is also in wide-spread use, so a commonly-used subset of the 600-page specification has emerged. GML is used in the OGC WFS payload described below.<br />
<br />
<blockquote style="background: white; border: 1px solid black; padding: 1em;"><br />
== Open Geospatical Consortium - OGC ==<br />
Since 1994, [http://www.opengeospatial.org/ Open Geospatial Consortium] has been developing open specifications to enable the exchange of geographic information between applications. While some GIS vendors opposed OGC initially, essentially all commercial GIS software companies have broken down their proprietary "stovepipes" by embracing OGC specifications. The recent groundswell of ajax mapping applications can benefit tremendously from using OGC specs.<br />
<br />
=== WMS ===<br />
The [http://portal.opengeospatial.org/files/?artifact_id=5316 OGC Web Map Service (WMS) specification] makes it easy to request map images from a map rendering engine, such as the [http://mapserver.gis.umn.edu/ UMN Map Server]. It is straightforward to build dynamic tiling ("slippy map") ajax applications that pull in OGC map tiles. At Where 2.0, [http://www.metacarta.com MetaCarta] demonstrated such an OGC-capable ajax GIS client. The portal map providers (yahoo/gmaps/msn/map quest) do not yet offer WMS interfaces, so someone should wrap their proprietary interfaces in a WMS wrapper to encourage them :-)<br />
<br />
=== WCS ===<br />
<br />
Web Coverage Service extends WMS to enable attribute information about large area overview maps.<br />
<br />
<br />
=== WFS ===<br />
The [https://portal.opengeospatial.org/files/?artifact_id=8339 OGC Web Feature Service (WFS) specification] is the best way to express geographic information about Web content. It is more complex than the <i>ad hoc</i> geoURL syntax, and for good reason: it can be loaded directly into any OGC-capable GIS even if the coordinate information is in a different projection/datum or is more complex than just a point.<br />
<br />
WFS provides a robust means of querying for geographic entities, such as points, polygons, and more complex feature types. One can define new feature types simply by describing them. One can even specify the visual appearance of the geographic features using the [https://portal.opengeospatial.org/files/?artifact_id=1188 OGC Styled Layer Description (SLD) specification]. <br />
<br />
WFS is to vector map data, as WMS is to raster map data.<br />
<br />
Geographic search results, such as the yellow page information from the portals, could be presented in WFS. John Battelle commented that RSS forces publishers to attach their business model to their content, instead of to the web site holding the content, so that they can make money no matter where their content flows. The search portals will probably be forced to do the same, e.g. putting click-through ads in the RSS search results or WFS yellow page results, so that even when you display them in your customized ajax mapping application, the portal publishing the search results can still make money.<br />
<br />
</blockquote><br />
<br />
== Google ==<br />
=== Google Earth XML ===<br />
20050629 at Where 2.0 conference:<br />
"Google Earth has an XML schema for describing a place on the earth. Will be releasing today or tomorrow." <br />
- John Hanke of Google/Keyhole.<br />
Official KML [http://www.keyhole.com/kml/kml_doc.html Docs] and [http://www.keyhole.com/kml/kml_tut.html Tutorial]<br />
<br />
[http://bbs.keyhole.com/ubb/showthreaded.php/Cat/0/Number/16076/an/khGlobe/page/0#16076] (deprecated now that KML 2.0 is officially released)<br />
<br />
== NMEA ==<br />
<br />
[http://www.gpsinformation.org/dale/nmea.htmhttp://www.gpsinformation.org/dale/nmea.htm Standard and Proprietary NMEA Sentances]<br />
<br />
== Wikipedia ==<br />
<br />
[http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Geo:Coordinates in Wikipedia Project]<br />
<br />
== Other Formats ==<br />
<br />
* GPX = GPS XML format<br />
* [http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates Wikipedia markup styles]<br />
* [http://openguides.org/ OpenGuides] and [http://b.evnt.org evnt] are both looking into real-world/folksonomic location name mappings<br />
<br />
= Location APIs =<br />
<br />
== Google Maps API ==<br />
* [http://www.google.com/apis/maps/ Google Maps API documentation]<br />
<br />
== Yahoo Maps API ==<br />
* [http://developer.yahoo.net/maps/ Yahoo Maps API documentation]<br />
<br />
= Location Data, Tools and Sites =<br />
<br />
== Address2Coordinates ==<br />
These systems are freely available sources of address to lat/long mappings (US only). The first few are based on US Census data, so they might be up to date.<br />
* [http://www.census.gov/geo/www/tiger/ TIGER]<br />
* [http://www.itl.nist.gov/fipspubs/55new/nav-top-fr.htm FIPS]<br />
* [http://geocoder.us/ geocoder]<br />
* You can get coordinates from UK post-codes from [http://www.streetmap.co.uk streetmap]<br />
* Worldwide city level location data (over 4 million entries) is available from the [http://earth-info.nga.mil/gns/html/ GNS]. This is accessible as a REST service from the [http://brainoff.com/geocoder/ worldkit geocoder]<br />
* [http://www.mysociety.org/?p=83 mysociety.org] is providing an interesting name-based location look-up services. The results are returned as a CSV file! &nbsp; For instance, the query [http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale http://gaze.mysociety.org/gaze-rest?f=find_places&country=US&state=CA&query=sunnyvale] returns <br />
<br />
<pre><br />
"Name","In","Near","Latitude","Longitude","State","Score"<br />
"Sunnyvale","Santa Clara County","","37.36889","-122.03528","CA","100"<br />
</pre><br />
but with a mime-type (text/csv) that browsers don't understand.<br />
<br />
== A2B ==<br />
[http://www.a2b.cc/ 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 [http://www.a2b.cc/help-searching-addurl-blogping.a2b pinged]. They support lat/long and ICBM meta tags.<br />
<br />
<br />
== Plazes ==<br />
[http://plazes.com 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.<br />
<br />
== Mapping Sites ==<br />
* [http://www.multimap.com Multimap]<br />
* [http://maps.google.com Google Maps]<br />
* [http://www.mapquest.com MapQuest]<br />
* [http://maps.yahoo.com Yahoo Maps]<br />
* [http://www.mapblast.com MapBlast]<br />
* [http://mapufacture.com mapufacture]<br />
<br />
= Location Brainstorming =<br />
<br />
A lot of was discussed and figured out at the Geo Microformat BOF at O'Reilly's Where 2.0 conference.<br />
<br />
See the [[geo-bof-2005-06-30]] minutes/notes.<br />
<br />
One of the thoughts that came out of BOF was the idea of [[location-tagging]].<br />
<br />
== Conclusions on new microformats ==<br />
<br />
The consensus conclusions from the Geo Microformat BOF at Where 2.0 was to define two new microformats to reflect the two kinds of most commonly published geo data.<br />
<br />
* [[adr]] - for representing / marking-up / publishing address location information. "adr" is simply the [[hcard|hCard]] "adr" property and all its sub-properties.<br />
* [[geo]] - for representing / marking-up / publishing latitude longitude location information. "geo" is simply the [[hcard|hCard]] "geo" property and all its sub-properties, with the explicitly specified datum of WGS84.</div>Eron Wrighthttp://microformats.org/wiki/index.php?title=User:Eron_Wright&diff=31717User:Eron Wright2006-02-13T18:40:08Z<p>Eron Wright: </p>
<hr />
<div><br />
Chief Architect<br />
Point2 Technologies Inc.<br />
306-955-1855<br />
<br />
Experienced with XSD, Web Services, and RSS.</div>Eron Wright