I've seen this too. It is possible Yahoo have interpreted the co-ordinates as WGS-84 (because they looked decimal) whereas the data source may have used a different datum, OSGB-36. Maybe Yahoo could look into this?

Clive Haworth,Amiplaying.com

Bali,Indonesia seems to be in the incorrect time zone. It is reported as Asia/Jakarta, should be Asia/Makassar. I reported this about 2 years ago:

http://developer.yahoo.com/forum/GeoPlanet-General-Discussion/Some-Incorrect-TimeZones-with-Reverse-Lookup/1297277890000-5d29eb44-4726-326b-8de6-f10c5e91c329

Do you plan to do fix it?

Clive HaworthAmiplaying.com

aaaaaa"""">>>>>>>

alert("XSS");//

%22%3E%3Cscript%3Ealert(%2FWEP%2F)%3C%2Fscript%3E

Hi,

I found these two cities have the state as their parent instead of a county:

Fremont, 2407405 (is in Alameda County, 12587670, http://www.fremont.gov/index.aspx?nid=493 )
Whittier, 2520031 (is in Los Angeles County, 12587688, http://www.cityofwhittier.org/about/default.asp )

kl;.

Any answer for this ?

HI,i,

I have the strong suspicion that for Germany the word "Au" is treated as a binding/grammar word. For example. 'an', 'am' translate to something like 'nearby'. 'Au' on the other hand is an old word for a field next to a river. Especially in Southern Germany and Austria "Au" by itself is the name of villages or cities.
There are lots of places called "Au" in the data and those are fine http://woe.spum.org//search/Au?placetype=town&page=2

But as soon as "Au" is not the first word I see it lowercased. Examples:
Todtmoos-au http://woe.spum.org/id/699604
Gemeinde au am Rhein http://woe.spum.org/id/12623899
Gemeinde au in der Hallertau http://woe.spum.org//search/au%20in%20der%20Hallertau

In those examples "Au" should be uppercase.


Somewhat related: Again in Germany for localAdmin types, whenever I see a dash both words before and after are cities. So both should be uppercase. Examples

Bodman-ludwigshafen http://woe.spum.org/id/12623535
Ebersbach-musbach http://woe.spum.org/id/12623837
Ettingshausen-flugplatzsiedlung http://woe.spum.org/id/20162313

Quite specific feedback, but I rather share it than adding fixes on my end only.

I found two cases in India where postcodes contain non-numeric characters.

75207S - http://woe.spum.org/id/55940762
53323O - http://woe.spum.org/id/55936070

Can you add a basic check or rule on your end for India and possibly other countries? In India postcodes are 6 digits and cannot start with 0. http://en.wikipedia.org/wiki/Postal_Index_Number

There is no clientaccesspolicy.xml to use in the geoplanet api like there is in the pipes api, I cannot access the api with Silverlight directly since there's only the crossdomain.xml so if there ware a clientaccesspolicy.xml i might be able to use it, although I don't know why Silverlight throws an error that clientaccesspolicy was not found though there is crossdomain.xml, maybe someone can help me here?

Thanks

We have been using the YDN Geo API for a while to provide approximate distances between locations. Recently we used the same integration to provide specific distances with a far higher degree of accuracy. We found that the API gives inaccurate locations for UK postcodes however the bug is straightforward to fix. The bug would appear to be related to the difference of the datum type from OSGB36 to WGS84. Changing the datum of the long/lat to WGS84 corrects the issue. The Ordnance Survey uses OSGB-36, based on an elliptical model of the earths surface which is a good fit to the UK. GPS systems generally use the world-wide WGS-84, based on an elliptical model which is a best approximation to the entire earth. At Greenwich, these differ by about 126m.

For anyone else, this takes a few minutes to fix when the data comes through. If this is an actual issue it would be good if Y! said when they were going to fix it as our fix will break our app.

Great API - many thanks Yahoo

I have a different situation that needs a similar approach.

I'm trying to find partial matches to a particular place name, restricted to a particular country (in my case, Australia). For example, I'd like to be able to query for towns in Australia beginning with "Mel" and get (for example) Melbourne as a match. Using something like places$and(.q('Mel%2A','au'),.type(7)) does not work as Neil discovered, as results from outside Australia are still returned. The other reasonable approach, places$and(.q('Mel%2A,au'),.type(7)), seems apparently to be misinterpreted and returns no results.

Being able to filter out results belonging to a particular country or WOEID would be very useful in this case, and I can't imagine it's much more difficult (if at all) in a technical sense than simply promoting them.

Hello everybody,
I read there is already a concordance between Wikipedia and Geoplanet in the meaning: given a Wikipedia article about any place in USA -> extract its woeid.
My question is: are you planning to build a service that works in the opposite way? It would be VERY useful to extract a wikipedia article or description of a place having its woeid.

Thanks bye

Hi Eddy,

A minimal would be a geo point for a continent, an admin1,an admin2 and an admin3 (country, state, and city) to point our maps selectors based in localities more quickly and limit the webservices and bandwidth. That is not under commercial rights and It's really usefull to increase facilities for dev.

Waiting a good news for next release.
Romi.

It does seem strange that centroids/bboxs data is missing from the data downloads. The shortcoming is also pointed out in this comparison. All the obvious kind of look-ups and use cases I can think of, require this, and so require using the API. Maybe that's deliberate.

Hi Team,

When you will add a geo latitude and longitude to Datasets?. We need this feature to fast point the maps to the places limiting web services for this basic information. It's time to share with us this feature. I can't use without this basic information and remains in geonames. Help us.

Peter.