<div>Hello Peter,</div><div><br></div><div>The approach of scaling values into integers, if I recall correctly, is also used in the transfer protocol for ArcSDE. I have considered this as an option and was wondering if any of the non-ESRI datasources used that approach. </div>
<div><div><br></div><div>I have seen the second method you describe being used for avoiding "small feature shakiness" (yes, I made that word up) in 3D globes when zoomed-in too close.</div><div><br></div><div>Thank you Peter for the response - I will definitely keep these options in the bag of tricks if I end up having to implement a new datasource.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>- Ragi</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, Jul 6, 2010 at 11:18 PM, Peter J Halls <span dir="ltr"><<a href="mailto:P.Halls@york.ac.uk">P.Halls@york.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Ragi,<br>
<br>
ESRI implemented something on these lines in the Personal Geodatabase, in an attempt to overcome data value restrictions in Access: they scaled the values into integers. This approach would work for the application you describe, but loses precision further from the origin. The scaling factor is stored separately.<br>
<br>
For some work I did, many years ago now, when working with a graphics package that could only handle 16bit coordinate values, I held the most significant part of the eastings and northings separately, subtracting it from the actual coordinates and adding it back on when I required the full value. This is simple and would work well for your application.<br>
<br>
Best wishes,<br>
<br>
Peter<br>
<br>
Ragi Burhum wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
Hello there,<br>
<br>
The other day I got a question from someone that wanted to store a<br>
relatively small amount of point features (~31K) that are close to each<br>
other in a 'highly compressed' format. He wants to be able to query features<br>
by proximity using coords. The reason for this requirement is that he wants<br>
to be able to use it in embedded devices with limited memory. Yes I know<br>
memory is cheap and keeps getting cheaper, but I still thought it was an<br>
interesting question.<br>
<br>
I can think of many ways to create a custom binary format to do such a<br>
thing, but I wanted to check the brain collective to hear what people<br>
thought. Of course spatialite and their new "compressed geometries" feature<br>
will come up in this conversation. I already sent an e-mail to that group<br>
for details about that :)<br>
<br>
I want to be able to avoid reinventing the wheel, so what are your thoughts<br>
on this?<br>
<br>
Thanks,<br>
<br>
- Ragi<br>
<br>
<br>
<br></div></div>
------------------------------------------------------------------------<div class="im"><br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></blockquote>
<br><div><div></div><div class="h5">
-- <br>
--------------------------------------------------------------------------------<br>
Peter J Halls, GIS Advisor, University of York<br>
Telephone: 01904 433806 Fax: 01904 433740<br>
Snail mail: Computing Service, University of York, Heslington, York YO10 5DD<br>
This message has the status of a private and personal communication<br>
--------------------------------------------------------------------------------<br>
</div></div></blockquote></div><br></div></div>