Saturday, November 26, 2005

A Small Fix

At some point this fall, Google made a small change to the GMaps API, admittedly not a public part of it. This broke the AGMM's use of custom tiles (so that it showed images of Amherst rather than maps of New York City). But now it's fixed, thanks to a small code change detailed on the Mapki.

Hopefully more work to follow. I'm trying to get some younger Amherst students to take over this project and finish it.

Friday, August 12, 2005

A Proof of Concept

I've been calling this web app a "proof of concept" ever since I actually got a Google Map interface to work. But now the term seems more appropriate as I've not just created a proof of the concept of zooming a map farther than intended, or of posting media to a map, or any of the other individual features. Rather, this should prove the larger concept of a web application that can provide an immersive, interesting experience of a location. I hope that I have shown some compelling reasons to try to implement this at Amherst College and at any college campus.

Note that the link has changed. The imagery proved to be too large for my account, so I've had to move it over to the ARC (Amherst Recording Council) account.

Amherst Geographic Meta-Medium Proof of Concept

It's been fun. I am surprisingly pleased with this result, or at least what this has the potential to be.

Wednesday, August 10, 2005

Hours and Item Types (and Lines, Oh My!)

Today's progress was remarkably slow (or at least is so visibly), despite putting in many, many hours. There are some changes worth mentioning though. I've made simple icons for the different types of items, so that from a zoomed out view, one can tell more easily what each item will be. These may change in the future (they are based on the Google pushpins, which are cute and all, but take up a lot more room than is necessary, I think), but this should demonstrate the idea, anyway.

And I've also added a new item type Hours_of_Operation, which administrators can use to attach the hours each building is open to that building. Going through this process also let me write up documentation (still on paper or I would link to it here) on how to add a new item type -- I'm hoping that future developers (me or any others) will want to do this a lot, because I think there are lots of distinctions worth making and lots of media worth adding (just off the top of my head: audio, video, links to forum threads, announcements, plans/blogs), and hopefully this documentation, and the effort I've put into making the code very generalized, will ease this process considerably.

As I'm rapidly running out of time, I think it may be worth modifying the goals for this project for the end of the week (that is, all the stuff I can't finish tomorrow). So I think I'll set aside the issue of handling lots of items (whether it be done by grouping, or on-the-fly spacing of icons to prevent overlap, or by showing only new or popular content) which looks to be complex, unsatisfying and perhaps even unrelated to the questions of media, and instead try to obtain at least conceptual versions of other features. For example, I'd really like to add Connections between items, so that I can refer to a certain location in my plan file, and then users can see a line from my dorm room to that location when they're looking through the map, or reading my text. I think that would have more serious implications for our discussions of media and the like.

Take a look at the most recent version (the link remains the same):
Amherst Geographic Meta-Medium
(Yep, still looking for names. Why is this so hard?)

Technobiography 2

In the first entry on this topic, I wrote about the advance of technology (and my, personal, chronological advance) and the shift from increased functionality toward increased usability. This month has surely been a reinforcement of those ideas -- I think the CET and this whole group of students feels (or at least acts upon; correct me anyone if you think I'm misrepresenting you) that same difference. The study of new or digital media (and the inevitable comparisons to "old" media) requires such a focus, I think.

But for the past week or two, I've been thinking about technology rather differently, and maybe that reflects something different about technology in my life, as well, that I hadn't previously realized.

Things like the EPIC video, our discussion of social software (and the thoughts I had had about it beforehand), talking about and using RSS, some of my thoughts concerning this geoWriting program, maybe even the beginnings of the Glass Bead Game that I've been reading a little of are making me think about the potential negatives of technology.

Perhaps I'll look back on this a few years down the road and realize the ridiculous naivete of my views -- in fact, just that possibility encourages me to continue writing this. [If there is any that I've become confident of, it is in the pleasures of remembering things.]

