loss of lat and lng decimals

51 views
Skip to first unread message

Nico Oudshoorn

unread,
Jul 11, 2011, 2:34:25 PM7/11/11
to google-map...@googlegroups.com
This is from a site of mine. In an example that I tested, the outcome of $vanposlat was 52.133333. $zoekafstand = 15. The result of  $zoekafstand / (69 * 1.61) = 0,1350256. And surprise surprse $maxlat = 52.1350256???? So we lost the 0.133333???? However when I echo $vanposlat it = 52.133333, but if I do whatever calculation with it, you calculate only with 52??????
 
Any suggestions?
 
$url = "http://maps.googleapis.com/maps/api/geocode/xml?address=".urlencode($zoekpos)."&sensor=false";
   $geo = new SimpleXMLElement(file_get_contents($url));
   if ($geo->status == "OK") {  
    $vanposlat = $geo->result->geometry->location->lat;
    $vanposlng = $geo->result->geometry->location->lng;
    $maxlat = $vanposlat + ( $zoekafstand / (69 * 1.61)); // 69 miles per degree of latitude

Andrew Leach

unread,
Jul 12, 2011, 5:10:48 AM7/12/11
to google-map...@googlegroups.com

I will guess that "$zoekafstand" is a search radius in kilometres, and
you're attempting to convert that into degrees via a figure in miles.

So you are using an approximate km/miles conversion, and then a
conversion from miles to degrees which only works in a north-south
direction (and again, is approximate).

And you're complaining that going through two approximations doesn't
produce an exact result. (0.000001deg is under 7cm E-W at 52N, and
around 11cm N-S)

Solution: don't use that method. Use the haversine method to calculate
distance server-side, or the API's methods client-side.

Nico Oudshoorn

unread,
Jul 12, 2011, 8:29:35 AM7/12/11
to google-map...@googlegroups.com, andrew....@gmail.com
I use the same method in my version 2 site. There I don't have this problem. $zoekafstand isn't the problem. $vanposlat is the problem. If $zoekpos is zutphen in the netherlands then the result $vanposlat = 52.133333. But in the calculation with the result $maxlat, the value of $vanposlat is 52 instead of 52.13333. That gives a difference with the V2 solution. So in $maxlat Th V2 result is 0,133333 higher and that is the correct result. Why I don't know. The same problem of course with $vanposlng.    

Andrew Leach

unread,
Jul 12, 2011, 8:42:22 AM7/12/11
to google-map...@googlegroups.com
On 12 July 2011 13:29, Nico Oudshoorn <ni...@meerijden.nu> wrote:
> I use the same method in my version 2 site. There I don't have this problem.
> $zoekafstand isn't the problem. $vanposlat is the problem. If $zoekpos is
> zutphen in the netherlands then the result $vanposlat = 52.133333. But in
> the calculation with the result $maxlat, the value of $vanposlat is 52
> instead of 52.13333. That gives a difference with the V2 solution. So in
> $maxlat Th V2 result is 0,133333 higher and that is the correct result. Why
> I don't know. The same problem of course with $vanposlng.

"Why" is because you're using the wrong method, as I explained
earlier. If you want to convince me (and, presumably, Google) that
you're using the right method, you're going to have to provide some
worked examples with real data.

Rossko

unread,
Jul 12, 2011, 10:32:34 AM7/12/11
to Google Maps JavaScript API v3
> the calculation with the result $maxlat, the value of $vanposlat is 52
> instead of 52.13333. That gives a difference with the V2 solution.

If you think your sum is giving the wrong answer then the php
interpreter on your server is broken.

Just possible whatever numbers you generate are being interpreted
differently at the client, if they are getting sent to the client (we
can't tell as you haven't shown us anything helpful about that)

I would be looking very carefully at the input to your sum, as the
geocoding result starts out as a string. You happened to use a comma
as a decimal indicator in your first post about this, perhaps that is
related.

Nico Oudshoorn

unread,
Jul 12, 2011, 1:07:25 PM7/12/11
to google-map...@googlegroups.com, andrew....@gmail.com

Both are version 3

In this page the lat and lng are geberated at the client side and come on the server side from $zoekaklat and $zoekaklng:
$naarposlat = $zoekaklat; // = 51.49457580000001
$naarposlng = $zoekaklng; // = 4.287162200000012
if($naarposlat==0 and $naarposlng==0) {
 $zoekmessage2 = $arz_zoekmessage;
}
else {
 $maxlat = $naarposlat + ( $zoekakafstand / (69 * 1.61)); // 69 miles per degree of latitude
 $minlat = $naarposlat - ( $zoekakafstand / (69 * 1.61));
 $maxlng = $naarposlng + ( $zoekakafstand / ( 69.172 * 1.61 * cos( $naarposlat * 0.0174533 ) ) );
 $minlng = $naarposlng - ( $zoekakafstand / ( 69.172 * 1.61 * cos( $naarposlat * 0.0174533 ) ) );
 $ritten = "SELECT *,(6366*acos(cos(radians(".$naarposlat."))*cos(radians(`naarpllat`))*cos(radians(`naarpllng`)-radians(".$naarposlng."))+sin(radians(".$naarposlat."))*sin(radians(`naarpllat`)))) AS verschil FROM ritten force index (naarpositie) WHERE vraag_aanbod like '$ag' AND naarpllat < $maxlat AND naarpllat > $minlat AND naarpllng < $maxlng AND naarpllng > $minlng AND vertrekdatum >= '$datum' HAVING verschil <= $zoekakafstand";

This select statement is the echo of $ritten:
SELECT *,(6366*acos(cos(radians(51.49457580000001))*cos(radians(`naarpllat`))*cos(radians(`naarpllng`)-radians(4.287162200000012))+sin(radians(51.49457580000001))*sin(radians(`naarpllat`)))) AS verschil FROM ritten force index (naarpositie) WHERE vraag_aanbod like 'A%' AND naarpllat < 51.6296014549 AND naarpllat > 51.3595501451 AND naarpllng < 4.50350079762 AND naarpllng > 4.07082360238 AND vertrekdatum >= '2011-07-12' HAVING verschil <= 15


This is from another page where the lat and lng are generated on the server side:
$url = "http://maps.googleapis.com/maps/api/geocode/xml?address=".urlencode($zoekpos2)."&sensor=false";
$geo = new SimpleXMLElement(file_get_contents($url));
usleep(1750000);


if ($geo->status == "OK") {

 $naarposlat = $geo->result->geometry->location->lat; // = 51.4945758 in the calculation this is handled as 51 ???
 $naarposlng = $geo->result->geometry->location->lng; // = 4.2871622 in the calculation this is handled as 4 ???
 $maxlat = $naarposlat + ( $zoekafstand2 / (69 * 1.61)); // 69 miles per degree of latitude
 $minlat = $naarposlat - ( $zoekafstand2 / (69 * 1.61));
 $maxlng = $naarposlng + ( $zoekafstand2 / ( 69.172 * 1.61 * cos( $naarposlat * 0.0174533 ) ) );
 $minlng = $naarposlng - ( $zoekafstand2 / ( 69.172 * 1.61 * cos( $naarposlat * 0.0174533 ) ) );
 $ritten = "SELECT *,(6366*acos(cos(radians(".$naarposlat."))*cos(radians(`naarpllat`))*cos(radians(`naarpllng`)-radians(".$naarposlng."))+sin(radians(".$naarposlat."))*sin(radians(`naarpllat`)))) AS verschil FROM ritten force index (naarpositie) WHERE vraag_aanbod like '$ag' AND naarpllat < $maxlat AND naarpllat > $minlat AND naarpllng < $maxlng AND naarpllng > $minlng AND vertrekdatum >= '$datum' HAVING verschil <= $zoekafstand2";

This select statement is the echo of $ritten:
SELECT *,(6366*acos(cos(radians(51.4945758))*cos(radians(`naarpllat`))*cos(radians(`naarpllng`)-radians(4.2871622))+sin(radians(51.4945758))*sin(radians(`naarpllat`)))) AS verschil FROM ritten force index (naarpositie) WHERE vraag_aanbod like 'A%' AND naarpllat < 51.1350256549 AND naarpllat > 50.8649743451 AND naarpllng < 4.2140244802 AND naarpllng > 3.7859755198 AND vertrekdatum >= '2011-07-12' HAVING verschil <= 15

So, in my opinion the input is the same, the formulas are the same and the outcome is different. Thats is because the lat and lng are handled in the calcultation as integers without decimals.

Andrew Leach

unread,
Jul 12, 2011, 3:27:14 PM7/12/11
to google-map...@googlegroups.com
On 12 July 2011 18:07, Nico Oudshoorn <ni...@meerijden.nu> wrote:
>
> This is from another page where the lat and lng are generated on the server
> side:
> $url =
> "http://maps.googleapis.com/maps/api/geocode/xml?address=".urlencode($zoekpos2)."&sensor=false";

What is the address you are using? What is the XML you are getting?

> $geo = new SimpleXMLElement(file_get_contents($url));
> usleep(1750000);
> if ($geo->status == "OK") {
>  $naarposlat = $geo->result->geometry->location->lat; // = 51.4945758 in the
> calculation this is handled as 51 ???

So the only difference is how $naarposlat is derived. One is set via a
$_GET parameter? And the other is derived from the XML.

I think I concur with Rossko: either something is broken or there are
issues with commas and points and internationalisation. $naarposlat
would be handled as an integer if the decimal character is not what is
expected.

Nico Oudshoorn

unread,
Jul 13, 2011, 8:35:11 AM7/13/11
to google-map...@googlegroups.com, andrew....@gmail.com
$naarposlat = $geo->result->geometry->location->lat;
 
the problem is this geo result. In ths example the echo is 51.4945758. But even if you only multiply it by 1 the result is 51. In the meantime I let the lat and lng come from the client side. But I am still wandering why on the server side this problem comes up. So the georesult has somthing that has the size of a point, looks like a point but acts like .......

Andrew Leach

unread,
Jul 13, 2011, 8:51:28 AM7/13/11
to google-map...@googlegroups.com

I still reckon it's an internationalisation problem -- that's exactly
the behaviour which will be seen if your decimal point is an
unexpected character. And it's a PHP issue, not a Maps problem per se.

Rossko

unread,
Jul 13, 2011, 9:07:45 AM7/13/11
to Google Maps JavaScript API v3
> the problem is this geo result. In ths example the echo is 51.4945758

Reminder ; that is a string. Have a play with the various php tools
like floatval to see what you get as a number.

Nico Oudshoorn

unread,
Jul 13, 2011, 10:25:30 AM7/13/11
to google-map...@googlegroups.com
I did the following test:
 
$url = "http://maps.googleapis.com/maps/api/geocode/xml?address=".urlencode($adress)."&sensor=false";
$geo = new SimpleXMLElement(file_get_contents($url));

if ($geo->status == "OK") {
 $vanpllat = $geo->result->geometry->location->lat;
echo $vanpllat;  //result = 52.1333333
$aa = $vanpllat * 1;
echo $aa; //result = 52
$aa = floatval($vanpllat);
echo $aa; //result = 52.1333333
so the conclusion is that you have to floatval the geo result before you can use it in a calculation. Thank you for your cooporation.
Reply all
Reply to author
Forward
0 new messages