John, Thanks for the note. Map projections are one of my personal interests... though I admit to approaching the topic with rather more enthusiasm than finesse. I'm going to try to resist the temptation to get carried away by a discussion of cartography on this data compression mailing list (well, I'm going to try). I will say that my library supports projected coordinate systems and accepts Well-Known Text (WKT) specifications as metadata. But, really, my focus is on developing lossless data compression tools for all sorts of raster data, including both integer data and real-valued surfaces (fields). Geophysical information is a natural topic because so much data is so readily available. Incidentally, with the addition of LZMA for high-resolution SRTM elevation data, compression rates are running about 1.9 bits per sample (more or less, depending on the terrain).
Gary P.S. That was an interesting note about UTM being in use for 70 years. I had no idea... The math has been around for a long time (I think Lambert invented it and Gauss made important refinements), but the transformation is so complex that I wouldn't have expected it to take hold until well into the computer era. P.P.S. The original posting in this thread mentioned the FAQ document. If you'd like to read more about what the GVRS software is attempting, it's a good place to start https://github.com/gwlucastrig/gridfour/wiki/A-GVRS-FAQ On Sun, Jul 10, 2022 at 10:07 PM John Reiser <jrei...@bitwagon.com> wrote: > > On 7/10/22, Gary Lucas wrote: > > > The other motivation for the block scheme is that the API provides > > random-access to data. Typically, if one is looking at data for > > Finland, one usually doesn't care much about the data from > > Australia.Thus the file is divided into regional blocks. So the choice > > of block size also reflects the way in which I anticipate applications > > would use the data. > > I hope you are aware that such a system has been in use for about seventy > years, > exactly for this purpose, namely the Universal Traverse Mercator system which > uses 70 rectangular zones (some of them slightly overlapping). See > https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system > . > Most serious public Earth spatial data systems are based on UTM coordinates. > If your system does not interoperate with UTMs then nobody will talk to you. > > Various package delivery corporations have proprietary systems > that are quite similar. United Parcel Service (UPS) in North America, > DHL (a division of Deutsche Post) for much of the world, and others. > Amazon had a coordinate system that specified points for delivery > in the first 48 US states using two 16-bit integers. Google Maps > identifies locations on Earth using about 7 characters which encode > a recursive nested quadrant system. > > I'm pleased that you consider altitude. There are places in > Grand Canyon National Park (Arizona, US) which have the same > (x, y) coordinates but are several hundred feet apart. > It takes a few hours to walk from one instance to another "same" > (x, y) point. And if you are delivering ice cream cones to > someone in a sky-scraper tall building, then it can take minutes > to travel from the street entrance to an upper floor. > > -- >
