Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #2686 > unrolled thread

From city to lati and long

Back to article view | Back to comp.lang.php

Contents

  From city to lati and long Sarah <dandi.box@gmail.com> - 2011-08-01 14:20 -0700
    Re: From city to lati and long Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-01 19:07 -0400
      Re: From city to lati and long Sarah <dandi.box@gmail.com> - 2011-08-02 01:19 -0700
        Re: From city to lati and long Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-02 06:50 -0400
      Re: From city to lati and long Sarah <dandi.box@gmail.com> - 2011-08-02 09:20 -0700
        Re: From city to lati and long Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-02 14:44 -0400
        Re: From city to lati and long A.Reader <anonymously@example.com> - 2011-08-02 15:53 -0400
      Re: From city to lati and long Sarah <dandi.box@gmail.com> - 2011-08-03 15:08 -0700
        Re: From city to lati and long Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-03 23:20 -0400
          Re: From city to lati and long Denis McMahon <denis.m.f.mcmahon@gmail.com> - 2011-08-04 15:27 +0000
            Re: From city to lati and long Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-04 14:24 -0400
              Re: From city to lati and long Denis McMahon <denis.m.f.mcmahon@gmail.com> - 2011-08-04 19:17 +0000
                Re: From city to lati and long Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-04 15:22 -0400
                  Re: From city to lati and long Denis McMahon <denis.m.f.mcmahon@gmail.com> - 2011-08-04 23:21 +0000
                    Re: From city to lati and long Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-04 19:58 -0400
                      Re: From city to lati and long Denis McMahon <denis.m.f.mcmahon@gmail.com> - 2011-08-05 04:49 +0000
                        Re: From city to lati and long Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-05 06:20 -0400
    Re: From city to lati and long Paul Herber <paul@pherber.com> - 2011-08-04 09:03 +0100

#2686 — From city to lati and long

Hi, I've created a PHP script that reads values from XML file

and that calculate longi and lati

