FR:OSM XML

Basics

XML est un meta format fournissant un fichier lisible par les êtres humains. Plusieurs formats de fichiers utilisent ces structures HTML en arbre pour embarquer leurs données, par exemple : SVG, ODT, etc.

avantages

inconvénients

lisible par les humains grâce à sa structure claire indépendant de la machine en raison de définitions précises, par exemple les jeux de caractères, des définitions de schéma XML, DTD, etc. ready to use parsers for general XML that can be customized for a concrete file format prêt à l'emploi pour les parseurs XML général qui peut être personnalisé pour un format de fichier concret bon taux de compression

de très gros fichiers peut être nécessaire de décompresser avant le parsing prend beaucoup de temps

Format de fichier OSM XML

Les principaux outils de l'univers OSM utilisent le format XML suivant cette définition de schéma XML, qui n'était au départ utilisé que par l'API. Fondamentalement, il s'agit d'une liste d'exemples de nos primitives de données (nœud, chemin et relations) que sont l'architecture du modèle de l'OSM.

Voici un court exemple d'un fichier complet OSM XML

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.0.2">
 <bounds minlat="54.0889580" minlon="12.2487570" maxlat="54.0913900" maxlon="12.2524800"/>
 <node id="298884269" lat="54.0901746" lon="12.2482632" user="SvenHRO" uid="46882" visible="true" version="1" changeset="676636" timestamp="2008-09-21T21:37:45Z"/>
 <node id="261728686" lat="54.0906309" lon="12.2441924" user="PikoWinter" uid="36744" visible="true" version="1" changeset="323878" timestamp="2008-05-03T13:39:23Z"/>
 <node id="1831881213" version="1" changeset="12370172" lat="54.0900666" lon="12.2539381" user="lafkor" uid="75625" visible="true" timestamp="2012-07-20T09:43:19Z">
  <tag k="name" v="Neu Broderstorf"/>
  <tag k="traffic_sign" v="city_limit"/>
 </node>
 ...
 <node id="298884272" lat="54.0901447" lon="12.2516513" user="SvenHRO" uid="46882" visible="true" version="1" changeset="676636" timestamp="2008-09-21T21:37:45Z"/>
 <way id="26659127" user="Masch" uid="55988" visible="true" version="5" changeset="4142606" timestamp="2010-03-16T11:47:08Z">
  <nd ref="292403538"/>
  <nd ref="298884289"/>
  ...
  <nd ref="261728686"/>
  <tag k="highway" v="unclassified"/>
  <tag k="name" v="Pastower Straße"/>
 </way>
 <relation id="56688" user="kmvar" uid="56190" visible="true" version="28" changeset="6947637" timestamp="2011-01-12T14:23:49Z">
  <member type="node" ref="294942404" role=""/>
  ...
  <member type="node" ref="364933006" role=""/>
  <member type="way" ref="4579143" role=""/>
  ...
  <member type="node" ref="249673494" role=""/>
  <tag k="name" v="Küstenbus Linie 123"/>
  <tag k="network" v="VVW"/>
  <tag k="operator" v="Regionalverkehr Küste"/>
  <tag k="ref" v="123"/>
  <tag k="route" v="bus"/>
  <tag k="type" v="route"/>
 </relation>
 ...
</osm>

Voir Data Primitives pour plus de détails sur les catégories d'objets.
Voir Map Features pour savoir comment les objets du monde réel sont modélisés et catégorisés.

La structure est la suivante :

• une entête XML indiquant le codage des caractères UTF-8 pour le fichier
• un élément osm, contenant la version de l'API (et donc les fonctions utilisées) et le générateur qui a généré ce fichier (par exemple, un éditeur de l'outil)
  • un bloc de nœuds contenant en particulier l'emplacement dans le système de référence WGS84
    • les étiquettes de chaque nœud
  • un bloc de chemins
    • les références à ses nœuds pour chaque chemin
    • les étiquettes de chaque chemin
  • un bloc de relations
    • les références à ses membres pour chaque relation
    • les étiquettes de chaque relation

Voir les pages OSM XML/XSD et OSM XML/DTD pour plus de détails sur les tentatives de définir le format dans ces langues.

Suppositions

Si vous développez des outils utilisant ce format, vous pouvez être sûr que :

• les blocs seront dans cet ordre
• les limites seront dans les données API et JOSM

Vous ne pouvez pas être sûr que :

• les blocs sont là (par exemple il peut y avoir seulement des nœuds, et pas de chemins)
• les blocs sont triés
• les identifiants des éléments ne sont pas négatifs (pas dans tous les fichiers osm. Les identifiants négatifs sont utilisés par les éditeurs de nouveaux éléments)
• les éléments doivent contenir des étiquettes (De nombreux éléments ne le font pas. Vous pourrez même tomber sur des nœuds non marqués non connectés)
• visible only if false and not in Planet.osm
• l'identifiant ou le nom d'utilisateur est présent (pas toujours, à cause des modifications anonymes au tout début)
• les groupes de modifications ont un attribut pour num_changes (cela a été abandonnée à partir de l'outil d'export histoire en raison d'incohérences)
• l'ordre des versions est séquentiel (il n'y a pas obligation de l'être)

JOSM utilise un attribut « action » au lieu de timestamp, version ou de modifications pour les nouveaux objets

Certaines saveurs pourraient avoir d'autres restrictions.