If I give a user the 'submit latitude/longitude' permission, any changes to postal code after the initial record creation does not result in a change to the lat/lon location data. This appears to be because the code handling the update in the nodeapi function ignores the postal code if lat/lon exist and the user has this permission. This may be by design, but it seems that there should be some way to allow both sets of fields to be present and discern which change to acknowledge (post code or lat/lon).

Comments

karens’s picture

karens commented
Status: Active » Closed (works as designed)

This is definitely by design if the user has the ability to set their own lat/lon. The problem is that the zip code lat/lon is generic -- it's the center point of the zip code. If someone goes to the trouble to set their own lat/lon (perhaps by using GMap), the point they set will almost certainly be more accurate than the center point of the zip code, so you wouldn't want to override their setting, esp if the change to the zip code was just to add or change the route number (the last 4 digits of a 10 digit zip) or if they changed it by mistake. So if you want the program to override the lat/lon the user set, you would have to be very careful and it would be hard to design a system that would pick out the right scenario and not wipe things out in the wrong situations.

The way to accomplish this manually when you change a zip is to wipe out the lat/lon at the same time. Then the program will update it.

I suppose you could change this to a feature request if you could figure out how to define the situation to make sure it only gets updated when it's supposed to.

smulkey’s picture

smulkey commented

Thanks for the quick response, sorry for the delay in follow up.

I can totally understand your reasoning for allowing lat/lon to take precedence over zip code and the location module code seems to reflect this explicit intention. I guess my hang up is the fact that the lat/lon is filled in automatically when the user provides address information and then this automatically generated data interferes with any future changes made by the user via the same interface. We would ideally like to give the user the option of entering via either method.

I suppose we could update our own code to intercept the form data and manually update the location information based one which fields changed and which remained, but this seems like a very brittle solution.

We'll play with it some more and if we find a reasonable alternative logic, we'll submit a feature request with either the suggested logic or a direct patch to the location module for consideration.

Thanks again for the response.

-SPM