Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I have a project in which I want to "extract" all of the geocoded addresses from a street centerline file (with my defined offset and whatever other user defined input is needed). If it is helpful here is a description of what type of format a street centerline file is in.

Currently the only way I know how to do this would be a brute force geocode (i.e. make all possible options and geocode the points that way). Which isn't an impossible option but I would like to see if a more efficient means exists.

I mostly use ESRI software (I have access to machines running 9.2 and 9.3) but if an easier solution exists in some freeware package I'm open to anything. I also have access to MapInfo through my university which I would be willing to use if a simple solution exists. Also all of the street centerline files are in .shp format so any other program will have to either use the shapefile format or have the ability for me to convert the shapefile to a useable format (I assume a trivial step).

I have a very little bit of programming experience in Python (and more extensive experience with statistical software but that won't really help out here). So if I had code options I suppose an ArcScript with a GUI or Python would be preferred.

Also my "universe" of locations I am creating will include street intersections, so if anyone can point to a solution to extract all of the street intersections in the street centerline file (and record both the intersecting streets) I would appreciate this as well. I assume this is more likely to already exist in some ArcScript.

Edit: To address DavidF's concerns, I know what information is contained in a street centerline file, and I know they are not actual and verified street addresses. For this project I am not making my own geocoder, I am simply defining the universe of address locations according to the street centerline file itself (I also know this universe will be dependent on how far I decide to offset the address locations).

The immediate goal of this question is simply to define a coordinate for all potential addresses. I'm assuming all potential addresses are integers between the minimum and maximum values for the centerline. For this project it is ok that they are not real or verified.

For alittle bit more insight into the project and its goals, often with inferential spatial statistics distributions are created via creating random locations within your study boundary and calculating distributions from those random samples. Often times the universe of potential locations is dictated by residential addresses (i.e. a potential location has to be defined by whatever geocoder you are using, it can't be everywhere within the study boundary). Since these residential addresses are likely clustered in space, I want to see if functions like Ripley's K tend to be biased in using complete spatial randomness to define the sampling distribution as opposed to using the actual locations of addresses (defined apriori by whatever you are using to geocode those addresses).

I know that if I use a parcel based geocoder that pretty much all of these concerns are circumvented. I am still interested in extending the analysis to street centerline files though because as far as I'm aware street centerline files are still regularly used to geocode addresses, and so such a question is still pertinent. I plan on conducting the analysis with a parcel based geocoding system as well.

As far as DavidF's and Mark Ireland's concern about the "realness" of the addresses if I use every integer value, it is a legitmate concern given the nature of the project. If I use more addresses than really exist, it will induce artificial clustering of addresses. I would likely conduct post hoc specificity tests using Both David's suggestion (addresses only every 40 feet by a sampling strategy) and Mark's suggestion (verifying real addresses from some outside source). In either case I still want to be able to extract all the address points from the street centerline file. I am not verifying the accuracy of the geocoder from the onset, I am seeing if complete spatial randomness conforms to the distribution of points that a geocoding process could potentially give. I understand the errors associated with street centerline files, but I want to mimic how geocoding is actually conducted with a street centerline file.

Also if people can point to some literature that they think would be pertinent I would appreciate it. I know of a bit of work done on the accuracy of geocoding, but I have not seen any work addressing this particular issue.

share|improve this question
    
Apologies for the pedantic response... So, do you have an idea on a density for your points? (at least along the line?) Are you thinking of putting an address point every 40 feet (residential lot width) along lines offset on each side of a street segment? –  DavidF Oct 12 '10 at 14:39
    
I was originally thinking every integer value. While every 40 feet may be more realistic, I think my universe should be dictated by all possible address points according to the geocoder (I don't know for sure but I imagine ESRIs geocoder does not stipulate addresses need to be 40 feet apart). As far as density I was going to test two mid size urban cities (pop around 100 thousand to 200 thousand), I can't site any specific estimates of numbers offhand (if it will help I can figure that out). –  Andy W Oct 12 '10 at 14:57
    
As far as densities along the line the min and max values are often between 100 addresses (i.e. 100 to 199), but I do not know the average length of a street segment (I can find this out as well though if it will help). –  Andy W Oct 12 '10 at 14:59
    
Two thoughts. I it sounds like you are interested in simulating/representing real addresses. I think that depending on your analysis, simulating the density of the points would be more realistic than representing all potential address numbers. –  DavidF Oct 12 '10 at 18:21
    
@David, I am actually not interested in simulating "real" addresses. I am using the geocoder itself as the gold standard and seeing how well complete spatial randomness represents that gold standard. Even if I was interested in the density of points (in this example I give Ripley's K, which is measuring the distance between points) I don't think it makes any sense to simulate points a geocoder would never reasonably return. –  Andy W Oct 12 '10 at 21:29
show 1 more comment

3 Answers

up vote 2 down vote accepted

Presumably you'd need to calculate the length of the road, divide by the number of addresses, and create an offset point for the addresses according to this result.

This might be useful for some tasks, but to my mind this doesn't really help address the issue of randomness vs reality, since what you're creating is not a reliable representation.

For example, there might be a single high-rise building with 100 units. You could end up spreading these along the road segment, when they are a single cluster. Also, if you have a segment of road that isn't straight, then this is going to throw things out (as well as make the task of calculating the offset more difficult).

Perhaps the best way is to get commercial geocoded data - like post office address data. I believe that there is such data for both the UK and Canada (not sure where you are) and as an academic study the access to this info should be free of charge (which is good because the prices to purchase are astronomical). I would think this would be more reliable than geocoding via an online service.

share|improve this answer
    
I understand your concerns that geocoding every point is probably not a realistic representation. This is how it is done in practice though, and so my motivation is that apriori by using a street centerline file your universe of potential locations is already defined. I could use some alternative source to verify if an address exists though, and I have updated my question to reflect this and how I would address your concern. The source of the information is not an issue either, although I obviously can't get this information for everywhere, I do know some places I can get access to this. –  Andy W Oct 12 '10 at 23:47
add comment

I think that you may want to think a little about your work flow, the problem that you are trying to solve, and how your are trying to solve it.

A street segment with an address range doesn't store actual address points. Most geocoding engines will find the correct street segment, look at the length of that segment, look at the range of address numbers and then calculate where on the line the address point might be based on these values. e.g. if the address range for a segment goes from 200 to 300 on main street, and you want to place a point for 225 main street, the engine will determine a point 1/4th of the way down the path from the start node (200) to the end node (300).

You could extract a point for each integer value in the address range for each segment, but these would not be actual addresses. In the previous example, you would create 100 points, but there may only be 10 buildings with actual addresses on the block.

You could certainly use some Python code to find all of the street segments that share a node, but have different names. This would get you intersections.

Unless this is some sort of academic project, I wouldn't try to reinvent a geocoding engine. There are plenty of opensource and proprietary ones out there. The tricky/expensive part is getting good data to feed the engine.

share|improve this answer
    
I appreciate your response, but it actually is an academic project. I understand how street centerline files work, and I understand that they are not real addresses per say. I will update my question to reflect these concerns, but I am not making my own geocoder. I'm simply trying to find an efficient way to extract the points that current street centerline geocoding services already give when you attempt to geocode an address. –  Andy W Oct 12 '10 at 13:57
    
If you think that using real data is better, you might want to get parcel data from a county/municipality. You could either use the polygons or the centroids. You could also look at openaddresses.org to find a city where there is good address coverage openaddresses.org –  DavidF Oct 12 '10 at 18:23
    
I agree and that basically all of these issues are circumvented if I use a parcel based geocoder. My motivation to do an analysis using the street centerline file is because it is still a regular means in which to conduct geocoding. I will update my question again to reflect that I plan on doing a similar analysis using parcels as well as street centerlines. –  Andy W Oct 12 '10 at 23:30
add comment

Well Ill try to answer your question as I understand it.

1) I would make two copies of the street centerline file.

2) I would then split the centerline A-"left to address" from the B-"left from address"

3) Then I would do something like (BmiunsA)/2)) so 198-100=98/2 = 49.

4) I would then split the center line into 49-2 equal segments or just use simple code to place 47 points evenly split.

5) Redo 2-4 for the odd numbers, be careful on the math and remember the start and end points.

6) Now you have points for each address range in the file. Add Lat long or similar. Points can read the name of the road from a SJ or near function.

7) Intersections are easy. Just build a network and extract all the nodes to points. This has likely been done.

As for reading it is specialized stuff but try Hamilton, S. E. (2003). Government Data in GPS-Enabled Location Services: A Case Study of Ithaca. Government Date in GPS-Enabled Location Services: A Case Study of Ithaca, State University of New York at Buffalo. 1: 180.

Griffith, D. A., et al. (2007). "Impacts of Positional Error on Spatial Regression Analysis: A Case Study of Address Locations in Syracuse, New York." Transactions in GIS 11(5): 655-679.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.