Microformats Wiki - User contributions [en]

geo-extension-nonWGS84

2021-02-17T04:18:55Z

Artoria2e5: /* Harmonization with Geo URI and h-geo */

=Geo Extension Straw-Man Proposal=

Further to proposals for [[luna]] and [[mars]] equivalents to [[geo]], the following is a "straw-man" proposal, to incorporate those ideas (and likewise for other bodies) into geo, and to make Geo available for other terrestrial schema than WGS84, in order that further debate may take place. Please feel free to critique it harshly but fairly!

__TOC__
==Author==
[[User:AndyMabbett|Andy Mabbett]]

==Straw-Man==

<pre><nowiki>



Mars [1]



[name of mapping schema] [2]


37.386013,
-122.082932 [3]

</nowiki></pre>

===Notes===
# A list of acceptable, case-insensitive, values for 'body' would need to be drawn up (e.g. "Earth", "Mars", "Moon", "Venus", etc.) with "Earth" being assumed if none is specified.
# A list of acceptable values for 'reference frame' would need to be drawn up, for each body, with one being declared the default, to be used if no value is present (geo for Earth uses the datum of [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] by default. This extension would also allow for other terrestrial schema, of which there are many, such as OSGB36).
# As currently with geo, if the "latitude" and "longitude" classes are omitted, the two values MUST be separated by a semi-colon and latitude MUST be first:<code><nowiki>37.386013;-122.082932</nowiki></code>
:Also:
:*If latitude is present, so MUST be longitude, and vice versa.
:*The same number of decimal places SHOULD be used in each value; zeros are significant
:*The [http://planetarynames.wr.usgs.gov/ Gazetteer of Planetary Nomenclature] has coordinates for other planets, e.g. [http://planetarynames.wr.usgs.gov/jsp/FeatureTypesData2.jsp?systemID=2&bodyID=17&typeID=10&system=Venus&body=Venus&type=Dorsum,%20dorsa&sort=AName&show=Fname&show=Lat&show=Long&show=Diam&show=Stat&show=Orig Venus] and moons, e.g. [http://planetarynames.wr.usgs.gov/jsp/FeatureTypesData2.jsp?systemID=5&bodyID=7&typeID=15&system=Jupiter&body=Io&type=Fluctus,%20fluct%C5%ABs&sort=AName&show=Fname&show=Lat&show=Long&show=Diam&show=Stat&show=Orig Io].

==Issues==
*Should other bodies be included in ''geo'', or have stand-alone microformats?
*What effect will this have on existing 'geo' parsers, and it is safe to ignore that?
*What appropriate "reference frame" sets exist?
**Earth: [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84], [http://itrf.ensg.ign.fr/ITRF_solutions/2005/ ITRF2005], [http://www.ordnancesurvey.co.uk/oswebsite/gps/information/gpsbackground/glossary.html EtrS89]
**Moon: Mean Earth Polar Axis
**Mars: IAU2000
***'Report of the IAU/IAG Working Group on Cartographic Coordinates and Rotational Elements of the Planets and Satellites: 2000', Celestial Mechanics and Dynamical Astronomy 82: 83-110, 2002 [http://astrogeology.usgs.gov/Projects/ISPRS/PREPRINTS/index_preprints.html]
*Moon is the preferred name, per [ http://planetarynames.wr.usgs.gov/ IAU nomenclature working group]
*Is it appropriate to use the name "geo" (which means "Earth") for other bodies?
*is ''body '' an acceptable class name, given that it's also an HTML element?

===Planetocentric longitude===

Geographical longitude on, for example, Mars is not 180 degrees west to 180 degrees east: 18N,226E is a legal Martian location.

This is from [http://en.wikipedia.org/wiki/Timekeeping%20on%20Mars Timekeeping on Mars] ([http://www.esa.int/SPECIALS/Mars_Express/SEM0VQV4QWD_0.html])

<blockquote>
Note that the modern standard for measuring longitude on Mars s "planetocentric longitude", which is measured from 0°–360° East and measures angles from the center of Mars. The older "planetographic longitude" was measured from 0°–360° West and used coordinates mapped onto the surface.
</blockquote>

You can also check the description in JPL Horizons document, which uses planetographic longitude rather than planetocentric longitude, and gives much more longitude ranges used for different planets and moons, at http://ssd.jpl.nasa.gov/?horizons_doc.

==Comments==
===thare===
Comments from [[User:PlanetGeo|thare]]
*geo does stand for Earth but it has previously been generalized for the planetary case. For example, the term geology is used for planetary bodies.
*using ''body'' is fine by me and do not see a conflict as an HTML element.
*by schema do you mean a natural surficial property like earthquake, volcano, or crater? Or do you also want to include man-made items building, house, landing site?
**No, I mean, for example, WGS84, or the Martian or lunar equivalents. Is "schema" perhaps the wrong word?. [[User:AndyMabbett|Andy Mabbett]]
*** Perhaps "reference frame" would be a less confusing term than "schema"? --[[User:DavidCary|DavidCary]] 17:06, 5 Apr 2007 (PDT)
**** The HTML class attribute is a space seperated list, so 'class="reference frame"' is semantically equivalent to 'class="frame reference"' or 'class="reference" class="frame"' (though the latter is not syntactically valid). This could clash with, say, a theoretical microformat for footnotes, endnotes and references. Hyphenating ('class="reference-frame"') may be an improvement. [[User:TobyInk|TobyInk]] 12:29, 6 Jun 2007 (PDT)
***** Often a reference system like WGS84 is referred to as [http://en.wikipedia.org/wiki/Datum datum] [[User:RichardFlapper|Richard Flapper]] 23:28 21 May 2008 (MET)
*I would suggest just using "''Moon''". For other spellings for planetary bodies I would look toward the IAU/IAG documentation (an international working group) [http://astrogeology.usgs.gov/Projects/WGCCRE/ IAU/IAG Working Group (WG) on Cartographic Coordinates and Rotational Elements]
*Since this is a simple case, I tried to stay away from this issue but just can't. What does Earth really mean? There a many definitions for the size of Earth that need to be resolved when using lat/lon coordinates. Is the size of the Earth defined by the WGS84 or NAD27 definition? For Mars, is it the definition used in 1991 or redefined in 2000? This has previously been solved in web GIS applications by using an "EPSG" code. For planetary bodies we are attempting to define a similar coded standard which currently is called the IAU2000 code or namespace. Thus for Mars the code might be IAU2000:49900.
**Hence 'schema'. [[User:AndyMabbett|Andy Mabbett]]
*still working - more later
**Thank you. [[User:AndyMabbett|Andy Mabbett]]

===Brent A. Archinal===

(reproduced from e-mail to [[User:AndyMabbett|Andy Mabbett]], by kind permission)

*I appreciate the information you've provided and certainly the general idea of using "microformats" to indicate geographical location of points on solar system bodies is interesting.
*As to any comments on the general idea or any specific implementation, I think my colleague, Trent Hare, has already addressed any primary concerns or questions (above).
*The main issue seems to be that both the body, and the specific definition (technically a "reference frame") in question need to be specified, e.g. 1) Earth, ITRF2005, 2) Moon, ULCN 2005, 3) Mars, "IAU2000" or similar. Note that these frames are actually realizations of various "reference systems" 1) ITRS, 2) mean Earth/polar axis system, 3) IAU2000 Mars body fixed, respectively), but the system is apparent once the frame has been identified.
*A secondary issue is that obviously a third coordinate may need to be specified, i.e. some sort of "radius" (from the body center of mass) or "elevation" about a reference surface. If the latter, then that reference surface needs to be specified as well (e.g. Mars, "IAU2000", "IAU2000 sphere").
*If the microformat(s) were expandable to handle these cases when necessary (and others we haven't yet thought of) then obviously they could have a lot of utility.
*There are plenty of GIS and standards organization formats out there for handling this type of data, even for the solar system case. I'm not at all an expert on what's available, but obviously for something like the microformats to be generally used, their advantages over these existing formats would have to be made clear.
*As to usage here, we'll let others know of the existence of these formats, but I can't say how much immediate interest there might be in using them. We already (and Trent could say more) use a wide range of GIS and even flat file formats to carry e.g. lists of point-like data.
*Regarding one other point on the web pages, I believe the "Moon" (capitalized) is the primary recognized name for the Moon. There is an [IAU nomenclature working group http://planetarynames.wr.usgs.gov/] that handles not only the names of features on planetary bodies, but of the bodies themselves, and I believe this is their position on this (since confirmed - [[User:AndyMabbett|Andy Mabbett]]).

::Brent A. Archinal, Geodesist, Astrogeology Team, U.S. Geological Survey

=== multiple representations of the same location ===

I assume that someday, some other reference frame will replace the WGS84 reference frame.
During the changeover,
I expect many people to post 2 descriptions for a particular location (giving slightly different lat/long coordinates for each reference frame).

Even today, I can imagine someone wanting to tag a single location with WSG84, UTM (universal transverse Mercator), MGRS (military grid reference system), and the Maidenhead locator system.
So readers can use whichever system they find most convenient, and ignore the others.

* Would it be better to put all these ways of describing a location inside a single
<code><nowiki> ... </nowiki></code>
span? If so, what is the best way to make sure that each set of lat/long numbers gets associated with the correct reference frame?
* Or would it be better to put all those descriptions in their own independent
<code><nowiki> ... </nowiki></code>
span? In that case, how do we indicate that they all (are indended to) indicate the same location, rather than a series of locations ?

--[[User:DavidCary|DavidCary]] 17:06, 5 Apr 2007 (PDT)

* Why not use the same approach as used in GML? Use the [http://en.wikipedia.org/wiki/Geography_Markup_Language#Coordinate_Reference_System srsName] attribute when referring to a Coordinate Reference System (CRS) (or Datum). This way a coordinate can be recalculated to whatever CRS.

--[[User:RichardFlapper|Richard Flapper]] 23:46, 21 May 2008 (MET)

===Other===
I'm no expert on these matters, and am not sure if this is the right place for such comments, but these are are a few ideas/issues that came to mind after reading this page:

'''Multiple (Image) geo-tagging'''

A single XHTML document might make reference to (or include images of) multiple locations. It is not clear from the documents on this site how thee are to be dealt with. Should an <IMG ... > be child of the < div class=geo > or should both tags be on the same level in a parent < div >?

* This is solved by using [[figure]]. [[User:TobyInk|TobyInk]] 10:54, 24 Feb 2008 (PST)

'''Geo-tagging areas and images of landscapes'''
Geo-tags specify a single point which occupies no space. It might be desirable to be able to define areas, or single locations in a more fuzzy manner. Sometimes, as in the case of pictures of landscapes, you might want to indicate the Point of View (i.e. the location of the viewer)

To accomplish all of this would require three additions to the geo microformat.
# a ''precision'' attribute: This can be generally useful as even GPS devices have a margin of error, which you might want to indicate. Otherwise it can be used to give an idea of the ''bounding sphere'' of a large object like a building.
# an ''area'' attribute: This could use a system similar to that used by [http://www.w3.org/TR/SVG11/paths.html#PathData SVG] for defining paths, but using lat and long for defining points. It is rather odd that, for example on wikipedia, entire countries or cities are identified by a single point.
# some sort of ''vector'' attribute: While the only use I can think of for this if for photos of landscapes, it would be good to be able to indicate that the Geographic information relates to the position of the viewer rather than the subject. The ''vector'' would indicate where the viewer (camera) is looking

I'm not sure whether the ''area'' and ''vector'' features are well suited to be extensions of ''geo'' or should be independent microformats. Particularly the ''vector'' might be better suited for inclusion in some 'EXIF-data equivalent micro format'. Unless of course it you can think of a use beyond photos of landscapes.

--[[User:Inkwina|Inkwina]] 01:54, 30 Nov 2007 (PST)

===Astronomical Coordinates===
Comments from [[User:StuartLowe|Stuart]]

Rather than limit the format to the surfaces of planets and moons, would it be possible to include astronomical coordinates for objects in celestial coordinate frames? This would be very useful for tagging astronomical objects (e.g. M41 or NGC 7027).

If you do not want to break the existing ''geo'' tag might I suggest the more generic term ''coord''?

As suggested already it is important to define a reference frame. The term ''coordinate-frame'' (or ''coord-frame'') might also avoid ambiguities that exist for the word ''reference''. In astronomical applications it is necessary to provide both a frame (e.g. FK5) and an equinox/epoch (e.g. 2000.0). Astronomical coordinate frames that are widely supported are: ICRS, FK5, FK4, ECL, GAL, SGAL.

===Harmonization with Geo URI and h-geo ===
As ''geo'' has always been supposed to match vCard's geo thing (currently RFC 5870), I believe we should change the "reference frame" class name to simply "p-crs". The semantics are pretty well-defined there.

As for the class-less format, I propose just referring to RFC 5870 parsing. Stick a geo: prefix to the front and parse it. --[[User:Artoria2e5|Artoria2e5]] ([[User talk:Artoria2e5|talk]]) 04:18, 17 February 2021 (UTC)

==Related pages==
{{geo-related-pages}}

==See also==
[http://www.theregister.com/2006/12/19/nasa_4_google/ NASA shares space with Google] (2006-12-20)

geo-extension-nonWGS84

2021-02-17T04:18:40Z

Artoria2e5: /* Harmonization with Geo URI and h-geo */ add comment

=Geo Extension Straw-Man Proposal=

Further to proposals for [[luna]] and [[mars]] equivalents to [[geo]], the following is a "straw-man" proposal, to incorporate those ideas (and likewise for other bodies) into geo, and to make Geo available for other terrestrial schema than WGS84, in order that further debate may take place. Please feel free to critique it harshly but fairly!

__TOC__
==Author==
[[User:AndyMabbett|Andy Mabbett]]

==Straw-Man==

<pre><nowiki>



Mars [1]



[name of mapping schema] [2]


37.386013,
-122.082932 [3]

</nowiki></pre>

===Notes===
# A list of acceptable, case-insensitive, values for 'body' would need to be drawn up (e.g. "Earth", "Mars", "Moon", "Venus", etc.) with "Earth" being assumed if none is specified.
# A list of acceptable values for 'reference frame' would need to be drawn up, for each body, with one being declared the default, to be used if no value is present (geo for Earth uses the datum of [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] by default. This extension would also allow for other terrestrial schema, of which there are many, such as OSGB36).
# As currently with geo, if the "latitude" and "longitude" classes are omitted, the two values MUST be separated by a semi-colon and latitude MUST be first:<code><nowiki>37.386013;-122.082932</nowiki></code>
:Also:
:*If latitude is present, so MUST be longitude, and vice versa.
:*The same number of decimal places SHOULD be used in each value; zeros are significant
:*The [http://planetarynames.wr.usgs.gov/ Gazetteer of Planetary Nomenclature] has coordinates for other planets, e.g. [http://planetarynames.wr.usgs.gov/jsp/FeatureTypesData2.jsp?systemID=2&bodyID=17&typeID=10&system=Venus&body=Venus&type=Dorsum,%20dorsa&sort=AName&show=Fname&show=Lat&show=Long&show=Diam&show=Stat&show=Orig Venus] and moons, e.g. [http://planetarynames.wr.usgs.gov/jsp/FeatureTypesData2.jsp?systemID=5&bodyID=7&typeID=15&system=Jupiter&body=Io&type=Fluctus,%20fluct%C5%ABs&sort=AName&show=Fname&show=Lat&show=Long&show=Diam&show=Stat&show=Orig Io].

==Issues==
*Should other bodies be included in ''geo'', or have stand-alone microformats?
*What effect will this have on existing 'geo' parsers, and it is safe to ignore that?
*What appropriate "reference frame" sets exist?
**Earth: [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84], [http://itrf.ensg.ign.fr/ITRF_solutions/2005/ ITRF2005], [http://www.ordnancesurvey.co.uk/oswebsite/gps/information/gpsbackground/glossary.html EtrS89]
**Moon: Mean Earth Polar Axis
**Mars: IAU2000
***'Report of the IAU/IAG Working Group on Cartographic Coordinates and Rotational Elements of the Planets and Satellites: 2000', Celestial Mechanics and Dynamical Astronomy 82: 83-110, 2002 [http://astrogeology.usgs.gov/Projects/ISPRS/PREPRINTS/index_preprints.html]
*Moon is the preferred name, per [ http://planetarynames.wr.usgs.gov/ IAU nomenclature working group]
*Is it appropriate to use the name "geo" (which means "Earth") for other bodies?
*is ''body '' an acceptable class name, given that it's also an HTML element?

===Planetocentric longitude===

Geographical longitude on, for example, Mars is not 180 degrees west to 180 degrees east: 18N,226E is a legal Martian location.

This is from [http://en.wikipedia.org/wiki/Timekeeping%20on%20Mars Timekeeping on Mars] ([http://www.esa.int/SPECIALS/Mars_Express/SEM0VQV4QWD_0.html])

<blockquote>
Note that the modern standard for measuring longitude on Mars s "planetocentric longitude", which is measured from 0°–360° East and measures angles from the center of Mars. The older "planetographic longitude" was measured from 0°–360° West and used coordinates mapped onto the surface.
</blockquote>

You can also check the description in JPL Horizons document, which uses planetographic longitude rather than planetocentric longitude, and gives much more longitude ranges used for different planets and moons, at http://ssd.jpl.nasa.gov/?horizons_doc.

==Comments==
===thare===
Comments from [[User:PlanetGeo|thare]]
*geo does stand for Earth but it has previously been generalized for the planetary case. For example, the term geology is used for planetary bodies.
*using ''body'' is fine by me and do not see a conflict as an HTML element.
*by schema do you mean a natural surficial property like earthquake, volcano, or crater? Or do you also want to include man-made items building, house, landing site?
**No, I mean, for example, WGS84, or the Martian or lunar equivalents. Is "schema" perhaps the wrong word?. [[User:AndyMabbett|Andy Mabbett]]
*** Perhaps "reference frame" would be a less confusing term than "schema"? --[[User:DavidCary|DavidCary]] 17:06, 5 Apr 2007 (PDT)
**** The HTML class attribute is a space seperated list, so 'class="reference frame"' is semantically equivalent to 'class="frame reference"' or 'class="reference" class="frame"' (though the latter is not syntactically valid). This could clash with, say, a theoretical microformat for footnotes, endnotes and references. Hyphenating ('class="reference-frame"') may be an improvement. [[User:TobyInk|TobyInk]] 12:29, 6 Jun 2007 (PDT)
***** Often a reference system like WGS84 is referred to as [http://en.wikipedia.org/wiki/Datum datum] [[User:RichardFlapper|Richard Flapper]] 23:28 21 May 2008 (MET)
*I would suggest just using "''Moon''". For other spellings for planetary bodies I would look toward the IAU/IAG documentation (an international working group) [http://astrogeology.usgs.gov/Projects/WGCCRE/ IAU/IAG Working Group (WG) on Cartographic Coordinates and Rotational Elements]
*Since this is a simple case, I tried to stay away from this issue but just can't. What does Earth really mean? There a many definitions for the size of Earth that need to be resolved when using lat/lon coordinates. Is the size of the Earth defined by the WGS84 or NAD27 definition? For Mars, is it the definition used in 1991 or redefined in 2000? This has previously been solved in web GIS applications by using an "EPSG" code. For planetary bodies we are attempting to define a similar coded standard which currently is called the IAU2000 code or namespace. Thus for Mars the code might be IAU2000:49900.
**Hence 'schema'. [[User:AndyMabbett|Andy Mabbett]]
*still working - more later
**Thank you. [[User:AndyMabbett|Andy Mabbett]]

===Brent A. Archinal===

(reproduced from e-mail to [[User:AndyMabbett|Andy Mabbett]], by kind permission)

*I appreciate the information you've provided and certainly the general idea of using "microformats" to indicate geographical location of points on solar system bodies is interesting.
*As to any comments on the general idea or any specific implementation, I think my colleague, Trent Hare, has already addressed any primary concerns or questions (above).
*The main issue seems to be that both the body, and the specific definition (technically a "reference frame") in question need to be specified, e.g. 1) Earth, ITRF2005, 2) Moon, ULCN 2005, 3) Mars, "IAU2000" or similar. Note that these frames are actually realizations of various "reference systems" 1) ITRS, 2) mean Earth/polar axis system, 3) IAU2000 Mars body fixed, respectively), but the system is apparent once the frame has been identified.
*A secondary issue is that obviously a third coordinate may need to be specified, i.e. some sort of "radius" (from the body center of mass) or "elevation" about a reference surface. If the latter, then that reference surface needs to be specified as well (e.g. Mars, "IAU2000", "IAU2000 sphere").
*If the microformat(s) were expandable to handle these cases when necessary (and others we haven't yet thought of) then obviously they could have a lot of utility.
*There are plenty of GIS and standards organization formats out there for handling this type of data, even for the solar system case. I'm not at all an expert on what's available, but obviously for something like the microformats to be generally used, their advantages over these existing formats would have to be made clear.
*As to usage here, we'll let others know of the existence of these formats, but I can't say how much immediate interest there might be in using them. We already (and Trent could say more) use a wide range of GIS and even flat file formats to carry e.g. lists of point-like data.
*Regarding one other point on the web pages, I believe the "Moon" (capitalized) is the primary recognized name for the Moon. There is an [IAU nomenclature working group http://planetarynames.wr.usgs.gov/] that handles not only the names of features on planetary bodies, but of the bodies themselves, and I believe this is their position on this (since confirmed - [[User:AndyMabbett|Andy Mabbett]]).

::Brent A. Archinal, Geodesist, Astrogeology Team, U.S. Geological Survey

=== multiple representations of the same location ===

I assume that someday, some other reference frame will replace the WGS84 reference frame.
During the changeover,
I expect many people to post 2 descriptions for a particular location (giving slightly different lat/long coordinates for each reference frame).

Even today, I can imagine someone wanting to tag a single location with WSG84, UTM (universal transverse Mercator), MGRS (military grid reference system), and the Maidenhead locator system.
So readers can use whichever system they find most convenient, and ignore the others.

* Would it be better to put all these ways of describing a location inside a single
<code><nowiki> ... </nowiki></code>
span? If so, what is the best way to make sure that each set of lat/long numbers gets associated with the correct reference frame?
* Or would it be better to put all those descriptions in their own independent
<code><nowiki> ... </nowiki></code>
span? In that case, how do we indicate that they all (are indended to) indicate the same location, rather than a series of locations ?

--[[User:DavidCary|DavidCary]] 17:06, 5 Apr 2007 (PDT)

* Why not use the same approach as used in GML? Use the [http://en.wikipedia.org/wiki/Geography_Markup_Language#Coordinate_Reference_System srsName] attribute when referring to a Coordinate Reference System (CRS) (or Datum). This way a coordinate can be recalculated to whatever CRS.

--[[User:RichardFlapper|Richard Flapper]] 23:46, 21 May 2008 (MET)

===Other===
I'm no expert on these matters, and am not sure if this is the right place for such comments, but these are are a few ideas/issues that came to mind after reading this page:

'''Multiple (Image) geo-tagging'''

A single XHTML document might make reference to (or include images of) multiple locations. It is not clear from the documents on this site how thee are to be dealt with. Should an <IMG ... > be child of the < div class=geo > or should both tags be on the same level in a parent < div >?

* This is solved by using [[figure]]. [[User:TobyInk|TobyInk]] 10:54, 24 Feb 2008 (PST)

'''Geo-tagging areas and images of landscapes'''
Geo-tags specify a single point which occupies no space. It might be desirable to be able to define areas, or single locations in a more fuzzy manner. Sometimes, as in the case of pictures of landscapes, you might want to indicate the Point of View (i.e. the location of the viewer)

To accomplish all of this would require three additions to the geo microformat.
# a ''precision'' attribute: This can be generally useful as even GPS devices have a margin of error, which you might want to indicate. Otherwise it can be used to give an idea of the ''bounding sphere'' of a large object like a building.
# an ''area'' attribute: This could use a system similar to that used by [http://www.w3.org/TR/SVG11/paths.html#PathData SVG] for defining paths, but using lat and long for defining points. It is rather odd that, for example on wikipedia, entire countries or cities are identified by a single point.
# some sort of ''vector'' attribute: While the only use I can think of for this if for photos of landscapes, it would be good to be able to indicate that the Geographic information relates to the position of the viewer rather than the subject. The ''vector'' would indicate where the viewer (camera) is looking

I'm not sure whether the ''area'' and ''vector'' features are well suited to be extensions of ''geo'' or should be independent microformats. Particularly the ''vector'' might be better suited for inclusion in some 'EXIF-data equivalent micro format'. Unless of course it you can think of a use beyond photos of landscapes.

--[[User:Inkwina|Inkwina]] 01:54, 30 Nov 2007 (PST)

===Astronomical Coordinates===
Comments from [[User:StuartLowe|Stuart]]

Rather than limit the format to the surfaces of planets and moons, would it be possible to include astronomical coordinates for objects in celestial coordinate frames? This would be very useful for tagging astronomical objects (e.g. M41 or NGC 7027).

If you do not want to break the existing ''geo'' tag might I suggest the more generic term ''coord''?

As suggested already it is important to define a reference frame. The term ''coordinate-frame'' (or ''coord-frame'') might also avoid ambiguities that exist for the word ''reference''. In astronomical applications it is necessary to provide both a frame (e.g. FK5) and an equinox/epoch (e.g. 2000.0). Astronomical coordinate frames that are widely supported are: ICRS, FK5, FK4, ECL, GAL, SGAL.

===Harmonization with Geo URI and h-geo ===
As ''geo'' has always been supposed to match vCard's geo thing (currently RFC 5870), I believe we should change the "reference frame" class name to simply "p-crs". The semantics are pretty well-defined there.

As for the class-less format, I propose just referring to RFC 5870 parsing. Stick a geo: prefix to the front and parse it.

==Related pages==
{{geo-related-pages}}

==See also==
[http://www.theregister.com/2006/12/19/nasa_4_google/ NASA shares space with Google] (2006-12-20)

geo-extension-nonWGS84

2021-02-17T04:17:44Z

Artoria2e5:

=Geo Extension Straw-Man Proposal=

Further to proposals for [[luna]] and [[mars]] equivalents to [[geo]], the following is a "straw-man" proposal, to incorporate those ideas (and likewise for other bodies) into geo, and to make Geo available for other terrestrial schema than WGS84, in order that further debate may take place. Please feel free to critique it harshly but fairly!

__TOC__
==Author==
[[User:AndyMabbett|Andy Mabbett]]

==Straw-Man==

<pre><nowiki>



Mars [1]



[name of mapping schema] [2]


37.386013,
-122.082932 [3]

</nowiki></pre>

===Notes===
# A list of acceptable, case-insensitive, values for 'body' would need to be drawn up (e.g. "Earth", "Mars", "Moon", "Venus", etc.) with "Earth" being assumed if none is specified.
# A list of acceptable values for 'reference frame' would need to be drawn up, for each body, with one being declared the default, to be used if no value is present (geo for Earth uses the datum of [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] by default. This extension would also allow for other terrestrial schema, of which there are many, such as OSGB36).
# As currently with geo, if the "latitude" and "longitude" classes are omitted, the two values MUST be separated by a semi-colon and latitude MUST be first:<code><nowiki>37.386013;-122.082932</nowiki></code>
:Also:
:*If latitude is present, so MUST be longitude, and vice versa.
:*The same number of decimal places SHOULD be used in each value; zeros are significant
:*The [http://planetarynames.wr.usgs.gov/ Gazetteer of Planetary Nomenclature] has coordinates for other planets, e.g. [http://planetarynames.wr.usgs.gov/jsp/FeatureTypesData2.jsp?systemID=2&bodyID=17&typeID=10&system=Venus&body=Venus&type=Dorsum,%20dorsa&sort=AName&show=Fname&show=Lat&show=Long&show=Diam&show=Stat&show=Orig Venus] and moons, e.g. [http://planetarynames.wr.usgs.gov/jsp/FeatureTypesData2.jsp?systemID=5&bodyID=7&typeID=15&system=Jupiter&body=Io&type=Fluctus,%20fluct%C5%ABs&sort=AName&show=Fname&show=Lat&show=Long&show=Diam&show=Stat&show=Orig Io].

==Issues==
*Should other bodies be included in ''geo'', or have stand-alone microformats?
*What effect will this have on existing 'geo' parsers, and it is safe to ignore that?
*What appropriate "reference frame" sets exist?
**Earth: [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84], [http://itrf.ensg.ign.fr/ITRF_solutions/2005/ ITRF2005], [http://www.ordnancesurvey.co.uk/oswebsite/gps/information/gpsbackground/glossary.html EtrS89]
**Moon: Mean Earth Polar Axis
**Mars: IAU2000
***'Report of the IAU/IAG Working Group on Cartographic Coordinates and Rotational Elements of the Planets and Satellites: 2000', Celestial Mechanics and Dynamical Astronomy 82: 83-110, 2002 [http://astrogeology.usgs.gov/Projects/ISPRS/PREPRINTS/index_preprints.html]
*Moon is the preferred name, per [ http://planetarynames.wr.usgs.gov/ IAU nomenclature working group]
*Is it appropriate to use the name "geo" (which means "Earth") for other bodies?
*is ''body '' an acceptable class name, given that it's also an HTML element?

===Planetocentric longitude===

Geographical longitude on, for example, Mars is not 180 degrees west to 180 degrees east: 18N,226E is a legal Martian location.

This is from [http://en.wikipedia.org/wiki/Timekeeping%20on%20Mars Timekeeping on Mars] ([http://www.esa.int/SPECIALS/Mars_Express/SEM0VQV4QWD_0.html])

<blockquote>
Note that the modern standard for measuring longitude on Mars s "planetocentric longitude", which is measured from 0°–360° East and measures angles from the center of Mars. The older "planetographic longitude" was measured from 0°–360° West and used coordinates mapped onto the surface.
</blockquote>

You can also check the description in JPL Horizons document, which uses planetographic longitude rather than planetocentric longitude, and gives much more longitude ranges used for different planets and moons, at http://ssd.jpl.nasa.gov/?horizons_doc.

==Comments==
===thare===
Comments from [[User:PlanetGeo|thare]]
*geo does stand for Earth but it has previously been generalized for the planetary case. For example, the term geology is used for planetary bodies.
*using ''body'' is fine by me and do not see a conflict as an HTML element.
*by schema do you mean a natural surficial property like earthquake, volcano, or crater? Or do you also want to include man-made items building, house, landing site?
**No, I mean, for example, WGS84, or the Martian or lunar equivalents. Is "schema" perhaps the wrong word?. [[User:AndyMabbett|Andy Mabbett]]
*** Perhaps "reference frame" would be a less confusing term than "schema"? --[[User:DavidCary|DavidCary]] 17:06, 5 Apr 2007 (PDT)
**** The HTML class attribute is a space seperated list, so 'class="reference frame"' is semantically equivalent to 'class="frame reference"' or 'class="reference" class="frame"' (though the latter is not syntactically valid). This could clash with, say, a theoretical microformat for footnotes, endnotes and references. Hyphenating ('class="reference-frame"') may be an improvement. [[User:TobyInk|TobyInk]] 12:29, 6 Jun 2007 (PDT)
***** Often a reference system like WGS84 is referred to as [http://en.wikipedia.org/wiki/Datum datum] [[User:RichardFlapper|Richard Flapper]] 23:28 21 May 2008 (MET)
*I would suggest just using "''Moon''". For other spellings for planetary bodies I would look toward the IAU/IAG documentation (an international working group) [http://astrogeology.usgs.gov/Projects/WGCCRE/ IAU/IAG Working Group (WG) on Cartographic Coordinates and Rotational Elements]
*Since this is a simple case, I tried to stay away from this issue but just can't. What does Earth really mean? There a many definitions for the size of Earth that need to be resolved when using lat/lon coordinates. Is the size of the Earth defined by the WGS84 or NAD27 definition? For Mars, is it the definition used in 1991 or redefined in 2000? This has previously been solved in web GIS applications by using an "EPSG" code. For planetary bodies we are attempting to define a similar coded standard which currently is called the IAU2000 code or namespace. Thus for Mars the code might be IAU2000:49900.
**Hence 'schema'. [[User:AndyMabbett|Andy Mabbett]]
*still working - more later
**Thank you. [[User:AndyMabbett|Andy Mabbett]]

===Brent A. Archinal===

(reproduced from e-mail to [[User:AndyMabbett|Andy Mabbett]], by kind permission)

*I appreciate the information you've provided and certainly the general idea of using "microformats" to indicate geographical location of points on solar system bodies is interesting.
*As to any comments on the general idea or any specific implementation, I think my colleague, Trent Hare, has already addressed any primary concerns or questions (above).
*The main issue seems to be that both the body, and the specific definition (technically a "reference frame") in question need to be specified, e.g. 1) Earth, ITRF2005, 2) Moon, ULCN 2005, 3) Mars, "IAU2000" or similar. Note that these frames are actually realizations of various "reference systems" 1) ITRS, 2) mean Earth/polar axis system, 3) IAU2000 Mars body fixed, respectively), but the system is apparent once the frame has been identified.
*A secondary issue is that obviously a third coordinate may need to be specified, i.e. some sort of "radius" (from the body center of mass) or "elevation" about a reference surface. If the latter, then that reference surface needs to be specified as well (e.g. Mars, "IAU2000", "IAU2000 sphere").
*If the microformat(s) were expandable to handle these cases when necessary (and others we haven't yet thought of) then obviously they could have a lot of utility.
*There are plenty of GIS and standards organization formats out there for handling this type of data, even for the solar system case. I'm not at all an expert on what's available, but obviously for something like the microformats to be generally used, their advantages over these existing formats would have to be made clear.
*As to usage here, we'll let others know of the existence of these formats, but I can't say how much immediate interest there might be in using them. We already (and Trent could say more) use a wide range of GIS and even flat file formats to carry e.g. lists of point-like data.
*Regarding one other point on the web pages, I believe the "Moon" (capitalized) is the primary recognized name for the Moon. There is an [IAU nomenclature working group http://planetarynames.wr.usgs.gov/] that handles not only the names of features on planetary bodies, but of the bodies themselves, and I believe this is their position on this (since confirmed - [[User:AndyMabbett|Andy Mabbett]]).

::Brent A. Archinal, Geodesist, Astrogeology Team, U.S. Geological Survey

=== multiple representations of the same location ===

I assume that someday, some other reference frame will replace the WGS84 reference frame.
During the changeover,
I expect many people to post 2 descriptions for a particular location (giving slightly different lat/long coordinates for each reference frame).

Even today, I can imagine someone wanting to tag a single location with WSG84, UTM (universal transverse Mercator), MGRS (military grid reference system), and the Maidenhead locator system.
So readers can use whichever system they find most convenient, and ignore the others.

* Would it be better to put all these ways of describing a location inside a single
<code><nowiki> ... </nowiki></code>
span? If so, what is the best way to make sure that each set of lat/long numbers gets associated with the correct reference frame?
* Or would it be better to put all those descriptions in their own independent
<code><nowiki> ... </nowiki></code>
span? In that case, how do we indicate that they all (are indended to) indicate the same location, rather than a series of locations ?

--[[User:DavidCary|DavidCary]] 17:06, 5 Apr 2007 (PDT)

* Why not use the same approach as used in GML? Use the [http://en.wikipedia.org/wiki/Geography_Markup_Language#Coordinate_Reference_System srsName] attribute when referring to a Coordinate Reference System (CRS) (or Datum). This way a coordinate can be recalculated to whatever CRS.

--[[User:RichardFlapper|Richard Flapper]] 23:46, 21 May 2008 (MET)

===Other===
I'm no expert on these matters, and am not sure if this is the right place for such comments, but these are are a few ideas/issues that came to mind after reading this page:

'''Multiple (Image) geo-tagging'''

A single XHTML document might make reference to (or include images of) multiple locations. It is not clear from the documents on this site how thee are to be dealt with. Should an <IMG ... > be child of the < div class=geo > or should both tags be on the same level in a parent < div >?

* This is solved by using [[figure]]. [[User:TobyInk|TobyInk]] 10:54, 24 Feb 2008 (PST)

'''Geo-tagging areas and images of landscapes'''
Geo-tags specify a single point which occupies no space. It might be desirable to be able to define areas, or single locations in a more fuzzy manner. Sometimes, as in the case of pictures of landscapes, you might want to indicate the Point of View (i.e. the location of the viewer)

To accomplish all of this would require three additions to the geo microformat.
# a ''precision'' attribute: This can be generally useful as even GPS devices have a margin of error, which you might want to indicate. Otherwise it can be used to give an idea of the ''bounding sphere'' of a large object like a building.
# an ''area'' attribute: This could use a system similar to that used by [http://www.w3.org/TR/SVG11/paths.html#PathData SVG] for defining paths, but using lat and long for defining points. It is rather odd that, for example on wikipedia, entire countries or cities are identified by a single point.
# some sort of ''vector'' attribute: While the only use I can think of for this if for photos of landscapes, it would be good to be able to indicate that the Geographic information relates to the position of the viewer rather than the subject. The ''vector'' would indicate where the viewer (camera) is looking

I'm not sure whether the ''area'' and ''vector'' features are well suited to be extensions of ''geo'' or should be independent microformats. Particularly the ''vector'' might be better suited for inclusion in some 'EXIF-data equivalent micro format'. Unless of course it you can think of a use beyond photos of landscapes.

--[[User:Inkwina|Inkwina]] 01:54, 30 Nov 2007 (PST)

===Astronomical Coordinates===
Comments from [[User:StuartLowe|Stuart]]

Rather than limit the format to the surfaces of planets and moons, would it be possible to include astronomical coordinates for objects in celestial coordinate frames? This would be very useful for tagging astronomical objects (e.g. M41 or NGC 7027).

If you do not want to break the existing ''geo'' tag might I suggest the more generic term ''coord''?

As suggested already it is important to define a reference frame. The term ''coordinate-frame'' (or ''coord-frame'') might also avoid ambiguities that exist for the word ''reference''. In astronomical applications it is necessary to provide both a frame (e.g. FK5) and an equinox/epoch (e.g. 2000.0). Astronomical coordinate frames that are widely supported are: ICRS, FK5, FK4, ECL, GAL, SGAL.

===Harmonization with Geo URI and h-geo ===
As ''geo'' has always been supposed to match vCard's geo thing (currently RFC 5870), I believe we should change the "reference frame" class name to simply "p-crs". The semantics are pretty well-defined there.

==Related pages==
{{geo-related-pages}}

==See also==
[http://www.theregister.com/2006/12/19/nasa_4_google/ NASA shares space with Google] (2006-12-20)

h-geo

2021-02-17T00:54:50Z

Artoria2e5: /* Property Details */ spell out the name "geoid"

{{DISPLAYTITLE:h-geo}}
[[User:Tantek|Tantek Çelik]] (Editor)
----
<dfn style="font-style:normal;font-weight:bold">h-geo</dfn> is a simple, open format for publishing [http://en.wikipedia.org/wiki/WGS84 WGS84] geographic coordinates. h-geo is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-geo is the [[microformats2]] update to [[geo]]. It is most commonly used as part of an [[h-card]] or [[h-event]].

{{cc0-owfa-license}}

== Example ==
Here is a simple h-geo example:

<source lang=html4strict>

-27.116667,
-109.366667

</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-geo"
],
"properties": {
"latitude": [
"-27.116667"
],
"longitude": [
"-109.366667"
],
"name": [
"-27.116667, -109.366667"
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-geo</code>''' is a ''root class name'' that indicates the presence of an h-geo.

'''p-latitude''', '''p-longitude''' and '''p-altitude''' classnames define an element as a ''property'' of the h-geo.

See [[microformats2-parsing]] to learn more about property classnames.

== Properties ==
h-geo properties, inside an element with class '''h-geo''':
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude

All properties are optional.

== Status ==

'''h-geo''' is a microformats.org draft specification. Public discussion on h-geo takes place on [[h-geo-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-geo is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-geos up with classic [[geo]] classnames.

== Property Details ==

'''p-altitude''' refers to the distance in metres from the nominal sea level along the tangent of the earth’s curve, i.e. the geoid height. For more information refer to the [http://en.wikipedia.org/wiki/WGS84 WGS84] specification and the [https://en.wikipedia.org/wiki/Geo_URI_scheme geo URI scheme].

== FAQ ==

'''How should I mark up lat/long coordinates without them looking messy and confusing?'''

Unless your content is targeted at an audience with a high leg authoring '''p-latitude''' and '''p-longitude''' as plain numbers on a webpage may not be the best approach. In addition to this there may be accessibility issues due to the potentially long strings of numbers being read out.

You could present the coordinates in a more human-readable form, retaining the decimal coordinates inside data value attributes:

<source lang=html4strict>

<data class="p-longitude" value="-27.116667">27° 7′ 0″ S</data>,
<data class="p-latitude" value="-109.366667">109° 22′ 0″ W</data>

</source>

Alternatively you could not show coordinates at all and simply show a human-readable representation of the location, with the lat/long in value attributes of empty data elements.

== Examples in the Wild ==
* … add any h-geo examples you find in the wild

== Validating ==
{{h-spec-section-validating}}

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[geo]] classnames in addition to the more future-proof h-geo properties, for example:

<source lang=html4strict>

-27.116667,
-109.366667

</source>

=== Parser Compatibility ===
Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-geo" is found, don't look for an "geo" on the same element.

Compatibility root class name: geo

Properties: (parsed as p- plain text unless otherwise specified)

* latitude
* longitude

== Background ==

h-geo is based on the [http://en.wikipedia.org/wiki/WGS84 WGS84] standard, as well as existing [[geo]] specification, which was extracted from [[hCard]] in order to allow it to be used for applications other than contact information.

== See Also ==
* [[microformats2]]
* [[h-card]] and [[h-event]] often contain h-geo
* [[h-adr]] is used to mark up human-readable structured addresses

[[Category:Draft Specifications]]

geo-extension-waypoints

2021-02-17T00:51:31Z

Artoria2e5: move toc and close a code tag

= Geo Waypoint Trails =

An exploration of publishing information about sequences of geographical points using series of Geo (or other) microformats.
__TOC__
==Terms==

Conceptually, a collection of points, with no sequential relationship (the county towns of England, say, or all skyscrapers in New York), is deemed a collection (or set) of individual [http://en.wikipedia.org/wiki/Waypoint Waypoints]. A sequentially-ordered collection of points may be expressed as a '''track''' or a '''route'''. Tracks are a record of where a person has been, routes are suggestions about where they might go in the future. So, for instance, there might be timestamps for each point in a track (because someone is recording where ''and when'' they were there), but timestamps for each point in a route are unlikely to be provided, because the author is suggesting it, and nobody might ever have travelled it.

A route which ends at its beginning may also describe a boundary (also called a box or polygon). A boundary may be for an object or area on any scale, from a small building or plot of land to a continent, at any level of granularity.

It may therefore be appropriate to use a sequence of hCalendar microformats for tracks and of hCard microformats for routes, boundaries and waypoints.

== The Problem ==
To allow the publishing of series of waypoints in such a way that they are downloadable '''and''' that their ordering is parsable.

== Participants ==
*[[User:AndyMabbett|Andy Mabbett]]

== Real-World Examples ==

*[http://gpsnepal.com/waypoint.php?trek=everest Jiri to Everest Trek in Nepal]
**(or any other treks on that site)
**relevant mark-up: <code><nowiki><tr><td>Jiri Bus Park</td><td>27° 38.173'</td><td>86° 13.909'</td><td>1924</td></tr></nowiki></code> ("1924" is the elevation)
*http://members.aol.com/gpspage/waypoints.html
*[http://grothserver.princeton.edu/~groth/frs142s04/waypoint_hunt/waypoint_hunt.html Freshman Seminar Waypoint Hunt]
**relevant mark-up: <code><nowiki><tr><td>BENCH</td><td>40.33855</td><td>-74.66465</td><td><a href="bench.html"><img src="bench_c.gif" alt="[...]"></a></td></tr></nowiki></code>

===Collections===
*[http://www.poi66.com/ POI66]
**example: [http://www.poi66.com/maps/show_album?album=adelaarspad Amsterdam CS-Alkmaar CS walking route] (n.b long page; 612 waypoints)
**relevant mark-up: <s><code><nowiki><li><div>waypoint 10 Latitude 52.386165 Longitude 4.91199</div></li></nowiki></code></s>
<pre><nowiki>
<tr>
<td>10</td>
<td>
<div class="geo">
52.38616 
4.91199
</div>
</td>
<td ><a href="...">Waypoint 10</a></td>
<td >Amsterdam (3 km) <a title="" href="...">Map</a></td>
</tr>
</nowiki></pre>

===Other===
* [http://www.topografix.com/gpx.asp GPX] - XML schema for trails
**[http://en.wikipedia.org/wiki/GPX GPX on Wikipedia]
**example (extract):
<pre><nowiki>
<wpt lat="39.921055008" lon="3.054223107">
<ele>12.863281</ele>
<time>2005-05-16T11:49:06Z</time>
<name>Cala Sant Vicenç - Mallorca</name>
<sym>City</sym>
</wpt>
</nowiki></pre>

===Existing formats===
A number of other formats (which route/ track parsers may wish to export) are listed at http://www.gpsbabel.org/capabilities.html

===Tools===
*[http://www.gpsbabel.org/ GPS Babel] is a free command line utility (there is a GUI, but it has limited functionality) for converting between these formats.
*[http://www.gpsvisualizer.com/ GPS Visualizer] reads a variety of GPS formats <blockquote>including but not limited to: GPX, OziExplorer, Geocaching.com (.loc), IGC sailplane logs, Garmin Forerunner (.xml/.hst/.tcx), Timex Trainer (v1.3+), Cetus GPS, PathAway, cotoGPS, CompeGPS, TomTom (.pgl), IGN Rando (.rdn), Emtac Trine, Suunto X9/X9i (.sdf), NetStumbler/WiFiFoFum, GPSManager, MS Excel, and of course tab-delimited or comma-separated text</blockquote> and converts them, maps them, or outputs a graphical representation or plain-text list.

===Typical mandatory attributes===
*Latitude (WSG84, using decimal or degrees-minutes-seconds values)
*Longitude (ditto)
*text label

===Typical optional attributes===
*timestamp
*elevation
*image
*note ?
*url ?

==Issues==
*How to indicate that a set of waypoints is a specific, but unordered, collection (i.e. a set of all the metro stations in Paris, and another set of all the underground stations in London, may be published on the same page)
**KML uses "Folder" for each such set. e.g [http://tinyurl.com/32o6lm]
*How to sequence routes
**Perhaps using order in source code, ordered lists, [[hcalendar|hCalendar]] or [[hatom|hAtom]]?
**We could use [[hatom|hAtom]] and the feed category to distinguish between ordered, unordered and polygons.
***hAtom requires both an author and date, neither of which are required for routes or polygons. [[User:AndyMabbett|Andy Mabbett]]
*How to timestamp tracks (timestamps imply a chronological sequence)
**Perhaps using [[hcalendar|hCalendar]]?
*How to differentiate between a route (for example in the shape of a letter "U") and a boundary (or polygon) - in other words, to say whether or not, after the last point, the line returns to the first.
**Suppose we use <code>class="folder"</code> for a sequence (per KML; see above). We could have <code>class="folder route"</code> or <code>class="folder polygon"</code>.
*What can we learn, or use, from the GPX (XML schema for GPS data) specification?

==References==
*[http://dublincore.org/documents/dcmi-box/ DCMI Box Encoding Scheme]

== See Also ==
{{geo-related-pages}}

geo-extension-elevation

2021-02-17T00:50:03Z

Artoria2e5: mention where the component is

'''This page is historical as of 2012. [[vCard4]] introduced an 'altitude' component (via RFC 5870) to its GEO property which is now incorporated in [[h-card]] and [[h-geo]].''' - [[User:Tantek|Tantek]] 18:30, 23 December 2012 (UTC)

{{DISPLAYTITLE: Geo Elevation }}
An exploration of adding elevation (altitude) information to geo data.

== The Problem ==
Publishers of elevation information on the web could make additional use of this information (e.g. in Google Earth) with a standard format.

Altitude data in waypoints is particularly used in aviation.

== Real-World Examples ==
*See [[geo-elevation-examples]]

==Issues==
*Metric (ISO) measurements, or feet/ yards/ whatever?
**See [[measure]]

== See Also ==
{{geo-related-pages}}