> fork <forkandwait <at> gmail.com> writes: > > One of these days hopefully soon, I'll dust off my OpenSUSE VM and > > build PostGIS 2.0 and test Tiger geocoder on it. Turns out we might have to test this and get it to work on Linux sooner than later since we have a prospective client running on Linux that wants this.
> If anyone is interested, I have been working on an alternative script to import Tiger, based on the output from the function that generates a script. Its a "gist" on github. You might want to also look at the script in the legacy_import folder of tiger_2010. That was a script set up by Steve Frost for 2008 when he reworked the tiger geocoder to work with the new shp format. We couldn't use that because the client we needed to get this to work for Was a windows client and that script is Linux centric. > I have only tested it piecemeal, and it is currently bombing at "## create address data, one per county" near the bottom (I think because the tiger parent addr table doesn't match the table generated by shp2pgsql. Yap that is correct. That is why we had a function that strips of the extra fields or renames them. It was easier for us to keep the same naming than to change to the new tiger field namings (which apparently in many cases they prefixed with the year). We also concluded it was more extensible for future because the idea of reworking the code everytime they came out with a new dataset was not terribly appealing to us. So check out the function - loader_load_staged_data in tiger folder and you'll see what I mean > The idea is that you just change a few parameters at the top and then run it for your state. It would be *far* easier to write code to SQL to generate a bunch of "X=Y\n" lines than what it does now. I like the idea of putting more parameters at the top, the reason we didn't and stored many of the parameters in the table is because that is where the Linux/Windows/Unix code breaks apart and is different and our objective was to strive to create Something that could be used on all platforms (not just Linux). Honestly that was our frustration with prior loader scripts is that most of our clients were on windows and needed it to work on windows and it didn't so they didn't use the geocoder. The only piece that is truly cross platform is plpgsql (and also partly shp2pgsql) so that is why most of the variable specific stuff is kept in the tables loader_platform, loader_variables so that we could as much as possible abstract away the non-crossplatform commandline and not require people to install perl or any other additional items Thanks, Regina http://www.postgis.us _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
