| From city to lati and long [message #174991] |
Mon, 01 August 2011 21:20  |
Sarah
Messages: 30
Registered: December 2010
Karma: 0
|
Member |
|
|
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_6t1bH2P 0vCI_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
|
|
|
|
| Re: From city to lati and long [message #174992 is a reply to message #174991] |
Mon, 01 August 2011 23:07  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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_6t1bH2P 0vCI_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(at)attglobal(dot)net
==================
|
|
|
|
|
|
|
|
|
|
| Re: From city to lati and long [message #175004 is a reply to message #175003] |
Tue, 02 August 2011 18:44 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
|
|
|
|
| Re: From city to lati and long [message #175023 is a reply to message #175022] |
Thu, 04 August 2011 03:20 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: From city to lati and long [message #175025 is a reply to message #174991] |
Thu, 04 August 2011 08:03 |
Paul Herber
Messages: 26
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
On Mon, 1 Aug 2011 14:20:03 -0700 (PDT), Sarah <dandi(dot)box(at)gmail(dot)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_6t1bH2P 0vCI_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/
|
|
|
|
| Re: From city to lati and long [message #175029 is a reply to message #175023] |
Thu, 04 August 2011 15:27 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: From city to lati and long [message #175030 is a reply to message #175029] |
Thu, 04 August 2011 18:24 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: From city to lati and long [message #175031 is a reply to message #175030] |
Thu, 04 August 2011 19:17 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: From city to lati and long [message #175032 is a reply to message #175031] |
Thu, 04 August 2011 19:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: From city to lati and long [message #175033 is a reply to message #175032] |
Thu, 04 August 2011 23:21 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: From city to lati and long [message #175034 is a reply to message #175033] |
Thu, 04 August 2011 23:58 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: From city to lati and long [message #175039 is a reply to message #175034] |
Fri, 05 August 2011 04:49 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: From city to lati and long [message #175043 is a reply to message #175039] |
Fri, 05 August 2011 10:20 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]