Opened 9 years ago
Closed 8 years ago
#2816 closed task (fixed)
Create data extension for address_standardizer
|Reported by:||robe||Owned by:||robe|
Create a data extension for address_standardizer
names under consideration: http://lists.osgeo.org/pipermail/postgis-devel/2014-July/024350.html
I like the template_data name.
Also will use these for automated testing and documentation exercises.
Change History (6)
comment:1 by , 8 years ago
|Priority:||medium → high|
comment:2 by , 8 years ago
Oops my comment on #2877 really belonged here.
I've decided to call the us extension one
It's long and painful instead of what I had thought before ads_data… but I think the fact it sorts along address_standardizer will be a big plus.
I've added a is_custom column which I have in the tiger packaged ones already to distinguish from user input ones vs. ones we package. this is mostly so rules/lex/gaz can be tested before they get promoted to being distributed.
tables committed at r13717, extension glue to follow:
comment:3 by , 8 years ago
Rest committed at r13718 so now new extension
address_standardizer_data_us will be installed alongside address_standardizer. Will close this out as soon as I document this extension.
comment:4 by , 8 years ago
comment:5 by , 8 years ago
update doc to show output with address_standardizer_data_us extension at r13724
comment:6 by , 8 years ago
|Status:||new → closed|
I think I'm done with this.
I was close to doing this but then realized my perl skills were too poor to accomplish this. The issue is that the copy script the perl generates is no good for including into extension.
These need to be changed to inserts instead of COPY from stdin.
My lame solution was to dispense with those csvs and just export out those tables and get rid of the perl script. That would mean these files will just need to be edited or exported when they change. Not quite as easy as editing the CSV, but may be easier for other users to work with for building their own.