4

I know a bit about lat/long, projected and geographic coordinate systems etc., and a bit about geodesy and datums.

I have a lat-long in deg/min/sec provided to me by someone else (point location = northern Italy). I have a map in ArcGIS in the same region and I'm constructing a grid over it for some analysis, centred on the lat-long point above.

In ArcGIS, I'm working with projection Roma 1940 Gauss Boaga Ovest - the data frame and map layer are both in it - and when adding the XY point also in this projection, it ends up pretty much where it should be (but not exactly)

The thing is, when putting these coordinates into Google Earth, the point is around 25 or 30 metres south east of where it is in ArcGIS. The provider is saying the Google Earth location is where it should be.

So, where does the difference derive from?

I understand Google Earth is a WGS84 geographic coordinate system so I tried a point file in WGS84 and added the XY and it still ends up in the slightly incorrect position in ArcGIS as outlined above. Also have tried various combinations of WGS84 and Roma 1940 Gauss Boaga Ovest and can't get it right.

Would the Roma 1940 datum skew it slightly or is it nothing to do with that?


I see that Google Maps actually uses WGS84 Web Mercator projected coordinate system, which has its own problems.

Would ArcGIS actually be more accurate then?


I asked the provider and they said the coordinates provided have come from Google Maps.

I've tried to reproject etc. and nothing will change the position from the red dot (see left of image). I've since discovered Google Maps is a WGS_1984_Web_Mercator projection, based on a sphere. I've attempted to create a custom transformation of datum in ArcMap from 'GCS_WGS_1984_Major_Auxiliary_Sphere' to 'GCS_Roma_1940', no change to dot position when entering the coordinates.

As you can see, the Google Maps on the right is in a slightly different position, by roughly 35m, to the ArcMap image on the left. I'm pretty much out of ideas.

enter image description here

6

Due to various vagaries in the ArcGIS software, I'm going to tell you to use different coordinate reference systems. That will let you access the predefined transformations and hopefully make your life easier.

Use WGS_1984_Web_Mercator_Auxiliary_Sphere instead. This one uses WGS 1984 for the geographic CRS (aka datum). The one you're using, WGS_1984_Web_Mercator, uses a sphere (GCS_WGS_1984_Major_Auxiliary_Sphere) and there are no predefined transformations for it.

Next, use Monte_Mario_Italy_1 which is the same, just a different name. Pick Monte_Mario_To_WGS_1984_4 for the transformation.

Or if you want to use Roma_1940_Gauss_Boaga_Ovest, you'll have to define a custom transformation that's a copy of Monte_Mario_To_WGS_1984_4.

FROM roma 1940 TO wgs84
Method: Position Vector
X axis translation: -104.1
Y axis translation: -49.1
Z axis translation: -9.9
X axis rotation: 0.971
Y axis rotation: -2.917
Z axis rotation: 0.714
scale difference: -11.68

If you define a custom transformation in ArcMap, you may have to define it FROM wgs84 TO roma 1940. If so, change the signs on all parameters.

  • i look forward to trying this 1st thing tomorrow and letting you know how it goes, thanks for now! – Sam Mar 18 '14 at 21:35
  • wonderful! aaah, i think it has worked. I set the original layer to Monte_Mario_Italy_1 (PCS) and created a new point.shp with the WGS_1984_Web_Mercator_Auxiliary_Sphere (PCS). I created the point with the given coords in the new point.shp before starting. – Sam Mar 19 '14 at 9:19
  • My 1st attempt was to add the point.shp and then transform Monte_Mario_Italy to WGS_1984_Web_Mercator_Auxiliary_Sphere. This, skews my layer map ever so slightly into the new WGS84 which is not what I want when I add an arbitrary grid but the point was correct. I simply started again and reversed the process, adding the map layer 1st and then the point.shp and performing the transformation from WGS_1984_Web_Mercator_Auxiliary_Sphere to Monte_Mario_Italy_1. The transformer was the same name but I just swapped the start and end PCS. It worked! – Sam Mar 19 '14 at 9:22
  • Thanks so much to mkennedy and radouxju. This is pretty confusing stuff but im glad it was resolved. – Sam Mar 19 '14 at 9:23
2

Datum transformation are never fully accurate, which could explain a small shift but not a difference of 30 to 40 m.

A difference of 30 to 40 m is more like an error due to the absence of datum transformation, or it could be an error in the dataset that you use for the relative evaluation of your position (Google registration can be wrong in some places of the world).

In order to solve this issue, you should try to contact the person who provided the lat/long coordinates in order to know in which CRS he was working. Then you should check your transformation used in ArcGIS to make sure hat it is corectly used. An error of transformation would result in a systematic error, but of course this is only visible if you have only one point. Another way to check for this is using an independent projection tool (e.g. http://twcc.free.fr/ ) and compare your coordinates with ArcGIS

EDIT :

By looking at your image, I see that your both coordinate are dd°mm'ss.0'' It therefore seems (99% chance) that you don't have the decimal values. Hence your precision is thus about 30 m in each direction. If the coordinates have been truncated, the error is up to 30*sqrt(2)= 42m. If it has ben rounded, this maximum error can be divided by 2.

  • sorry, see my answer above as i couldnt post images in comments, thanks – Sam Mar 18 '14 at 12:08
  • please edit your question (there is an edit button under the tags) instead of posting an answer. – radouxju Mar 18 '14 at 13:15
  • 1
    Sam, I think @radouxju is checking on whether you converted the DMS values to decimal degrees correctly. That can cause an offset too. – mkennedy Mar 18 '14 at 17:36
  • 1
    There are so many different sources of errors that you need to eliminate them one by one. I am sorry if some of my test look trivial, but I don't know you, so I rather start with the obvious errors before more complex ones. another test that you could do is to convert your coordinates based on another software (e.g. twcc.free.fr) to validate your transformation. If you have the same problem, the error could be in your vector dataset or in the google image (google registration is not always correct) – radouxju Mar 19 '14 at 6:43
  • 1
    concerning the rounding, what I meant is that the decimal value could have been rounded before you received it. It is of course possible that the true coordinates are both ss.0 (p=0.01), but when I receive rounded coordinates I am always careful. Again, with more points it would be easier to detect the source of errors. On the other hand, I don't think that your conversion form DMS to DD is wrong because you seem to know what you are talking about, and this would have resulted in a larger error. – radouxju Mar 19 '14 at 6:56
0

Just a note on the matter of the point data provided to you, as others have stated you are missing the decimal part of the minutes, if the longitude was 10 44 31.9E then it would be on the other side of the clearing.

Also the provider is using google earth, placing of pins on google earth is VERY imprecise. The 3D nature of it means that every location is interpreted from the point of view of the camera.

Try drawing 3 polygons that meet a single point and then view these in a "flat viewer" Arc and you will see that they do not meet up.

Lucky the clearing is determinable from the image, thus it's seems irrelevant, in this case, what it's exact co-ordinate is, or rather what the provider thinks it's lat/lon is.

I'm sure the transformations answer has solved the technical problem for you.

  • thanks for answering. I think what I was trying to say to others is that there is NO decimal part to the seconds, they are right on .0 . Google map can cope to the nearest 0.1 arcsecond and if you put an extra .1 onto the coordinates provided, the point will shift a touch, even in google maps. That implies the original ArcMap transformation was incorrect or wrong datum being used somewhere, which has been resolved. Also, it was from google maps and not google earth, which use different PCS/GCS. – Sam Mar 20 '14 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.