76kE1h

6Rubul

Do you want play Warhammer?
Do you want buy Warhammer gold and Warhammer Power leveling?
you can to the website:www.gold-warhammer.com
湖南留学网

Thanks a lot. This has probably saved me a few hours of searching. Great!
This is a list of great resource. Thanks! Best Hidden object games, free Hidden object games, New hidden object games

Tnx!

Need to know before buying Lace wigs

If you want do delete your site from our spam bases - just email us with domain of your site:

abuse-here@inbox.ru

thank you!

Hello! great idea of color of this siyte!

And some more..
,

Szervusz!
Check this out!
,

*

And some more..
*

Hi!!!
Check this out!
,

At last...
*

And some more..
*

how do I get my national weather alerts from the rss feed?
<p>
Visit http://weather.gov/alerts/
<p>
You select to get either a state or county feed of currect weather watches or warnings.

how do I get my national weather alerts from the rss feed?

have spent an awfully long time trying to find an open source for ONLY temperatures. Here is why. Check my site at http://www.salmiset.com. about 39 people in nine countries - 11 cities. Instead of getting the multi-colored, flashy weather+your-bank-balance+birthday-reminders all I am really after is tobe able to pull current temperature for specific cities around the globe and have the temperature mark the spot on the map. Not really interested in the other "visitor experience enhancing stuff". This is just for the family to keep track of and communicate to one on other, so stickyness appeal is limited and commercialization and money-making from it just isn't there. Any direction would be greatly appreciated.

Happy Holidays.

Please join us any time, as we welcome all new comers.
Hope to see you soon.

http://www.quicktopic.com/27/H/yf6n5CMKrr4mf

I know this topic has been inactive for a while, but I'm actually having freetime and I'm (re-)starting my openWeather project.

I currently have a blog setup at http://blog.openweather.com/ which will be the main source of news and info regarding the project. I also have a Wiki in the works.

If anyone who's on this list is still interested in weather, XML and RSS, please feel free to subscribe to the RSS feed over at the blog, or get in touch with me if you want to contribute to the project. Code, blog posting, wiki content, anything.

Tony

Slashdot on the NWS XML Data:

http://yro.slashdot.org/yro/04/06/27/02162...d=126&tid=95&tid=99

This appeared over the weekend, but it's interesting on many levels. I find it almost comical that people think the NWS should just go away.

Food for thought,

Tony

NWS data is in the public domain.

Will NWS be charging a fee once this beta is up or will it be open to anyone who wants to use it?

Just a quick update. NWS is now experimenting with additional XML feeds:

http://weather.gov/xml/

This is seven day digital forecast data for 5x5km grids.

http://weather.gov/data/current_obs/

This are current observations in xml and rss formats.

and some more.

http://rssweather.com/

Well, they're getting data from somewhere, and then someone built a Drupal (http://www.drupal.org) module for it:
 http://drupal.org/project/weather

Here's a demo site that uses it:
 http://www.badgergoose.com/drupal/weather

Just more sources to get to know about.


--
Boris Mann
http://www.bmannconsulting.com

Tony:

On Feb 12, 2004, at 2:08 PM, QT - Tony Collen wrote:

> Not sure if there's still interest, but I've picked up
> openWeather a little bit more lately. I've got a program
> parsing the data at
> http://weather.noaa.gov/pub/data/forecasts/city/ into XML, and I
> will have forecasts put up on the openweather site within the
> next couple days I would imagine.

Nice work.

> Here's the sample "raw" xml format I am using. As you can see,
> it's pretty well marked up. Any input on the intermediate format
> (which will also be provided) is welcome. I apologize if this
> does not come through correctly:

I actually think it should be MORE marked up. Also, the DTD would be more useful than sample output...

Comments on potential additional markup in-line:

> <?xml version="1.0" ?>
> <fc>
> <header>
> <city>Anchorage</city>
> <state>AK</state>
> <issued>
> <time>Wednesday morning</time>
> <date>Feb 4</date>
> <year>2004</year>

