This TechTip series explores the useful yet simple Web services of GeoNames. We started with the time zone API, and now we'll combine two other Web services in order to retrieve data about a country, using an address or set of GPS coordinates as a starting point.

Now that we know how to find a time zone (given an address or set of GPS coordinates), let's find out more about the country! For that, I'll use the Country Info REST Web Service. As with the previous tip of this series, I won't discuss the methodology—only the highlights of the Web services used here—so if you haven't read the first tip, it might be a good idea to do it now.

The Country Info Web Service requires a slightly different approach, because you need to know the country code in order to invoke it. If you only have an address, this might be a problem. One way to solve it is using several Web services sequentially, using the output of the first as the input of the second and so on—in other words, orchestrating the Web services to get the data you need. But first, let's analyze this Web service. For our example, let's properly invoke the Web service, using the USA country code (US):

http://api.geonames.org/countryInfo?country=US&lang=en&username=demo

This is what you get in return:

<geonames>

  <country>

    <countryCode>US</countryCode>

    <countryName>United States</countryName>

    <isoNumeric>840</isoNumeric>

    <isoAlpha3>USA</isoAlpha3>

    <fipsCode>US</fipsCode>

    <continent>NA</continent>

    <continentName>North America</continentName>

    <capital>Washington</capital>

    <areaInSqKm>9629091.0</areaInSqKm>

    <population>310232863</population>

    <currencyCode>USD</currencyCode>

    <languages>en-US,es-US,haw,fr</languages>

    <geonameId>6252001</geonameId>

    <bBoxWest>-124.733253</bBoxWest>

    <bBoxNorth>49.388611</bBoxNorth>

    <bBoxEast>-66.954811</bBoxEast>

    <bBoxSouth>24.544245</bBoxSouth>

  </country>

</geonames>

In this case, I'll use everything, but feel free to discard the data that you don't consider relevant.

Here's a rundown of the XML, with a little help from Wikipedia. Just click on the parameter name for more information:

• CountryCode
• CountryName—This is self-explanatory, but there's an important detail that's worth mentioning. The names of the country, capital, and continent are returned in the language indicated on the "lang" parameter of the URL. By default, the information is returned in English.
• IsoNum
• IsoAlpha3
• FipsCode
• Continent
• ContinentName—Self-explanatory
• Capital—Self-explanatory
• AreaInSqKms—Area of the country. Please note that the data is in square kilometres, not miles.
• Population—self-explanatory
• CurrencyCode
• Languages—The languages spoken in the country, using the IETF language tag.
• GeoNameID—The GeoName's internal ID for the country. It can be used as a parameter to invoke other Web services.
• bBoxWest, bBoxNorth, bBoxEast, bBoxSouth—Each parameter contains a coordinate (latitude or longitude), and the intersection of these four "lines" forms a rectangle with roughly the area of the country.  GeoName's documentation for this Web service can be found here.

For a simple RPG example, see the QRPGLESRC/TST_CINCOD source member. (You can find all the source code here.) 

The problem is that the input parameter is the country code, which you might not know beforehand. Imagine a client that requires you to ship products to a foreign address. It would be great to be able to determine the country code from the address, right? Well, the way to do it is via the GeoNames Country Code Web service. It's quite simple; invoke it like this:

http://api.geonames.org/countryCode?lat=47.03&lng=10.2&type=XML&username=demo

The URL is composed by the Web service location (http://api.geonames.org/countryCode?), its parameters (lat=47.03&lng=10.2&type=XML&username=demo, which are latitude and longitude), type of reply (XML in this case), and user. By the way, the "demo" user has a per-day limit of 30,000 requests and shouldn't be used in an application. Check out how to create your own user on the previous tip of this series!

The Web service's response is also very simple:

<geonames>

  <country>

    <countryCode>AT</countryCode>

    <countryName>Austria</countryName>

    <languages>de-AT,hr,hu,sl</languages>

    <distance>0.0</distance>

  </country>

</geonames>

Notice the parts highlighted in blue; the XML structure is similar to the Country Info Web service. I was able to use the same data structure for both Web services (see GeoNames in QCPYLESRC/RTVCIN_PR) because of the XML-INTO options "allowextra=yes" and "allowmissing=yes", which allow the data structure used with the opcode to contain elements that don't match the XML structure and vice versa.

Finally, to consolidate all of this, let's analyze an example (see the QRPGLESRC/TST_CINADD source member). Here, I'm using an orchestration of Web services to retrieve the country information, using an address as a starting point: procedure RtvGpsFrmAddr, which was described in a previously published article, is used to obtain the GPS coordinates of an address, stored in the P_Address variable. Then RtvCntrCodeFrmGPS invokes the Country Code Web service to obtain the country code that matches the address, using the P_Latitude and P_Longitude parameters that were returned by the first Web service. Finally, RtvCntrInfoFrmCode is called to retrieve the country information, via the Country Info Web service and using the country code that was returned by the RtvCntrCodeFrmGPS web service.

That's it for now. The next tip will cover the Find Nearby Points Of Interest!

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1