coordinates problem

[msand42]

I have a set pictures, taken at a local park, to be added to Panoramio. I first marked their locations in Google Earth using the Placemark tool. Here is one example of the problem:

The Placemark in Google Earth is 41°51'16.32"N 88° 9'7.04"W.
I uploaded the picture to Panoramio and with "Map this photo" entered the same location 41°51'16.32", -88° 9'7.04.

However this took me to 41°51'25.70"N 88°9'7.38"W which, using the Ruler tool in Google Earth, shows a difference of .18 miles away from the Google Earth Placemark. I had to do a "Change position" in Panoramio to drag the location marker to the true location.

All the other pictures I upload had a similar Panoramio distance (.16 to .19 miles) from the Google Earth location.

[Galatas ©]

I often use the same procedure , but with decimal coordinates , and get the same result as you.

[Old Nick]

Quote msand42:

Did you in fact enter the co-ordinates with the °, ', and " signs as you show in your example?

I use exactly the same procedure that you describe but when I enter the co-ordinates I enter them without the °, ', and " signs. so using your location all I would enter is 41 51 16.32, -88 9 7.04 using a space to separate the different values. Up to now I have not had an error like you describe.

Try it without the signs, just use spaces and see if this makes a difference.

John

[Galatas ©]

I made a test using decimal coordinates both with and without the degree symbol , which is the only non numerical character when using decimal format.
The results were identical. The error in both cases was insignificant at 20 yards , but nevertheless it is there.
I have just done another test mapping in a different location. The error in both cases this time was more significant at 430 yards.

[Tomas K☼h☼ut]

First:
enering coordinates in dd°mm'ss.sss" or dd mm ss.sss format was not possible in "map photo" dialog not very long ago. Only accepted format for coordinates was dd.ddddddd.
So there is some silent improvement of functionality - acceptable formats are extended. Great!

Second:
Coordinates entered in dd°mm'ss.sss" or dd mm ss.sss format are not evalueted correctly. Seems to me - at least decimal part of ss.sss value is totally ignored. So improvement is not working properly.

Code:

I made a test with different coordinates representation:



A

Map input:

49.25773472, 14.7145900

Mapped to:

49° 15' 27.85" N  14° 42' 52.52" E (correct)



B 

Map input:

49°15'27.845", 14°42'52.524"

49 15 27.845, 14 42 52.524



Note: coordinates A = B

Position on map is moved!: A <> B

Mapped to:

49° 15' 28.29" N  14° 42' 53.72" E  (wrong)



C 

Map input:

49°15'27", 14°42'52"

49 15 27, 14 42 52

Note: this is position derived from b) - decimal part is stripped

Final position on map of B and C is equal:  C = B

Mapped to:

49° 15' 28.29" N  14° 42' 53.72" E   (wrong)



D

Map input:

49.2575, 14.7144444

Note: this is decimal representation of C

But final position on map D is not equal as C, 

e.g. D <> C, D <> B

Mapped to:

49° 15' 27.00" N  14° 42' 52.00" E  (correct)



E

Map input:

49°15'28.29"  14°42'53.72"

Note: This is decimal representation of resulting position in B, C

Final E position is same as resulting position in B, C!

Mapped to:

49° 15' 28.29" N  14° 42' 53.72" E (correct)

Conclusion:
a) Decimal input does not work properly. It makes some internal rounding that caused final coordinates to be "sticky" to one place on map, although original coordinates are different.

b) due to this bug, recommended coordinates input is decimal.

c) I will report this bug to admins and give them my test results.

[Galatas ©]

D
Map input:
49.2575, 14.7144444

That is exactly the format I use with the results having errors as I described.
The amount of error appears to vary from area to area.

[Old Nick]

Quote Tomas K☼h☼ut:

First:
enering coordinates in dd°mm'ss.sss" or dd mm ss.sss format was not possible in "map photo" dialog not very long ago. Only accepted format for coordinates was dd.ddddddd.
So there is some silent improvement of functionality - acceptable formats are extended. Great!

Second:

Coordinates entered in dd°mm'ss.sss" or dd mm ss.sss format are not evalueted corectly. Seems to me - at least decimal part of ss.sss value is totally ignored. So improvement is not working properly.

Tomas, I always map my photo's when uploading and have always used dd mm ss.ssss and always the positioning is in the correct place.

I once tried to map after uploading but got so misplaced I deleted the photo and uploaded again using my normal method of mapping during upload.

John

[Tomas K☼h☼ut]

John, I don't know when limitation for sexadecimal format was removed.
It was introduced after September 2009 upgrade.
But I remember - moderators many times adviced users to use decimal format for coordinates input.

[JBTHEMILKER]

