geo-brainstorming - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:22:49Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:22, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~geo brainstorming~~</entry-title>~~		{{DISPLAYTITLE:geo brainstorming}}

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

Tantek: move single geo value possibility examples to brainstorming since it wasn't previously in the spec, altitude is now in vCard4, h-card, h-geo

2012-12-23T18:31:35Z

move single geo value possibility examples to brainstorming since it wasn't previously in the spec, altitude is now in vCard4, h-card, h-geo

@@ Line 25: / Line 25: @@
 <span id="Geo_improvements">Possible ways to improve geo markup formats/syntaxes.</span>
-=== abbr geo with title lat long ===
+=== single geo value ===
 One possible new format would be to wrap existing human viewable/clickable view markup of a latlong point on a map with an abbr that has the machine readable geo location information in the title attribute:
@@ Line 88: / Line 91: @@
 <source lang=text>
 GEO:37.386013;-122.082932
 </source>
@@ Line 188: / Line 213: @@
 === altitude ===
+"altitude" was added as a component of the GEO property in [[vCard4]] and thus is in [[h-card]], and [[h-geo]].
 === radius/zoom ===
 Kevin Marks has asked for "radius" or "zoom" as an extension to GEO.  Currently we are rejecting all property/value extensions to hCard/vCard.
 === ISO 19136 ===

Tantek: /* microformats2 p-geo */ ws

2012-08-20T21:38:33Z

microformats2 p-geo: ws

← Older revision		Revision as of 21:38, 20 August 2012
Line 77:		Line 77:
	The resulting JSON fragment from a microformats2 parser:		The resulting JSON fragment from a microformats2 parser:
	<source lang=javascript>		<source lang=javascript>
	"properties": {		"properties": {
	"geo": ["37.386013;-122.082932"]		"geo": ["37.386013;-122.082932"]
	}		}
	</source>		</source>

Tantek: microformats2 p-geo

2012-08-20T21:32:57Z

microformats2 p-geo

@@ Line 1: / Line 1: @@
-<entry-title>Geo brainstorming</entry-title>
+<entry-title>geo brainstorming</entry-title>
 This page is for further brainstorming about how to better markup [[geo]] microformats, whether stand-alone, alongside/with an [[adr]], and/or as part of an [[hcard|hCard]]. See also [[hcard-brainstorming]].
@@ Line 65: / Line 65: @@
 If a "geo" property lacks explicit "latitude" and "longitude" subproperties, then the "geo" property is treated like any other string property  (e.g. following rules for parsing <code><nowiki><abbr title></nowiki></code>, <code><nowiki><img alt></nowiki></code> etc.), where that string value has the same literal syntax as specified in RFC 2426 section 3.4.2: single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59), specifying latitude and longitude, in that order.
 === geo links ===

Tantek: /* marking up more geolocation information */ markup effects

2012-08-20T21:19:57Z

marking up more geolocation information: markup effects

← Older revision		Revision as of 21:19, 20 August 2012
Line 10:		Line 10:

	We can study how existing pages link to or embed location-specific map links/views to see if there is some way we can (in preference order) :		We can study how existing pages link to or embed location-specific map links/views to see if there is some way we can (in preference order) :
	# re-use existing data being published (no modification to data on pages)		# re-use existing data being published (no modification to data on pages, perhaps additional markup to help discover/parse the data)
	# provide guidelines for making published data more easily discoverable/parseable (minor modifications to data on pages)		# provide guidelines for making published data more easily discoverable/parseable (minor modifications to data on pages, additional markup)
	# come up with a new format/expression for publishing/linking data on pages (likely rewrite to how data is published on the page)		# come up with a new format/expression for publishing/linking data on pages (likely rewrite to how data is published on the page, new markup)

	== existing geolocation publishing examples ==		== existing geolocation publishing examples ==

Tantek: entry-title, autotoc, abbr updates, reduce personal POV (make more generic), start updating analysis per existing visible geodata publishing practices

2012-08-20T18:14:43Z

entry-title, autotoc, abbr updates, reduce personal POV (make more generic), start updating analysis per existing visible geodata publishing practices

