[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Java-dev] XML Standards



Here is an example of what we have been using, we have a queryable
service.  Here's the current result from the request
http://weather.aero/dataserver/httpparam?dataSource=metars&requestType=retrieve&format=xml&stationString=KDEN&hoursBeforeNow=1:

<?xml version="1.0" encoding="UTF-8"?>
<response version="1.0">
  <request_index>26467</request_index>
  <data_source name="metars" />
  <request type="retrieve" />
  <errors />
  <warnings />
  <time_taken_ms>43</time_taken_ms>
  <data num_results="1">
    <METAR>
      <raw_text>KDEN 231653Z 27020G28KT 10SM FEW080 SCT120 BKN160 11/M05
A2993 RMK AO2 PK WND 27028/1650 SLP097 ACSL DSNT S T01061050</raw_text>
      <station_id>KDEN</station_id>
      <observation_time>1135356780</observation_time>
      <latitude>39.83</latitude>
      <longitude>-104.65</longitude>
      <temp_c>10.6</temp_c>
      <dewpoint_c>-5.0</dewpoint_c>
      <wind_dir_degrees>270</wind_dir_degrees>
      <wind_speed_kt>20</wind_speed_kt>
      <wind_gust_kt>28</wind_gust_kt>
      <visibility_mi>10.0</visibility_mi>
      <altim_mb>1013.6</altim_mb>
      <slp_mb>1009.7</slp_mb>
      <sensor_status_indicators>
        <auto_station>true</auto_station>
      </sensor_status_indicators>
      <conditions>
        <cloud_condition sky_cover="FEW" cloud_base_ft="8000" />
        <cloud_condition sky_cover="SCT" cloud_base_ft="12000" />
        <cloud_condition sky_cover="BKN" cloud_base_ft="16000" />
      </conditions>
      <metar_type>METAR</metar_type>
      <elevation_m>1640.0</elevation_m>
    </METAR>
  </data>
</response>

If you are interested, you can take a look at what we're doing at
http://weather.aero/tutorials/dataserver/DataServer.php.

We are trying to bring our formats in line with the rest of the
community, but the community itself is so fragmented that I have yet to
find a real standard.  We have the option of providing data in multiple
formats, but I feel that that would fragment groups even further.  I
would prefer to adopt a single standard and try to unify what people are
using.  Our format was modeled in form after what the NWS is publishing,
but their format is for human-readable purposes (RSS) and ours is for
bare data access so our content differs.  I have been talking with Bob
Bunge from the NWS, and I am waiting to hear his opinion on the WMO
format.

So if you know of any other widely-adopted formats, I'd be happy to hear
about them.  Another format I came across was the Navy's OMF.
http://www.metnet.navy.mil/Metcast/XML/OMF.html  I haven't looked into
that one in enough detail to comment on it.

Thanks,
Aaron

Robb Kambic wrote:
> Aaron,
> 
> wow, this seems to be the metadata standard that the WMO approved. The
> metadata overhead is large considering the small amount of data in the
> reports. the <contentInfo> implies that the data should be included and
> all the elements <featureAttribute> does not cover all of the 140+ METAR
> fields that can exist in a report.
> 
> I don't favor this at all, maybe if the metadata was used like a THREDDS
> catalog metadata, and all the files(reports) are represented as urls. The
> idea is that the metadata would only be represented once and all the
> reports would be in a directory under it. But this is almost another
> topic.
> 
> I did create a java METAR decoder that produces XML in the following
> format. This method only produces parameters for the fields in the report.
> 
> robb...
> 
> <reports>
> <station name="KDTN">
>         <parameter name="Date" value="2005-12-23T12:15:00"/>
>         <parameter name="Report" value="KDTN 231215Z AUTO 16005KT 3SM VCTS
> +RA BR OVC026 23/23 A2991 RMK AO2 LTG DSNT SW AND W P0006"/>
>         <parameter name="Report_Type" value="METAR"/>
>         <parameter name="AUTOS" value="1"/>
>         <parameter name="Wind_Direction" value="160"/>
>         <parameter name="Wind_Speed_KT" value="05"/>
>         <parameter name="Visibility_SM" value="3"/>
>         <parameter name="Weather" value="VCTS +RA BR"/>
>         <parameter name="Cloud_Layer_1_Type" value="OVC"/>
>         <parameter name="Cloud_Layer_1_Height_Feet" value="2600"/>
>         <parameter name="Cloud_Layer_1_Height_Meters" value="780"/>
>         <parameter name="Temperature" value="23"/>
>         <parameter name="DewPoint" value="23"/>
>         <parameter name="Inches_Altimeter" value="29.91"/>
>         <parameter name="Automatic_Report" value="AO2"/>
>         <parameter name="Hourly_Precipitation" value="0.06"/>
>         <parameter name="Plain_Language_remarks" value="LTG DSNT SW AND
> W"/>
> </station>
> <station name="KDNV">
>         <parameter name="Date" value="2005-12-23T12:15:00"/>
>         <parameter name="Report" value="KDNV 231215Z AUTO 04006KT 5SM BR
> CLR 23/21 A2991 RMK AO2"/>
>         <parameter name="Report_Type" value="METAR"/>
>         <parameter name="AUTOS" value="1"/>
>         <parameter name="Wind_Direction" value="040"/>
>         <parameter name="Wind_Speed_KT" value="06"/>
>         <parameter name="Visibility_SM" value="5"/>
>         <parameter name="Weather" value="BR"/>
>         <parameter name="Cloud_Type" value="1"/>
>         <parameter name="Temperature" value="23"/>
>         <parameter name="DewPoint" value="21"/>
>         <parameter name="Inches_Altimeter" value="29.91"/>
>         <parameter name="Automatic_Report" value="AO2"/>
> </station>
> </reports>


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.