Logotip de l'OpenStreetMap OpenStreetMap

Simple File Format

Publicat per Stefano Fraccaro el 29 Octubre 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 correu electrònic Icona de Bluesky Facebook Icon Icona de LinkedIn Icona de Mastodon Icona de Telegram Icona de X

Discussió

Comentari de Zverik el 29 Octubre 2013 a les 07.57

Are you reinventing o5m?

Comentari de Stefano Fraccaro el 30 Octubre 2013 a les 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 sessió per a fer un comentari