-------- Original Message --------
Subject: Re: Phoenix street network data
Date: Tue, 17 Feb 2009 09:36:15 -0500
From: C.C. Miller <[log in to unmask]>
To: [log in to unmask]
References: <[log in to unmask]>
Chieko, I think this post will be very helpful to a lot of people in the
future. One additional possibility that we started to explore here
before we were pulled away to other work was using the PostGIS geocoder
(http://svn.refractions.net/postgis/trunk/extras/tiger_geocoder/)
<http://svn.refractions.net/postgis/trunk/extras/tiger_geocoder/%29>.
Our problem initially was that it was old -- not written for TIGER 2008
for sure -- so we were staring down the barrel of rewriting some queries
at least.
We didn't get far, but since TIGER 2008 is relatively complex,
postgres/postgis might offer a good mix of geospatial and traditional
dbms. If anybody is interested let me know. I have one grad student whom
I could put back on the trail if it looks like there was interest.
Chris
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C.C. Miller
Assistant Professor of Library Science
Geographic Information Systems Specialist
Purdue University Libraries
http://gis.lib.purdue.edu
feed://www4.lib.purdue.edu/gis/rss.php
[log in to unmask] <mailto:[log in to unmask]>
765.496.9474
[log in to unmask] <mailto:[log in to unmask]>
AIM=cecmcgee
[log in to unmask] <mailto:[log in to unmask]>
Twitter=http://twitter.com/pugolian
2215E EAS (CIVL)
Earth & Atmospheric Sciences Library (EAS)
Civil Engineering Building (CIVL)
550 Stadium Mall Drive
West Lafayette, IN 47907-2051
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Feb 17, 2009, at 9:23 AM, Maps-L Moderator wrote:
> -------- Original Message --------
> Subject: Re: Phoenix street network data
> Date: Mon, 16 Feb 2009 19:17:17 -0600
> From: Chieko Maene <[log in to unmask]
> <mailto:[log in to unmask]>>
> Reply-To: [log in to unmask] <mailto:[log in to unmask]>
> To: [log in to unmask] <mailto:[log in to unmask]>
> References: <[log in to unmask]
> <mailto:[log in to unmask]>>
>
>
>
> Hi everyone,
>
> I finally had a chance to create geocodable street data using TIGER2008
> - I had to. I know my patrons would ask me about it. Yes, TIGER2008 has
> been improved greatly, especially geometry-wise (more lines, spatially
> accurate) - how wonderful.
>
> Though, as Edward wrote, I realized it isn't easy to use TIGER2008 for
> geocoding. I thought it's just a matter of joining associated tables
> (EDGES/FEATNAMES/FACES) and merge fields in ArcGIS, but I was wrong. The
> main problem for me was the one-to-many relationship between EDGES and
> FEATNAMES. (In fact, EDGES's Prime Key TLID isn't unique - i.e. there
> are quite a few duplicate TLIDs in EDGES, looks like it's because the
> edges are between two counties - so, it's actually many-to-many
> relationship.) Since ArcGIS cannot handle one-to-many outer join (i.e.
> ArcGIS will grab only the first matching row information, not all
> matching rows), you would need another software that you are comfortable
> to use, statistical software or DBMS such as access or foxpro (my
> choice), so that you won't lose useful information/rows from FEATNAMES
> table.
>
> It worked for me in the end but I spent a whole weekend to do this. I
> think it's better if we can geocode addressed using relational
> geodatabase in ArcGIS, not using single-table shapefiles (i.e. streets)
> so that we can keep table relationships without combining to create a
> large and un-normalized single table (i.e. shapefiles.) I don't know if
> I can do that without ArcSDE though, and I would love to know how to do
> it. Or, I can just wait until ESRI releases a new version of StreetMap
> N.America dataset based on TIGER 2008..
>
> Or, as Edward pointed out, we can use third-party geocoding tools. I
> think the USC website is wonderful. I don't know if the USC geocoder is
> based on TIGER 2008, though.
>
> I was a fan of batchgeocoder but later, I found some inaccurate results.
> I also like to be able to select candidates for ambiguous addresses..
> kind of..
>
> One more thing: at the end, I wanted to know how good my result was - I
> tested my final TIGER2008 Chicago area roads data to geocode Chicago
> area addresses, and then compare the result with that of the ESRI 2008
> StreetMap N. America streets dataset (from ESRI Data & Maps 9.3,
> TeleAtlas base. *Not* a premium version.) To be fair, I clipped ESRI
> 2008 StreetMap streets using the same 7 counties boundaries. Then I
> geocoded the addresses under same conditions (i.e. same method: US
> Streets with City, State and ZIP, same thresholds, no alias tables,
> etc.) The results: Unmatched cases(%) without interactive matching,
> TIGER2008: 5,574 (23%) vs. ESRI2008: 5,650 (23%), total N was 24,158.
> Happily, TIGER2008 did slightly better than ESRI 2008 StreetMap, though
> the difference was minuscule.. (The reason for the high unmatched cases
> is because my addresses contained out-of-the-extent addresses, such as
> outside state addresses.)
>
> Just in case, here is what I did to create the Chicago metropolitan area
> (7 counties) geocodable streets. Please feel free to correct me if I am
> doing wrong.
>
> Also, if anybody wants the final data, you can download the Chicago
> metropolitan area TIGER2008 street file from here (no metadata..)
> http://www.library.northwestern.edu/map/TIGER2008_NE7CO_ROADS.zip (64MB)
>
> [Note: I didn't bother to add a extra address-ranges table (ADDR) since
> dealing with just three tables was enough for me. Well, I guess FACES is
> optional too, but it's good to include additional left/right side
> polygon attributes for those who like to aggregate data based on
> boundaries, i.e. tracts, blocks.]
>
> (1) In ArcGIS : append 6 counties EDGES shapefiles to the main county
> (cook county.) Select road edges only ([roadflg]='Y') and also get rid
> of miscellaneous road types we don't want to use, i.e. alleys and misc.
> trails ((MID([MMTFCC],1,3)='S17'OR (MID([MMTFCC],1,3)='S18') and then
> finally add a new identifier field, FID2 (copy value from FID), to keep
> a unique ID key for each polyline.
>
> (2) In DBMS software: append all 7 counties' FEATNAMES tables. Do the
> same for the 7 counties' FACES tables. Create a query, [EDGES left outer
> join FEATNAMES on EDGES.TLID=FEATNAMES.TLID]. From FEATNAMES, you will
> get parsed road information (dir, pretype, name, surfix, type) with
> variations of street names. (i.e. "E. Main St" in Cook County is also
> known as "W County Line Rd", "Main St", "Lake-Cook Rd", etc. We want all
> these variations/rows for better geocoding results.) After that, I got
> left and right sides face/polygon information by joining EDGE-FEATNAMES
> table and FACES, twice (left side, and then right side) - this part is
> straightforward since it's all one-to-one relationship.
>
> (3) Optional - In DBMS software: You can further continue to query
> (join) to get textual place and state abbreviation names, i.e.
> "Chicago", and "IL". Get the information from other TIGER tables (i.e.
> COUNTY or PLACE.) Also, you may want to rename fields so that ArcGIS can
> recognize geocodable fields (i.e. instead of LFROMADD, change it to
> L_F_ADD).
>
> (4) In DBMS software: find duplicate FID2 (unique identifier for EDGE
> shapefile polylines), and separate the duplicate sets by the number of
> duplicate (i.e. group1: duplicate 1, group2: duplicate 2, group3:
> duplicate 3, etc.. I found up to 9 duplicate name groups as a result of
> EDGES-FEATNAMES one-to-many joining.. I am not sure if this part makes
> sense to anybody..)
>
> (5) In ArcGIS: join EDGES polylines from (1) and the first group of the
> EDGE-FEATNAMES-FACES joined table from (4) using a common field,
> EDGES.FID and EDGES-FEATNAMES-FACES.FID2. Export as EDGES_1. Remove the
> previous join in EDGES polylines and join EDGES and the second group of
> EDGE-FEATNAMES-FACE (duplicate group 2) and then export only the joined
> rows (i.e. only rows with matching join fields) as EDGES_2. Repeat this
> for all duplicate group tables. Lastly, merge all EDGES groups (EDGES_1,
> EDGES_2, EDGES_3, etc.) by appending others to one.
>
> (6) Optional: I added a spatial index in ArcCatalog for faster rendering
> in ArcGIS. TIGER files don't come with these index files, .sbn & .sbx. I
> didn't add any attribute indexes since "create a geocode locator" will
> create indexes for geocoding.
>
> Sincerely,
> Chieko
> --
> Chieko Maene, MS, MLIS
> Maps & State Documents Librarian
> Government and Geographic Information and Data Services
> University Library
> Northwestern University
> 1970 Campus Drive
> Evanston, IL 60208-2300
> Phone: (847) 467-3679
> Fax: (847) 491-7603
> [log in to unmask] <mailto:[log in to unmask]>
> http://www.library.northwestern.edu/map/
> http://geospatial.edublogs.org/
>
>
> Maps-L Moderator wrote:
>> -------- Original Message --------
>> Subject: RE: Phoenix street network data
>> Date: Sat, 14 Feb 2009 12:28:52 -0800
>> From: Edward Sullivan <[log in to unmask]>
>> To: <[log in to unmask]>, <[log in to unmask]>
>> References: A<[log in to unmask]>
>>
>>
>>
>> This is a bit "outside the box", but rather than going to the trouble of
>> locating, standardizing, and performing quality checks on 'free' road
>> network and address layers, I've lately taken to using the Batch Geocode
>> site to do many of my smaller (< 5,000 addresses) geocoding tasks -
>>
>> http://www.batchgeocode.com/
>>
>> I believe the Yahoo! Geocoding API this 'mashup' page utilizes is using
>> the very good GDT/TeleAtlas road network base maps, so the quality of
>> the results are typically as good or better than what I can accomplish
>> with free data and desktop GIS geocoders.
>>
>> There are more advanced batch geocoding services available to academic
>> users without charge from the USC GIS Research Laboratory:
>>
>> https://webgis.usc.edu/
>>
>>
>>
>> Edward A. Sullivan, III
>> Senior Technical Associate
>> Economic & Planning Systems, Inc.
>> 2501 9th Street, Suite 200, Berkeley, CA, 94710-2515
>> Voice: 510-841-9190 FAX: 510-841-9208
>> Email: [log in to unmask]
>> Web site: www.epsys.com
>>
>> Due to the potential that information exchanged by electronic media can
>> deteriorate, be damaged, lost or modified, intentionally or otherwise,
>> use of this electronic data by anyone other than Economic & Planning
>> Systems, Inc. shall be at the sole risk of such user and without
>> liability or legal exposure to Economic & Planning Systems, Inc.
>>
>> The recipient is responsible for verifying the accuracy of data against
>> governing hard copy documentation. If there is a discrepancy between
>> the hard copy and the electronic copy, the hard copy will govern.
>>
>> Recipient assumes all risks in the changing or modification of data and
>> revisions or updating of hard copy documents.
>>
>> -----Original Message-----
>> From: Maps, Air Photo & Geospatial Systems Forum
>> [mailto:[log in to unmask]] On Behalf Of Maps-L Moderator
>> Sent: Friday, February 13, 2009 11:43 AM
>> To: [log in to unmask]
>> Subject: Phoenix street network data
>>
>> -------- Original Message --------
>> Date: Fri, 13 Feb 2009 11:38:48 -0800
>> From: andrew nicholson <[log in to unmask]>
>> To: <[log in to unmask]>, <[log in to unmask]>, tanya
>> <[log in to unmask]>
>>
>>
>>
>>
>> Hi everyone,
>>
>> My apologies for the cross posting.
>>
>> We are looking for a good quality road network for Phoenix Arizona to
>> allow students to geocode too. We have downloaded the Tigerline files,
>> but they are not very good for this purpose. Can anyone provide us with
>> suggestions for a source or two for high quality and free Phoenix street
>> network data?
>>
>> thanks for your help,
>> Andrew
>>
>>
>> --
>>
>> Andrew J.P. Nicholson
>>
>> GIS/Data Librarian
>>
>> Hazel McCallion Academic Learning Centre
>>
>> Room 360A
>>
>> University of Toronto Mississauga
>>
>> 3359 Mississauga Road North
>>
>> Mississauga, Ontario
>>
>> CANADA
>>
>> L5L 1C6
>>
>> Phone:(905)828-3886
>>
>> Fax:(905)569-4320
>>
>> Email: [log in to unmask]
>> <mailto:[log in to unmask]>
>>
>> Web: http://www.utm.utoronto.ca/library/
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> Windows Live(tm): Keep your life in sync. See how it works.
>> <http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks
>> _022009>
|