$town = $event->town;
$position = $town . " " . $city . " " . $state;
$whereurl = urlencode($position);
$location = file("http://maps.google.com/maps/geo?q=
$whereurl&output=csv&key=ABQIAAAAvp3__HwvT3VkixIIbsW0axQuKI_6t1bH2P0vCI_Q8jfpn8qdNBQMnneljxh9czilkau_bYSCXteS_A");
list ($stat,$acc,$latitude,$longitude) = explode(",",$location[0]);


it works but sometimes lati and longi are both set to zero (in the
same record) .... and if I re-execute script I show differents records
set to zero .... can you help me?

Thanks

[toc] | [next] | [standalone]

#2687

On 8/1/2011 5:20 PM, Sarah wrote:
> Hi, I've created a PHP script that reads values from XML file
>
> and that calculate longi and lati
>
> $town = $event->town;
> $position = $town . " " . $city . " " . $state;
> $whereurl = urlencode($position);
> $location = file("http://maps.google.com/maps/geo?q=
> $whereurl&output=csv&key=ABQIAAAAvp3__HwvT3VkixIIbsW0axQuKI_6t1bH2P0vCI_Q8jfpn8qdNBQMnneljxh9czilkau_bYSCXteS_A");
> list ($stat,$acc,$latitude,$longitude) = explode(",",$location[0]);
>
>
> it works but sometimes lati and longi are both set to zero (in the
> same record) .... and if I re-execute script I show differents records
> set to zero .... can you help me?
>
> Thanks

Did you try asking in Google developer's support?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2692

No... where??

[toc] | [prev] | [next] | [standalone]

#2695

On 8/2/2011 4:19 AM, Sarah wrote:
> No... where??

On the google site?  And please learn to copy the question you're 
responding to.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2699

Can you give me link of group where I can send this kind of question??

I can't resolve this problem :(

[toc] | [prev] | [next] | [standalone]

#2700

On 8/2/2011 12:20 PM, Sarah wrote:
> Can you give me link of group where I can send this kind of question??
>
> I can't resolve this problem :(

No, I don't have the link handy - but it isn't too hard to find.  I 
would suggest you start with Google and look for developer support on 
their site.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2702

On Tue, 2 Aug 2011 09:20:26 -0700 (PDT),
Sarah <dandi.box@gmail.com> wrote:

>Can you give me link of group where I can send this kind of question??
>
>I can't resolve this problem :(

Try this, Sarah:
http://earth.google.com/support/bin/request.py

[toc] | [prev] | [next] | [standalone]

#2720

I can't find a solution :((( please help me!

[toc] | [prev] | [next] | [standalone]

#2721

On 8/3/2011 6:08 PM, Sarah wrote:
> I can't find a solution :((( please help me!

Ask in the right place and you'll get a good answer.  This isn't a PHP 
problem (other than maybe the parameters being sent are wrong - but that 
could be in any language).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2727

On Wed, 03 Aug 2011 23:20:28 -0400, Jerry Stuckle wrote:

> On 8/3/2011 6:08 PM, Sarah wrote:
>> I can't find a solution :((( please help me!
> 
> Ask in the right place and you'll get a good answer.  This isn't a PHP
> problem (other than maybe the parameters being sent are wrong - but that
> could be in any language).

There are, though, imo, php issues with the code, and php techniques that 
can be used to try and determine the problem.

eg test that location is not false, is an array and has a viable count 
before handling it as an array and passing its first element to explode.

if ($location === false) 
  {
  alert_mission_control("Houston, we have a problem! We failed to receive 
a file from google maps!");
  }
else if (!isarray($location))
  {
  alert_mission_control("Houston, we have a problem! We didn't get an 
array of lines from the file received from google maps!");
  }
else if (count($location) == 0)) 
  {
  alert_mission_control("Houston, we have a problem! The file of lines we 
got from google maps is empty!");
  }
else if (count($location) > $max_lines_in_google_maps_file)) 
  {
  alert_mission_control("Houston, we have a problem! The file of lines we 
got from google maps is too big!");
  }

eg use curl to retrieve the page, allowing better handling for timeouts 
and errors from the remote (google maps) web server, as well as checking 
of the return code such as:

$response_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
if ($response_code != "200") 
  {
  alert_mission_control("Houston, we have a problem! Google maps didn't 
respond with a 200 code, gave us {$response_code} instead");
  }

eg use php functions to test the returned values and write details of 
each request and the response received from the remote (google maps) web 
server to a suitable log file if one of $stat, $acc, $latitude, or 
$longitude is unexpectedly null, undefined or empty after the line:

list ($stat,$acc,$latitude,$longitude) = explode(",",$location[0]);

if ($latitude == null || $latitude = "" || floatval($latitude == 0.0))
  {
  alert_mission_control("Houston, we have a problem! Latitude is a weird 
value '{$latitude}'. Position was '{$position}' and Location[0] was 
'{$location[0]}'.");
  }
if ($longitude == null || $longitude = "" || floatval($longitude == 0.0))
  {
  alert_mission_control("Houston, we have a problem! Longitude is a weird 
value '{$longitude}'. Position was '{$position}' and Location[0] was 
'{$location[0]}'.");
  }

All of these, whilst not actually solving her problem, are things that 
can be done in php that might improve the robustness of the code and / or 
make it easier to determine what's going wrong.

For completeness:

function alert_mission_control($msg)
  {
  file_put_contents ("/home/<myname>/logs/something.log", 
      date(DATE_RFC2822) . " " . $msg . "\n", 
      FILE_APPEND);
  }

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#2728

On 8/4/2011 11:27 AM, Denis McMahon wrote:
> On Wed, 03 Aug 2011 23:20:28 -0400, Jerry Stuckle wrote:
>
>> On 8/3/2011 6:08 PM, Sarah wrote:
>>> I can't find a solution :((( please help me!
>>
>> Ask in the right place and you'll get a good answer.  This isn't a PHP
>> problem (other than maybe the parameters being sent are wrong - but that
>> could be in any language).
>
> There are, though, imo, php issues with the code, and php techniques that
> can be used to try and determine the problem.
>
<snip a bunch of crap>
> Rgds
>
> Denis McMahon

If you read her post, sometimes the code works and sometimes it fails - 
with *exactly the same parameters*.  The problem is NOT the PHP code.

She can try things for the next two years.  She can play with the PHP 
code until she's blue in the face.

Or she can go to the right place, get good help, and solve the problem 
quickly.  And if they need her to do some testing, they can tell her 
what they need done.

What you don't seem to understand is not everything using PHP code is a 
PHP problem, nor should it be approached that way.  She would have the 
same problem is she were using Perl, ASP.NET, Java or even C - because 
the problem is not on the Google maps side - and should be troubleshot 
from that angle.

But of course, that takes a little understanding of client/server 
relationships, and how to troubleshoot a failure in such an environment 
- which, from your previous posts espousing similar things, you clearly 
don't have.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2729

On Thu, 04 Aug 2011 14:24:31 -0400, Jerry Stuckle wrote:

> If you read her post, sometimes the code works and sometimes it fails -
> with *exactly the same parameters*.  The problem is NOT the PHP code.

Yes, and perhaps using a better method (curl vs file) for getting the web 
page might enable her to determine that sometimes she gets something 
other than the data that is expected. For example, maybe she gets a 4xx 
page and is trying to parse the first line of that with explode?

Her error then would be failing to handle the 4xx page appropriately, or 
even treating it as valid data.

Likewise validating that the contents of the received file met some basic 
criteria might help detect errors, and knowing what was being received 
when invalid data was generated by the explode could certainly help in 
determining what was causing the problem.

But I'm glad that you reject all of these possible php steps she could 
take to identify and solve her problem as irrelevant to discuss here 
because her problem doesn't fit your smallworld view of a php problem.

As I said, the underlying problem might not be the php code, but surely 
just as it is good practice to validate and verify everything one 
receives as form input before doing any calculations with it, so it is 
also a good idea to validate and verify that any data obtained from an 
external server is in an expected format before attempting to process it 
further ... which is part of what I am suggesting she do. The other parts 
of what I am suggesting she do are to use functions that give her a finer 
degree of control and feedback over the http request she makes, and that 
if she does detect an error, she records as much of the relevant data as 
possible for analysis to help determine the fault. These are all things 
that she can do in php that may help her discover what the issue is and 
find ways in php to mitigate (wait a few secs and retry the request 
perhaps if she gets an "upstream server error" or timeout type response) 
or gracefully fail.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#2730

On 8/4/2011 3:17 PM, Denis McMahon wrote:
> On Thu, 04 Aug 2011 14:24:31 -0400, Jerry Stuckle wrote:
>
>> If you read her post, sometimes the code works and sometimes it fails -
>> with *exactly the same parameters*.  The problem is NOT the PHP code.
>
> Yes, and perhaps using a better method (curl vs file) for getting the web
> page might enable her to determine that sometimes she gets something
> other than the data that is expected. For example, maybe she gets a 4xx
> page and is trying to parse the first line of that with explode?
>
> Her error then would be failing to handle the 4xx page appropriately, or
> even treating it as valid data.
>
> Likewise validating that the contents of the received file met some basic
> criteria might help detect errors, and knowing what was being received
> when invalid data was generated by the explode could certainly help in
> determining what was causing the problem.
>
> But I'm glad that you reject all of these possible php steps she could
> take to identify and solve her problem as irrelevant to discuss here
> because her problem doesn't fit your smallworld view of a php problem.
>
> As I said, the underlying problem might not be the php code, but surely
> just as it is good practice to validate and verify everything one
> receives as form input before doing any calculations with it, so it is
> also a good idea to validate and verify that any data obtained from an
> external server is in an expected format before attempting to process it
> further ... which is part of what I am suggesting she do. The other parts
> of what I am suggesting she do are to use functions that give her a finer
> degree of control and feedback over the http request she makes, and that
> if she does detect an error, she records as much of the relevant data as
> possible for analysis to help determine the fault. These are all things
> that she can do in php that may help her discover what the issue is and
> find ways in php to mitigate (wait a few secs and retry the request
> perhaps if she gets an "upstream server error" or timeout type response)
> or gracefully fail.
>
> Rgds
>
> Denis McMahon

Sure, I reject them - because I believe in finding the PROBLEM - not 
guess and try things until something might work *right now*.    She can 
do that - she can jump up and down on the sofa, or hold her breath until 
she's blue in the face.  All have an equal likelihood of finding the 
problem.

Without knowing the cause of the problem, you don't know if it's fixed 
or not.  Maybe it's gone away for now, for instance.  Or maybe it only 
happens under specific server or network conditions.

And without finding the problem, you don't know if you have it solved.

But hackers don't care about that.  All they care is finding something 
that works *right now*.  Real programmers care about finding something 
that works *all the time*.

And when you do find the source of the problem, often the code to solve 
the problem becomes much easier and straightforward.  Not always - 
sometimes it's the code on the server which needs to be fixed, for instance.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2731

On Thu, 04 Aug 2011 15:22:20 -0400, Jerry Stuckle wrote:

> Sure, I reject them - because I believe in finding the PROBLEM - not
> guess and try things until something might work *right now*.    She can
> do that - she can jump up and down on the sofa, or hold her breath until
> she's blue in the face.  All have an equal likelihood of finding the
> problem.

So you reject the suggestions I make to try and find the problem because 
you believe the correct solution is to find the problem.

The "problem" might be:

(a) she is making a malformed request (that she will need to refer to 
google)
(b) she is sometimes getting valid data in different format to that which 
she expects (the logging I suggest will help identify that problem)
(c) she is occasionally getting something other than a 200 response from 
the google maps server but she is not recognising let alone handling that 
response (the logging I suggest will help identify that problem, and 
using curl instead of file to get the page will provide a better 
mechanism to handle such cases)

Now I will agree that from her description of the problem I have no idea 
what is causing these errors. Clearly nor does she, and clearly nor do 
you. That's a given.

However, I believe that there are constructive steps that can be taken 
using php to identify several possible issues that might be arising and 
in some cases mitigate or resolve those issues.

I'm pretty sure that, for example, opening a url with "file()" won't pay 
any attention to response codes, so the content of the array that you 
assign the return of the function call to (given that the return value 
was not false, something she doesn't test for) could be an error page, 
some sort of redirection, etc.

But she's using file and assuming that she always gets csv data whose 
first line is in a standard format.

The first rule of getting data from an external source is surely to 
sanitise, verify and validate?

Which is why I also think she should check that what she gets is what she 
expects before she starts doing things like exploding it. And if she has 
a csv string, there may be better ways to process that too.

eg if she thinks expects a 4 value csv string:

<?php
$arr = str_getcsv ($the_string_of_csv_data);
$items = count($arr);
if ($items !== 4)
  {
  alert_mission_control("Houston, we have a problem! Found {$items} 
elements in the csv data, expected 4 elements. position was 
'{$position}', location[0] was '{$location[0]}'")
  }
?>

might be a better approach than her:

<?php
list ($a, $b, $c, $d) = explode (",", $the_string_of_csv_data);
?>

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#2732

On 8/4/2011 7:21 PM, Denis McMahon wrote:
> On Thu, 04 Aug 2011 15:22:20 -0400, Jerry Stuckle wrote:
>
>> Sure, I reject them - because I believe in finding the PROBLEM - not
>> guess and try things until something might work *right now*.    She can
>> do that - she can jump up and down on the sofa, or hold her breath until
>> she's blue in the face.  All have an equal likelihood of finding the
>> problem.
>
> So you reject the suggestions I make to try and find the problem because
> you believe the correct solution is to find the problem.
>
> The "problem" might be:
>
> (a) she is making a malformed request (that she will need to refer to
> google)
> (b) she is sometimes getting valid data in different format to that which
> she expects (the logging I suggest will help identify that problem)
> (c) she is occasionally getting something other than a 200 response from
> the google maps server but she is not recognising let alone handling that
> response (the logging I suggest will help identify that problem, and
> using curl instead of file to get the page will provide a better
> mechanism to handle such cases)
<More crap snipped>
>
> Rgds
>
> Denis McMahon

Yes, I reject it.  The problem is not:

a) If you actually READ her message, a retry works fine.  But if it is a 
malformed request, the problem should be troubleshot from the server - 
where the problem with the request can be identified.

b) Again, if that were the case, the problem is not in her request - but 
in the server responding improperly.

c) She may or may not be getting other than a 200 response from the 
server - but that would be a server or network problem, not something in 
her code, and should be troubleshot from the server.

In all cases, the problem is independent of the language, because the 
server has no idea what language is being used on the client side.

She can keep experimenting until the end of the world, and may or may 
not find the problem.  Or she can get the PROPER support and find out 
what's actually going on - from the server end.

Programmers find the problem and resolve it.  Hackers just keep trying 
with the code until it works at the time, without finding the real 
problem - which means it can fail again.

You obviously have no idea how to troubleshoot a client-server problem. 
  Not everything is a PHP problem just because the code is PHP.  And not 
everything should be troubleshot as a PHP problem just because the code 
is PHP.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2737

On Thu, 04 Aug 2011 19:58:51 -0400, Jerry Stuckle wrote:

You don't read anything do you.

I'm not suggesting it's a php problem. I'm not suggesting she 
troubleshoot it as a php problem.

I am suggesting that:

a) There may be better ways in php to do what she is doing in php; and
b) there may be things she can do in php that will help her identify and 
resolve the problem; and
c) some of a might even also help with b.

As she doesn't have access to the server, and as it's reasonable to 
assume that the server either works for everyone or is broken for 
everyone, there's a good chance that the problem is either:

a) she isn't sending the right request to the server; or
b) she isn't getting what she expects from the server.

Now both of these are probably issues between her code and the server 
specs for what it expects / responds with.

The first place she should look, obviously, is the specs for the server, 
what it expects, and what it replies with. Yes, I don't dispute that at 
all.

However, it might also help if, for example, she dumps a failed request, 
looks at the response data and discovers an error message or error code 
in it that relates to the server documentation.

She can then determine what she might be doing in forming the request 
that she sends which causes that error. However, to do this, first of all 
she needs to find the error code, which is why I still maintain that, 
when she gets a failed request, she should try and preserve the original 
request url and the response text and study them to try and see what's 
happening.

Obviously this doesn't match your response to fault finding complex 
systems. Well I'm very sorry, but 20+ years of troubleshooting 
interconnected systems have taught me that if you have any sort of 
communication problem between two such systems, capturing and 
understanding the data that is being transferred in both directions is a 
very important part of understanding and fixing the problem, whether 
you're talking about telephone billing data being transferred from an 
exchange in germany to a billing processor in the uk, signals between 
processors inside a telephone exchange, data being transferred from a 
software module written in fortran to a software module written in pascal 
through interfaces written in ada, or the launch commands that a plane 
sends to a heat seeking missile.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#2741

On 8/5/2011 12:49 AM, Denis McMahon wrote:
> On Thu, 04 Aug 2011 19:58:51 -0400, Jerry Stuckle wrote:
>
> You don't read anything do you.
>
> I'm not suggesting it's a php problem. I'm not suggesting she
> troubleshoot it as a php problem.
>
> I am suggesting that:
>
> a) There may be better ways in php to do what she is doing in php; and
> b) there may be things she can do in php that will help her identify and
> resolve the problem; and
> c) some of a might even also help with b.
>
> As she doesn't have access to the server, and as it's reasonable to
> assume that the server either works for everyone or is broken for
> everyone, there's a good chance that the problem is either:
>
> a) she isn't sending the right request to the server; or
> b) she isn't getting what she expects from the server.
>
> Now both of these are probably issues between her code and the server
> specs for what it expects / responds with.
>
> The first place she should look, obviously, is the specs for the server,
> what it expects, and what it replies with. Yes, I don't dispute that at
> all.
>
> However, it might also help if, for example, she dumps a failed request,
> looks at the response data and discovers an error message or error code
> in it that relates to the server documentation.
>
> She can then determine what she might be doing in forming the request
> that she sends which causes that error. However, to do this, first of all
> she needs to find the error code, which is why I still maintain that,
> when she gets a failed request, she should try and preserve the original
> request url and the response text and study them to try and see what's
> happening.
>
> Obviously this doesn't match your response to fault finding complex
> systems. Well I'm very sorry, but 20+ years of troubleshooting
> interconnected systems have taught me that if you have any sort of
> communication problem between two such systems, capturing and
> understanding the data that is being transferred in both directions is a
> very important part of understanding and fixing the problem, whether
> you're talking about telephone billing data being transferred from an
> exchange in germany to a billing processor in the uk, signals between
> processors inside a telephone exchange, data being transferred from a
> software module written in fortran to a software module written in pascal
> through interfaces written in ada, or the launch commands that a plane
> sends to a heat seeking missile.
>
> Rgds
>
> Denis McMahon

