Thanks for taking the time to run through my project with tabgeohack 2.0.6. I definitely ran the --shapes step multiple times the first time that I tried this, so I'm not sure what the problem was. However, I'm glad that a reinstall fixed it!
All the best,
Richard, Thanks for all your work on this. I've used it several times in the past with previous versions of Tableau. Its a great tool.
I'm trying to refresh a data set I've used in the past. I'm basically using your tool to make BEA regions used by the economists for the US.
I've done this in the past but this time with version 9.1 and the latest gdal and tabgeohack I'm getting an error on the shapes steps.
08/12/2015 13:21:22: Generating shapes...
08/12/2015 13:21:22: Died: No such file or directory
08/12/2015 13:21:22: at tabgeohack.pl line 837
I can't figure out if I've missed a configuration on directory path or not. I've gone through it several times. Any help would be appreciated.
I just had a quick look to see where that error is happening and it is on a slightly obscure bit of code that I had to introduce to cope with a change that happened in Tableau 8.2 to do with the handling of numeric identifiers. I can't immediately see how that code can give the error you are seeing, so I'll probably need a copy of your shapefile and your YAML file in order to debug it.
As a workaround, you could try setting the 'generate_unique_id' field to true in your YAML file - I think that might just avoid the problem for you - though you might also need to add some extra fields into the list of required geocoding fields.
Let me know how you get on - and if possible post those files so I can take a look.
Many thanks for developping tabgeohack. Were using it intensively at the City of Amsterdam for showing administrative area aggregates, which are working great! Unfortunately the filling of the polygons has become quite coarse when 9.0 was released. See the screenshot. On the left is 8.2 and the right one is 9.2. Do you know what could be the problem and if this could be fixed for 9.2 somehow, or is this an issue of a simplification setting due to the newly added panning option in the map viewer itself?
We tried using the latest tabgeohack, simplifing the polygons, but all tests are giving the same jagged fill result.
Yuck, that's really ugly.
I confess I haven't looked at 9.2 yet, but that definitely looks to be a breakage caused by a change in 9.2. I picked up a very similar issue a while back - possibly on a beta for a previous version - and was able to work through it with Tableau who fixed it at the time. No guarantees whether that will be possible this time though - this is a classic example of why I put all those caveats about this being an unsupported hack. It could be that the you have imported finer-grained detailed than Tableau use for their internal geocoding. Maybe they are now truncating to lower resolution for some reason. Last time it happened that was exactly what the cause was, and it was an unintended side-effect of a change which didn't show up on Tableau's built-in geocoding.
I'll ping someone at Tableau and see if they know what the story is.
I just had a look and it seems the problem has been there since 9.1. It's definitely a Tableau change - opening up an old packaged workbook with 9.0 it looks fine, but with 9.1 or 9.2 it is similarly jagged.
I'm sure the issue will just be that the coordinates are being truncated to a lower resolution than they used to be for some reason.
I've mentioned it to one of the Tableau folk I know who is going to take a look. I'll keep you posted. As I say, no guarantees it will be addressed.
hello Richard and Eelke. I tried out existing custom geo-coding in 9.0, 9.1, and 9.2 and it all works fine, but the keyword here is "existing". In other words, I have a zipped up copy of the "Local Data" directory of when I imported the custom geo-codes within 9.0 and then I reuse this. I am thinking that perhaps the problem is within the import step or the generation of the filled areas within the fdb. So a workaround for now is to do the same, generate the data with 9.0 and then use it.
I heard back from my Tableau contact who confirmed that the relevant team are looking at it - they've raised it as a bug and expect that it will get fixed.
It turns out that the issue only affects the 'OpenGL' accelerated graphics rendering - which can be turned off. So until the bug is fixed you can disable accelerated graphics (Help->Settings and Performance->Disable Accelerated graphics) and it will display fine. Note that you have to exit and restart Tableau for that change to take effect.
Jeffrey: The issue is definitely with the rendering, not the importing. I opened up an old saved workbook in 9.0, 9.1 and 9.2 and 9.0 was fine, but 9.1 and 9.2 had the problem. I think the key point is probably the scale of the maps. The issue is that it is rounding or truncating the precision of the coordinates - so it will only show up on maps of a small area. Here are Tsunami Warning Zones around my house that I used in the original Grow Your Own Filled Maps thread, as shown by 9.0 and 9.2. The reason the effect is so marked here is that the map only covers an area a few hundred metres across.
I'm not sure why the yml file has a .zip extention. It not zipped. The map files are though.
Just checked. My Unique ID is already set to True
thanks, this makes sense. The maps that we are rendering are on much broader areas and therefore we don't see the affect. But it sounds like Tableau is on top of this. Cheers.
Jeffrey (Barlow as there are 2 Jeffreys active at the moment)
Thanks for the files. I reproduced your issue and can see exactly what is wrong - when I made that change I mentioned that I had to do to account for a change in Tableau 8.2 I did it in a way that only works for ESRI shapefiles and you are using a MapInfo file. It will be an easy fix, but I'm not sure when I'll get a chance to do that.
But the good news is that the workaround I guessed might help before does indeed work - so I was able to generate this:
You need to add an entry to your YAML file telling tabgeohack to generate a new unique ID, and you'll also need to tell it that the existing ID isn't the unique ID (it still will be unique - it just won't be the one tabgeohack uses internally for identifying the roles). You will just have an extra unique ID column appearing in the list of options.
I've attached an updated copy of your YAML file with that change in it.
bea_gen_unique_id.yml.zip 3.2 KB
FYI I've fixed the issue, so it will work properly for all spatial file types again without needing to generate that extra unique ID.
The fix will be in the next release. I won't do a release specially as I think that work-around should be fine. I'm not quite sure when the next release will be - I'm in the middle of some work to produce a native Mac version and that needs a bit more work. I'm currently waiting on Eldan Goldenberg who set me off on the Mac version. I don't have a Mac so Eldan has become the official tabgeohack Mac testing department...
I had no problems using your YML. I'm all set. I see there is a line specifically for generating it's own unique id. I was confusing that with the one the "unique_id" field.
Thanks for your help, I'm glad you were able to fix it for a future release. Just an awesome little program.