Proc Geocode doesn't return tract or block when zip or city match

[jerry898969]

Hi Darrell,

Why isn't that listed as a required statement?  How would it cause bad data?

This is the page that I looked at when I was working on that.

SAS FAQ: How can I generate maps in SAS using an external shape file?

In that example they don't use the id statement but the select statement.   We are not mapping this data.  All we need is the codes returned back using ginside.   Will that still return bad data?

Here it says that mapimport will use the existing polygon order for the output map data set.

SAS/GRAPH(R) 9.2: Reference, Second Edition

For the block shape files what should the id be blockce10?  How about the other fields?

Thank you,

Jerry

[Darrell_sas]

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#p1sz5u47czzcj2n12...

I don't know about the documentation that isn't SAS.

[jerry898969]

Hi Darrell,

Thank you so much for all your help.

We are going to redo the process and use the id statement.

With the block shape files it has Statefp10, CountyFp10, TractCE10 and BlockCE10 that I need to get back from proc ginside.

Would this be the correct way to execute the proc mapimport?  I will try doing gmap on one of my current files to see what it looks like and then for the same state I will do it with the id statement.

Proc mapimport datafile="c:\temp\tl_2014_01_tabblock10.shp" out="AL_Block" contents;

id statefp10 countyfp10 tractce10 blockce10;

run;

This should give me correct data now when I do proc ginside, correct?

Thank you,

Jerry

[Darrell_sas]

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.

[jerry898969]

Hi Darrell,

Previously I didn't use the id statement at all.  I will use GEOID10 within my proc mapimport.

This is the code I should use, correct?

Proc mapimport datafile="c:\temp\tl_2014_01_tabblock10.shp" out="AL_Block" contents;

id GEOID10 ;

run;

I did run your code using the id statement and a version without the id statement and I did proc gmap.  I can see what you were talking about with the lines not lines up correctly without the id statement. 

But when I did a proc ginside using the 2 rows of data you created for Birmingham and Jefferson county no data is returned back.   I'm running your code as it is.

Thank you

[Darrell_sas]

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 */

[jerry898969]

Good morning Darrell,

I still have to re-run the map import because I used the select statement and only returned back state, county, tract and block.  GEOID10 is not in those tables.

I did do a test with mapimport where I didn't use id or select statements.  This returned everything.  With proc gmap I used ID GEOID10 and it gave me the same map that it did when I used the id statement with blockce10.

Thank you so much for all your help.

[jerry898969]

Hi Darrell,

I just ran a proc ginisde using this code and it doesn't return back the statefp10, countyfp10 or tractfp10.  It does return blockce10.

proc ginside

    data=addr

    map=blockData

    out=addr_out

    ;

    id blockce10 ;

run ;   

This is using data that I got from proc mapimport using id blockce10;

Can I add the other fields to my id statement within proc ginside?  Will it cause the data to be incorrect?

Thank you

[Darrell_sas]

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.