Is there an existing date format that can be used? Like, dc:date ? Transformations should be done earlier rather than later, IMHO.

Don't know why it has to be wrapped in "header"...why not:

<location>
U
</location>
<issued>
U
</issued>

> <forecast>Cloudy, high 22, 0% chance of
> precipitation.</forecast>

<forecast>
   <description>cloudy</description> <-- normalize case
   <high>22</high> <-- what about units? e.g. <high units="celsius"> <low>18</low>
   <precipitation>0</precipitation>
</forecast>STRIPMIME_JOINLINES

Hey guys,

Not sure if there's still interest, but I've picked up openWeather a little bit more lately. I've got a program parsing the data at http://weather.noaa.gov/pub/data/forecasts/city/ into XML, and I will have forecasts put up on the openweather site within the next couple days I would imagine.

Here's the sample "raw" xml format I am using. As you can see, it's pretty well marked up. Any input on the intermediate format (which will also be provided) is welcome. I apologize if this does not come through correctly:

<?xml version="1.0" ?>
<fc>
  <header>
    <city>Anchorage</city>
    <state>AK</state>
    <issued>
      <time>Wednesday morning</time>
      <date>Feb 4</date>
      <year>2004</year>
    </issued>
  </header>
  <outlooks>
    <outlook>
        <period>Wednesday</period>
        <forecast>Cloudy, high 22, 0% chance of precipitation.</forecast>
    </outlook>
    <outlook>
        <period>Wednesday night</period>
        <forecast>Low 29, 0% chance of precipitation.</forecast>
    </outlook>
    <outlook>
        <period>Thursday</period>
        <forecast>Cloudy, high 23, 0% chance of precipitation.</forecast>
    </outlook>
    <outlook>
       <period>Thursday night</period>
       <forecast>Low 32.</forecast>
    </outlook>
    <outlook>
      <period>Friday</period>
      <forecast>High 18.</forecast></outlook>
  </outlooks>
</fc>

>I see this actually has the full information, which may be >the easiest way to work with it if people want the more >detailed info.

Yes... this allows some additional parsing for some fields as well as additional information (like the geocode tag - the county FIPS code in our case - usefull if you are doing GIS stuff).

>Are you aware of an XML format for describing standard, >i.e. >non-alert, weather forecasts?

Not really... just some very informal ones here and there... some discussed in this thread. Was surfing today looking (again) when I stumbled across this thread.

The Weather community has had some very weather specific formats in place for many years (like METAR) that work great if you are an expert in those formats. Several attempts within the community to jump start some xml standards have apparently not seen much progress. That's one reason why we focused on these already existing formats - it made this a low hanging fruit project to help show how xml and weather data can work together.

However, for me, the key is to keep it simple. An all encompassing xml schema for "weather" will be so complex (IMHO) as to be unusable. That's why, in my own mind, I tend to break it up into several areas; forecasts, alerts, current obs, hydro/water, climate, historical, etc.

Also, keep your eye on this: http://weather.gov/ndfd/

NWS forecasts are now being produced for 5x5km grids (not large "zones" that are somewhat based on counties) every three hours instead of every 12 hours. This digital data is mostly raw numbers from which you can build a worded forecast from using a program.

Cheers,

Bob


>Boris Mann
>http://www.bmannconsulting.com

On Nov 12, 2003, at 4:45 PM, QT - Bob Bunge wrote:

> Interesting thread.
>
> Here at NWS we are starting to experiment with RSS feeds:
>
> http://weather.gov/alerts/

Thanks for the information, Bob. This looks like some really useful stuff. It would be more useful to have the entire announcement included in the RSS feed, rather than just the "header" information. I'll note it in the feedback form.

> We are also producing data in another xml format, CAP (Common
> Alerting Protocol), which is more tailored towards the hazard
> messages we are working with.

I see this actually has the full information, which may be the easiest way to work with it if people want the more detailed info.

Are you aware of an XML format for describing standard, i.e. non-alert, weather forecasts?

--
Boris Mann
http://www.bmannconsulting.com

Awesome!

