GEOID -- The LCIDs maligned little brother....

by Michael S. Kaplan, published on 2005/02/04 04:41 -05:00, original URI:

(Matt, never believe I don't hear you when you are saying things. This one is for you!)

Inside of Microsoft, there is a huge database of location data. That database is used to support products like MapPoint, Passport, Windows, and others with important information that each can use when they provide data about locations -- countries, regions, provinces, states, cities, and so on. How important it is varies from product to product (of course). But on Windows it is particularly dissed, and that ought to change.

In Windows, the primary key of this database is the GEOID, and many of the core GEOID values can be found in the Table of Geographic Locations.

(Lest you think I was talking out of my hat when I was talking about a huge shared database, compare the values in that table with those in MapPoint's GeoMapRegion values table!)

We have a program manager who started with us a while back and who has owned our Regional Options control panel applet for most of that time. One of the first things he noticed about Regional Options were that it was not driven by region, but by locale (which is itself primarily driven by language and secondarily by region as a tiebreaker any time the language alone would not give sufficient information). He was struck by how flawed that was as a concept, and has been trying to get us to think a bit beyond our current model. The model that gives the regional differences less importance than they deserve.

Although it is in my fundamental nature as a developer to disagree with him as a program manager (insert grin here), I will try to rise above that nature as a technical lead and admit that he is 100% correct. It does not make a lot of sense.

(teams throughout Microsoft start to get nervous)

However, the fundamental support of the locale model has been a central means of international support in almost every product at Microsoft. And there is no good way to reverse that and make everyone rewrite their functionality.

(teams throughout Microsoft breathe sighs of relief)

But this is no excuse for bad decisions in functionality!

APIs like GetUserGeoID are the most intuitive and obvious way to find out where someone is located. It is the answer a user gives in Regional and Language Options when asked for their location. The text in that dialog claims that the setting is used "To help services provide you with local information, such as news and weather." But how can we make those words true if applications Internet Explorer make their fundemental decision about the setting that controls the support of regional content on the default user locale (an LCID) rather than the geographical region (a GEOID)? As I said the other day when I asked "What is my locale? Well, which locale do you mean?" the default user locale is meant to impart the user's choice in format and collation preferences, NOT their location. So IE should be using the GEO settings for that!

Some will freak out at this point -- what would such a change to do users?

Well, let us say that we made the two settings act as being tied together by default, so that if you changed the locale that by default the GEOID would be changed with it.

This is easy since there is an under-documented LCType for GetLocaleInfo that retieves the GEOID that is asociated with a locale1 -- LOCALE_IGEOID (the value is 0x0000005B and the functionality has been since Windows XP). Any time the user explicitly changes the location after seeing the description in RED above, wouldn't the user be expecting IE to follow such a request?

Such a solution would solve the real problem for almost all users, and perhaps other folks for whom region is important (Windows Media Player, Passport, and news services for starters) would be able to start using the GEOID preference of the user as a starting point. Even the time zone settings would get an effective first guess with such a system (even if tweaking as required to obtain the best answers).

Because GEOIDs kind of rock. They provide a lot of potentially interesting information, as the SYSGEOTYPE enumeration defines:

Shouldn't we all consider using the result of GetUserGeoID when the question is "where am I?" rather than any of the various locale settings?

I think it really is enough of this "I don't want to make a a change because what if no one else does?" problems -- let's break the logjam and do the right thing, and work to make sure it is a better situation for everyone!

(Though with that said I will go in to work and still be just as cautious about any attempt at a suggestion to undo the current archeciture, beyond the (suggested above) step of having LOCAL_USER_DEFAULT drive the GetUserGeoID value!)


1 - There is also a RegionInfo.GeoID property that has been added to the Whidbey release of the .NET Framework, for a lot of the same reasons that inspired that LCType. The actual regions that fill the RegionInfo collection are locale-based, but at least now you can tie them together a little more than previously. Getting GEO information as listed in the SYSGEOTYPE enumeration is still not possible using the .NET Framework, though. Maybe something for next time....


This post brought to you by "" (U+2708, a.k.a. AIRPLANE)

# Jonathan Wilson on 4 Feb 2005 5:58 AM:

I imagine that managing this database must be a headache.
Especially when you consider that if you get geographic or geopolitical information wrong, it can cause big problems. (for example, is there any way to list what country the region of kashmir is in without pissing someone off?)

# Michael Kaplan on 4 Feb 2005 7:59 AM:

Well, any time some issue is updated, it obviously must be updated....

You may also have successfully hit on one os the reasons why MapPoint does not cover all locations in the world? :-)

# Ivan Petrov on 4 Feb 2005 1:44 PM:

(Ivan, I have moved your comment to without prejudice since it was horribly offtopic for here)

# Ruben on 4 Feb 2005 2:01 PM:

Would you care to explain a little further what the heck the use is for RegionInfo.GeoId without any of the SYSGEOTYPE information? Who needs a GeoId when the only way to do something with it, is by P/Invoking to Win32?

But then again, what is the use for a TimeZone class, when the only time zone supported is the current time zone?

# Michael Kaplan on 4 Feb 2005 2:12 PM:

Ruben -- one is for custom cultures (which eventually become custom locales), and the other is the along the lines of "maybe next version"....

Both of which will be interesting topics for another day!)

# Ruben (176) on 4 Feb 2005 2:56 PM:

Well, I don't quite see the custom cultures argument, unless it's some internal necessity in Windows to always assign a GeoId to a locale. But then again, if it's just an integer without context, why not give it the value 0. Just as meaningful as 221, which btw seems to be the GeoId for Sweden, according to the .NET SDK sample on GeoId. Who knew.

Anyway, great blog! I just love topics where no-one will ever be right and it's all one jolly mess of compromises.

Drewfus on 2 Feb 2010 10:28 PM:

The Table of Geographic Locations has moved to:

I've always thought that regional settings were too, um, regional - that there should be a way of incorporating international standards into setup answer files that overrides regional and other defaults.

Example for Winnt.sif:


;Date/time formatting


;Paper sizes


This would seem/look more professional than a series of reg add commands.

referenced by

2010/02/14 Whither RegionInfo?

2007/12/13 If you play with your gadget, there are all kinds of problems you can run into

2006/12/26 On holiday? Outlook might try to tell you where....

2006/08/19 What the hell is up with Timor-Leste?

2006/03/10 Setting the location in unattend?

2005/12/10 CurrentRegion is not based on the GEOID

2005/06/26 Client side locale settings on the server?

2005/05/28 Time zones and locations and keyboards, oh my!

go to newer or older post, or back to index or month or day