|
Hi all, Firstly, I'm no expert at computer programming or GPS but I am in real need of some expert advice! I have plotted out lots of points in Google Earth using the drop pins. I have saved these places as a KML file and then opened that in Excel to get the coordinates. So far so good. An example of one of these coordinates is the middle of the road to the entrance to a station car park: -0.495209547 51.9623976 However, I need to input these coordinates into a program that uses Open Street Map. Copying these coordinates over does not seem too work, they seem to be too long and it gets shortened automatically to: -0.49521 51.96240 The problem is, this location is about 25 metres to the right and not my exact location. If I MANUALLY (so using my eye to place the pin in the centre of the road at the junction (so it might not be 100% accurate but near enough)) plot the location I need directly into Open Street Map, it tells the coordinates are: -0.49568 51.96240 Notice the difference with first value... When copied from Excel to Open Street Map, it rounds the last few digits up to 1. But the actual value I need (according to my manual plot in Open Street Map), the above value of -0.49568. Is there a way that I can use/convert the longer version of the coordinates I have into the slightly shorter coordinates that Open Street Map appears to use, but Open Street Map actually plotting the same exact position? Is someone able to explain why this happens please? Any help greatly appreciated as I have hundreds of these pins to transfer over and I don't want to manually plot them all! Thanks, Matt |
|
You also need to keep in mind that precision may not be the only problem here. There's also the matter of accuracy. The Google Earth imagery is almost always misaligned to some degree. In some places it can be within a few feet, but I've seen examples where the imagery is out by hundreds of feet. If you want a marker in a particular spot in OSM, you'll want to get the coordinates from OSM to avoid this error. Also, the rounding error between the first two sets of coordinates in your question comes out to a difference of about 3 inches. When you take into consideration that the imagery can be misaligned by many times that, the rounding error becomes negligible. |
|
There is no need to move the pin manually if you already have the exact coordinates. Just use the following URL by replacing LAT and LON: E.g. for the coordinates you mentioned: |
|
What I suspect you're seeing is at the limits of imagery alignment / OSM accuracy. Here's what I see with your 51.9623976 -0.495209547 co-ordinates in Google Earth:
and here's what I see in OSM:
If we assume the railway line in OSM is in the middle of both tracks and correct (and the GPS traces for it in OSM, and the Bing imagery would suggest that it pretty much is), then the discrepancy's < 5m. Are you seeing something different? Thanks for that, although the second link shows the wrong location, that link shows the location about 25 metres to the right of where the location I want is in my Google Earth. Although I did just stumble across this: http://www.satsig.net/degrees-minutes-seconds-calculator.htm The coordinates in Google Earth are for this example are 0°29'44.48"W 51°57'44.57"N. I put this into the above website and it gave me the correct location in the short version of decimal value. These values are correct (and I realised I need the 4 and 5 decimal point values for my project). But the decimal value that Google spits out in it's KML file is to about 9 decimal points (in this case -0.495209547 51.9623976). So I think my question is (I think!), what is the best (and easiest) way to convert the long decimal coordinates I have in Excel, into the the shorter ones that appear in Open Street Maps (I noticed on your second link, once I clicked it right at the very end, the URL ends with these shorted coordinates "51.9624/-0.4952"). Does that make sense or have I completely over complicated the situation!? Cheers, Matt
(09 Jul '14, 12:25)
Matthew
Maybe there is something wrong with my Google Earth, I'm lost as your answer makes sense.
That is where I want the decimal degree coordinates. I've saved this pin in Earth as an KML file, opened it in Excel and the coordinates it gives me in Excel are: -0.495209547 51.9623976 But if you put these decimal degree coordinates into OSM, you get this:
Note that the pin is OSM is now about 25 metres to the right of my original pin in Earth, it should be just under the 'n' of 'Toddington Road'. Cheers Matt
(09 Jul '14, 12:57)
Matthew
2
If you search for a feature using Google tools, you won't necessarily get the actual location of that feature back - just something fairly near it. You're searching for 0°29'44.48"W 51°57'44.57"N and are receiving 51.9623976, -0.495209547 back, but (as a search in Google Earth shows) they're not the same location. If the column in your Excel spreadsheet was obtained this way, all values may have the same problem. As you've noticed, whenever you move the map in OSM you'll see co-ordinates in the address bar. I'd ignore Google altogether and just use those.
(09 Jul '14, 13:01)
SomeoneElse ♦
1
The short coordinates after #map= are just for the browser's viewport. They don't affect the position of the pin which will still use the long coordinates given via mlat= and mlon=.
(09 Jul '14, 13:05)
scai ♦
|
|
To your point about decimal degrees getting rounded, it looks like the data itself goes to 7 decimal places. For example, see http://www.openstreetmap.org/node/2009506481 I don't know about the other editors, but while editing in Potlatch 2, you can view the mouse lat/long by checking the box in Options. That only shows to 5 decimal places, but would allow you to get very close. I know you want to be precise, but given that .00001 decimal degrees is around a meter, that's probably no more than the error which likely exists in the imagery. Edit: didn't answer the last part of your question, about getting your points entered in a non-manual way. Two points:
|
|
May have solved the mystery... In the data that Google Earth spits out, there is a Longitude column and a Latitude column. These you would assume, would contain the correct Longitude and Latitude and this is what I had been looking at and getting the problems with. It appears these are incorrect though. There is another column towards the end of the row that has the LON, LAT and ALT combined in one cell. If I actually break these numbers up manually into three, and then use the LON and LAT from there, I finally get the results I want in OSM. And these numbers that are combined in this one cell are slightly different to the original ones I was looking at. At first I thought Excel might be trying to round up or down the numbers in the individual columns containing the LON and LAT separately. But looking at the raw data, it appears not. So I have no idea why Earth is spitting out a second set of near correct coordinates for a point, there seems no reason. Anyone heard of anything like this before? Cheers, Matt 1
That'd be a question for Google rather than OSM - as I said above:
(10 Jul '14, 17:20)
SomeoneElse ♦
I don't know the details of your process, but kml files may include lat and long as attributes, as well as the actual lat/long coordinates. While you'd think they're the same, maybe they're not?
(10 Jul '14, 17:24)
neuhausr
|
Please do not enter data in OSM using coordinates that you derived from Google imagery, as that is incompatible with Google's TOS and OSM's license. You may display that Google-tainted data over an OSM basemap, but not import it into the OSM database.