← Older revision		Revision as of 18:14, 20 August 2012
Line 1:		Line 1:
	<h1>Geo brainstorming</h1>		<entry-title>Geo brainstorming</entry-title>
	~~{{TOC-right}}~~
	~~This page is about [[geo]] both as a stand-alone microformat, and as a sub-set of [[hcard\|hCard]]. See also [[hcard-brainstorming]].~~

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

	~~I (Tantek) have seen examples of where there is~~ a human viewable/clickable ~~presentation~~ of a point on a map~~, and the desire to include the machine readable geo information with the same element,~~ e.g. ~~something like~~:		== marking up more geolocation information ==
			Web pages with geolocation information often present a
			human viewable/clickable view of a latlong point on a map. e.g. [https://twitter.com/jkprime/status/233778329340223488 Tweet permalink] with hyperlinked embedded map view and city/state/country.

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

			We can study how existing pages link to or embed location-specific map links/views to see if there is some way we can (in preference order) :
			# re-use existing data being published (no modification to data on pages)
			# provide guidelines for making published data more easily discoverable/parseable (minor modifications to data on pages)
			# come up with a new format/expression for publishing/linking data on pages (likely rewrite to how data is published on the page)

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

			* [https://twitter.com/jkprime/status/233778329340223488 Tweet permalink] with map and city/state/country - uses:
			** maps.googleapis.com image embed
			** hyperlink URL with latlong: https://maps.google.com/maps?q=45.52792708%2C-122.68458260&z=15
			* ...

			== geo improvements ==
			<span id="Geo_improvements">Possible ways to improve geo markup formats/syntaxes.</span>

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

			<source lang=html4strict>
	<abbr class="geo" title="machine-readable-geo-info">		<abbr class="geo" title="machine-readable-geo-info">
	human readable/clickable point on a map		human readable/clickable point on a map
	</abbr>		</abbr>
	</~~nowiki></pre~~>		</source>

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

	~~Fortunately, there already is a~~ syntax ~~for that,~~ in vCard RFC 2426 3.4.2:		We can try the syntax in vCard RFC 2426 3.4.2:
	<pre>		<pre>
	Type value: A single structured value consisting of two float values		Type value: A single structured value consisting of two float values
Line 33:		Line 54:

	Thus:		Thus:
	<~~pre><nowiki~~>		<source lang=html4strict>
	<abbr class="geo" title="37.386013;-122.082932">		<abbr class="geo" title="37.386013;-122.082932">
	Mountain View, CA		Mountain View, CA
	</abbr>		</abbr>
	</~~nowiki></pre~~>		</source>

	~~I think this is pretty much a no-brainer, because the~~ rules for parsing "geo" ~~are simply~~ altered to:		The rules for parsing a "geo" would be altered to include:

			* <span id="latitude_longitude_shorthand">latitude longitude shorthand</span>
	=== latitude longitude shorthand ~~===~~

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

	In addition, people may publish Google Maps links like this:		In addition, people may publish Google Maps links like this (need source citation) :
			<source lang=html4strict>
	<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>		<a href="http://maps.google.com/maps?q=37.386013+-122.082932">this spot</a>
			</source>

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

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

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

	~~I'm raising this to make sure it is considered.~~		First guess is NO for two reasons:

	~~However, my first~~ guess is NO for two reasons.

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

Line 204:		Line 225:

	If ISO6709 is used, it is likely to be able to write as follows.		If ISO6709 is used, it is likely to be able to write as follows.
	<~~pre><nowiki~~>		<source lang=html4strict>
	examples		examples
	<abbr class="geo" title="+40-075CRSxxxx/">		<abbr class="geo" title="+40-075CRSxxxx/">
Line 213:		Line 234:
	Point represented as Degrees, minutes, seconds and decimal seconds, with +2.79 a height or depth as defined through the CRS.		Point represented as Degrees, minutes, seconds and decimal seconds, with +2.79 a height or depth as defined through the CRS.
	</abbr>		</abbr>
	</~~nowiki></pre~~>		</source>

	A C# library to read and write ISO 6709 coordinates from/to xml can be found in [http://coordinate.codeplex.com Codeplex]		A C# library to read and write ISO 6709 coordinates from/to xml can be found in [http://coordinate.codeplex.com Codeplex]
Line 236:		Line 257:
	Quite recently an the [http://tools.ietf.org/html/rfc5870 RFC 5870] document has been published that describes a URI format for geographic locations. The [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13 draft for vCard version 4.0] establishes [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13#section-6.5.2 new GEO parameter format] with reference to that RFC. You can find more information related to the RFC at http://geouri.org/ . With this RFC at hand a reference to a geographic position in microformats (and in HTML generally) should look as simple as:		Quite recently an the [http://tools.ietf.org/html/rfc5870 RFC 5870] document has been published that describes a URI format for geographic locations. The [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13 draft for vCard version 4.0] establishes [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13#section-6.5.2 new GEO parameter format] with reference to that RFC. You can find more information related to the RFC at http://geouri.org/ . With this RFC at hand a reference to a geographic position in microformats (and in HTML generally) should look as simple as:

	<~~pre><nowiki~~>		<source lang=html4strict>
	<a href="geo:51.511233,-0.128317">Leicester Square, London</a>		<a href="geo:51.511233,-0.128317">Leicester Square, London</a>
	</~~nowiki></pre~~>		</source>

	==Geo implementations==		==Geo implementations==

Steelman: /* RFC 5870 */ dleted unnecessary words

2010-11-07T11:48:15Z

RFC 5870: dleted unnecessary words

← Older revision		Revision as of 11:48, 7 November 2010
Line 234:		Line 234:
	=== RFC 5870 ===		=== RFC 5870 ===

	Quite recently an the [http://tools.ietf.org/html/rfc5870 RFC 5870] document has been published that describes a URI format for geographic locations. The [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13 draft for vCard version 4.0] establishes [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13#section-6.5.2 new GEO parameter format] with reference to that RFC. You can find more information related to the RFC at http://geouri.org/ . With this RFC at hand~~, and~~ reference to a geographic position in microformats (and in HTML generally) should look as simple as:		Quite recently an the [http://tools.ietf.org/html/rfc5870 RFC 5870] document has been published that describes a URI format for geographic locations. The [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13 draft for vCard version 4.0] establishes [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13#section-6.5.2 new GEO parameter format] with reference to that RFC. You can find more information related to the RFC at http://geouri.org/ . With this RFC at hand a reference to a geographic position in microformats (and in HTML generally) should look as simple as:

	<pre><nowiki>		<pre><nowiki>

Steelman at 11:33, 7 November 2010

2010-11-07T11:33:49Z

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

			=== RFC 5870 ===

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

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

	==Geo implementations==		==Geo implementations==

Tantek: /* latitude longitude shorthand and geo link */ follow-up to CSarven's questions

2010-02-08T20:37:57Z

latitude longitude shorthand and geo link: follow-up to CSarven's questions

← Older revision		Revision as of 20:37, 8 February 2010
Line 94:		Line 94:
	There are a few things interesting about this example.		There are a few things interesting about this example.
	* It's prime for marking up as an [[adr]] - a structured address, since it has locality, region, country-name semantics.		* It's prime for marking up as an [[adr]] - a structured address, since it has locality, region, country-name semantics.
	*# I acknowledge that adr can be used here, but example is minimized for geo. -[[User:Csarven\|Sarven Capadisli]] 13:55, 15 January 2010 (UTC)		** I acknowledge that adr can be used here, but example is minimized for geo. -[[User:Csarven\|Sarven Capadisli]] 13:55, 15 January 2010 (UTC)
			*** ''Need complete example.'' It's better to work with a complete real-world example rather than one that has been minimized, so that all the relevant content/markup/context can be considered. [[User:Tantek\|Tantek]] 20:37, 8 February 2010 (UTC)

	* Using the title attribute for semicolon separated lat-long may not be the user-friendliest thing to do.		* Using the title attribute for semicolon separated lat-long may not be the user-friendliest thing to do.
	*# I'd presume that this is similar to the general public comprehending the full ISO8601 format, but much harder. So, I can agree with that. For this geo minimization though, it had to go somewhere. -[[User:Csarven\|Sarven Capadisli]] 13:55, 15 January 2010 (UTC)		** I'd presume that this is similar to the general public comprehending the full ISO8601 format, but much harder. So, I can agree with that. For this geo minimization though, it had to go somewhere. -[[User:Csarven\|Sarven Capadisli]] 13:55, 15 January 2010 (UTC)
			*** However, we must avoid presenting the user with content that is not human readable/listenable. If it "has to go somewhere", we must figure out a human readable/listenable way to do so. [[User:Tantek\|Tantek]] 20:37, 8 February 2010 (UTC)

	* Given microformats experience with various uses of the the title attribute - a good rule of thumb is to check to make sure that the content you are putting into the title attribute is both reasonably human readable and listenable.		* Given microformats experience with various uses of the the title attribute - a good rule of thumb is to check to make sure that the content you are putting into the title attribute is both reasonably human readable and listenable.
	Here is some better markup that could be applied to the example today:		Here is some better markup that could be applied to the example today:
Line 124:		Line 128:

	-[[User:Csarven\|Sarven Capadisli]] 13:55, 15 January 2010 (UTC)		-[[User:Csarven\|Sarven Capadisli]] 13:55, 15 January 2010 (UTC)


			When the two examples are rendered, the first:

			* lat:45.5140800; long:-73.6111000

			is more user friendly than

			* 45.5140800;-73.6111000

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

			-[[User:Tantek\|Tantek]] 20:37, 8 February 2010 (UTC)

	=== altitude ===		=== altitude ===

Csarven: s/this/that

2010-01-15T14:13:52Z

s/this/that

← Older revision		Revision as of 14:13, 15 January 2010
Line 110:		Line 110:
	- [[User:Tantek\|Tantek]] 15:08, 31 December 2009 (UTC)		- [[User:Tantek\|Tantek]] 15:08, 31 December 2009 (UTC)

	~~This~~ is changing the example. Could you explain how		That is changing the example. Could you explain how

	<source lang=html4strict>		<source lang=html4strict>