I have been using getLocations() to return one point if geographical
coordinates were entered, but after Google introduced reverse
geocoding the function returns multiple addresses, most of them being
garbage. The reverse geocoding was introduced with version 2.133
according to the API Reference, so I have tried getting the old
behavior back by specifying 2.97, but it makes no difference. I still
get reverse geocoding.

How can I avoid this (short of parsing and processing the input
string) and why don't I get version 2.97 behavior when I specify this
version?

Carl F

On Mar 2, 10:16 am, hiviking <c...@ullerup.com> wrote:

The first Placemark should be the most accurate (that is the location
returned by getLatLng).

That is because the geocoder/reverse geocoder is a server side service
and doesn't depend on the API version.

  -- Larry

Larry,
If server side functions do not depend on the API version, then there
is no way to preserve or guarantee a certain behavior by specifying
the version. That is not very good - to say the least.

That bahaviour is correct.  It'd be like insisting a search engine
should always return the same results for a given keyword, for ever.
Geocoding is an inexact art, and the geocoders are being improved -
well changing, anyway - constantly.

That is not the same at all. The issue is not the data that is
returned by the reverse geocoding function. The issue is that the API
functionality has changed. When I submitted getLocations() with
geographical coordinates before 2.133 I got the same point back, now I
get multiple locations none of which (in general) have the exact
coordinates that I entered. If you want to see the difference in
behavior, you can try entering coordinates at map.netkvik.dk (an
English version) and at kort.netkvik.dk, the Danish version that I
have just corrected so that it behaves like pre-2.133. The English
version will soon be corrected as well.

On Mar 2, 8:16 pm, hiviking <c...@ullerup.com> wrote:

You need reverse geocoding if you enter geographical coordinates and
expect addresses. How did you get any results before that.

You can filter the results by 'accuracy' value.

I think I see now , you were using the geocoder as a text parser.
Send it text "70.54, -4.32" and get a location back of 70.54, -4.32 in
an API-friendly format.  I'm afraid that wasn't what the geocoder was
really intended for, and things have moved on now.

You could look into other geocoding services (though I think you'll
hit similar issues) - or sort out a text parser, which should improve
your page's speed and reliability anyway by reducing the net traffic.

cheers, Ross K

Using the geocoder as a text parser is normal. When somebody enters a
wrong or unknown address the geocoder returns an error code indicating
why it could not provide a location. It does that by parsing the input
etc. In the past, when it found that the input was a set og
geographical coordinates it retuned the country name and the exact
location provided. This behavior has now been changed, and that is
fine, as long as you get the old behavior when you specify a version
before 2.133.

There is no way that this problem can be explained away. It is simply
an error in the Google API. That is what I wanted to point out in the
hope that Google might fix it. I am sure there are other users who
rely on the fact that when you specify version 2.97 you get version
2.97 behavior. At the moment you don't.

I can easily do my own parsing to detect a coordinates input, and that
is what I have already done on the Danish page. It is certainly the
right solution for the future, but the fact remains that you don't get
the behavior you expect when you specify older versions.

On Mar 3, 7:26 am, Thomas <c...@ullerup.com> wrote:

Was it documented behavior?  If not, it can change at any time.

  -- Larry

On Mar 3, 3:26 pm, Thomas <c...@ullerup.com> wrote:

But the version number is the *client* version number, not the version
number of server-side behaviour. The fact that the geocoder's
behaviour changed with v2.133 of the client doesn't mean that the old
behaviour will be available after that point.

However, you may have found a problem if you are supplying a string to
the getLocations() method and it's not behaving as the documentation
says it should. Reverse geocoding should work with a GLatLng object;
and if you supply a string it should do "forward" geocoding --
according to the documentation.

If you are supplying a string and it's being treated as a GLatLng
because it can be interpreted as that, you could validly claim it's a
departure from the documented behaviour.

BUT!! What you are describing is a form of reverse geocoding -- supply
something which looks like coordinates and get the country returned --
so that's undocumented behaviour too, and you can't rely on its being
available indefinitely.

Andrew

On Mar 3, 5:48 pm, Andrew Leach <andrew.leac...@googlemail.com> wrote:

That's true, it is not available anymore. It makes a full reverse
geocoding nowadays. We lost the country-only response which made
possible to define if a point is on an ocean or on a country.

Question : if you specify an older API version, would you expect to
get out-of-date map image tiles too?   It's very similar situation,
where the API is fetching some info from Googles servers which is
valid 'today' and not tied to the API version.

There's absolutely nothing to stop you raising it as a formal issue if
you feel it is the wrong behaviour.

"v=2.233d... Note however this should not be left in long term..."

Actually this is the preferred method for a production environment.
We have seen in the past where Google has broken the 2 version and
recommended that everyone change to the 2.x version!  A production
environment where people are relying on the accuracy of the data on
the maps needs stability and that means testing and testing in a QA
environment by the client before we go to production with a new Google
release.  The version included as v=2.s is 2.73 which is more than a
year old.  I think this is good from Google.  One year is long enough
for a production environment to move up a release but I also think
that the Google Maps API Notify group should post a warning at least
one month before a a version is removed.  You have to remember that
some production environments can require several levels of approval
and QA testing before production changes are allowed to occur. ;)

Such an environment should never be relying on external services over
which it has no control.  As already discussed, various aspects of
'the maps API' are server-supplied - map images, geocoding, etc. - and
you probably won't even be aware when they change.  But change they
will.   If you were to use, say, search features, the data that might
or might not be returned would be changing on a daily basis, and
certainly without QA approval..  That's the internet, QA procedures
appropriate for billing systems cannot be applied in the same way.

You could always ask for your money back?

cheers, Ross K

Ross, I hate to remind you but some customers are paying Google for
this service.  Not everyone is getting this service for free.

If you are suggesting that the Google Map API is not appropriate for a
production environment, don't you think that is something Google
should state up front before they send the bill?

On Apr 2, 1:51 pm, Tom NY <thomas.p...@gmail.com> wrote:

However...  this group supports the free API (pretty much).  Those
with premier licenses can get support from google.  And should
complain there.

Not suggesting that at all, I was pointing out that QA procedures
suited for static applications will find it hard to keep tabs on any
internet based services, it's a moving target.  Doing things like
pegging an API version is certainly the best you can do, but its not
the whole story.  Can't suggest any solutions for that!

You could dispute your bill of course, but I suspect you'd run into
the documentation issue again, "where does it promise the service you
came to rely on".

cheers, Ross K

And please, I am not complaining.  Pamela has asked for advice and
help in making their service even more useful.  Should we ignore her
and say it's fine as it is?  I'm not talking about reworking the API.
I'm not even asking for an enhancement to the API!!!  All I'm
suggesting is that the documentation be cleaned up a little and that
the Notify group be notified of all changes to the API.  Why does
anyone think that this is radical?

And production environments don't have to control everything but they
need to understand their potential exposure.  All I'm suggesting are
simple ways that Google can help minimize those exposures.

"If you were to use, say, search features, the data that might
or might not be returned would be changing on a daily basis, and
certainly without QA approval."

That isn't the same thing.  Getting different data is not unusual.
Anyone who uses a database does that without QA approval.  But if, for
example, I was using a search feature that returned the results in an
XML document and any day the tags of that XML document could change
without notification then yes, that would be a problematic service to
use in a production environment.  That doesn't mean that I wouldn't
use it if I had to but is does mean that I would need to understand my
exposure so that I could write my code to notify me when those tags
changed.