Coordinates

[GoogleCodeExporter]

Add possibility insert coordinates to Geotoad in a format that is used on 
Geocaching, ie e.g. N 49° 14.574 E 016° 40.412
and not as it is now - N49 14.574 E016 40.412,
because every time I have to input the coordinates editing.

Original issue reported on code.google.com by tomus...@gmail.com on 8 Sep 2012 at 6:44

[GoogleCodeExporter]

What's your version and OS?
With Debian Linux, and the "-v" option, I get

...
( o ) Coordinates "N 49° 14.574 E 016° 40.412" parsed as latitude 49.2429000, 
longitude 16.6735333
...

which seems to be the right thing.
Actually, leading N|S|E|W (which may be followed by any amount of white space) 
should be interpreted as "signs", and "°" should be stripped. If that doesn't 
happen in your case, I'd like to know the details.

Original comment by Steve8x8 on 9 Sep 2012 at 8:23

• Changed state: InfoNeeded

[GoogleCodeExporter]

I am using Windows XP SP3,
if I put the coordinates in the format N 49 ° 14.574 E 016 ° 40.412 ,
so Geotoad crashes after starting the download caches.

Original comment by tomus...@gmail.com on 9 Sep 2012 at 8:53

[GoogleCodeExporter]

( o ) Coordinates "N 49 ° 14.574 E 016 ° 40.412" parsed as latitude 
49.3927778, longitude 16.7811111

May I see your debugging output then? (starting with "D: D/T/S decoding uses 
code ...")

... unable to reproduce - must be a codepage issue (?)
Can you write the coordinates (as entered into GeoToad) into a file, and upload?

Original comment by Steve8x8 on 10 Sep 2012 at 7:17

[GoogleCodeExporter]

I make print screen:
http://pub.upczone.cz/geotoad.avi

Original comment by tomus...@gmail.com on 10 Sep 2012 at 3:29

[GoogleCodeExporter]

Umm, you haven't been using "coord" but "location".

Yes, there's a difference: "coord"s are interpreted by GeoToad while 
"location"s are handed over to Google Maps, without _any_ sanitizing. (And I 
can hardly imagine how sanitizing place names should look like.)

Your video shows that there's a (hex) F8 in the location string. Google Maps 
seems to choke on that.
I'm afraid the same would happen with other special characters in the search 
string, at least with non-UTF-8 environments (what does "chcp" on the cmd line 
return for you? What happens if you search for a place name containing umlaut 
characters?)

Would it be OK for you to enter coordinates into a "coord" query? From my POV 
this fixes the issue. (Your report wasn't useless though, as I found another 
small glitch, introduced after the previous release.)

Another hint: If you open a terminal ("Run" "cmd"), and type 
c:\Programs\GeoToad\geotoad.exe, the window won't close when GeoToad exits, and 
you've got plenty of time to copy&paste...

Original comment by Steve8x8 on 11 Sep 2012 at 8:26

• Changed state: Accepted

[GoogleCodeExporter]

Addendum:
"N 49 ° 14.574 E 016 ° 40.412" maps to a place in Turkey 
(37.9240707,40.1999024) while
"N 49° 14.574 E 016° 40.412" (and "N 49 14.574 E 016 40.412") points to a 
Czech railway station. Try Google Maps.
That means that not only special characters make a difference with Google Maps 
- even innocent blanks do. Another reason not to use "location"s if there are 
"coord"s.

Original comment by Steve8x8 on 11 Sep 2012 at 8:42

[GoogleCodeExporter]

OK,I understand, when setting "coord" in "(2) Search type", it works without 
any problems.

And I have one small question:
is possible filtered in Geotoad caches that I have found ?

Thanks.

Original comment by tomus...@gmail.com on 11 Sep 2012 at 1:59

[GoogleCodeExporter]

What about (16) and (18)?
(Command line options -e/-E. A manual page, converted to pdf, will come with 
the next release.)

Original comment by Steve8x8 on 12 Sep 2012 at 8:21

• Changed state: FixAvail

[GoogleCodeExporter]

Issue is supposed to be taken care of by recent 3.16.2 release.

Original comment by Steve8x8 on 28 Sep 2012 at 11:27

• Changed state: Fixed