Purpose: This post will discuss tips and point out potential problems you can avoid when performing data connections to sub-national, administrative boundary map layers for countries other than the U.S. Why point this out for areas of the world outside of the U.S.? Connecting a table of data to US State map layer or to a US County map layer is facilitated by the ‘FIPS’ system that assigns a standard, unique ID to each Federally recognized administrative unit (i.e. State, county, census tract, etc). However, when performing data connections to map layers containing the sub-national admin units of other countries of the world, a ‘FIPS-type’ unique ID system might not be applicable, so you might need to watch out for and try to avert certain pitfalls that result from the lack of a unique ID system if you run into that situation. First off, if you are unfamiliar with why a unique ID attribute is necessary for establishing data connections between a map layer in AWhere and an external table of data, I highly recommend that you click here to read a forum post on that topic before proceeding; you will better understand the remainder of this post if you understand how/why a unique ID attribute must be used to establish a Data Connection.
In locations outside of the US, you will not specifically have the 'FIPS' system of unique, sub-national administrative unit identification, though some areas do have similar systems. Countries in the European Union use a system called ‘NUTS’, so if you are mapping data for Europe, you could potentially use the NUTS IDs as your unique identifier. There is also an internationally recognized system for assigning unique ID values to administrative boundaries globally, and that is the ‘ISO 3166’ standard. Unfortunately, it does not seem to be something people are generally familiar with, or utilize when organizing their data (many people simply use the names of admin units to 'uniquely' identify each record in their databases/data tables, and this has inherent pitfalls, unfortunately. What pitfalls? This is discussed below.) So, this forum post is going to assume that your data is not organize by, nor contains the ISO 3166 unique identifiers for the sub-national administrative units to which you want to connect and map some data.
Why am I talking about ‘Sub-National’ Administrative Units? – Well, when you are dealing with data at the national level (i.e. connecting a table of national-level data to a map layer of country boundaries), that is pretty straight-forward stuff…everyone is quite familiar with the correct spelling of given countries, and/or generally use the standard, recognized 2-letter or 3-letter country abbreviations (e.g. 'ET' or 'ETH' for Ethiopia). So, a person will probably be able to easily recognize if they have a county’s name mis-spelled in their table of data, or recognize if an incorrect country abbreviation is being used in their data table, and so it can be corrected.
However, when you begin dealing with sub-national administrative units, you might find that local variations in the spelling of administrative units’ names might cause headaches. The name of the admin unit might be spelled one way in the map layer in AWhere, but in the data table that you are connecting to that layer, the name of that same admin unit might be spelled differently. Even if the spelling of an administrative unit’s name is off by one letter, the data connection between that map feature and its corresponding record in the data table will fail.
Let’s take an example from Ethiopia. Ethiopia’s sub-national administrative units are in this order: First sub-national level units are ‘Regions’, Second sub-national level units are ‘Zones’, and Third sub-national level units are ‘Woredas’.
Let’s say you have a table of Region-level data that you want to connect to the Ethiopia ‘Regions’ map layer in AWhere (we have an Ethiopia AWhere dataset available, with these various political administrative boundary layers included...click here for more on our available data sets). In Ethiopia, there are eleven (11) regions (actually 9 regions and 2 chartered cities). The first image below shows the ‘Regions’ map layer available in our Ethiopia data set…note the spelling of the names of the regions in the map legend.
Now, consider this snap-shot (below) of a ‘Wikipedia’ page on Ethiopia, this lists the names of the regions as well, but note the differences in spelling between several of them (compare the map legend above with the spelling of the same Regions' names below, specifically #s 4, 6, 8 and 10).
Imagine that you have put together a table of data that you want to connect to the Regions map layer in AWhere, but you used (in your table) the spellings of the Regions’ names as seen in the Wikipedia page…immediately, you have a problem that needs to be corrected. Remember, for a data connection to be fully successful (in this example) the spelling of Regions’ names in the map layer must be exactly the same as their spelling in the corresponding data table. The easiest way to do that is to correct the spelling of the Regions’ names in your data table so that they mirror the spelling of the regions names in the map layer. This is something easy to catch and fix when you are dealing with only eleven possible map features and thus only eleven possible records in your data table.
Now, assume you have a table of Woreda-level data that you want to connect to the Ethiopia ‘Woreda’ map layer in AWhere. First, know that there are over 500 Woredas in Ethiopia, and so your data table could have that many records. Also know that there could be (and probably will be in numerous cases) differing ways of spelling the name of given Woredas. So, just as with the case of the ‘Regions’ example above, the way that a given Woreda is spelled in the Woreda map layer in AWhere could be different from the way it is spelled in the data table you have, and that is a no-no…perhaps the person who put the data table together is someone who commonly spells the name of a given Woreda differently due to some regional differences in pronunciation. Of course, detecting such spelling inconsistencies in a Woreda data table (with 500+ records) is going to be much more difficult than detecting spelling inconsistencies in a ‘Region’ data table with only 11 records. So, just know that when you are dealing with sub-national administrative units around the world, this issue of variations in the spelling of names can be prevalent, and is something for which you must watch out when performing data connections in AWhere. This simply requires diligent data-quality control efforts on your part, in terms of the organization of your data.
Know that one way you can potentially ‘catch’ these spelling inconsistencies is by going ahead and establishing a data connection between your data table (as is) and the relevant map layer, and then rendering (setting the display properties for) the map in the following manner to look for visual anomalies in the map:
1) Display one of the attributes that came over via the data connection, preferably use an attribute that is a numeric data type
2) It will initially be displayed using a solid color for the whole map. So, use the ‘Display Properties’ tab to display it using the ‘Class Breaks’ display type option, and set the ‘Number of classes’ to 2.
3) Click on the ‘Class Breaks’ button on the Display Properties tab.
4) You will see a small table with two ‘From’ and ‘To’ values…if the top ‘From’ value is ‘0’, go ahead and also set the top ‘To’ value to ‘0’ as well. By doing this, you are telling AWhere to display all of the map features with a value of ‘0’ for that attribute using that color (whatever color is shown there to the left of that row). Every map feature with a value of something greater than ‘0’ will be displayed using the other color there. Therefore, in this manner you can ‘catch’ (visually) if there were any records in your data table that did not successfully connect due to a spelling inconsistency; it will be one of these ‘0’ features, because any map features for which the data connection failed will have a zero value for all of their attributes, due to the data connection failure. So you can begin to click on those map features one at a time and back-check to see if there was a spelling issue. If there was, fix the spelling issue directly in the data table, save the data table, and then refresh the data connection in AWhere (to refresh the data connection, right click on the data connection in the treeview, and click on ‘Refresh’ in the menu that appears). (Note, if your data table does have legitimate ‘0’ values, or even values less than ‘0’ (negative values), you’ll need to take into consideration that some map features that have a ‘0’ value (or less), might actually be correct, and thus do not necessarily reflect a data connection error.
New Boundaries – another problem that you might encounter when mapping data to sub-national administrative units is the fact that governments might occasionally re-draw boundary lines, or maybe split one ‘district’ (or whatever) into two, etc. In cases like this, the map layer in AWhere might be out-dated…it might still show only one ‘district’ polygon where there are now actually two…but your data table, on the other hand, might be up-to-date enough to have data for both of the new districts. Again, no simple solution to this, just be diligent in checking your data’s integrity. In this case, you might need to seek out a newer boundary map layer showing the newer boundary lines, and bring that into AWhere (i.e. the foundation data sets that AWhere Inc freely provides as ‘get you started’ samples of data are not necessarily going to have the latest and greatest sub-national administrative unit boundaries for everywhere in the world.)