TODO file for Gtopo Tom Trebisky 12/6/2007 These are ideas, subject to revision as the time to implement them arises, but will give you an idea where gtopo is heading. After about 3 years time (in 6/2011), I am back to working on gtopo with the primary goal of adding support for Alaska. Alaska has very different map series, and this will require changing some basic assumptions in gtopo, and is tempting me to generalize the way I handle the maplet index internally. * It would be nice when gtopo starts that it would NEVER start with just a white screen. If the starting lat/long do not locate a map for the specified starting series, one of two things ought to be done: 1) First stay on that series if possible and find the closest point that is on a map (which could be thousands of miles away). This would require keeping some info about the centroid of the area actually covered by maps (and this could get complex if there were disjoint areas, we would need to keep the centroid of each disjoint area in a list and then pick the closest of those to the specified lat/long and then do a binary search along the line between the centroid and the point specified. This does not need to be done accurately, just correctly. 2) If there are no maps at that series, gtopo should walk thru series to try to display something. Display something, that is the guiding rule in all of this. 3) It should be possible to not specify ANY starting lat/long and then gtopo would fire up displaying the center of the largest scale series, or something like that so the user could zoom in. Google earth is a good guiding light here. ---- Current work is focused on allowing gtopo to get maplets via the public SOAP interface to Terraserver. -- As of Fedora Core 8 and gtk 2.xxx, a thing called "bug buddy" has popped up, and I have not yet learned how to tame it. If gtopo does something bad (such as segfault), which does happen now and then during development, "bug buddy" goes crazy and throws a fit. The intention is that bug buddy will automatically file bug reports once the entire known universe is using gtopo. For now it is just a pain in the arse when I am developing, so my solution was: yum erase bug-buddy This certainly gets the monkey off my back, but now when you launch gtopo, you get a message: Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory This is harmless, but annoying, stay tuned. -- Currently known and not yet fixed bugs: * Series 2 (and maybe 1) maps have a bug (sort of cosmetic) The maplets only match at the center of the viewed area, All the maps actually change pixel count (along the longitude direction) as latitude changes. At the series 2 scale, this is visible sometimes; the same issue is there with other map series, but is never a real issue with the size of screen that is generally used). * Now that I have 4 states on my machine, gtopo can be a little slow starting up. This isn't bad on my fast computer with a decently fast disk, but other people may object. What I may want to do is to build and keep an index on disk to speed this up. Actually on a linux system, this may be slow the first time, but subsequent gtopo startups are fast thanks to the disk cache, but this may mostly benefit me as a developer, most people will just start it once and then use it for long periods. * It should be fairly straightforward to get gtopo to talk to Terraserver and get maps, as well as photos, stay tuned. -- fixed bugs, new features, activity log. -- Latest stuff at the top. 6/5/2008 - gtopo builds just fine on an intel OS-X mac laptop running OSx Leopard (10.5) and with gtk2 2.12.9 from darwinports. 6/5/2008 - add the ability to specify the location of maps on the disk to the config file, and confirm that these can be split between several directories and work "seamlessly" (much as I hate to use that expression of speech). 12/5/2007 - allow a grab and move feature on the left mouse button, which replaces the previous "recenter on mouse location". For now, this recenter is gone, but I intend to move it to the right mouse. Scale changes are done via page up/down, I may put them on the mouse via ctrl or shift, but as long as you are using the keyboard, why not just use the page up/down 10/7/2007 - allow d:m:s notation as well as fractional angles for lat and long read from the settings file. 9/27/2007 - add a settings file. It looks in the order: /etc/gtopo/config HOME/.gtopo/config Both are processed if found. 9/18/2007 - putting version 0.9.7 up for download. Changed the static "box" for map center position to a tiny blinking cross that is easy to locate and hard to confuse with a symbol for a structure on the map. Changed the right mouse key to zoom scales one way when clicked, the other way when clicked with control held down. This now does the same function as the page up/down to change scales and does not go in a cycle as it used to. Getting ready to allow the mouse to be used to move around in a much different way (just grab map and slide it). 9/11/2007 - put version 0.9.6 up for download. This is a feature addition version, now the keyboard is involved and page up/down change map series, and keyboard arrow keys move around. Left mouse clicks still recenter on the spot clicked. 9/5/2007 - put version 0.9.5 up for download. 9/4/2007 - When using the SI_D01 full US maps, when it zooms from STATE to ATLAS, it looses position substantially. This is now understood and much better, there is still some error but it is a lot smaller and manageable 9/1/2007 - I have made it a lot harder to wander off the edges of the map coverage and get lost in white screen regions, both while using the mouse to move and when changing scale. Some of the map images include sizeable sections of scanned white paper, and there is nothing I can (at least not easily) do about preventing wandering into these areas. 9/1/2007 - put version 0.9.4 up for download. Version 0.9.4 fixes two major bugs. One was preventing it from viewing the filesets from Backcountry explorer, the other from viewing the 500K series when the SI_D01 full USA information was present. 8/30/2007 - When using the SI_D01 full US maps, and zooming from ATLAS to 500K, it can find no maps. Fixed, now it sees all 3 map series over the entire USA. 8/30/2007 - Certain map sets (like backcountry explorer), which have C and G named tpq files can display nothing in 100K and maybe 500k. This seems fine with lower case names. Fixed 9/1/2007, this was a problem with mixed case filenames such as C37120E1.tpq or some such nonsense, now OK. 8/30/2007 - put version 0.9.3 up for download. I made a number of changes to this version so it now runs on 64 bit machines (in particular linux x86_64 systems). It also will run on big endian machines (like Mac OS-X with powerPC processors, but my ability to test on these targets is limited. And it still runs on 32 bit i386 machines! It still needs some work to handle the 100K series properly in the new generation TOPO! releases (such as my 4.2 Nevada set). It handles 100K just fine with my old Arizona and California 2.6.9 and 2.7.6 version sets. 8/30/2007 - this currently does not run on an x86_64 machine, which my machine just became, so I am working on that, and worrying about regression testing (my home machine is a 32 bit, so I will just have to drag my feet upgrading it). Fixed 8-28-2007, so it now runs on both 64 and 32 bit intel machines, and while things were being generalized, it was made to work on a big endian machine too. 8/30/2007 - gtopo builds nicely on a big-endian OS-X mac laptop, and runs with some reported problems, what I need is access to such a machine for half a day or so. === Things to definitely do, but not top priority * Be able to print to a 8.5 by 11 inch equivalent postscript file. In particular the 7.5 minute maps should print at the true 1:24,000 scale === Things to probably not do. Somewhere, I read the suggestion that a GtkImage widget could be used in lieu of a drawing area for the kind of thing I am doing (namely copying a single pixmap to the drawing area). I don't know what advantages there would be to this, maybe it would be faster and lighter weight. I don't know if there would be any issues receiving events. Pixmaps would be sent to such a widget via gtk_widget_queue_draw.