Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>A hexdump of the first 30 bytes (I did "od -H -N 30 elevmap.assoc") looks like this:</p> </blockquote> <pre><code>0000000 20202020 20202020 30303237 20202020 0000020 20202020 30363320 4f4d2030 0000414c 0000036 </code></pre> <p>These are obviously stored in little endian so you should reverse each byte sequence. Here, I have translated that to ASCII for you:</p> <pre><code>0000000 20 20 20 20 20 20 20 20 37 32 30 30 20 20 20 20 _ _ _ _ _ _ _ _ 7 2 0 0 _ _ _ _ 0000020 20 20 20 20 20 33 36 30 30 20 4d 4f 4c 41 _ _ _ _ _ 3 6 0 0 _ M O L A </code></pre> <blockquote> <p>A hexdump of the first 30 bytes after the header ("od -H -j 14400 -N 30 elevmap.assoc", please let me know if I'm misunderstanding this) looks like this:</p> </blockquote> <pre><code>0034100 0e970e93 0ea50e9d 0ea50ea5 0ea50ea5 0034120 0ea50ea5 0ea40ea4 0ea20ea3 00000ea2 </code></pre> <p>Header says that there are 7200 x 3600 INT values. How big is INT? If INT is as big as <code>int</code> on most Unix systems (4 bytes) then the total size of the file should be <code>7200 x 3600 x 4</code> or almost 99 MiB. You say it is 49 MiB hence either there is a compression being used (unlikely) or INT is 16-bit (more likely). Strong evidence for the latter is what you get from this second <code>od</code> - <code>0e970e93</code> looks very much like <code>0e97</code> and <code>0e93</code> being wrongly concatenated in a 32-bit integer. One would expect from a topographical map that neighbouring values should not change abruptly (except at the borders of some deep vertical trench or a steep mountain wall). This is also consistent with the fact that values are within the range of <code>short int: [-32768, 32767]</code>.</p> <p>With this knowledge in place the above dump should be read as:</p> <pre><code>0034100 0e93 0e97 0e9d 0ea5 0ea5 0ea5 0ea5 0ea5 +3731 +3735 +3741 +3749 +3749 +3749 +3749 +3749 0034120 0ea5 0ea5 0ea4 0ea4 0ea3 0ea2 0ea2 +3749 +3749 +3748 +3748 +3747 +3746 +3746 </code></pre> <p>Now you only have to figure out if X-major or Y-major data storage was used. In my experience most data processing tools follow the Fortran column-major order and if data is <code>DATA(X,Y)</code> then X should be the leading dimension, i.e. consequitive data values should be <code>DATA(1,Y)</code>, <code>DATA(2,Y)</code>, <code>DATA(3,Y)</code>, ..., <code>DATA(1,Y+1)</code>, <code>DATA(2,Y+1)</code>, etc. You can always plot the data using PIL or any other image manipulation package for Python and see if you get something akin a topographic map or a messy whatever.</p> <p>If unpacking the data with <code>struct.unpack()</code> as suggested by mgilson, you should be using the <code>h</code> format for signed short integer values:</p> <pre><code>data = struct.unpack('%dh' % (7200*3600), f.read(7200*3600*2)) </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POAssociate (.assoc) binary file structure / probing unknown file structure
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USHristo Iliev
    1. USHristo Iliev
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POAssociate (.assoc) binary file structure / probing unknown file structure
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you so much, that's a great explanation.
      singulars
      1. PO
      1. USEddyTheB
    2. COFor completeness I'll post my own answer with the code that read the file for me.
      singulars
      1. PO
      1. USEddyTheB
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload