FIPS 20 causes wildcard expansion to wget all files

[skipl]

Postgis 2.1.0 beta 2, tiger_geocoder extension, tiger2012 dataset:

In loader_generate_script() the pattern for generating the per-state wget line is '/*_'

s.state_fips. When processing Kansas (FIPS 20), the expansion matches '20' in the year 2012.

This results in downloading the entire nation from each directory (i.e. *_20 matches tl_2012*). Tightening the pattern to '/tl_*_'

s.state_fips does not appear to cause any problems with the rest of the census tiger2012 directory structure.

PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit POSTGIS="2.1.0beta2 r11441" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" RASTER

[robe]

skipl thanks for the info. I plan to get this fixed before the next beta comes out.

[robe]

fixed at r11548

[jhughesjr]

This issue appears to have only been partially fixed in version: POSTGIS 2.1.3. When loading KS - the following wget commands are still loading all files and not using the tighter '/tl_*_' pattern:

wget ​ftp://ftp2.census.gov/geo/tiger/TIGER2010/ZCTA5/2010/*_20* --no-parent --relative --recursive --level=2 --accept=zip --mirror --reject=html wget ​ftp://ftp2.census.gov/geo/tiger/TIGER2013/FACES/*_20* --no-parent --relative --recursive --level=2 --accept=zip --mirror --reject=html wget ​ftp://ftp2.census.gov/geo/tiger/TIGER2013/FEATNAMES/*_20* --no-parent --relative --recursive --level=2 --accept=zip --mirror --reject=html wget ​ftp://ftp2.census.gov/geo/tiger/TIGER2013/EDGES/*_20* --no-parent --relative --recursive --level=2 --accept=zip --mirror --reject=html wget ​ftp://ftp2.census.gov/geo/tiger/TIGER2013/ADDR/*_20* --no-parent --relative --recursive --level=2 --accept=zip --mirror --reject=html

[robe]

Thanks for reporting. Will try to fix in next couple of days. I was debating of just upgrading upcoming 2.1.5 to tiger 2014 which I have already in PostGIS 2.2 since 2.2 is still a ways away. I imagine the same issue exists there too.

[robe]

I have to check if this is still an issue

[robe]

Fixed for postgis 2.1.9 at r13989 and PostGIS 2.2 at r13990