OpenStreetMap-ан логотип OpenStreetMap

Simple File Format

Арахецна Stefano Fraccaro 29 October 2013, мотт: 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)
Email icon Bluesky Icon Facebook Icon LinkedIn Icon Mastodon Icon Telegram Icon X Icon

Дийцар

Коммент Zverik 29 October 2013 07:57

Are you reinventing o5m?

Коммент Stefano Fraccaro 30 October 2013 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?

ЧугӀо, коммент йитарна