Oh, I read everything you wrote.  And rather than troubleshooting the 
problem, you want to just blindly hack some code until it works.

20 years of troubleshooting interconnected systems - if you really had 
that (probably more like 20 minutes), then you didn't learn much.

But then you've repeatedly shown here that you have no idea how to find 
a problem - you just hack away until you find something that works.

Good programmers find the problem and fix it.  They don't just keep 
trying things until they find something that works - like you have been 
suggesting.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2723

On Mon, 1 Aug 2011 14:20:03 -0700 (PDT), Sarah <dandi.box@gmail.com> wrote:

>Hi, I've created a PHP script that reads values from XML file
>
>and that calculate longi and lati
>
>$town = $event->town;
>$position = $town . " " . $city . " " . $state;
>$whereurl = urlencode($position);
>$location = file("http://maps.google.com/maps/geo?q=
>$whereurl&output=csv&key=ABQIAAAAvp3__HwvT3VkixIIbsW0axQuKI_6t1bH2P0vCI_Q8jfpn8qdNBQMnneljxh9czilkau_bYSCXteS_A");
>list ($stat,$acc,$latitude,$longitude) = explode(",",$location[0]);
>
>
>it works but sometimes lati and longi are both set to zero (in the
>same record) .... and if I re-execute script I show differents records
>set to zero .... can you help me?

Have you considered what happens if Google is slow to respond to your request?
Try using the cURL functions.



-- 
Regards, Paul Herber, Sandrila Ltd.
http://www.sandrila.co.uk/          

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web