OpenStreetMap : Formats ...

Vu l'évolution un peu chaotique du projet, on a eu une prolifération de formats différents, qui répondaient aux besoins différents. Officiellement ce qui domine, c'est la catégorie XML. C'est un méta-format, non pas un format, conçu pour être textuel, lisible, et facile à analyser et convertir par des outils existants... Le Schéma officiel XSD pour ce format n'existe toujours pas, le descriptif DTD unique non plus, même si la standardisation progresse.

Une classe de problèmes avec ces formats vient du fait que tout ceci n'est pas seulement pour la visualisation. Coder les lignes (ou polygones), marqueurs et autres icônes, textures (remplissage avec des couleurs, ou dégradés, ou motifs hachurés) peut utiliser des techniques différentes, mais largement équivalentes.

Par contre, le traitement d'une zone comme un graphe qui facilite la navigation : les connexions entre les routes, les rues à sens unique, les propriétés comme des limites de poids ou de la hauteur des véhicules, etc. – tout ceci jusqu'aujourd'hui reste évolutif.

Voici un petit catalogue de formats exploités. Quelques détails viendront plus tard.

• Fichiers .osm "standard". C'est un format XML, contenant surtout des éléments primitifs, comme des noeuds (localisations nommées ; dans la base globale il y a 3 milliards de noeuds <node id="2988" lat="54.0901" lon="12.2516" user="SvenHRO" .../> ...), les "ways", +/- équivalents aux polylines ou polygones, et relations, qui décrivent comment les éléments coopèrent, quel est leur rôle. Aussi des "tags". Voici un échantillon du format .osm. On y reviendra.
  
  Le format XML "canonique" est très "creux" et redondant ; les balisent consomment beaucoup d'espace et de temps (transmission et décodage). Plusieurs autres variantes sémantiquement équivalents ont vu le jour.


• Level0L, restreint, sans balises décodables intuitivement, par ex. node 4272: 54.0901, 12.2516 ... (id, latitude, longitude), etc. Parfois utilisé comme un format plus facile à éditer manuellement.


• Format OSM JSON (et même quelques uns...). Puisque JSON est un format hiérarchique moins bavard que l'XML, et est considéré comme "natif" pour Javascript, et est similaire aux dictionnaires en Python, par ex. :
  {"type": "node", "id": 1, "lat": 2.0, "lon": -3.0, "tags": {"highway": "bus_stop", "name": "Albert Camus"}}, etc., il est souvent utilisé comme intermédiaire, pour le stockage local. Dans le monde Java EE, où on programme et accède aux services Web, JSON fait la concurrence aux protocoles de sérialisation XML (SOAP, etc.). En général, si vous êtes déjà ennuyés, sachez que la programmation distribuée, nomade, etc., c'est surtout la communication, ce qui implique la sérialisation des données hiérarchiques.


• PBF (Protocolbuffer Binary Format), initialement inventé par Google, devenu un de plus populaires pour le transfert et le stockage, car économique (la moitié de OSM gzippé). Il faut lui consacrer quelques mots, car c'est un de rares formats binaires considérés portables, bien documenté, et adapté à la multitude des langages de programmation (C, C++, Python, Java, Ruby, et quelques autres). Ceci va au delà de OSMap, et devient un des formats populaires de communication avec les services Web de toute sorte.
  Pour savoir comment une entité (une personne, un croisement, un parc) doit être codé, on stocke sa définition dans un fichier xxx.proto, par ex.

  message Person {
    required string name = 1;
    required int32 id = 2;
    optional string email = 3;
    enum PhoneType {
      MOBILE = 0; HOME = 1; WORK = 2;}
  

    message PhoneNumber {
      required string number = 1;
      optional PhoneType type = 2 [default = HOME];}
    repeated PhoneNumber phone = 4;}
  message AddressBook {
    repeated Person person = 1;}
  

  et ceci, "compilé" par un programme spécial, engendre une librairie adaptée à votre langage préféré, permettant de coder et de décoder des fichiers binaires. Vous faites dans votre programme, disons, jean=Person(); jean.name="Jean", etc. et le système produit d'une manière cohérente les objets Python, et peut engendrer les fichiers binaires PBF à partir de ces données.
  
  Le format PBF a moins de 5 ans, donc son usage dans d'autres branches de l'informatique communiquante prendra du temps.
  
  Pour l'instant vous pouvez télécharger un petit programme osmconvert pour votre plate-forme ; souvent les fichiers textuels .osm distribués par des institutions opérant avec ces données, sont reconstruits des PBFs grâce à ce logiciel. (Pour la zone Caennaise le raport de tailles entre .osm.zip et .pbf est 2/1 ; pour le fichier textuel .osm non-compressé : 16/1. Les PBFs ne se compressent plus.)
• Shapefiles.