geo-brainstorming-fr

From Microformats Wiki
Revision as of 23:00, 29 June 2007 by ChristopheDucamp (talk | contribs) (création)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Brainstorming Geo

Cette page traite de geo à la fois comme un microformat autonome et comme un sous-ensemble de hCard. Voir aussi hcard-brainstorming.


améliorations Geo

J'ai (Tantek) vu des exemples où il existe une présentation visible/cliquable d'un point sur une crte, et le désir d'inclure l'information lisible par une machine geo avec le même élément, par ex. quelque chose comme : 

<abbr class="geo" title="machine-readable-geo-info">
 point lisible par un humain/cliquable sur une carte
</abbr>

Mais pour faire ça nous devons spécifier une syntaxe pour placer tant la latitude et la longitude dans l'attribut title comme l'info-geo-lisible-par-la-machine.

Heureusement, il existe déjà une syntaxe pour cela, dans la RFC vCard 2426 3.4.2 : 

   Type value: A single structured value consisting of two float values
   separated by the SEMI-COLON character (ASCII decimal 59).

   Type special notes: This type specifies information related to the
   global position of the object associated with the vCard. The value
   specifies latitude and longitude, in that order (i.e., "LAT LON"
   ordering).

...

   Exemple type :

        GEO:37.386013;-122.082932

Par conséquent : 

<abbr class="geo" title="37.386013;-122.082932">
 Mountain View, CA
</abbr>

Je pense qu'il n'y a vraiment pas à se casser la tête, parce que les règles pour parser "geo" sotn simplément modifiées en :

latitude longitude raccourci

Si une propriété "geo" manque des sous-propriétés explicites "latitude" et "longitude", alors la propriété "geo" est traitée comme toute autre propriété de chaîne (à savoir les règles suivantes pour parser <abbr title>, <img alt> etc.), où cette chaîne de valeur a la même syntaxe littérale spécifiée dans RFC 2426 section 3.4.2 : une valeur unique structurée constitué de deux valeurs flottantes séparées par le caractère POINT VIRGULE (ASCII decimal 59), spécificant la latitude et la longitude, dans cet ordre d'apparition.

liens geo

En outre, les personnes peuvent publier des Google Maps comme ça :

<a href="http://maps.google.com/maps?q=37.386013+-122.082932">ce spot</a>

ou des liens vers Yahoo! Maps comme ceci :

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

Est-ce que ça vaut la peine de permettre à cela d'être un geo ?

Je soulève ça pour m'assurer que ce sera considéré.

Néanmoins, mon premier sentiment est NON pour deux raisons :

  1. Aucun exemple de ce type n'a été documenté ou vu à cette heure (je n'en ai certainement vu aucun).
  2. Cela sous-tendrait des exigences supplémentaires de parsage qui vont surtout aller pour être spécifiques à un site/domaine, et encoder une syntaxe de paramètre de requête particulière dans un format semble être une mauvaise idée (contre le principe de décentralisation).

Ceci pourrait être mitigé si les services de cartographie acceptait simplement la syntaxe littérale vCard GEO "37.386013;-122.082932", par ex. http://maps.google.com/maps?q=37.386013;-122.082932 (qui ne fonctionne pas à cette heure) puis nous pourrions produire une règle simple comme pour les hyperliens, parser l'attribut href pour une valeur geo à la fin du href, délimitée avant la valeur par a "=" (ou peut-être "/" pour des services qui utilisent des URLs plus amicales).

  • considérer aussi <a href="http://www.rhaworth.myby.co.uk/oscoor_a.htm?SJ870099_region:GB_scale:25000" title="52.6866;-2.1937">SJ870099</a> qui est largement utilisé (à cette heure sans attribut geo-title) (Wikipedia, et al). Peut-être que nous devrions aussi supporter title="various maps of 52.6866;-2.1937" de façon que l'attribut title puisse être utilisé comme ceci était initialement conçu.

altitude

Quelques types ont demandé "altitude" comme une extension pour GEO. Actuellement, nous rejetons toutes les extensions propriété/valeur vers hCard/vCard.

radius/zoom

Kevin Marks a demandé "radius" ou "zoom" comme une extension pour GEO. Actuellement nous rejetons toutes les extensions propriétés/valeurs vers hCard/vCard.

ISO 19136

When it comes to anything geospatial, any unadorned / simple encoding must remain upwardly-compatible with the more sophisticated GML schema (Geography Markup Language ) which is also known as ISO 19136. This is so that all the fundamental nuances underpinning geocoding ( different datums, different projections, elevation, etc etc ) can ultimately ( or sooner ? ) be completely accounted for.

If you don't know/supply your Coordinate Reference System CRS identifier, your location could fall 100s of metres away from the position intended ie plot in the wrong location on a map. Appendix B of draft ISO/DIS 6709 highlights the variation among three commonly used systems.