Bob, I must compliment you and the NWS on the work you've done. It's nice to see a data format that is descriptive and useful, finally.

Interesting thread.

Here at NWS we are starting to experiment with RSS feeds:

http://weather.gov/alerts/

We are also producing data in another xml format, CAP (Common Alerting Protocol), which is more tailored towards the hazard messages we are working with.

If you have comments, filling out the survey/feedback form is the best way to ensure your comment is in the official record and will be taken into account when it's time to decide if the rss feeds should become an official product or not.

Bob

Wow. I just had a totally awesome idea, and I think I can pull it off.

I had thought about the problem of decoding raw METAR data. I found WeatherEase Toolkit, which is written in Java, and up until about 15 minutes ago I thought it was the best way to decode METAR.

In one of my classes, we've been talking about grammars, and how they relate to parsing a program. It's all interesting, but we weren't really applying it much in the class.. it would be better off as a project for a class on compilers and interpreters.

Fast forward to tonight. I was randomly poking around the site for Chaperon, a parser which "converts structured text to XML." You define a grammar, and Chaperon will produce XML output based on that. I didn't think about it in the context of how it's used.

Suddenly I put 2 and 2 together, and whammo, I figured it out. I'll write a grammar that describes a METAR report, and let Chaperon parse it. The METAR format is well defined, the problem is the order that report elements come in. Hoefully Chaperon can fix this.

So what do you guys think.. shall I forge ahead into this new territory of grammars, or should I try to shoehorn something like the WeatherEase Toolkit into openWeather?

Tony

I hit 'reply' but not 'reply all', which might have messed it up. Strange. A blog or even a wiki would be good, but I guess I got a handle on the QT so it's all good for now.

On Wednesday, September 3, 2003, at 01:33 PM, QT - Tony Collen wrote:
> Dang, this quicktopic stuff is all messed up for me, so I'll
> resend the message I wrote but the list didn't seem to get:

Should just be able to hit "reply" and it just works.

> openWeather is me!

I almost suspected as much when I hit somewhere by mistake and it gave me a pretty Cocoon error page :p

> I still get tons and tons of weather rss searches, I just wish I
> had all the time to devote to it. I need a week off work and
> school or something.

Put me down in the same request for time off.

> I'm contemplating setting up a weather-rss mailing list in
> mailman, would you guys be interested in a real list by any
> chance?

For now, this Quicktopic seems to meet the needs -- especially with only three people. I sent an email to Chris Heathcote, inviting him to subscribe.

If there is to be a mailing list, there needs to be a common purpose -- like developing WeatherML or something.

And actually, a blog with multiple posting permission might serve just as well...

Dang, this quicktopic stuff is all messed up for me, so I'll resend the message I wrote but the list didn't seem to get:

Boris wrote:

> Since I'm in the process of aggregating, I should enter the
> other service that Chris pointed out OpenWeather.

openWeather is me!

> They serve up RSS as well as "raw" XML, but the XML is pretty
> useless -- for instance, the location (loc) field has the entire
> thing in one big string, instead of semantically tagging with
> city, state, etc. etc.
>
> The units as well are mixed in with data.

I know, I know, it was a super sloppy implementation that I did quickly due to time limitations. Last semester was hell on my body.

I've been busy doing some administrative things on the web server, like switching the main web server to port 80, along with reorganizing the other virtualhosts on this web server. All this is so I can use mod_proxy and point it at Cocoon.

Another thing I need to do is to rewrite my data downloader in Java, since Cocoon recently got a scheduler component, eliminating the need for a crontabbed python script.

Oh, and I might as well integrate that METAR decoder, too :)

I still get tons and tons of weather rss searches, I just wish I had all the time to devote to it. I need a week off work and school or something.

I'm contemplating setting up a weather-rss mailing list in mailman, would you guys be interested in a real list by any chance?

Tony

Since I'm in the process of aggregating, I should enter the other service that Chris pointed out OpenWeather.

They serve up RSS as well as "raw" XML, but the XML is pretty useless -- for instance, the location (loc) field has the entire thing in one big string, instead of semantically tagging with city, state, etc. etc.

