>From: alan anderson <address@hidden> >Organization: St. Cloud State >Keywords: 200103232054.f2NKsZL14821 McIDAS-X Fkey MCGUI sounding Alan, Alan, >Looks fine to me. Anything that allows a more complete listing, >especially the pairing of ID# and city, even if the city is not well >known (e.g. chanhassen). OK. The objective of the bubble help is to quickly show the info for a station when a user moves the mouse cursor over the selector button. One can always see the full list of station information by clicking on the selector button. In a previous version of the list, I did not include all of the information, but I have changed that recently. A snippit out of the station information file looks like: 72365 KABQ Albuquerque NM US 35:02:30 106:36:53 1631 72376 ---- Flagstaff AZ US 35:14:00 111:49:00 2192 72381 KEDW Edwards Air Force Ba CA US 34:55:00 117:54:00 702 72387 KDRA Mercury NV US 36:37:14 116:01:40 1007 72389 KFAT Fresno CA US 36:46:48 119:43:10 101 72393 KVBG Vandenberg Air Force CA US 34:45:00 120:34:00 112 72402 KWAL Wallops Island VA US 37:56:26 75:27:47 12 72403 KIAD Washington DC VA US 38:56:05 77:26:51 95 72426 ---- Wilmington OH US 39:25:00 83:49:00 317 72429 KDAY Dayton OH US 39:54:22 84:13:07 307 72440 KSGF Springfield MO US 37:14:23 93:23:23 386 72451 KDDC Dodge City KS US 37:46:22 99:58:11 790 72456 KTOP Topeka KS US 39:04:21 95:37:33 268 72469 KDNR Denver / Stapleton I CO US 39:47:00 104:52:00 1626 72476 KGJT Grand Junction CO US 39:08:02 108:32:19 1481 72489 ---- Reno NV US 39:34:00 119:48:00 1463 72493 KOAK Oakland CA US 37:43:10 122:14:07 1 This list can be generated at will by each user from the interface. The routine that creates the list includes only those stations for which there are upper air reports. This process is nice and general, but it takes more time than I think the user is willing to spend routinely. It could also be generated by a cron process at some time after the observation hour (like 14Z for 12Z data, etc.). The information included in the list comes from the master station database, so the informational field (the column containing items like 'Albuquerque', 'Flagstaff', 'Denver / Stableton I') is kinda fixed. >What about a table that shows: ID# City (comment) + balance of info >now listed where (comment) could reference the larger city that the >station is near. and example would show: > > 72649 Chanhassen (Minneapolis) ..... > >or 72649 Chanhassen (KMSP) ..... > >This might not be useful for foreign stations, but would be fine for >the US. Unfortunately, the master station database does not include things like a reference to a better known city proximate to the RAOB station. In order to include this, one would have to generate a table that includes each upper air station in the world and then make a judgement call about which larger city should be listed for the reporting station. This might be not so hard to do for the US stations, but it could be very hard for international ones. Since the full station listing contains the STate and COuntry information for the station, do you think it would be useful to include that in the button label also? What I have in mind is: +----------------------+ | 72469 KDNR CO US | +----------------------+ or, perhaps something with more formatting: +----------------------+ | 72469/KDNR (CO US) | +----------------------+ +----------------------+ | 68328/FBTS ( BC) | +----------------------+ The inclusion of the STate and COuntry information would at least tell the user approximately where the station is IF they can figure out the two letter codes for STate and COuntry (this information is available from the interface, but in a different location). The bubble help would give a quick look at the station's information field, latitude, longitude, and elevation, and the list box of all stations would show the same for all of the stations that are available. The good news in the list is that the WMO station IDNs are assigned in a manner that contains information on where the station is located. By the way, this kind of input from you (and others) _really_ helps in designing a useful interface. Please keep telling me how the present MCGUI should be improved! >I am checking out for the day. Going home and build a fire. Thanks I think that we will be going out for a hike in a little while. Talk to you more on Monday. Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.