A <geo> element for marking up locations in a document

We have already the <time> element which is quite useful. We could have a <geo> element. for marking places.

<p><q cite="urn:isbn:978-0684824994">If you are lucky enough to have lived in <geo geolocation="48.856667, 2.350929">Paris</geo> as a young man, then wherever you go for the rest of your life, it stays with you, for Paris is a moveable feast.</q> once said Ernest Hemingway in <cite>A Moveable Feast.</cite></p>

The model of values could be declined through similar constructs than the time element.

<geo geolocation="48.856667, 2.350929">Paris</geo>
<geo>48.856667, 2.350929</geo>

The browser would create a Coordinates object.

Why it could be useful?

It could enable application where you might want to show a map widget for localizing a place you are mentioning in a text, such as an hotel page.

You might want to be able to automatically extract geodata from a document without relying on complicated heuristic or ambiguities, such as Paris in France or Paris in Texas.

As I’m pretty sure this is not a new proposal, there are certainly plenty of discussions already on W3C mailing-lists to dig out.

Some references

• datetime values for time element in HTML.
• geolocation API data format

I like it. Maybe also an attribute to indicate precision, and possibly elevation?

Do you want to put together and extension spec?

Great idea! Would it not make sense for the spec to match directly with the geolocation API format?

<geo><position timestamp="Thu Jun 05 2014 10:42:15"><coordinates latitude="123" longitude="234" altitude="345" accuracy="456" altitudeAccuracy="567" heading="678" speed="">thing with geo attributes</coordinates></position></geo>

The <geo> specification should use the same types as the interfaces defined in the Geo API spec and the same rules for which attributes are required and optional.

Ideally this would mean that the DOM objects would also have the same type as objects returned through interacting with the Geo API.

One could extend this to offer locations that are not defined by coordinates. Bad example:

<geo><place country="FR" city="Paris">Paris</place></geo>

That markup looks way too complicated to me. Do you have use cases that justify the extra complexity? I think that capturing information in the same manner that <time> does is certainly useful in terms of what can be repurposed from it, but elements stacked three levels down seems overkill, as do speed, timestamp, etc.!

Speed, heading etc are all optional attributes of the Coordinates object (per Geo API spec which @karl references).

Comparison to the <time> element is not fair in as much as time is a very specific thing. Geo is not, hence my suggestion of a <coordinates> element.

One could define an optional attribute of the <geo> tag called coordinates with specific parsing rules but I would argue that parsing rules that dictate a strict input format make things more complex than a well structured set of tags and attributes.

Consider also that co-ordinates are often expressed in various formats that can be ambiguous due to minor errors.

If I write an ECMAScript lib to work with these objects wouldn’t it be ideal if the DOM object I get from a <coordinates> tag has the same structure as the object I get when I interrogate the Geo API?

I am a big fan of having some kind of geo element for semantics. I also like the idea of mapping to the Geolocation API, but that does look like overkill markup for very little gain.

A specification should allow for both forms. Simple (for simplicity) and complex for those that require the precision. Bear in mind that most markup is rendered by some application not hand coded so complex markup that is still human-readable shouldn’t be discarded purely on that basis.

A suggestion:

<geo coordinates="123, 234, 345">A place</geo> 

should be equivalent to

<geo><coordinates latitude="123" longitude="234" altitude="345">A place</coordinates></geo>

Adding a time dimension converts a place to a position.

<geo coordinates="123, 234, 345" timestamp="Thu Jun 05 2014 10:42:15">A position</geo> 

should be equivalent to

<geo><position timestamp="Thu Jun 05 2014 10:42:15"><coordinates latitude="" longitude="" altitude="345">A position</coordinates><position></geo>

I’m not a fan of bikeshedding, but I’d really like to call this element <place>, so I can corner the market in t-shirts saying "if you’ve got the <time>, I’ve got the <place>. kthxbai.

We’ve started a CG to discuss the idea of adding a element + map media type for use by html: http://www.w3.org/community/maps4html/

Would be interested in having participation there. The project is just getting started.

What do you think?

Just use <address> or <address type=geo>. The current definition of address in HTML5 is nonsense (and hence people will use it “correctly” - as in a street address) and could just be redefined. In any case, this seems like something better suited for a Web Component that could automatically hook itself up to the geolocation API and some kind of map widget.

Indeed, nothing like this has a realistic chance of making it into browsers. Web components are perfect for this use case. If a ton of people start using this (way more than are currently using e.g. <time>, which is widely regarded as a mistake) then maybe it’ll get baked in, assuming browser vendors have nothing else to work on.

I’m much in favor of @marcosc’s idea of re-defining <address>. My discontent with the current definition of <address> dates back to the dark XHTML 2 ages.

Or put another way, what about this definition:

If <address> contains an attribute geo (or location, …), it represents a physical location. Otherwise it represents any contact information. (The part about the information in <address> being related to the closest content element is omitted.)

schema.org provides a way of marking this up, although it’s a bit more verbose than what’s being proposed here. I’d probably lean for a more generic type such as <place> with geocoordinates as an attribute. Then again, I’m not sure there is a strong enough reason to put this into the HTML spec, when it can be solved via microdata.

But then it also needs an <inclination>

I hear you. At least that’s not a “that’s impossible!”. Thanks.

Since not all geographical objects represent single point. Should tag use Well-known text instead? So it could be line or polygon?

Could I make a small suggestion? As we move towards the Interplanetary Internet, would it not make sense to also include an (optional) celestial object parameter?

E.g.

See where the <geo celestial="mars" latitude="123" longitude="345">Mars Rover landed</geo>

I was thinking of the same. For one, the ISS is connected to the Internet. Let’s stay future-proof! On the other hand, naming the element <geo> would then be a not-so-clever idea. <space> it’s then.

<space galactic-coords="..." />

TL;DR: There are already some XML based markup languages to store geo-informations. Please don’t invent another one. The better way would be to embed one of the existing solutions into HTML, as it is done with SVG and MathML.

…

The complex markup form is already covered when using KML embedded directly into HTML. This is already a specification and you can use it since years. Of course you will need additional scripts to get the information out of the DOM – but on the other hand KML is already widely used for GEO location information interchange.

KML is currently already in use by many applications, most well known maybe are Google Earth and the Google Maps API, but also some OpenSource project like OpenLayers do support KML.

There is also theGeography Markup Language, but I don’t know of any real world usage examples of this one.

Since HTML5 already has an extension capability built-in (Microdata), it makes sense to use it. As @Nettsentrisk mentioned, schema.org (the collaborative effort of Google, Microsoft, Yahoo and Yandex to create a shared vocabulary) already has GeoCoordinates markup that is already being used and indexed by Google and the rest of the search providers. This works in production, today.

HTML5 has built-in support for Microdata which gives you the ability to add GeoCoordinates to an HTML5 document; you can also use RDFa Lite for newbies, RDFa for more features or JSON-LD if you want the new hotness.

The issue with another HTML5 tag is you can’t express the relationship between things only using that tag. Expressing relationships (“we want to visit that resort located on this island at these coordinates”) is becoming increasingly important; schema.org vocabulary was created to solve this precise problem.