Tag: parse

  • <code> vs. <pre> in WordPress editor

    Writing my earlier post about the textarea issue I initially ended up with a funny looking post. It was due to the examples of HTML code included in the post not being parsed properly. Apparently I had been writing my post in HMTL mode instead of Visual mode and all the HTML code was parsed as “real” code.

    The code was wrapped in <code> tags, instead of the usual <pre> tags which keeps the code looking as expected.

    If you are neither certain of the exact uses of each of these two tags I suggest you read this documentation page for a quick overview of the differences along with other usage hints.

  • Latitude & longitude weather API

    While looking for a free and decent weather service API to display localised weather forecasts on tudomo‘s property details pages, I came across another blog describing how to get the current weather by using the iGoogle weather gadget API.

    The examples provided were mainly to locate the weather in a certain known city. My situation was a bit different as I never know beforehand where the properties for sale on tudomo are located in the world. So what I needed was a weather service based on latitude and longitude solely. Then it would not matter where in the world a property was located as I would get the closest possible matching weather measurement.

    To accomplish this you need to change the original query to the following. Please note all the commas are needed to make it work.:

    http://www.google.com/ig/api?weather=,,,36575560,-04670219

    Which will output some XML as the following:

    <xml_api_reply version="1">

    <weather module_id="0" tab_id="0" mobile_row="0" mobile_zipped="1" row="0" section="0">

    <forecast_information>
    <city data=""/>
    <postal_code data=""/>
    <latitude_e6 data="36575560"/>
    <longitude_e6 data="-4670219"/>
    <forecast_date data="2009-05-11"/>
    <current_date_time data="2009-05-11 17:09:51 +0000"/>
    <unit_system data="US"/>
    </forecast_information>

    <current_conditions>
    <condition data="Partly Cloudy"/>
    <temp_f data="71"/>
    <temp_c data="21"/>
    <humidity data="Humidity: 62%"/>
    <icon data="/ig/images/weather/partly_cloudy.png"/>
    <wind_condition data="Wind: SW at 13 mph"/>
    </current_conditions>

    <forecast_conditions>
    <day_of_week data="Mon"/>
    <low data="53"/>
    <high data="75"/>
    <icon data="/ig/images/weather/sunny.png"/>
    <condition data="Clear"/>
    </forecast_conditions>

    <forecast_conditions>
    <day_of_week data="Tue"/>
    <low data="53"/>
    <high data="75"/>
    <icon data="/ig/images/weather/sunny.png"/>
    <condition data="Clear"/>
    </forecast_conditions>

    <forecast_conditions>
    <day_of_week data="Wed"/>
    <low data="53"/>
    <high data="75"/>
    <icon data="/ig/images/weather/sunny.png"/>
    <condition data="Clear"/>
    </forecast_conditions>

    <forecast_conditions>
    <day_of_week data="Thu"/>
    <low data="46"/>
    <high data="71"/>
    <icon data="/ig/images/weather/mostly_sunny.png"/>
    <condition data="Mostly Sunny"/>
    </forecast_conditions>
    </weather>
    </xml_api_reply>

    Now it is up to you to simply parse the XML and process it as you wish. Please note that this is untested as I did not end up using the iGoogle API but instead Wunderground‘s as I felt it was more dedicated for the purpose. The same example call with Wunderground’s weather API would be:

    http://api.wunderground.com/auto/wui/geo/WXCurrentObXML/index.xml?query=36.575560,-4.670219

    Note there is a slight difference on how the latitude and longitude values are included in the GET request between the two APIs.