It you called MAPIMPORT with an "id statefp10 countyfp10 tractce10 blockce10" then you can put the same ID statement on GINSIDE.  That will cause it to return those values.  Alternately, you can use GEOID10, which returns all those variables in one variable. It turns out MAPIMPORT must be called with that ID statement or GEOID10.  GEOID10 is what it is sorted be so you don't have to have an ID statement for that.  Since 'blockce10' is not unique (there is one in many tracts, it many counties) then you cannot use just that. ... View more

I am saying that if you use GEOID10 with GINSIDE, you can just use MAPIMPORT with no ID statement (which you did originally).  So, MAPIMPORT and GINSIDE are this:      Proc mapimport out=save.blocks4 datafile="c:\Public\user_data\tl_2014_01_tabblock10.shp"            contents; run;      proc ginside data=points map=blocks out=out&state&fip; id geoid10; run; So, you shouldn't have to run MAPIMPORT again. The results are:     x          y            GEOID10            city              county        fips -86.8025 33.5206  010730027001097 Birmingham Jefferson      073 . .                         -86.8024 33.5206  010730027001097 Birmingham Jefferson      073 . .                         -86.3000 32.3667  011010015003009 Montgomery Montgomer  101 . .                         Since BLOCK can be the same in a county with each TRACT, you need the other info to uniquely identify which block you are referring to. Here is the whole program: libname save 'C:\'; filename fipsout 'c:\blocks\myfips.sas'; %let state=01; Proc mapimport out=save.blocks4 datafile="c:\Public\user_data\tl_2014_01_tabblock10.shp" contents; run; data save.points; x= -86.8025; y=33.5205556; city="Birmingham"; county="Jefferson"; fips="073"; output; x= -86.8024; y=33.5205556; city="Birmingham"; county="Jefferson"; fips="073"; output; x= -86.3;    y=32.3666667; city="Montgomery"; county="Montgomery"; fips="101"; output; run; proc sort data=save.points; by fips; run; %macro ginside_cnty(state, fip ); data points; set save.points(where=(fips="&fip")); run; data blocks; set save.blocks4(where=(countyfp10="&fip")); run; proc ginside data=points map=blocks out=out&state&fip; id geoid10; run; /*concat the blocks in the state*/ data save.blks&state; set save.blks&state out&state&fip; run; %mend; data save.blks&state; run; data out_fips;    file fipsout; set save.points; length lastfips $3;  retain lastfips '';    if  (lastfips ne fips) then do; out='%ginside_cnty('||"&state"||','||fips||');'; put out; end;    lastfips=fips; run; %inc fipsout;  /*Results in save.blks01 */ ... View more

I don't think you need to re-import them again if you use GEOID10 instead of blockce10. I looked a little further at the data.  BLOCKs are not unique even by county.  The same block number exist in the same county in 2 tracts: Statefp10  Countyfp10    tractce10   blockce10 01             001                 020500      1000 01             001                 020600      1000 01             001                 020700      1000 ... 01            003                  011403      1000 ... 01            133                  965900      1000 These maps ARE sorted by GEOID10.  GEO10 contains Statefp10 Countryfp10 Tractce10 and Blockce10 as a single number.  They are in that order.  You can get BLOCK by using the last 4 digits and TRACT by using the previous 6 digits. ... View more

It isn't required if the shapefile is sorted correctly (in polygon order).  That is, if it is sorted to use a particular variable such as BLOCKCE10.   Frequently, the Census data is not sorted correctly.  If you use the ID statement, then you need to specify the variables in order of how you use them.  So, if you used county, tract and block, you should sort them with "ID countryfp10 tractce10 blockce10;". The map must be in order that you can view it with GMAP to be able to use it with GINSIDE. If you see lines crossing with GMAP, then GINSIDE will 'see' the map that way too. Therefore, the data would be wrong. We used an example of a Census file for the ID statement because it is wrong so often: http://support.sas.com/documentation/cdl/en/graphref/67288/HTML/default/viewer.htm#p1sz5u47czzcj2n120k9fnqeb249.htm I don't know about the documentation that isn't SAS. ... View more

It will give you bad data.  You might try just importing Alabama and experimenting with that state with the ID statement before importing all the states. You can use Proc GMAP to see the Census map, but i would look at one County at a time because otherwise it will look like an all black mess due to the many Census Blocks.  I used county "101". ... View more

Regarding MAPIMPORT, sorry but the ID is important.  The Census frequently does not sort the data by what you need (blockce10, in this case).  In fact, you need to sort the data by  'ID countyfp10 blockce10;'. See my example below.  I don't understand the problem with sub-setting the data.  I am not subsetting the data from MAPIMPORT, but I am subsetting a copy into a smaller data set.  Otherwise, you will continue to run very slow.  This example does one state at a time and then only the counties that you have in your "point" data. libname save 'C:\'; filename fipsout 'c:\blocks\myfips.sas'; %let state=01; /*Alabama block data*/ Proc mapimport out=save.blocks2 datafile="c:\Public\user_data\tl_2014_01_tabblock10.shp" contents; id countyfp10 blockce10; run; data save.points;  /*The data that I'm matching to the blocks*/ x= -86.8025; y=33.5205556; city="Birmingham"; county="Jefferson"; fips="073"; output; x= -86.8024; y=33.5205556; city="Birmingham"; county="Jefferson"; fips="073"; output; x= -86.3;    y=32.3666667; city="Montgomery"; county="Montgomery"; fips="101"; output; run; proc sort data=save.points; by fips; run; %macro ginside_cnty(state, fip ); data points; set save.points(where=(fips="&fip")); run;  /*subset points by county*/ data blocks; set save.blocks2(where=(countyfp10="&fip")); run;  /*subset map by county*/ proc ginside data=points map=blocks out=out&state&fip; id blockce10; run; data save.blks&state; set save.blks&state out&state&fip; run;  /*concat the blocks in the state*/ %mend; data save.blks&state; run; /*empty results data out*/ data out_fips;    file fipsout; set save.points; length lastfips $3;  retain lastfips '';    if  (lastfips ne fips) then do; out='%ginside_cnty('||"&state"||','||fips||');'; put out; end;    lastfips=fips; run; %inc fipsout;  /*Run the file created above and Results in save.blks01 */ ... View more

Sorry, it took us several days to research this.  It looks like the problem is the number of Blocks you have in Alabama, but mostly the number of points in each Block.  As you said, there are around 16 million observations.  I think there are around 6000 Blocks, so each Block (polygon) has 2000 to 3000 points. The I/O seems to be a big factor.  And the searching the polygons. You have the county in both the Block map and your points.  You could search by county. The Block isn't the same as a county, but close since they list the county in the Block map.   For example: libname foo 'C:\'; Proc mapimport out=foo.blocks datafile="c:\Public\user_data\tl_2014_01_tabblock10.shp" contents; id blockce10; run; /* Proc gmap data=foo.blocks map=foo.blocks; id blockce10; choro blockce10; run; */ data points; x= -86.8025; y=33.5205556; city="Birmingham"; county="Jefferson"; fips="073"; x= -86.8024; y=33.5205556; city="Birmingham"; county="Jefferson"; fips="073"; run; proc sort data=points; by county; run; data blocks; set foo.blocks(where=(countyfp10='073')); run; proc ginside data=points map=blocks out=out; id blockce10; run; ... View more