So the NOAA web service is great.  It is a nice easy way to give forecasts based on LatLong, etc.  The problem that it doesn't conquer is the question that my wife and I (and all Austin mountain bikers) ask before we choose which wonderful Austin trail to ride - when was the last time it rained at the trail?  Once you have the answer to that - you can whittle down your trail choice - or if it's been dry for weeks, have them all to choose from.  Let's take two trails as examples.

If I know that it has rained more than 1.5" at the Barton Creek Greenbelt, then I probably won't want to ride it (or at least the part North of 360) until at least 2 to 3 dry days (depending on sunlight and humidity...it's really wooded) after that rainfall.  On the other hand, the same rainfall amount (or even a little more) could fall at Emma Long Park yesterday and be ok to ride today (Emma Long is more rock/caliche than dirt).  I need a service that will not just give you the forecast for the future, but give you the history of rainfall/sunlight/etc so you can make your decision.  I want to be able to go to a website, look at this data for all of the trails on one page, make the decision as to which one I want to ride that I also CAN ride, then click on the map for a refresher on the route in Virtual Earth.  Today I started looking for a service that would provide historical weather data.  There aren't very many "almanac" data sites that keep this data and provide it in a easily available format (XML).  Also, the data is usually from the airport, a military base, or a weather station not near any of the trails...and I wanted this to be specific.

Enter the PWS or personal weather station.  I never really realized that there is this whole world of personal weather stations.  The place that I found the 2 components I was looking for - detailed historical weather data recorded at a specific LatLong PLUS the XML format was at Weather Underground.  Type in a zip code to get started, then down near the middle of the page you can see a map of all the PWS in the area using Google Maps.  Pretty cool!  Of course there aren't any right smack in the middle of the Greenbelt, but it's better than the airport data, right?  You can even view the current conditions AND the daily observations in XML!  Not all of the PWS have daily observations that go back very far, probably a limitation of the weather station itself or the service that they use to send the data.  So now all I have to do is find the page that shows the WSDL to get me all of this great data.

No dice.  As far as I can tell I don't see that WUnderground has a web services setup.  I wrote them an email to inquire about becoming a member if this were the case.  I looked into it a little further, and what I want IS possible, it just requires too much care and feeding for a site that would be a hobby.  The URL of the daily observations for a weather station don't change.  Every station in Austin has a name that begins with KTXAUSTI followed by a number .  The LatLong is in the data that is returned via XML, so I could map the stations myself.  I would just have to build the list of stations, query the data a few times a day and put that in SQL, add the station location to the maps of the trails using the LatLong returned by the XML query (which is really just a GET on the HTML of the page linked above), summarize the data that I want - precipitation, sunlight, humidity, etc, and add that to a SQL view or table that keeps data for a specified amount of time (probably one week or so) and only return weather data for a set of trails based on the proximity of the weather station location in the database to the trails location in the KML overlay and I suppose that if there were multiple weather stations that contained data that was relevant to the same trail, I would have to aggregate and average the data to give an accurate report.  Not too much work (ha!) and it could all break if WUnderground changes their URL style or subdomains...or they could ban my IP.  They should just offer this as a web service though, I think it would be a great pay web service (not for hobbyists like me of course, but for people who use it commercially) for places like ski areas...many times during the year, the weather at the base is not available because there's ONE weather station - run by a resort - that's broken or needs to be reset, or isn't linking to their website.  You would still be able to get that data (or at least nearby data) from other sources on a ski conditions site.  Just a thought. 

Also, I looked into it a little further and if you take apart the code on the WUnderground site, there is a web service of sorts (not WSDL) already.  There is a cgi-bin call back to the server that uses the corners of the GMap control to return a list of weather stations in the map's visible area.  Pretty sure using that would get you into some sort of trouble though.  For now, I'll wait for a response back instead of going down the aforementioned path, but if I get really bored over a weekend, it could happen.

I think something cool to add to a map is weather.  Take weather.com's use of Virtual Earth, I like it much more than the old Java timeline player.  I was looking at something done by Peter Bromberg on eggheadcafe.com.  He made some additions to a ASCX User Control that Mikhail Arkhipov created shown on his blog at MSDN.  I liked it.  I wanted it.  I downloaded Peter's project and built it.  It was pretty neat.  After integrating it into my TrailMaps website, I then realized what I didn't like about it - it was a server control.  Virtual Earth works on AJAX calls, so this didn't work for my TrailMaps website.  Or did it?  I needed to call the NOAA webservice after the map had loaded and I had a location.  Peter Bromberg's code translated zip codes into Lat/Long combinations to make it easier to implement, but I already had Lat/Long coordinates, so I reworked some of the code to query on LatLong instead of zipcode.  There was still the problem of the code needing to postback after I grabbed the LatLong from the map.  I had two choices:

