Tuesday, August 02, 2005

Progress; Zooming

Note that the title is not "Progress: Zooming!" nor "Progress, Zooming" as both of those might be misinterpreted as meaning that my progress is itself zooming. The semi-colon is used here to mark a list, not an ellipsed copula. Make no mistake: progress is not zooming.

I did not lay out an explicit plan of intended progress last week (see Another idea, call it "geoWriting") as I was in the middle of determining what project path I would actually follow, rather than at the intended point where the direction of the path was already determined and steps along that path were being laid down. I suppose that implicitly my goals were to choose a path, and in that sense I have succeeded. The long post below on geoWriting (still need other potential names for this), and work over the past two days confirming the technical feasibility, at least marginal originality, and ability to challenge and interest me of this project have convinced me that it's worth pursuing for these two weeks.

Yesterday's work was almost entirely research, for which I have to show a large list of links in a post below (On Google Maps), and, today, a growing list in a new section at right ("relevant project links"). I have come to the conclusion that Google Maps will be a particularly good base for this work. It lacks the 3D immersion and control that Google Earth or a powerful GIS application would provide, but has fluent web access (particularly important in a program that seeks to be used widely, frequently, and briefly) and an open, simple API (in fact, the whole JavaScript source is technically available -- though heavily obfuscated -- as it must be for a JS application). These characteristics should help enable, respectively, the success of a finished implementation, and the feasibility of completing such an implementation.

I've also begun a detailed list of features that I'd like to implement as I move along (the scope), and questions that will need to be answered (answers that will affect scope, structure and skeleton). Those may one day soon find themselves in this electronic forum, but I will spare you them for now, at least.

As for zooming, this is the basis of my major need for the coming week. It has become clear from my investigations into how the Google Maps interface works and what I will want from my finished project, that I would very much like the ability to zoom in farther than Google's zoom level 0. Google's Zoom 0 displays approximately 1920 linear pixels per linear mile (see Continuing to Map the MBTA, a project of an Amherst alumnus). A little calculation shows this to be about 63 inches per pixel. Now, this number may not be right (for example, I think cars at maximum zoom tend to be about two pixels wide, which suggests fewer inches per pixel) -- perhaps Google has updated its service to show off higher resolution (it has all of Massachusetts at 2 foot resolution) with more zoom -- but in any case at least the order of magnitude of that resolution is confirmed. For the purposes of my program, I'd like to be considerably more zoomed in than that -- in part because I want to show more detail (more on that in a second) but also because for purposes of geographic localization (see end of More geoWriting), I'd like users to be looking at only a single part of the campus at any one time while still showing quite a bit of information. Zoomed out the way Google Maps is by default, one can see almost the entire campus at once with a fairly large browser window. I could limit the size of the map box if I wanted to, but I'd rather not do that, particularly given the increased realism that the extra detail of higher resolution could show.

So anyway, I'm trying to increase the zoom past Google's limit Zoom 0. This requires (1) making larger map tiles (preferably from a more detailed image, not just pixelated blowups of the current versions) and (2) changing various parts of the code to show less geographic area, but the same number of pixels, as Google Maps does currently. The first requires a higher resolution image, but I've been in email contact with Andy Anderson, who leads GIS efforts at Amherst, and am confident that I'll be able to get an image of 6 inch resolution over the next few days.

As for the second requirement: that is not so easily solved, but it must be solved if I am to continue. Because the JavaScript behind Google Maps (currently maps.15.js, but it changes not infrequently) is so extraordinarily complex (a weak attempt at dissection is linked to in the sidebar, but that is far from complete, and is only for version 5 anyway), I'd rather not have to change significant parts of that code to ask for different sizes (in geographic space) of tiles. So instead I am considering instead zooming the entire world, and having a tile server return a smaller geographic area at higher resolution (the two changes canceling each other out leaving an image of the same dimensions). I spent a long time on that late this afternoon (the whiteboard in the Mac lab is currently covered with my notes on that) and I think it is probably the right solution.

What if I just returned larger tiles with my server? I would meet the (private) API continuity commitments of returning a tile between the two lat/lon points, but could still show more pixels. I don't know if this would work or not -- I'm not sure what parts of GMaps depend on a fixed tile size.

Name possibilities:
  • The Amherst Geographic Medium (AGM)
  • The Amherst College Augmented Geography Project (ACAGP)
  • Project To Combine Text, Audio, Photography and Video In Geographic Form (PtCTAPViGF)
  • Video, Audio, Photography & Text Combined on a Map (VAPTCoaM)


Blogger Sarah said...

lol! I want to say VAPTCoaM, but I think PtCTAPViGF might be the clear winner here.

12:23 PM  
Blogger saratoga said...

Hey, I just randomly got to this on google, thought it might be something useful for your project:


Oh, AGM sounds good...it would be so neat if the acronym was yet another word like... Map? Media - Amherst P...

2:37 AM  

Post a Comment

<< Home