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?