2

I have created an Origin-Destination cost matrix showing the distance in feet between several thousand home addresses (origins) and about 24 rental vehicles (destinations) at various points throughout the city. Each address point that was input into the OD matrix analysis also originally contained information on the number of times the resident at each address had reserved a particular vehicle.

My goal is to create a table that will show, for all home addresses, the distance from that address to each of the 24 rental cars and the number of times the resident reserved each of the 24 cars. I could then say, for example, "40% of reservations made by residents of Neighborhood A are for cars within 1/2 mile" or "Residents who reserved car X lived an average of 2000 feet away".

Here is the problem. In conducting the OD matrix analysis, it seems that all the unique identifiers of the data that I input have been obliterated. It would appear that there is no way to associate the distances between origins and destinations back to the other attributes associated with the home address points except for some sort of spatial join. Yet, between the inaccuracies introduced by geocoding thousands of addresses and the fact that many home locations are apartments with multiple residents in the same building, it is impossible to distinguish which resident made which trips by using a spatial join.

How have others typically handled the origin-destination problem when origin points overlap and still need to be associated back to other attributes?

  • I dont see how this works because the fields added in the layers that are used to load locations does not show in the "origins" layer. Can you please discribe this method more detailed? Magnus – user61742 Nov 3 '15 at 15:17
2

This is a known "limitation" of all the solvers as far as I know.

I approach this problem through my work by doing the following. I add a unique field to each feature class that participates in the analysis, so you would need to uniquely identify each home address and each destination (rental care place). And use this field when loading locations for the Name field.

After solving the OD, open the attribute table of all three sublayers. I think I've shown clearly enough on the picture that you should be able to perform joins now since you have the values to base your join upon.

enter image description here

In case you want to refer to the source feature class, you would need to split the Name field in the Lines layer. This is why you needed a unique field in the first place.

I use a simple Python function for calculating the field, see the picture below. You can run Field Calculator on the Name field in the Lines layer. This will give you the origin name (a string before the "-" symbol")

def slicing(field):
    head, sep, tail = field.partition(':')
    return head.rstrip() 

enter image description here

  • Thank you! This method worked very well. I never considered sneaking the IDs through the solver by way of the name field. Appreciate the help - this problem has been bothering me for quite a while. – Mike Jul 10 '14 at 20:33
  • @Mike, you are welcome, no problem at all. I myself was puzzled after generating my service area polys some years ago and scratching my head thinking how to get the attributes from the source feature further in the workflow. – Alex Tereshenkov Jul 10 '14 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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