OpenStreetMap

Simple File Format

Posted by Stefano Fraccaro on 29 October 2013 in Italian (Italiano).

Descrizione

Sto lavorando su un nuovo formato file chiamato “Simple File Format” che dovrebbe risultare facile da implementare e veloce da analizzare. Il formato non è estendibile come il ProtocolBuffer di Google ma include un indicatore di versione nel file codificato.

Concetti di base

Nelle intestazioni è indicato il byte di partenza dei nodi, delle way e delle relazioni per saltare direttamente alla sezione che interessa senza dover analizzare tutto il file. Per ogni elemento base (nodi, way, rel.) è prevista una suddivisione in blocchi detta “stride” in modo che sia possibile utilizzare più thread in parallelo per l’analisi del file. La lunghezza della stride è variabile (parametro opzionale in fase di codifica) e deve essere letta dall’intestazione del file codificato. Ogni elemento viene salvato sequenzialmente e non viene fatta distinzione fra attributi e sottonodi.

struttura

  • 1 byte = versione maggiore della struttura file usata
  • 1 byte = versione minore della struttura file usata
  • 8 bytes = punto partenza nodi
  • 8 bytes = punto partenza way
  • 8 bytes = punto partenza relation
  • 8 bytes = lunghezza stride

  • 4 bytes = lunghezza blocco nodo
  • 8 bytes = id
  • 8 bytes = latitudine
  • 8 bytes = longitudine
  • 4 bytes = lunghezza elenco valori
  • N bytes = elenco valori separati da chr(1)
  • 4 byte = lunghezza elenco chiavi
  • N bytes = elenco chiavi separati da chr(1)
  • 4 bytes = lunghezza blocco way
  • 8 bytes = id
  • 4 bytes = lunghezza elenco id nodi (multiplo di 8)
  • N bytes = elenco valori in blocchi da 8 bytes
  • 4 bytes = lunghezza elenco valori
  • N bytes = elenco valori separati da chr(1)
  • 4 byte = lunghezza elenco chiavi
  • N bytes = elenco chiavi separati da chr(1)
  • 4 bytes = lunghezza blocco relation
  • 8 bytes = id
  • 4 bytes = lunghezza elenco valori
  • N bytes = elenco valori separati da chr(1)
  • 4 byte = lunghezza elenco chiavi
  • N bytes = elenco chiavi separati da chr(1)

Discussion

Comment from Zverik on 29 October 2013 at 07:57

Are you reinventing o5m?

Comment from Stefano Fraccaro on 30 October 2013 at 04:35

I haven’t seen o5m before your comment … thanks ;-) sff is simpler than 05m and it can be processed with multiple cores. The encoder is already done, now I’m workiing on search tool. For example: 4.1 Gb OSM file » 3.0 Gb Sff file search for “house” value take 55 seconds with 1 core, 13 seconds with 6 core (intel i7)

At the moment I have not optmized anything : it just works. I will stop myself if other tools like osmosis or 05m can do the same work faster than sff. Can 05m use mutiple cores when searching data?

Log in to leave a comment