The units as well are mixed in with data.

I'm still getting lots of referrer hits from search engines for people looking for RSS weather info.

Chris Heathcote at anti-mega has made a screen scraper (I think?) that uses worldweather.org as its source.

I just wanted to say sorry for being so quiet. I suggested this write before getting on the road for 2+ weeks. Great info so far. Hopefully I'll have some time to respond next week.

I've created a straw-man Current Weather DTD and a matching Sample Current Weather XML file.

Yet another opportunity to "test" QuickTopic's features. As well, I've been snooping around Google and found some interesting links:

Weather Info as RDF/XML -- takes interceptvector data and turns it into an RSS channel. What does this mean? Technically, we could create the XML format and just run it through this -- you can even download the XSLT transformations.

Here's another PHP parser

Another source for feeds from boygenius.com.

XML.org has a list of related mark-ups for weather. Ha. Except that weatherml.com is a site not found...it expires this October...

So, in summary, it looks like there is no open, XML-based, standard way of displaying weather. Let's go!

On Thursday, July 3, 2003, at 04:21 PM, QT - Tony Collen wrote:

> I think I mentioned it before, but we may have problems defining
> a weather XML description format which the "industry" will use..
> mostly because we're not meteorologists and we don't work for
> the NWS. It may be best to just invent a format which is
> descriptive and versatile, publish the DTD, and just put it out
> there.

Agreed. At the same time, it should be simple enough and yet
extensible/powerful enough for people to do whatever they want with the raw XML. I'm doing some snooping right now, and other than the "made up" XML format at http://weather.interceptvector.com, I haven't seen a common format.

> My main focus is RSS, however, and the "descriptive" XML
> format is just an intermediate step in my Cocoon transformation
> pipelines.

I have to disagree here -- the XML format is where all the info
actually lives. It will be useful to the largest number of people via an RSS feed, BUT, the early adopters and disruptors will want to do their own work with that data, and the raw XML feeds are going to be the easiest way to get it to them.

For you, working with Cocoon and all it's nifty XSLT/pipeline stuff, that's perfect. (Your illustration of pipelines in Cocoon was
excellent; I spent a bunch of time working with Cocoon in early 1999 but haven't really looked at it again -- it's still an excellent application/framework). For others, the XML will be important to build their own PHP/Perl/Python hooks.

> My goals in order of importance with openWeather are:
>
> - Provide a useful set of (free) RSS feeds for weather
> reports
> - Provide severe weather warnings/watches via RSS.
>
> The second one could possibly put services like
> http://www.weather.com/services/notify.html out of business. Or
> compete with them.

Good to get that out in the open. I am totally in sync with your first goal, except of course my ulterior goal is what uses the
consumers/users of those RSS feeds might do with it -- integrating into blog posting, gathering comments, etc. etc. Of course, once you've got an RSS feed, these other uses become trivial to implement.

I don't think we'll worry about competing with anyone yet :p

P.S. Just continue to reply to the sender and everything should
auto-magically appear in the forum.

sending this to the QT forum to see if it goes up.

On Thu, 3 Jul 2003, Boris Mann wrote:

> Yup. We are likely looking at defining a format for weather reports.
> The next step is to provide a couple of different things:
> - a "raw feed" of our new XML format, so people can do things we never
> expected
> - an XML-->HTML-->RSS feed with some options (append various parameters
> like "?icons=small, etc.)

This is all pretty trivial to customize the output in this way, especially with something like Cocoon. Except it looks more like:


Source Data (NWS Screenscrape, Decoded METAR, other Web Services) |
                  V
HTML<-- XSLT <-- XML --> XSLT --> Echo/RSS 0.9x/1.0/2.0
                  |
                  V
              Anything

Output here can be anything. Other XML (RSS/Echo), HTML, WAP, etc
I think I mentioned it before, but we may have problems defining a weather XML description format which the "industry" will use.. mostly because we're not meteorologists and we don't work for the NWS. It may be best to just invent a format which is descriptive and versatile, publish the DTD, and just put it out there. My main focus is RSS, however, and the "descriptive" XML format is just an intermediate step in my Cocoon transformation pipelines.

> > The permalink could link to a description of the feed, or the station,
> > or
> > lots of things. Or a historical report of that particular report. The
> > problem is there's lots of weather reports, so I think it would make
> > the
> > most sense to just have a permalink point to an HTML
> > description/representation of the feed.

> Right now, historical weather data is all for pay. There are lots of
> sources of weather data, but it is hard to get at data that is older
> than a week or so. So, this is the second part -- building some scripts
> that can handle creating blog-like entries out of weather information.

Yep, historical is quite the problem. There's so much of it. I used to work at a place where we had approximately 670GB of raw historical population data. I can only imagine what sort of raw historical weather data is out there in the NWS archives (or wherever it's kept).