Old Nick, John, How is it you do it? If I get the coordinates off my GPS, I can't make it give me the correct location no matter how I enter it.
I would like to be able to. I take some pictures out in the woods, and I use my GPS. But right now I can't map them, not correctly.

[Old Nick]

Quote JBTHEMILKER:

Old Nick, John, How is it you do it? If I get the coordinates off my GPS, I can't make it give me the correct location no matter how I enter it.
I would like to be able to. I take some pictures out in the woods, and I use my GPS. But right now I can't map them, not correctly.

JB, as I mentioned earlier I map my photo during the upload procedure.

My GPS only gives me co-ordinates to one decimal point of seconds, so like most I use GE to refine that to an exact point.

Step by step this is what I do.

1. Select 'Browse' and get the photo I wish to upload.

2. Select 'Upload' to start the upload procedure.

3. When the photo is uploaded but before 'Save', map the photo and as I said before I use dd mm ss.ss, dd mm ss.ss for my co-ordinates.

4. Click on 'Search' after you enter the co-ordinates which should take you to the exact position you have entered.

5. Click on 'Save Position'

6. Click on 'Save'


John

[NightHunter]

The sextadecimal bug is a feature of GMaps. When you enter an exact coordinate, it finds the nearest addresspoint. When you type these coordinates in GMaps, it give you two placemarks. A green arrow with the exact point, and a red ballon with the address nearby. See: http://tinyurl.com/gmapsbug

The problem is that you cannot see the two placemarks when you want to map a photo. In this case focusing to the exact coordinates should be default (now it finds the addresspoint, which is totally bad now), I don't know if there is an option for that in the API.

[JBTHEMILKER]

My plan after reading all this is to walk to some rather spectacular stone work in the woods. I will take my Garmin legend HCx handheld GPS. Then when I get home I will attemp, as I have before to plot the location from the coordinates off the way points on the GPS.
What I am reading are two things. Many do is wrongly (as I have always) and it can be done.

[Wim Constant]

May I suggest the use of an i-gotU GPS logger. ( http://www.i-gotu.com/ ). I use it all the time. It is small, cheap an simple to use. Included is a program called @trip PC. It is reasonably accurat. Not always exact "spot-on", but close enough . Upload the photos on your PC, run the program and the GPS co-ordinates are put in the EXIF-data of the photo.

Succes,

Wim

[Gerard Sanz]

Quote Tomas K☼h☼ut:

First:
enering coordinates in dd°mm'ss.sss" or dd mm ss.sss format was not possible in "map photo" dialog not very long ago. Only accepted format for coordinates was dd.ddddddd.
So there is some silent improvement of functionality - acceptable formats are extended. Great!

Second:

Coordinates entered in dd°mm'ss.sss" or dd mm ss.sss format are not evalueted correctly. Seems to me - at least decimal part of ss.sss value is totally ignored. So improvement is not working properly.

Code:

I made a test with different coordinates representation:



A

Map input:

49.25773472, 14.7145900

Mapped to:

49° 15' 27.85" N  14° 42' 52.52" E (correct)



B 

Map input:

49°15'27.845", 14°42'52.524"

49 15 27.845, 14 42 52.524



Note: coordinates A = B

Position on map is moved!: A <> B

Mapped to:

49° 15' 28.29" N  14° 42' 53.72" E  (wrong)



C 

Map input:

49°15'27", 14°42'52"

49 15 27, 14 42 52

Note: this is position derived from b) - decimal part is stripped

Final position on map of B and C is equal:  C = B

Mapped to:

49° 15' 28.29" N  14° 42' 53.72" E   (wrong)

D

Map input:

49.2575, 14.7144444

Note: this is decimal representation of C

But final position on map D is not equal as C, 

e.g. D <> C, D <> B

Mapped to:

49° 15' 27.00" N  14° 42' 52.00" E  (correct)



E

Map input:

49°15'28.29"  14°42'53.72"

Note: This is decimal representation of resulting position in B, C

Final E position is same as resulting position in B, C!

Mapped to:

49° 15' 28.29" N  14° 42' 53.72" E (correct)

Conclusion:
a) Decimal input does not work properly. It makes some internal rounding that caused final coordinates to be "sticky" to one place on map, although original coordinates are different.

b) due to this bug, recommended coordinates input is decimal.

c) I will report this bug to admins and give them my test results.

You will see that this is the same bug reported here. It is not a problem of the decimals taken on the seconds, but the fact that in degrees,minutes,seconds format we always return the location suggested by Google Maps as Closest Public Address Point and this is obviously wrong. This is the reason why you see this small diferences in where the place is and where the place should be. As said in the other topic. We will work in the fix very soon. Thank you all.

[Draken]

Please continue in the linked topic as to avoid duplication. Thanks.