Investigate convert_to_block issue #43

Open
copelco opened this Issue Jun 5, 2012 · 1 comment

Comments

Projects
None yet
2 participants
Contributor

copelco commented Jun 5, 2012

It seems like using convert_to_block=True will always convert to a block address. For example, 7683 Sidney Cherry Grove Road becomes 7600 block of Sidney Cherry Grove Road. My initial impression was that it should only do this if it doesn't find a matching address.

Contributor

kmtracey commented Jun 5, 2012

Yes, if convert_to_block is set to True for newsitem creation then the address will, unconditionally, be converted to a block address at some point during the newsitem creation. To avoid that what I had done at one point was leave convert_to_block at the default of False when calling newsitem create, but force it to True in the newsitem geocode method when calling the address geocoder. This would result in the address geocoder changing the address to a block address if it was unable to locate the specific address but leave the address as a specific address in cases where that address was able to be geocoded directly.

It seems to be an argument that is used to two slightly different purposes at two different levels of the code. We want the fallback behavior it provides at the low-level geocoding step, but don't want the address-changing behavior that is present in some higher level. I mentioned this issue to Paul as a reason why setting convert_to_block to true by default probably isn't desirable, at least with its current behavior. (I think this was in the most recent thread about geocoding success on the mailing list.) Changing the behavior at the upper level may be an option, since at the lower level the address will be changed if it was necessary to get a match...but that would affect anyone who was actually wanting all their newsitem addresses converted unconditionally to block addresses, if anyone like that exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment