Optimization of a big MySQL weather archive table
Too slow and there is a better index?  No brainer.  Add the index.  But...  If you already have INDEX(x) drop it as you add any index starting with x.  (I'm thinking of longitude and RMathis' comment.

You are likely to have trouble with things like latitude=42.75.  latitude is FLOAT; 42.75 is (I think) DOUBLE.  In this case, 42.75 can be represented exactly in both FLOAT and DOUBLE.  But 42.76 cannot, hence it may not find a match due to roundoff.

A pair of floats consumes 8 bytes.  See this for other representation choices.  For weather stations that are no closer than a mile, DECIMAL(4,2)/(5,2) would save space (5 bytes instead of 8) and avoid the potential roundoff problem.

You mentioned "one of the slow queries".  To best serve you, let's see all the frequent queries, even those that are not slow now.  Then we can suggest a set of indexes to best handle all of them.

(When discussing performance issues, please provide SHOW CREATE TABLE; there are several details missing from what you provided.)

How much RAM do you have?  What is the value of key_buffer_size?  (Recommend 20% of available RAM.)  If you have a tiny RAM, then, I will impart some other advice.