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.”
Hi Richard leeke,
I am trying to create custom geocoding for Southafrica suburb places. I got issues when i tried
--info command read all the details of the file.
Error message :
Generating custom geocoding files...
Type of argument to keys on reference must be unblessed hashref or arrayref at tabgeohack.pl line 522."
Configuration file :
# Definition of geographic roles to process
- role_name: SP_Code
- role: Country
- role: State
- role: City
- role: County
- role: Congress
- role: ZipCode
- role: AreaCode
- role: CMSA
# All countries except any listed are purged.
Where am in going wrong?
Yes, those yaml error messages are really obscure, aren't they? My code just passes on whatever the yaml component I'm using tells me, so that message isn't mine.
Editing the YML file with a text editor that understand yaml can really help. I use a free editor called Scite. That highlights any yaml structural errors in bright red.
I'll take a look when I get to a PC. It will probably just be a slight mistake in the indentation or a missing hyphen or something like that.
Sent from my phone - excuse the weird typos.
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.
Please find the YML file (subplace.yml) and result of --info command (sp_2011.txt).
This is shapefile of the subplaces (suburb) in southafrica . Shape file have other columns like Province, Municipality,District and Mainplace the subplace belongs to.
Sorry, I'm a bit confused what the actual problem is.
By trial and error, I think that what you are saying is that you have run the --info command successfully, but when you tried the --roles command it gave you that weird message.
I think your problem is that you haven't filled in the fields that you need in the YML for the --roles command to work.
I've taken a stab at defining the minimum set of fields that you need, but can't test it without your shape files. Have a go with the attached.
By the way, my text editor complained about some blank lines with the wrong indentation, so I cleaned those up. Here's how Scite displays lines it doesn't like:
I changed the role name to subplace and filled in a single required_geocoding_field of SP_CODE. You probably want more. Take a look at the examples .
subplace_RL.yml.zip 3.1 KB
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.
I fixed the issue with the CSV , imported the CSV and generated the shapes and tested successfully . That's why i deleted my post (Sorry).
Thanks a million for your assistance. you are genius. Your Process is the best to generate Tableau custom geocoding.
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.
scratch that last remark. I overlooked the need for a schema.ini file when importing numeric descriptors.
Glad to have helped (both of you) - and I'm glad you found the schema.ini issue, Jeffrey, I knew we'd hit that recently, but I couldn't remember what the issue was.
i am trying to include the municipality name as the required field.
The municipality names in my DBF file concatenated with the other codes and province value in my DBF file as shown below.
P2D04M03: Maletswai (EC143)
I can open the DBF file in excel and remove the unwanted data . But, i couldn't save the file as DBF.
Does Tabgeohack needs DBF file for the conversion process or can i replace the DBF file with the CSV file or any other file format ?
Solved : Found a excel macro to save the dbf file .
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).