My goals in order of importance with openWeather are:

 - Provide a useful set of (free) RSS feeds for weather reports
 - Provide severe weather warnings/watches via RSS.

The second one could possibly put services like
http://www.weather.com/services/notify.html out of business. Or compete with them.


Tony

--
Tony Collen
ICQ: 12410567
--
Cocoon: Internet Glue (A weblog about Apache Cocoon)
http://manero.org/weblog/
--

On 3 Jul 2003, QT - Boris Mann wrote:

oops, that last message didn't go to QT. testing 1234.

tony

>

--
Tony Collen
ICQ: 12410567
--
Cocoon: Internet Glue (A weblog about Apache Cocoon)
http://manero.org/weblog/
--
< replied-to message removed by QT >

On Thursday, July 3, 2003, at 01:24 PM, Tony Collen wrote:

> Well, now I think we're starting to talk about two different things.
>
> We're talking about:
>
> 1) A format for defining weather reports
> 2) A subscription format

Yup. We are likely looking at defining a format for weather reports. The next step is to provide a couple of different things:
- a "raw feed" of our new XML format, so people can do things we never expected
- an XML-->HTML-->RSS feed with some options (append various parameters like "?icons=small, etc.)

> The permalink could link to a description of the feed, or the station,
> or
> lots of things. Or a historical report of that particular report. The
> problem is there's lots of weather reports, so I think it would make
> the
> most sense to just have a permalink point to an HTML
> description/representation of the feed.

I think the permalink is part of the genius of weather feeds. Imagine a photo gallery that grabs info from our feed to display alongside a picture -- the weather at this place at this time was such-and-such.
Right now, historical weather data is all for pay. There are lots of sources of weather data, but it is hard to get at data that is older than a week or so. So, this is the second part -- building some scripts that can handle creating blog-like entries out of weather information.
--
Boris Mann
http://www.bmannconsulting.com

> Quick note as I'm on my way to bed (and then on the road for 10 days)
>
> > > Oh yeah, and now there's this whole "Echo" business
> > > (http://www.intertwingly.net/wiki/pie/), which seems to have tons of
> > > support from lots of people in the weblogging and software community,
> > > so
> > > we should be keeping an eye on this.
> >
> > I wouldn't worry about it *too* much. The "seven elements" are all
> > fairly common, and it really won't be too difficult to generate an RSS
> > feed/Echo feed/whatever. I would think that the important parts to look
> > out for would be namespaces and escaped/encoded XML/HTML.
>
> I personally think Echo is going to be useless for anything other then
> syndicating weblog posts. I've tried to raise this point again and again
> with the people working on it, but as so few people have any awareness or
> expirence of RSS in any other context, this concern has fallen on deaf
> ears.

Well, now I think we're starting to talk about two different things.
We're talking about:

 1) A format for defining weather reports
 2) A subscription format

The problem with "adding on" to RSS is that I seriously doubt many news aggregators will be able to grok the new elements. Do they display the text inside the elements? Do they strip anything that's not RSS (i.e. a special namespace?)

That's why I think plopping the weather report in an <item> or whatever element as plain text works just fine, and I think it will work with Echo (or whatever they decide to call it) as well.