The efficiency of technology is generally considered its greatest advantage. It allows for a "purity" of information. Many of Manovich's characteristics of new media describe ways to personalize content to the viewer (variability, programmability, etc.). RSS, Google News, del.icio.us and other aggregators of content filter the content, which is certainly necessary given the enormous amounts of it that technological advances have given us access to. But that filtering and specialization leads to some of the narrowing problems that EPIC described. I admit that it may be my lack of familiarity with it, but I'm not particularly comfortable reading my news through an RSS reader, or some other aggregator service. I prefer going to the New York Times website and see the editors' presentation of the day's news, rather than seeing a list of the most popular stories averaged across every news organization that Google can find.

More broadly, computers often, in general, lead us to be not broad enough. Consider our spending all our time in the living room staring at our individual laptops, even after we've spent all day in front of computers. I've made similar analogies with the googlemaps project: technology (amongst other things, I suppose) has allowed us to break down barriers like location, but though location can be a harmful barrier in some cases, it's also a real characteristic that it's negative to disregard entirely. Hesse is ironic (parodic, maybe) in the Glass Bead Game when describing the Castalian's absolute devotion to the Mind, free from the distractions of the world outside the Order. It's not an irony that everyone picks up on right away (I think there are some pretty interesting positive points even read completely seriously), but a point that is most certainly being made -- its subtlety is a reflection of the unobviousness of the problem.

Perhaps this reflects something that has happened (or will happen) in my use and relation to technology. I've become in recent years more interested in exploring forms of technology to keep up with what's out there, without getting completely lost in them (like games, or even serious programming). And perhaps our discussions here, all the good things I've been given to think about, will lead me to choose better uses of technology rather than worse ones, or perhaps simply to see the error of my thinking here.

Tuesday, August 09, 2005

Some More Progress

So here's today's trick (and today's solution): when zooming in to the map, fewer items will be showing, and these items should be bigger: the user becomes immersed in the closer location, able to really see the images, read significant amounts of text, etc.

Thanks to the finally-arrived JavaScript: The Definitive Guide, I've learned quite a bit more about objects in JavaScript and put that knowledge to good use for, so far, pictures on the map. Instances of each NItem are made for each label on the map, and handle changing the image at different zoom levels. This is where it gets difficult: changing from one image to another on a user-clicked zoom creates a long pause before the new image shows up. Even though these images aren't that big, the time gap is distracting enough to significantly detract from the experience.

The solution, of course, is to pre-load the images. This is a fairly simple, well-known technique (people use this for mouseovers a lot), though it may prove slightly more complicated here. I've chosen to always pre-load just the next zoom level. And the images are stored in the NItem object, so that pre-loading shouldn't be repeated accidentally (perhaps that coudln't happen anyway, I'm really not sure). Documentation available upon request.

So please take a look at the progress so far and let me know what you think of it so far:
AGM

Monday, August 08, 2005

A Little Progress

Update, 2:56 PM: The page now works in Safari. A missing quotation mark and a very minor difference in handling of selected options made me think that Safari handled onLoad differently than other browsers. But actually it's perfectly normal and I just spent hours and hours doing research so that I could find a missing quotation mark. One useful result, though, is that I looked into better JavaScript/DOM developer tools for Safari, and found out how to enable the Debug Menu on Safari, which includes a JavaScript console, some basic DOM stuff (not quite as useful to me as the Firefox one, but still nice to have) and various other features. Check out this hint for an explanation of how to enable it on your computer (and ask me for help if you don't understand those instructions). Also potentially useful are the Safari WebDevAdditions.

I haven't made nearly as much progress as I had hoped to this weekend, but there is at least something to see:

Amherst Geographic Medium Proof of Concept

That page will let you see all the images so far posted on the map, and will let you add images to the map (click on Add an item to bring up the form, click the place on the map to place the image, then change the type of to Picture, select a file and hit submit). Unfortunately, images don't show up in Safari (which also has problems with the textarea in the initial form -- I've been investigating how it may handle onload() differently than the other browsers, but am still confused), and really all I've tested it in is Firefox, so I don't know how it will work in IE either.