1.  Write the code on the client-side to create the control via javascript that I already had on the server-side in C#. OR

2.  Figure out a way to return the ASCX control via javascript webservice calls using the AJAX Toolkit in VS 2008

I went with option 2 because I'm lazy, I liked what the control looked like already, and it's just HTML in the end right?  There has to be a way to get the HTML out of a user control and then grab that via a JS webservice call right?

 There is.  You have to use the System.Web.UI.Page class, but you can get it....you just have to render it first as if you were adding a control to a page.

public static string getWeatherControlHTML(decimal myLat, decimal myLon)
        {
            WeatherControl.WeatherLookup lookup = new WeatherControl.WeatherLookup();
            lookup.MyLat = myLat;
            lookup.MyLon = myLon;

            Page pageHolder = new Page();

            pageHolder.Controls.Add(lookup);

            StringWriter lookupOutput = new StringWriter();
            HttpContext.Current.Server.Execute(pageHolder, lookupOutput, false);

            return lookupOutput.ToString();
        }

Call this function from your webservice webmethod and you've got it.  I also added some animated gif's to simulate "working".  Check it out here and click the Get Weather button to grab the weather.  You can pan around and get weather all over the map, Colorado, New York, wherever the map is centered, those are the coordinates that are sent to the NOAA webservice.  I will warn you, Canadian weather is not supported. 

You can read more about the NOAA webservice:

Overview of the forcast webservice

So after playing with the 3D overlay issues in Virtual Earth, I decided to tear out the elevation data before the import.  This "fixed" the problem (see here).  In this example the map is set to 3D mode, the KML overlay is placed over the map, and my reference point (3 trails converging - click the button to the right of the map to go there) is correctly shown on the map.  This works because there is NO elevation data in the KML file, or rather it is zeroed out.  I noticed something else with the overlay issues though, check this out:

This is a screen shot of this map using this KML file after you use the control+down arrow, or the tilt button on the left-hand menu pane on it.  If you notice, in the lower right corner the altitude is given by the mouse cursor's position.  In the KML file, remember that the 3rd number in the comma-delimited string before the next space is the elevation.  Given the elevation data in the KML file, and the elevation data by the altitude display on the VE control, it is very strange that the overlay is approximately 400-500 feet above the maps elevation at every point.  What is also perplexing is that the track that is overlayed DOES seem to show elevation - i.e. it's not a flat line - there is some gradiation/relief in the overlay.

Compared with GPX files, KML files are ugly - at least when they are saved by Google Earth.

Look at this file:  GPX File

and compare it to this:  KML File

The KML file is XML, but when it comes to coordinates it just craps them out in one HUGE coordinates tag.  Take a close look,

-97.82383400000001,30.275435,267.383911

The 3rd number in the comma-delimited string (I thought that went away with XML?) is the elevation.  Not very pretty.  Compared with the GPX format:

I have been importing different KML files into the webpage I have been working with.  I first tried the 2D setting on the map control.  This works very well.  It wasn't until I played with the 3D capabilities of the VE control that I noticed some issues.  The following is excerpted from my post on the MSDN Virtual Earth Map Control Forum:

 When adding a KML overlay using ImportShapeLayerData the VEDataType.ImportXML type in a 2D rendering of the map works wonderfully.  Hybrid, road, even birds eye - they all work.  However, change the map to 3D style and the KML overlay is skewed and does not appear to be overlayed correctly on the map. 

<script type="text/javascript">

var map = null;
var layerid=1;

function GetMap()
{
map = new VEMap('myMap');
map.LoadMap(null,null,'h',null,null,null,null);
var l = new VEShapeLayer();
var veLayerSpec = new VEShapeSourceSpecification(VEDataType.ImportXML, "http://www.spencerwilliams.net/kml/kmltest2.xml", l);
map.ImportShapeLayerData(veLayerSpec, onFeedLoad, 1);
}

function AddMyLayer(type)
{
var l = new VEShapeLayer();
var veLayerSpec = new VEShapeSourceSpecification(type, txtSource.value, null);
map.ImportShapeLayerData(veLayerSpec, onFeedLoad, 1);
}

function onFeedLoad(feed)
{

}

When you look at the map in 2D, zoom into the area where 3 trails meet by clicking the "Go To Position" button on the right side of the map (Click here for this map). 

This is a hiking trail where 3 trails come together.  This placement is correct.  Now change it to 3D view and you will see that the triangle section is nowhere near the previous spot.  I would assume that this has something to do with a 2D KML overlay being placed on a 3D contoured shape, like a paper cutout that doesnt fit around an object.  I thought about this for a while and then looked at the KML.

UPDATE - 7-18-2008 : this appears to be fixed as long as you don't zoom in past 20yds in 3d - I'll have to research if there were changes to the rendering of 3D overlays by the virtual earth team