OS X - build/tiger_import error

[tyrauber]

I am on OS X Lion (or leopard). I have sqlite3 - (SQLite version 3.7.5) - installed at /usr/bin/sqlite3, and sqlite3, sqlite3-ruby and Text gems installed.

I have downloaded what I believe to be the required Census 2010 files- EDGES, FEATNAMES, ADDR, ADDRFN - and placed them in opt/tiger/TIGER2010/

When I run build/tiger_import, I get the following error:

$ build/tiger_import /opt/tiger/geocoder.db /opt/tiger
--- 01001
Error: unknown command or invalid arguments:  "load". Enter ".help" for help
memory
Error: near line 49538: no such function: metaphone
Error: near line 49559: no such function: compress_wkb_line
Error: near line 49566: no such function: digit_suffix

geocoder.db is created in opt/tiger but looks to be only the table structure.

I understand that this is probably an OS X issue, our target platform is ubuntu, but I was looking at taking advantage of my eight cores before moving the db to a server slice.

Any assistance would be greatly appreciated.

[timwaters]

I use linux so don't know the differences between the two systems.

I think this is a mac issue. .load is a unix command which may not be present on macs. If it is, though, looking at the build/tiger_import it is trying to load the sqlite3.so

I dont know if .so libraries are OSX compatible, but if it is, you should compile this first. It's not in the repo and must be made.

from the README.rdoc

"Building Geocoder::US

Unpack the source and run ‘make’. This will compile the SQLite 3 extension needed by Geocoder::US, the Shapefile import utility, and the Geocoder-US gem. You can run ‘make install’ as root to install the gem systemwide. "

Did you do this, did you see any errors?

I'd suggest using a linux virtual machine if all else fails.

[tyrauber]

I have got the Developer Tools, so I was able to run make. The process did complete - although I am not entirely sure about errors, I should have saved the output - I do have sqlite3.so in vendor/plugins/geocoder/lib/geocoder/us/sqlite3.so though.

I was interesting in mucking around with the codebase locally first before deploying, but it seems like that is probably not worth the headache. I will set up an ubuntu slice and build on it, as the platform was intended.

Oh. Any word on the required census files? Is this correct - EDGES, FEATNAMES, ADDR, ADDRFN - placed them in opt/tiger/TIGER2010/

Thanks for the assistance.

[timwaters]

Hi tyrauber,

it does seem that load is not on OSX - (you can use dlopen) but apparently that's not the issue here. I did a web search of the error you were encountering, and found someone else with the same issue with this code!

http://forums.gentoo.org/viewtopic-t-820663-start-0.html

You need sqlite3 with the ability to load extensions dynamically, it appears.

From the prerequisites:

NOTE: If you do not have /usr/include/sqlite3ext.h installed, then your sqlite3 binaries are probably not configured to support dynamic extension loading. If not, you must compile and install SQLite from source, or rebuild your system packages. This is not believed to be a problem on Debian/Ubuntu, but is known to be a problem with Red Hat/CentOS.

[tyrauber]

Yeah, I read that. I thought I might give it a try since OS X is supposedly Unix compliant.

What about the required 2010 census files? EDGES, FEATNAMES, ADDR, ADDRFN - placed them in opt/tiger/TIGER2010/

Is this correct?

[timwaters]

I believe the zips need to be in two or three directories under that directory. Like opt/tiger/TIGER2010/state/county/*.zips

[alexsenxu]

This is not a Mac OS X issue, this is because the geocommons:geocoder at the current stage, was written to imports TIGER/Line 2009 data, if you look at the ftp download page (from the census bureau), you will see that the data organization of TIGER/Line 2009 is different from TIGER/Line 2010.

Since 2010, the census bureau has changed the file organization from organized by state/county to organized by data types, which I agree is a more sensible data organization. What is means is that you either need to download 2009 data (or before) to use the default data import, or modify the data import yourself for it to take 2010 or 2011 data.

[smartacus]

Sorry to comment on such and old issue. I ran into the same problem with the stock version of SQLite 3 on OS X. The simple workaround is to install SQLite using Homebrew and update your path accordingly.