Review:
Air Apparent, by Mark Monmonier
| Publisher: |
University of Chicago |
| Copyright: |
1999 |
| Printing: |
2000 |
| ISBN: |
0-226-53423-5 |
| Format: |
Trade paperback |
| Pages: |
232 |
Subtitled "how meteorologists learned to map, predict, and dramatize the
weather,"
Air Apparent is a history of weather maps. Mapping the
weather is a surprisingly new field, dating only from the early 19th
century when a combination of scientific understanding and the ability to
combine scattered observations made it practical. They're also a
particularly tricky problem since weather is inherently three-dimensional,
and even to the present day nearly all of our maps are two-dimensional.
Monmonier starts with the earliest observational maps and the attempts to
use them for prediction and tracks developments up to the late 1990s, with
TV weathermen and (simple) interactive web data viewers.
I got a copy of this book after Paul Krugman mentioned it. I don't know a
lot about weather forecasting or weather maps, but I remembered finding
the science of weather fronts and maps of them fascinating in high school,
and I hoped I'd get the same feeling from this. Unfortunately, I probably
need to stop reading Monmonier's books; they always sound interesting, but
I don't enjoy reading them.
One thing that's important to know is that this is not a history of
meteorology. One can't hold that against the book, of course, because it
never claimed to be. But it has just enough of a history of meteorology
mixed into its history of map-making to make at least this reader wish he
were reading that other book. I like maps, I really do, but I was hoping
for either a book that melded a history of the science of weather
forecasting with the maps that were used in that science, or a book that
dove deep into the effective and ineffective ways to make weather maps
(ideally, Edward R. Tufte for maps). This is neither; it's little more or
less than a detailed history of the making of weather maps. Each time it
gets close to a clear explanation of the underlying meteorology, it finds
a map to examine and skips the rest of the explanation.
I kept almost understanding the underlying science, but not enough to
really understand the goals of the map makers, or why one presentation was
better than another, or how those presentations were used to make
forecasts or track weather data. I think I would have found this book
more interesting in conjunction with a full history of meteorology, but I
suspect that a history of meteorology would include enough about the maps
to render this book largely redundant for the casual reader.
The other problem I had with this book is that it's very dry. Monmonier
is clearly trying, and clearly cares a lot about his topic, but the book
has no flow. I kept getting lost in the barrage of names, arguments over
technique, and struggles for government funding. It's hard to put a
finger on why the book didn't grab me; the closest I can come is that it's
a book stuffed full of facts. Monmonier did exhaustive historical
research on weather map making, saved numerous quotes from original
documents, and laid it all out chronologically. That's fine if you just
want the information, but I was looking to be entertained in the process,
and that didn't happen.
I think the problems get worse in the second half of the book, when
weather satellites and computers enter the picture and the laborious,
manual map-making fall out, although maybe I was just exhausted with the
book by then. The early history of weather maps at least has the benefit
of showing the logistical struggles behind creating an effective weather
service: insufficient observation points, slow communication methods, and
the need for skilled map-makers to turn measurements into visual
representations. Once computers and satellite photography enter the
picture, the science matters even more, and I think the reader needs a
better understanding of the underlying science to make sense of the
results.
Air Apparent has a tendency to provide a brief
introduction to the type of data, a detailed chronological history, and
then a discussion of the ways of presenting and representing that data,
without ever getting the reader to care about the data itself or see how
it ties into forecasting.
Part of the problem, I suspect, is that the history of meteorology seems
to be full of sensible, careful people who largely did sensible, careful
things with the data they had available at the time. This is great for
the advancement of science, and not so helpful at making a history
engrossing.
I wish I could say that I was glad I read this book for the information,
if not the presentation, but unfortunately I didn't retain much. I needed
some sort of structure or frame on which to hang all of the specifics,
some sense of story or controversy or at least scientific understanding,
and I didn't get it. It took me a couple of months to finish this book
because I kept setting it down to read other things, and I only finished
it out of a combination of stubbornness and knowledge that other people
liked it.
If the topic sounds interesting, well, this book exists, and it's gotten
several good reviews. But I'm afraid I can't recommend it.
Rating: 4 out of 10
This week I received a logitech squeezebox radio, which is basically an expensive toy that allows you to listen to either "internet radio", or music streamed from your own PC via a portable device that accesses the network wirelessly.
The main goal of this purchase was to allow us to listen to media stored on a local computer in the bedroom, or living-room.
The hardware scans your network looking for a media server, so the first step is to install that:
Today was Playgroup. We had a pretty early start to the day, and Zoe wanted
porridge for breakfast, so we made that together in the Thermomix, and she got
dressed while it cooked.
After a bit of TV, we biked over. I got to witness semi-firsthand my first
mother-to-mother altercation. I said hi to a mother I'd met a previous week,
and asked her how she was, and got "Pissed off" as the response. Apparently a
reasonably large boy (I'd put him at about the 4 mark) had been in the face of
her daughter, and distressed her daughter a bit, so she'd apparently politely
told the boy to back off, and then been revved by the mother of the boy for
talking to her son. The boy continued hanging around her daughter, and she left
Playgroup not long after telling me all about it.
I worked out later on that the mother of the boy was one of the women who
helped run the Playgroup. Fun times. He was a bit out of control. He full on
screamed at me at the end of Playgroup for no reason. His mother did make him
apologise to me for that, without me requesting it.
There were some dress ups (mostly skirts) today, so Zoe had a fabulous time
cavorting around on the stage in a big pink lacy skirt, doing "ballet". She
dragged me up on stage with her, and we danced around for a bit. It was quite
fun.
She was very helpful at pack up time, and was bringing a lot of equipment back
to the storage room at the back of the hall. I was helping load stuff into the
large crate in the storage room. After parachute time, I lost sight of her
briefly, and after a quick search, deduced that she must have gotten herself
locked in the storage room. Sure enough, that's where she was. She was only
missing for as long as it took me to notice and search in all the other
possible places, so she wasn't particularly distressed. Poor thing.
After Playgroup, we biked back home, and I had another photo I wanted to print
out, so we drove over to Officeworks and had a sausage sizzle after we got the
photo printed out, and then drove back home.
Zoe had a pretty good bedtime last night, so I decided to try skipping her nap
today.
I wanted to get the 5-8 player extension pack for 
I used to use 
I have just pushed our pseudo-monthly batch of keyring updates to Debian. I am happy to inform you that, while the situation described in 
I ve slowly come to the conclusion that I should likely not work as much as I do. Looking back over my GitHub graphs, and feeling my own internal pressure to do more work is getting to the point of insanity. I can t remember the last time I took a whole day off.
As a result, I m going to make a new rule for myself, and put it in a semi-public place to help with peer-pressure enforcing this.
I m not going to use my computer (except in vary rare and urgent circumstances) on Sundays, from here on out. The exact rules are still up in the air (Is the Phone OK? Tablet?)
Let s see how this goes! I ll start next week (or just stop doing things today)
If you ever find yourself doing a bit of technical support for relatives
over the phone, there's nothing like actually seeing what they are doing on
their computer. One of the best tools for such remote desktop sharing is
First step will be getting a NetBSD ISO image for installation
purpose. It can be downloaded from 
A new minor upstream release 4.100 of the 
So you can see no response header in the above image but there is a
response and below how is response content visible on firebug.
Still weird part was when using wget/curl directly to get the CSS I
was getting correct reply and the file, which is puzzling.
So I went ahead opened the CSS url directly using browser and saved
the resulting file. When I used file command on it, output
suggested the saved file in gzip compressed!. I went ahead
uncompressed it and opened the file and inside it I found response
header and the response body! So what just happened? Did apache some
how manage to compress entire respone not just response body?
The more puzzling question was why did it work when I was using
mod_proxy_uwsgi and failed when I switched to mod_uwsgi. I had no
clue at this point why this behavior is coming up.
So response is still gziped but this time only response body was
gziped and Content-Encoding field was set properly which makes browser
to properly uncompress the response body and use it.
So it seems like there is a difference between mod_uwsgi and
mod_proxy_uwsgi implementation. mod_uwsgi was sending the response
along with response headers which was compressed by mod_deflate there
by rendering browser helpless to interpret the response. But
mod_proxy_uwsgi seems to be only sending the response content without
response body and this content was later compressed by mod_deflate and
proper response headers were set by apache before sending it to
browser.
So now whose fault is this? Is it the bug in mod_uwsgi or, mod_deflate
not being able to exclude response headers from compression? I've no
clue! If you have a clue and you want to share it with me, please
consider writing to me over email. My details are available in
Thanks to bernat on #debian @ irc.debian.org for