Features that will be my focus for the next few days (besides browser compatibility, which has a ways to go apparently, and obviously filling out similar functionality for text):
  1. Changing the size of images when the user zooms in (thumbnails are already generated for this, they just need to be used)
  2. Handling many, many items on a page at once, either through grouping, or some method of selective display (or determining that this doesn't really matter at the moment)
  3. Updating with the new image data (which will hopefully be available Monday -- I'd like to know how many levels of zoom will actually be feasible)

Oh, and of course I'd like to add some nice functionality for playing sound and video from within the interface, probably using Flash. So I'll be busy for the next week, at least.

Please leave comments on how it looks on your browser, what ideas you have concerning my list of features/improvements here, and insights concerning the Safari browser and onLoad(). Thanks.

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)

Monday, August 01, 2005

Learning Objects

I've been asked a couple of times for the link to the Kanji Quiz and Kana Quiz that I showed briefly on Friday afternoon, so I'll finally post it here. We've been working on this for a couple of summers now, and it seems to have been fairly successful (the kana quiz has been used signficantly by beginning students, and we expect that the kanji quiz will be very useful for more advanced students). Sound is actually implemented fairly well, despite that being a very difficult thing to do in DHTML (I think all somewhat modern browsers except for IE/Mac support it fully). So, please feel free to take a look, practice your Japanese, or see how this sort of flashcard system might be used elsewhere:

Amherst College Kana Quiz
Amherst College Kanji Quiz

Programmatically they're pretty interesting projects as well. We did some bizarre things with innerHTML and JavaScript: PHP writes out a long HTML page based on the type of quiz you want, this page includes inline JavaScript which itself includes a long array of cards, whose entries are HTML, and get switched in and out to mimic flashcards without all the mess of reloading pages. The Kanji Quiz has much cleaner code in every respect, so if you're interested in code, I strongly recommend that you look at that one.

Our Curricular Computing Services group has students work on similar projects every summer, so there are others I could perhaps show you if you're interested (just let me know). Many of those students just get used for slide-scanning or faculty website development, so there aren't as many as I'd like, but nonetheless. I think it's a pretty interesting use of technology: it's really exciting for me, anyway, to see technology implemented such that it really helps the learning process (which has not always been the case in the past).

On Google Maps

So I've spent the morning researching Google Maps. There is, of course, a lot on it, as people get pretty excited when they can add usable functionality to their own pages, when they can associate themselves with Google, and when they can make maps of things, and particularly excited when they can do all three.

So, a few sites. Note that much of the work that has been done on Google Maps has been made obselete by the public API having been released. So some of these links may be pragmatically useless, but they're interesting nonetheless. Recreating Google Maps on your own server has also been done (and might be good for my project) and that may require the reverse engineering stuff that people worked on before the API.

How Google Maps' path-drawing works
Drawing arbitrary GIS data on Google Maps
GoogleMapki
Chicago Crime
so you want to create filled polygons, custom icons, and more?
TLabel, a Google Maps API extension: small, nice labels

Google Maps API Documentation
Google-Maps-API Group

Related links that aren't specifically about Google Maps (yes, there are organizations besides Google!):
GPSVisualizer
MSN Virtual Earth (and the unofficial developer site)
ESRI ArcWeb Services, free, online ESRI stuff (but not as nice as Google Maps, I think)

Also, my Google Maps API key (which it seems isn't bad to make public, as it can only be used for this one directory, and can be viewed by anyone who looks at the source of a page that uses it):
Thank you for signing up for a Google Maps API key. Your key is:

ABQIAAAAz2M5cuqrh1bI4SbYWGBT4xTOOPrZ5Xxw1CXLv691am9S5hsqCxRasNX4PO_5yyLlTDlx7s5Q9frTIA

This key is good for all URLs in this directory:

http://www.amherst.edu/~npdoty/gmaps/