Logotipo do OpenStreetMap OpenStreetMap

Simple File Format

Publicado por Stefano Fraccaro o 29 de Outubro de 2013 en 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)
Icona de correo electrónico Icona de Bluesky Icona de Facebook Icona de LinkedIn Icona de Mastodon Icona de Telegram Icona de X

Parola

Comentario de Zverik no 29 de Outubro de 2013 ás 07:57

Are you reinventing o5m?

Comentario de Stefano Fraccaro no 30 de Outubro de 2013 ás 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?

Inicia sesión para deixar un comentario