<html>
<head>
</head>
<body>Sorry Mateusz, I think I sent the last one only to you. 
        <div><br />
                </div>
        <div>I have not had time to do any testing, but I doubt json format can be that slimmed or fast.
                <div><br />
                        </div>
                <div>It is not even handling relative coordinates as I understand. </div>
                <div>The "header" of each geom also seems to be both the word "type", the type as characters and the word "coordinates"</div>
                <div><br />
                        </div>
                <div>the header of twkb is 6 bytes for a POINT including, "id", "number of dimensions", "type" and "precision". And the endianess flag.</div>
                <div>the header of a LINESTRING is 10 bytes also including "number of points"</div>
                <div>and the polygon has also number of rings so another 4 bytes. </div>
                <div>and 4 more bytes for number of points in each ring</div>
                <div><br />
                        </div>
                <div>So a one ring polygon has a header of 14 bytes, including 4 bytes of id.</div>
                <div><br />
                        </div>
                <div><br />
                        </div>
                <div>It also seems that it gives a good speed up on the server that the amount of data is stripped directly.</div>
                <div><br />
                        </div>
                <div>I did a test doing</div>
                <div><br />
                        </div>
                <div>CREATE TABLE test AS</div>
                <div>SELECT ST_AsBinary(geom) FROM my_table;</div>
                <div><br />
                        </div>
                <div>It took 6.5 seconds and gave a 330 mb table.</div>
                <div><br />
                        </div>
                <div>The same thing with ST_AsTWKB without decimals took 3.5 s and gave 103 mb table.</div>
                <div><br />
                        </div>
                <div>So the overhead in creating the twkb is smaller than the cost of handling the extra data in the database.</div>
                <div>Of course the discwriting is also a player here, but that disc is ssd and somewhere the data should go anyway.</div>
                <div><br />
                        </div>
                <div>How heavy the reading is on the client side is also a factor. I guess my reader can be optimized, but it seems to perform well. It is no parsing of strings, just reading binary data with some rules about how long a coordinate is.</div>
                <div><br />
                        </div>
                <div>But I will try to get some time this evening to compare different formats.</div>
                <div><br />
                        </div>
                <div><br />
                        </div>
                <div>Thanks</div>
                <div><br />
                        </div>
                <div>Nicklas</div>
                <div><br />
                        </div>
                <div><br />
                        </div>
                <div><br />
                        </div>
                <div><br />
                        2013-03-06 Mateusz Loskot wrote:<br />
                        <br />
                        On 5 March 2013 23:27, Nicklas Avén 
                        <nicklas.aven@jordogskog.no>wrote:<br />
                                >><br />
                                >> I tested on a dataset with 10000 linestrings. With wkb the client<br />
                                >> recived 2.14 mb. With twkb and 1 decimal precision 670 kb and twkb with<br />
                                >> integer values 420 kb.<br />
                                ><br />
                                >Is this dedicated to Web clients?<br />
                                >Have you considered comparing with "Content-Encoding: gzip" on server?<br />
                                ><br />
                                >Best regards,<br />
                                >--<br />
                                >Mateusz Loskot, http://mateusz.loskot.net<br />
                                ><br />
                                ></nicklas.aven@jordogskog.no></div></div>
</body>
</html>