[gdal-dev] highly compressed vector format for points

[Ragi Burhum]

Thanks for the info Stephen.

On Jul 7, 2010, at 10:28 AM, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:

> RoadMap http://roadmap.sourceforge.net/
> 
> uses a similar compression trick of storing data in spatial "squares"
> Each square has an origin of x,y, and all coordinates within the square are stored relative to the square origin. So depending on your needed resolution you might be able to compress an arbitrary x,y into a reference to a square and 2 ints for x,y position in the square. If all data the is fullly in the square is maintained in a list, then you only need to store the reference to the square once for the list.
> 
> -Steve
> 
> Ragi Burhum wrote:
>> Hello Peter,
>> 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. 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.
>> 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.
>> Thanks,
>> - Ragi
>> On Tue, Jul 6, 2010 at 11:18 PM, Peter J Halls <P.Halls at york.ac.uk <mailto:P.Halls at york.ac.uk>> wrote:
>>    Ragi,
>>      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.
>>      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.
>>    Best wishes,
>>    Peter
>>    Ragi Burhum wrote:
>>        Hello there,
>>        The other day I got a question from someone that wanted to store a
>>        relatively small amount of point features (~31K) that are close
>>        to each
>>        other in a 'highly compressed' format. He wants to be able to
>>        query features
>>        by proximity using coords. The reason for this requirement is
>>        that he wants
>>        to be able to use it in embedded devices with limited memory.
>>        Yes I know
>>        memory is cheap and keeps getting cheaper, but I still thought
>>        it was an
>>        interesting question.
>>        I can think of many ways to create a custom binary format to do
>>        such a
>>        thing, but I wanted to check the brain collective to hear what
>>        people
>>        thought. Of course spatialite and their new "compressed
>>        geometries" feature
>>        will come up in this conversation. I already sent an e-mail to
>>        that group
>>        for details about that :)
>>        I want to be able to avoid reinventing the wheel, so what are
>>        your thoughts
>>        on this?
>>        Thanks,
>>        - Ragi
>>        ------------------------------------------------------------------------
>>        _______________________________________________
>>        gdal-dev mailing list
>>        gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>>        http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>    --     --------------------------------------------------------------------------------
>>    Peter J Halls, GIS Advisor, University of York
>>    Telephone: 01904 433806     Fax: 01904 433740
>>    Snail mail: Computing Service, University of York, Heslington, York
>>    YO10 5DD
>>    This message has the status of a private and personal communication
>>    --------------------------------------------------------------------------------
>> ------------------------------------------------------------------------
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>