GeoNames Forum

If you search for postal codes in sweden with the name "Gråbo" you get fourteen hits, all of those should be at the same location, but in the list you can see they are divided between two places.
There are two "Gråbo" places in sweden, one is a populated place (57.8333333/12.3) and one is a section of populated place (57.9166667/12.55) all "Gråbo" postal codes should be placed at the first "Gråbo" (57.8333333/12.3), the second "Gråbo" is a part of the city "Alingsås" and all postal codes there begins with 441 and all "Gråbo" ones begins with 443, I know this for sure because i live in "Alingsås"

I don't know exactly how you update the postal codes, but if it's a match between the names in the source-file and PPL(X) names then I think you should change it to first look for PPL places and then for PPLX places, this will solve the problem when one city has then same name as a part of another city, I think you should allways choose the PPL place if there is any.

The update is an iterative process using the PPL(X).
In a first step it takes the first place and then it is using average lat/lng of neighbouring postal codes to remove errors and find better matches. For postal codes without a PPL(X) an estimated lat/lng is deduced from the neigbouring postal codes.

I have run all our postal codes against the google gecoder and I am now using this to find errors in our algorithm and improve it.

OK, but in the case of "Gråbo" it seems that some of the postal codes (44304, 44312, 44371) are located at 57.8333333/12.3 and that is correct, but some (44311, 44313, 44314, 44315, 44340, 44341, 44342, 44343, 44370, 44372, 44373) are located at 57.9166667/12.55 and that is not correct.

The first place is a city (PPL) and the second place is a part of (PPLX) another city "Alingsås", and both places have the name "Gråbo".

All the above codes should be for the city "Gråbo" (57.8333333/12.3)

Hi HBBq

I believe you and I didn't want to contadict you. What I was trying to say is, we are working on it. I have manually corrected your town on the development system, but I would like to fix the problem in the algorithm and not for one postal code only.

Marc

Ok, of course it's best to fix the algorithm, I just wanted to explain the problem a bit more detailed.

The algorithm is improved and all postal codes for Gråbo have now the same lat/lng (57.833/12.3)

Part of the problem was that we have two neigbouring places with the same place names Stenkullen and Sjövik in different parts of Sweden. For the 4430* postal codes we have them numericaly close :

44303 STENKULLEN > 58.6666667,16.2166667 instead of 57.8/12.3166667
44305 SJÖVIK > 58.4,16.7 instead of 57.9166667/12.3666667

The old algorithm caught got in a local suboptimal solution. The new improved algorithm has more iterations and more leeway to find its way out of local suboptima.

Marc

Also try "11127"

This is in Stockholm, the capitol, but gives the coordinates for another Stockholm - a small village in the south of Sweden. How come?

Thanks for spotting this problem.

The whole range of '11xxx' codes is wrongly mapped to the small Stockholm and the algorithm does not escape from it as there are not correct neighbours in this number range.

I think we have to look for clusters of postal codes and assign these clusters to the biggest cities of a country :

Code:

 geonames_db=> select substring(postalcode,0,3),placename,count(*) 
 from postal_code where countrycode = 'SE' group by 1,2 order by 3 desc limit 10;
  substring | placename | count
 -----------+-----------+-------
  11        | STOCKHOLM |   449
  41        | GÖTEBORG  |   298
  10        | STOCKHOLM |   263
  21        | MALMÖ     |   228
  75        | UPPSALA   |   206
  90        | UMEÅ      |   166
  58        | LINKÖPING |   160
  72        | VÄSTERÅS  |   155
  40        | GÖTEBORG  |   150
  50        | BORÅS     |   142

I will let you know as soon as we have changed it.

Marc

I have found the source of the problem. It was caused by a bug in the algorithm. At one point in the code it could happen that an unitialized lat/lng was used, which caused it to get a southward tendency and chosing the smaller Stockholm in the South.

Marc

Great marc, now it works fine. Thanks for all the time you put into this!