> For example Echo requires the fields subtitle, summary, and author.
> Summary can be used like the current RSS description field, but what the
> hell would someone list as the subtitle, and author for a weather report?

Author? Whoever generated the data, or whoever reported it. In my case, I use my name and "openWeather" as the <dc:creator> element. If I felt like it I would just report the NWS as the author.

My weather feeds only contain one <item> element, and I think the Echo feed would be the same.

> Or the fact that they keep using the language of "permalink" when so
> applications simply don't have the concept of a non-transitive link (for
> example the way I've implemented my weather rss 0.1)


The permalink could link to a description of the feed, or the station, or lots of things. Or a historical report of that particular report. The problem is there's lots of weather reports, so I think it would make the most sense to just have a permalink point to an HTML
description/representation of the feed.On Thu, 3 Jul 2003 kellan@protest.net wrote:
--
Tony Collen
ICQ: 12410567
--
Cocoon: Internet Glue (A weblog about Apache Cocoon)
http://manero.org/weblog/
--

Quick note as I'm on my way to bed (and then on the road for 10 days)
> > Oh yeah, and now there's this whole "Echo" business
> > (http://www.intertwingly.net/wiki/pie/), which seems to have tons of
> > support from lots of people in the weblogging and software community,
> > so
> > we should be keeping an eye on this.
>
> I wouldn't worry about it *too* much. The "seven elements" are all
> fairly common, and it really won't be too difficult to generate an RSS
> feed/Echo feed/whatever. I would think that the important parts to look
> out for would be namespaces and escaped/encoded XML/HTML.

I personally think Echo is going to be useless for anything other then syndicating weblog posts. I've tried to raise this point again and again with the people working on it, but as so few people have any awareness or expirence of RSS in any other context, this concern has fallen on deaf ears.

For example Echo requires the fields subtitle, summary, and author. Summary can be used like the current RSS description field, but what the hell would someone list as the subtitle, and author for a weather report? Or the fact that they keep using the language of "permalink" when so applications simply don't have the concept of a non-transitive link (for example the way I've implemented my weather rss 0.1)

Good night,
Kellan

--
"its going to get ugly. and then its going to get boring"

kellan@protest.net
http://laughingmeme.org

On Wednesday, July 2, 2003, at 12:56 PM, Tony Collen wrote:

> On Tue, 1 Jul 2003 kellan@protest.net wrote:
>
>> But I was wondering if anyone is interesting collaborating on a RSS
>> namespace for weather? Wouldn't be very useful for now, but a new
>> generation of aggregators is starting to arrive who are able to
>> leverage
>> more then just the core TLD.
>
> Hmm.,.. Have you seen this:
>
> http://zowie.metnet.navy.mil/~spawar/JMV-TNG/XML/OMF.html ?
>
> There's a service which lets you query for METAR reports, and it spits
> stuff back in XML. The only problem is that the XML isn't technically
> XML
> since it's got everything except the <?xml version="1.0"?> at the top,
> which makes it hard to play with things like Cocoon.

I looked at this....specifically, it is a "Weather Observation
Definition Format", which is not necessarily the best format for describing the current conditions, forecasts, etc.

> The weather XML format from the "zowie" host is an ok format, but I
> think
> the simpler the better. I've noticed that some of the OMF XML could
> use a
> little reworking, there are some elements where they just slapp all the
> data into a tag and separate things by spaces, which IMO is a no-no,
> and
> degrades the information contained inside.

So, this seems to agree with me -- make a new format that is
RSS-weather friendly.

> Temperature and unit conversion IMO is a localization issue. We can
> build
> the unit reporting into the element, such as <temp units="c">24</temp>,
> etc.

+1 Agreed.

>> Sometimes visibility is noted as "10 miles", other times as "very
>> good".
>
> Yes, this does create issues. We'd almost need to decide whether to
> report a value and units, or just a generic "description" of the
> conditions.

There are likely sources of meteorological that could point us in the right direction for "standardized" reporting language.

