0

WOEID: Great Idea, Too Many Limitations To Be Useful

I really like the idea of WOEID and there are some great things that Yahoo! has already done--but it's just not enough to be useful!

The downloadable data has too little information to be useful:

WOE_ID : 2347110
ISO : AE
Name : Ajman
Language : ENG
PlaceType : State
Parent_ID : 23424738

First off, you should have a readme.txt that describes what the data is; your terminology is non-standard and confusing.

First off, no location data, no geocoordinates.

ISO. ISO what? OK, it's the ISO code for the country--so call it ISO Country.

This is a 1st level administrative district (State) and there is no ISO /HASC code for Ajman (AE:AJ), so there is no way to relate that to other data with standard codes. MAYBE you can relate the name (but spellings / transliterations are not always accurate or consistent.)

Place Type: State. OK, that's an 1st level Administrative district--so are all ADM1's listed as states? What is a "Suburb" or a "LocalAdmin"? I don't see the documentation anywhere.

So... the TSV file is basically useless data--a list of WOEID's a best.

That means you need to query the web service to get any useful data.

The Web Serivce does have useful data--great data!

<?xml version="1.0"?>
<places xmlns="http://where.yahooapis.com/v1/schema.rng" xmlns:yahoo="http://www.yahooapis.com/v1/base.rng" yahoo:start="0" yahoo:count="1" yahoo:total="1">
<place yahoo:uri="http://where.yahooapis.com/v1/place/28717584" xml:lang="en-US">
<woeid>28717584</woeid>
<placeTypeName code="20">Point of Interest</placeTypeName>
<name>Sydney Opera House</name>
<country type="Country" code="AU">Australia</country>
<admin1 type="State" code="AU-NSW">New South Wales</admin1>
<admin2/>
<admin3/>
<locality1 type="Town">Sydney</locality1>
<locality2/>
<postal type="Postal Code">2000</postal>
<centroid>
<latitude>-33.857639</latitude>
<longitude>151.214706</longitude>
</centroid>
<boundingBox>
<southWest>
<latitude>-33.859119</latitude>
<longitude>151.213577</longitude>
</southWest>
<northEast>
<latitude>-33.856159</latitude>
<longitude>151.215836</longitude>
</northEast>
</boundingBox>
</place>
</places>

I like the bounding box... useful.

However, a 50K daily cap and 6,000,000+ places means it would take more than 120 days to fill in the blanks. That's not feasible for a large project.

It renders the service useless.

Now, if you could provide dumps of the web service data in XML or JSON--then 50K a day for checking / updating data is viable.

I am undertaking a large project that is geo-oriented. I would consider using WOEIDs in the project--but not as this resource stands; I can't, it would not be viable.

That leads me to another concern: these limitations will limit other developers adopting WOEIDs. If nobody implements WOEIDs, Yahoo will eventually stop supporting them eventually.

My apologies for being negative, but I see a lot of potential here and would love to see it realized.

