Thanks for the replies. No its not 32 bit/64 bit issue. (both 64 bit and its not a floating point issue anyway)
Correct: I dont need to *have* the problem except some of the requirements in the project require passing of 8 decimal place lat/longs in the url. I was hoping not to have to take steps to either: *change the db side to hold only 8 dec place points or *change the javascript front end to deal with variable dec place numbers. If there was something in the geodjango ORM i missed i hoped someone would pick it up and point me in that direction. Search radius instead of a finite point is not possible unfortunately. Plus if im dealing with a dataset where im evaluating 500+ points (upper bounds of my projected workload) I would need the answer evaluated as quickly as possible, radius calculation would be slower (how much slower depends on the algorithm used and other variables). If there's no option I will probably go with changing the code to handle variable length points on the javascript side. Thanks for your help. cheers sam_W On Wed, Aug 25, 2010 at 9:40 PM, J. Cliff Dyer <[email protected]> wrote: > Is one server 32 bit, while the other is 64 bit? It may be that on the old > server, your representations of the number were precise enough to be > identical, but on the new server, there is enough precision in the database > to represent different numbers. > > > > "Reinout van Rees" <[email protected]> wrote: > >>On 08/25/2010 02:57 AM, Sam Walters wrote: >>> Hi fellow Django developers >>> >>> I have Lat/Lng points stored in my db: >>> >>> class Airfield(models.Model): >>> point = models.PointField(srid=4326) >>> >>> I noticed when i query on my development server with postgresql i DONT >>> have to have the EXACT number of decimal places to find that point. >>> (what i want) >>> However on the production server if i ask for a point then i have to >>> give the exact same number with the same number of decimal places. >>> (undesired) >>> >>> Production server is postgresql-8.3 where as my development server is >>> postgresql-8.4 >>> >>> Obviously the db backend is behaving differently. >>> >>> 8.4: >>> -32.6666666667 == -32.66666667 >>> 8.3: >>> -32.6666666667 != -32.66666667 >> >>Obviously, this is a problem. >> >>But: do you need to *have* the problem? I mean, why would you look up >>the airfield in the DB, grab x/y and then try to grab the same one back >>again with the exact coordinates? >> >>Normally, searching by coordinates would mean clicking on a map which >>results in a DB query with a location plus a margin around that location. >> >>=> Can you work with a "search radius" in your query? >> >> >>Reinout >> >>-- >>Reinout van Rees - [email protected] - http://reinout.vanrees.org >>Programmer at http://www.nelen-schuurmans.nl >>"Military engineers build missiles. Civil engineers build targets" >> >>-- >>You received this message because you are subscribed to the Google Groups >>"Django users" group. >>To post to this group, send email to [email protected]. >>To unsubscribe from this group, send email to >>[email protected]. >>For more options, visit this group at >>http://groups.google.com/group/django-users?hl=en. >> >> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