Le Standard Draft International ISO/DIS 6709 spécifie la représentation standard de la localisation d'un point géographique par des coordonnées. La section 6.3 note les éléments requis pour la localisation d'un point géographique :

ISO 6709

The Geo field in the vCard format seems to be based on ISO 6709:1983.

The International Standard is being updated, ISO/DIS 6709, to allow for depths as well as heights and to include Coordinate Reference System (CRS) identification. Voting on the revised standard finishes on the 15th February 2007.

Section 6.3 of ISO/DIS 6709 notes the elements required required for geographic point location:

In this International Standard, geographic point location shall be represented by five elements:

  • a coordinate reference system identification;
  • coordinate representing “x” horizontal position such as latitude;
  • coordinate representing “y” horizontal position such as longitude;
  • for three-dimensional point locations, a value representing vertical position through either height or depth;
  • metadata associated with geographic point location(s) (ISO 19115)

The CRS identifier is important otherwise your location could fall 100s of metres away from the position intended.

Annex H details the ISO standard for text string representation of point location.

H.6 Format

H.6.1 Elements shall be combined in a point location string in the following sequence:

a) Latitude

b) Longitude

c) if represented, height or depth

d) Coordinate Reference System identifier


H.6.2 The number of digits for latitude, longitude and height (depth) shall indicate the precision of available data.


H.6.3 There shall be no separator between the elements for latitude, longitude, height (depth) and CRS. NOTE The use of designators "+", "-" and "CRS" preceding the value part of each element permits the recognition of the start of each element and the termination of the previous one.


H.6.4 The point location string shall be terminated. The terminator character shall be a solidus (/), unless otherwise specified in the documentation associated with interchange.

It differs from the notation of vCard, for example.


If ISO6709 is used, it is likely to be able to write as follows. 

examples
<abbr class="geo" title="+40-075CRSxxxx/">
 Point represented as Degrees
</abbr>

<abbr class="geo" title="+401213.1-0750015.1+2.79CRSxxxx/">
 Point represented as Degrees, minutes, seconds and decimal seconds, with +2.79 a height or depth as defined through the CRS.
</abbr>

Encodages Geo

Il est important que chaque fois que le lieu est décrit, que ce puisse être produit de la façon la plus interopérable. Un nombre relativement faible d'encodages est requis qui servira les besoins d'une large gamme de communautés d'information et d'utilisateurs. Chez http://www.georss.org/ deux schémas relativement simples ont été publiés ; l'un pour WGS84 latitude/longitude ( dénommé 'simple'), et les autres dispositions pour ceci ET les systèmes de référence de coordonnées autres que le WGS84 latitude/longitude ... à partir desquels il existe une multitude - aussi ceci est un argument pour des encodages simples qui soient en compatibilité ascendante avec le schéma plus sophistiqué GML ( Geography Markup Language ).

ISO 19115

ISO 19115:2003 defines the schema required for describing geographic information and services. It provides information about the identification, the extent, the quality, the spatial and temporal schema, spatial reference, and distribution of digital geographic data.

Catégoriser les lieux

Peut-être que la catégorisation des lieux permettrait des mashups cartographiques d'information microformatée ? Par exemple, montre-moi une carte des 'lieux de culte' ou 'banques' les plus proches. Ce fragment extrait d'un schéma d'application illustre une étendue de catégories de places.

http://www.linz.govt.nz/resources/esa-appl-schema-v1-9-5/esa-46.html#1804

UN/LOCODEs

UN/LOCODE (United Nation/LOcation CODE) est un code géographique élaboré et géré par la Commission économique des Nations unies pour l'Europe (CEE-ONU ou UNECE en anglais), un organisme de l'Organisation des Nations unies. Il fournit un moyen unifié d'identifier des localisations géographiques à travers des définitions de fonctions. Ce peut être utile si le microformat géo pouvait le supporter. http://fr.wikipedia.org/wiki/UN/LOCODE

Implémentations Geo

GPX

Les parseurs pourraient convertir Geo en GPX ("GPS eXchange Format"), un schéma XML conçu pour transférer les données GPS entre les applications logicielles (et les terminaux GPS), qui peut être utilisé pour décrire des waypoints, des tracks et des routes. Voir GPX sur Wikipedia. Andy Mabbett 11:44, 3 Apr 2007 (PDT)

Great circle distance

Un parseur pourrait offrir l'option de sélectionner deux Geo-uFs provenant d'une page, ou l'unique Geo sur chacune des deux pages, et calculer les distance entre euxm. Andy Mabbett 04:36, 18 Apr 2007 (PDT)

  • Exemple de calculateurs en ligne : [1], [2]


Pages en Rapport

Retrieved from "http://microformats.org/wiki/index.php?title=geo-brainstorming-fr&oldid=21249"