> Oh yeah, and now there's this whole "Echo" business
> (http://www.intertwingly.net/wiki/pie/), which seems to have tons of
> support from lots of people in the weblogging and software community,
> so
> we should be keeping an eye on this.

I wouldn't worry about it *too* much. The "seven elements" are all fairly common, and it really won't be too difficult to generate an RSS feed/Echo feed/whatever. I would think that the important parts to look out for would be namespaces and escaped/encoded XML/HTML.

I could go on here for a bit about different ways to display
information (basic info only [skip the dewpoint...] large icons, small icons, no icons), what kind of info to display (current, forecast, current + forecast, etc.), but that should be something that can be nice and configurable -- a template system for what you choose to display?

So, in summary:

- I think that designing an XML format for weather info is a good start - the format should "respect history" and try and re-use any existing XML fragments that make sense, while not sacrificing simplicity
- I agree that the elements for current, forecast, and warning would have some overlap (temperature, different kinds of units, standardized names for conditions, etc.)
- I would suggest starting with current and then tackling the more complicated forecast (which, from looking, is actually "short term forecast" and "long term forecast) and warning

Hmmm...I had found a definition list with icons of "sky conditions" somewhere, but I haven't been able to find it again...

I've started gathering links on my website at my RSS Weather node: http://www.bmannconsulting.com/node.php?id=333

-- Boris

On Tue, 1 Jul 2003 kellan@protest.net wrote:

> But I was wondering if anyone is interesting collaborating on a RSS
> namespace for weather? Wouldn't be very useful for now, but a new
> generation of aggregators is starting to arrive who are able to leverage
> more then just the core TLD.

Hmm.,.. Have you seen this:

http://zowie.metnet.navy.mil/~spawar/JMV-TNG/XML/OMF.html ?

There's a service which lets you query for METAR reports, and it spits stuff back in XML. The only problem is that the XML isn't technically XML since it's got everything except the <?xml version="1.0"?> at the top, which makes it hard to play with things like Cocoon.

> As I started to jot down what might go in a weather namespace, I decided
> that weather reports really come in 3 separate types, and perhaps they
> need 3 namespaces? Simplicity cries out for just one, but I thought a
> hybrid spec that defines some common units and talks about the
> relationship between the different namespaces might make it all work.
>
> The 3 separate types are: current conditions, forecasts, and hazardous
> weather/storm warnings. (Tentatively thinking of recomending the
> prefixes: weather, forecast, and storm)
>
> Current might include:
> * sky - a prose description of current conditions
> * temp - the current temperature
> * humidity - the percent humidity
> * windspeed - wind speed
> * dewpoint - another temperature
> * heatindex - relative heat, another temp
> * windchill - relative cold, another temp.
> * visibility

The weather XML format from the "zowie" host is an ok format, but I think the simpler the better. I've noticed that some of the OMF XML could use a little reworking, there are some elements where they just slapp all the data into a tag and separate things by spaces, which IMO is a no-no, and degrades the information contained inside.

> Did I forget any?
>
> One of the first things you notice with weather is people like to use
> their annoying, region specific measurements. Are temperatures in
> Fahrenheit or Celsius? Is windspeed miles per hour? kilometers per hour?
> knots?

Temperature and unit conversion IMO is a localization issue. We can build the unit reporting into the element, such as <temp units="c">24</temp>, etc.

> Sometimes visibility is noted as "10 miles", other times as "very good".

Yes, this does create issues. We'd almost need to decide whether to report a value and units, or just a generic "description" of the
conditions.

> There are a number of potentially complex solutions we could come up with,
> involving sub-elements, or attributes, or what not, but I thought the
> easiest would be to require measurements of temperature and distance to be
> marked unambigously. So valid temps are 32F or 5C, and a valid windspeed
> is 13MPH.

> The nice thing being none of these scales are all that hard to convert
> between, but if for example you're going to calculate windchill, you'll
> need to make sure you know if you're working in Farenheit & miles, or
> celcius and kilometers.
>
> Forecast will generally be simpler as there is rarely much info available,
> still any element from current should be valid in forecast.

Some forecasts are like that. I've noticed the NWS forecasts for an area can be one of two formats: Tabular, and Discussion.

Compare http://weather.noaa.gov/pub/data/forecasts/state/mn/mnz001.txt to http://weather.noaa.gov/pub/data/forecasts/state/il/ilz001.txt, and you'll see the problem.

> Forecast adds
> * period - prose description, "Today", "Thursday", "Tuesday Night"
> * date - the day the forecast is for
> should one be able to represent a range of dates here?
> often you'll see something like "Monday Night - Friday, Clear"
> * hi - forecasted high/max temperature for a period
> * lo - forecasted lo/min temp for a period
>
> I haven't really thought about the Storm namespace yet.
>
> What do you think, seem like a good idea? Sound interesting? Did I miss
> something obvious?

I think the OMF format is good because it's already well-defined. However, it's run by someone in .mil, so I'm not sure what would happen if we want to make additions to the DTD, etc. mostly because we have no clout in the meteorological community =]

I like the idea of a forecast format, but there's lots of different ways to represent this. Naturally, I want a format that will work very well with the data coming directly off weather.noaa.gov/pub/* data.

Storm warning formats are good. There are things like geographic information (bounding boxes, or lists of counties?) which need to be taken into consideration.

I think it would be awesome to have a service eventually when the NWS requests the activation of skywarn (http://www.skywarn.org/) of a certain area, again delivered over RSS.

Oh yeah, and now there's this whole "Echo" business
(http://www.intertwingly.net/wiki/pie/), which seems to have tons of support from lots of people in the weblogging and software community, so we should be keeping an eye on this.


Tony

--
Tony Collen
ICQ: 12410567
--
Cocoon: Internet Glue (A weblog about Apache Cocoon)
http://manero.org/weblog/
--

I had an idea this morning while waiting on the queue at the corner coffee shop waiting for the morning pick me up. (which is by way of saying I haven't thought about this idea much)

But I was wondering if anyone is interesting collaborating on a RSS namespace for weather? Wouldn't be very useful for now, but a new generation of aggregators is starting to arrive who are able to leverage more then just the core TLD.

As I started to jot down what might go in a weather namespace, I decided that weather reports really come in 3 separate types, and perhaps they need 3 namespaces? Simplicity cries out for just one, but I thought a hybrid spec that defines some common units and talks about the
relationship between the different namespaces might make it all work.
The 3 separate types are: current conditions, forecasts, and hazardous weather/storm warnings. (Tentatively thinking of recomending the prefixes: weather, forecast, and storm)

Current might include:
* sky - a prose description of current conditions
* temp - the current temperature
* humidity - the percent humidity
* windspeed - wind speed
* dewpoint - another temperature
* heatindex - relative heat, another temp
* windchill - relative cold, another temp.
* visibility

Did I forget any?

One of the first things you notice with weather is people like to use their annoying, region specific measurements. Are temperatures in Fahrenheit or Celsius? Is windspeed miles per hour? kilometers per hour? knots?

Sometimes visibility is noted as "10 miles", other times as "very good".
There are a number of potentially complex solutions we could come up with, involving sub-elements, or attributes, or what not, but I thought the easiest would be to require measurements of temperature and distance to be marked unambigously. So valid temps are 32F or 5C, and a valid windspeed is 13MPH.

The nice thing being none of these scales are all that hard to convert between, but if for example you're going to calculate windchill, you'll need to make sure you know if you're working in Farenheit & miles, or celcius and kilometers.

Forecast will generally be simpler as there is rarely much info available, still any element from current should be valid in forecast.

Forecast adds
* period - prose description, "Today", "Thursday", "Tuesday Night" * date - the day the forecast is for
 should one be able to represent a range of dates here?
 often you'll see something like "Monday Night - Friday, Clear"
* hi - forecasted high/max temperature for a period
* lo - forecasted lo/min temp for a period

I haven't really thought about the Storm namespace yet.

What do you think, seem like a good idea? Sound interesting? Did I miss something obvious?

kellan

--
"the truth is always revolutionary" [antonio gramsci]

kellan@protest.net