The file you provided is definitely truncated. It's at least 8 bytes short. There's a GIF image data block at the end with a declared length of 168 bytes, but only 162 bytes remain in the file at that point. Even after that there should be, at a minimum, a 0 terminator and then a GIF "trailer" block (the byte 0x3B).
Browsers are designed to render partially downloaded images, so they don't complain about this, although you can see the corruption: on the road that touches the very bottom of the image, there is a pattern of vertical lines (Firefox) or horizontal lines (Chrome) that shouldn't be there.
If you execute the following code to affix eight bytes to the file, it clears up that spot of corruption and also becomes possible to open the file in other programs:
$data = file_get_contents('map.gif');
$data .= "\x00\x00\x00\x00\x00\x00" . "\x00" . "\x3B";
file_put_contents('map-repaired.gif', $data);
That's six (null) bytes to finish the block, the terminating data block's length 0 byte, then the trailer byte. Such a crude fix won't work as a general solution for all the other images though.
There's nothing wrong with the code you've provided. I don't have a key for the API so I can't actually test it, but I can only imagine there must be a bug at MapQuest's end. Perhaps its GIF compressor is broken, or perhaps the server is sending an incorrect Content-Length
HTTP header? I don't really know.
Since MapQuest can return the images in PNG format, and since that apparently works, go for it. PNG compression is always superior to GIF compression (except in the case when the images are extremely tiny -- around 100 bytes; then the headers of the more complex PNG format put it at a disadvantage) so there is no reason to prefer GIF in this case.