> 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