by
2 Replies
  • I totally agree.

    a) Unless the downloaded data has coords, it is useless
    B)Thanks
    0
  • QUOTE (John @ Feb 19 2010, 12:15 PM) <{POST_SNAPBACK}>
    I really like the idea of WOEID and there are some great things that Yahoo! has already done--but it's just not enough to be useful!

    The downloadable data has too little information to be useful:

    WOE_ID : 2347110
    ISO : AE
    Name : Ajman
    Language : ENG
    PlaceType : State
    Parent_ID : 23424738

    First off, you should have a readme.txt that describes what the data is; your terminology is non-standard and confusing.

    There is a Readme.txt file included in the GeoPlanet ZIp file. While it may be terse, it should have sufficient information to allow you to access and use GeoPlanet Data. If you have suggestions for improving the documentation, please let us know.

    I've copied (and expanded) the Readme.txt file provided in the GeoPlanet Data Zip file to http://developer.yahoo.net/forum/index.php?showtopic=7150. It includes a list of supported languages and placetypes.

    QUOTE
    First off, no location data, no geocoordinates.

    We are evaluating the possibility of including centroid and bounding box data in GeoPlanet Data. In the meantime, please use the GeoPlanet web service (Place resource) for any applications that require this data.

    QUOTE
    ISO. ISO what? OK, it's the ISO code for the country--so call it ISO Country.

    You may rename this field as you like.

    QUOTE
    This is a 1st level administrative district (State) and there is no ISO /HASC code for Ajman (AE:AJ), so there is no way to relate that to other data with standard codes. MAYBE you can relate the name (but spellings / transliterations are not always accurate or consistent.)

    We are evaluating the possibility of including third-party place identifiers in GeoPlanet Data. In the meantime, please use the GeoPlanet web service (Concordance resource) for any applications that require this data.

    QUOTE
    Place Type: State. OK, that's an 1st level Administrative district--so are all ADM1's listed as states? What is a "Suburb" or a "LocalAdmin"? I don't see the documentation anywhere.

    "State" is the placetype used for first-level administrative areas within a country; it does not specifically refer to states. For example, the District of Columbia is classified as a State even though it is a Federal District. Also, the Province of Ontario is classified as a State.

    QUOTE
    So... the TSV file is basically useless data--a list of WOEID's a best.

    That means you need to query the web service to get any useful data.

    The Web Serivce does have useful data--great data!

    GeoPlanet Data is provided as a supplement to the web service. It is not intended to be used independently of the web service. Many users are finding value in the information contained in GeoPlanet Data. Its value to you depends on the application that you are building.

    QUOTE
    <?xml version="1.0"?>
    <places xmlns="http://where.yahooapis.com/v1/schema.rng" xmlns:yahoo="http://www.yahooapis.com/v1/base.rng" yahoo:start="0" yahoo:count="1" yahoo:total="1">
    <place yahoo:uri="http://where.yahooapis.com/v1/place/28717584" xml:lang="en-US">
    <woeid>28717584</woeid>
    <placeTypeName code="20">Point of Interest</placeTypeName>
    <name>Sydney Opera House</name>
    <country type="Country" code="AU">Australia</country>
    <admin1 type="State" code="AU-NSW">New South Wales</admin1>
    <admin2/>
    <admin3/>
    <locality1 type="Town">Sydney</locality1>
    <locality2/>
    <postal type="Postal Code">2000</postal>
    <centroid>
    <latitude>-33.857639</latitude>
    <longitude>151.214706</longitude>
    </centroid>
    <boundingBox>
    <southWest>
    <latitude>-33.859119</latitude>
    <longitude>151.213577</longitude>
    </southWest>
    <northEast>
    <latitude>-33.856159</latitude>
    <longitude>151.215836</longitude>
    </northEast>
    </boundingBox>
    </place>
    </places>

    I like the bounding box... useful.

    However, a 50K daily cap and 6,000,000+ places means it would take more than 120 days to fill in the blanks. That's not feasible for a large project.

    GeoPlanet is intended to be used interactively and should not be used to populate a database. It would be interesting to learn why you require a local copy of the full dataset including coordinates.

    QUOTE
    It renders the service useless.

    Now, if you could provide dumps of the web service data in XML or JSON--then 50K a day for checking / updating data is viable.

    We currently update GeoPlanet Data every quarter. Your update process should take this into account.

    QUOTE
    I am undertaking a large project that is geo-oriented. I would consider using WOEIDs in the project--but not as this resource stands; I can't, it would not be viable.

    That leads me to another concern: these limitations will limit other developers adopting WOEIDs. If nobody implements WOEIDs, Yahoo will eventually stop supporting them eventually.

    Can you share information about your application and how you wish to use geographic data? We think that GeoPlanet provides a rich set of information about named places throughout the world with minimal limitations. We would like to better understand how these limitations create barriers for adoption.

    QUOTE
    My apologies for being negative, but I see a lot of potential here and would love to see it realized.


    Negativity aside, you raise interesting questions about GeoPlanet can best serve the geographic developer community. Feel free to comment on my answers, and continue this dialog.

    Eddie Babcock
    Yahoo! Geo Technologies
    0
This forum is locked.

Recent Posts

in GeoPlanet Enhancement Requests