Duh, sorry, you are quite right, I wasn't thinking straight - that was before breakfast and I obviously wasn't fully awake.

Unfortunately I didn't implement what you really need, which is a way to purge a role except for those for nominated higher level roles, so as it stands you would have to specify all the individual zip codes to retain. Even that wouldn't really be guaranteed, because if it so happened that any of the other countries you retained have zip codes which are the same as any in Canada or the US they would be retained for the other countries too.

I'll have a think, but at first glance it looks like quite a bit of extra complexity to do it how you really want - not least in terms of how to express it in the YML.

I'm guessing your motivation here is to minimise the size of any packaged workbooks you create, is it? I'm just wondering if the overhead of the extra size would justify the effort of adding the extra capability. Especially since this is the first time it has come up in the 3 years or so since I wrote it.

I understand the complexities and it's more of a nice to have so don't worry about it. I can create two versions, one that has zip for the included countries, and one that does not include zip at all (to make the workbooks smaller).

Or now that I think about it, is there a way to include multiple purge_roles_exceptions sections (e.g. purge_roles_exceptions1 could include state,city and zip for 2 out of 7 of the countries, and purge_role_exceptions2 could include state,city for the other 5 countries).

There's no support currently for multiple purge_roles_exceptions sections. Adding something like that was exactly what I was thinking of when I said there would be some extra complexity.

I just tried to reply to your other question about purge_synonyms over on Robert Mundigl's Clearly and Simply site - but for some reason my answer didn't show up when I posted. In fact after I'd posted I couldn't see your question any more either. So to save it getting lost, here's what I said:

“The geocoding database includes multiple synonyms for many geographic roles, allowing both for different forms in common usage as well as different languages. There are 17 synonyms for 'USA' for example ('America', 'US', 'USA', United States of America', 'Estados Unidos', 'Etats-Unis', etc).

If purge_synonyms is false all synonyms will be retained for any listed role. If it is true, only the explicitly listed synonyms will be retained.

Why would you want to purge them? Simply to minimise space used by the geocoding database. I can't recall if I ever did any testing to see how much difference it makes, my guess is that the synonyms take a lot less space than the boundary data. I just thought it was worth exposing the option when I was writing it.

Hopefully our exchange on your question on the Tableau forums has answered all you need on the question on how to pare down the roles.”

Well the indentation in what you have pasted in to the question is a bit inconsistent, but it's hard to tell whether that is what is in your original file or whether that is the forum software realigning it.

The thing to remember is that yaml is critically dependent on the indentation structure - that is how the meaning is conveyed, so you need to make sure you don't change the indentation levels from what is in the supplied sample files at all. The best way to be sure of that is to use a monospaced font (courier or courier new are good choices) and if your editor allows it turn on showing white space.

Also, I think there are some required sections missing in what you posted (things like required_geocoding_fields). Maybe you just left those out to keep the posting short.

If you are still having problems attach the actual .yml file rather than pasting it in to the message.

I just typed up this reply to VRM K's post saying that he can't import custom geocoding because Latitude and Longitude don't exist - but that post seems to have been deleted now. I see there is forums maintenance going on, so in case it's a quirk of that, here's the reply anyway.

My guess is that you have system locale / country settings which mean that a comma isn't recognised as the field separator. Your file imports fine for me:

If that is the issue you will need to change your settings to English temporarily while you import. I did try to handle international settings when I first wrote it, but it got too hard - there were issues in several of the 3rd party components I'm using. I'm pretty sure there is something about that in the documentation - and I know that Robert Mundigl wrote about it on his Clearly and Simply blog - he had to switch from German to English.

thank you for all the thorough explanations. If you ever make it to Chicago, let me know and I will buy you dinner.

I think I have found a bug in Tableau related to custom geo-coding, let me know if you've seen this as well. When importing a list of state id's and state names (I'm using 8.3.x) on the map "import custom geo-code" menu, it only imports the state name. No matter what I do, it will not import the numeric values as another column. I reinstalled 8.3.1 and both columns are imported successfully using this version.

If I understand you correctly, the other way of achieving what you want would be to import each of the fields that you want with tabgeohack and then combine them with a calculated field within Tableau. Check out the manual for "geocoding fields" (fields from the shape file that you may want to geocode by - typically IDs or uniques names) and "feature fields" (other metadata available in the shape file that you may want to import - may be higher level geographic role details (dimensions) or may be measures like area or population).