<html>
<head>
</head>
<body><br />
>Not sure that "decimal digits" makes sense as a parameter as<br />
>the semantic of those digits really depends on the width/height<br />
>of the layer extent. Should the function maybe just take care<br />
>of the encoding leaving quantization to ST_SnapToGrid ?<br />
>
<div><br />
</div>
<div><br />
</div>
<div>The reason I added that parameter is that all datatypes are integers and to make it possible to store lat long values it has to do some multiplacation and dividing on server side vs client side. </div>
<div><br />
</div>
<div>I just uploaded some data to:</div>
<div><br />
</div>
<div>http://178.79.156.122/twkb/twkb.htm</div>
<div><br />
</div>
<div>In google the developer tools is a way to see how much data is transported. The binary stream are supposed to be compressed with z-lib to gzip by lighttpd, but I don't know enough about that to confirm it right now.</div>
<div><br />
</div>
<div>I also added a php page to just send it as geojson. </div>
<div>http://178.79.156.122/twkb/json.php</div>
<div><br />
</div>
<div>since it renders all the text on the screen the time is not comparable to the twkb example, but the size (compressed with gzip, I think ...) is about 4.8 mb as sent and 17 mb at cliant according to chrome, and the twkb axample generates 1.5 mb of network-traffic.</div>
<div><br />
</div>
<div>The data set is quite detailed border of regions in Norway. It demonstrates that the design is not optimal since it is jumbing betwen relative coordinates over 127 meters (stored as Int8) and coordinates more apart. The cost of changing size is to big now and it does the change without checking the next comming coordinate. To get that handling better is quite easy I think.</div>
<div><br />
</div>
<div>Thanks</div>
<div><br />
</div>
<div>Nickals</div>
<div><br />
</div>
<div><br />
</div>
</body>
</html>