1

Tested on: different workstations, different Windows versions; ArcGIS Desktop 10.3, different license levels

Background:

I use the Google Maps DistanceMatrix to calculate drive times between two point feature classes (FC). Therefore I use the XY coordinates with simplejson (instead of street and city names). I get this XY coordinates from the attribute table of a point FC. This part of the workflow is working well.

But before I can do that, I have to geocode adresses from an Excel file to get the needed FC. I do this with the Geopy module. In a part of my script I use this also to calculate the X and Y coordinates of the feature and put it in the attribute table of the FC, because it´s needed for the calculation of drive times. It´s also working great. My results are looking like 47.5925516, 7.6168828, my FC is in WGS84 (4326).

Problem:

Most of the features are geocoded correctly, but some points - because they are not so exactly how I need them - need to be moved by hand. My idea for that was easy: If I have to move a feature, my XY coordinates also need to be updated. Simple click on calculate geometry (attribute table), set it to decimal degrees and finished. But if I do that without moving a feature, the calculation result - not for all features but a lagre part of them - differs from my original XY coordinates, which I get from Geopy/ GoogleMaps in WGS84. For example the original XY coordinate 47.5925516, 7.6168828 were calculated to 47.5923835, 7.61109560000006. Only the first few decimal places are correct.

Because I need the XY coordinates for my drive time matrix and I am working with very short distances, the result could be a significant deviation. If I use a aerial image or a basemap to check the points, the position of the original XY coordinates/ the features are exact but the calculated position could be more then 500 m away.

What I have tried:

What I am doing wrong, this could not be an typical projection inaccuracy,or?! I tried different fieldtypes (double, text) and precisions. I changed my layer coordinate system to WGS84, WGS84 auxiliary sphere and DHDN_3_Degree_Gauss_Zone_3. Nothing worked for me.

*******UPDATE********

I geocoded the adresses with the "original" Google Maps API (same FC, in WGS 84, too) and it works. If I put both FC (Geopy and original Google Maps API) in the same Layer and calculating the XY coordinates, the old ones are still calculated wrong, the Google API ones are calculated right.

  • They are both in the same coordinate system (WGS84)

  • visually the point FCs have the same location on the map

André
  • 311
  • 2
  • 7
  • I'd say project everything to projected (m) system, make your adjustments, preoject back to geographic. Have a look at http://gis.stackexchange.com/questions/138956/how-to-handle-coordinates-accuracy-in-arcgis – FelixIP Sep 09 '15 at 20:20
  • It's very likely that your different calculations are done using a sphere and a spheroid, which would be expected to give different results. You'll need to track down the exact spheroid details of each component you are using before you'll be able to implement reliable calculations. – Vince Sep 09 '15 at 20:32
  • 1
    The "new" values are much farther away than the differences between DHDN and WGS84. Calculate geometry is just reporting what the feature's coordinates are, so I think you need trace the workflow through and check the coordinates are each step. – mkennedy Sep 09 '15 at 21:05
  • @FelixIP: Tried your suggestion. Thanks for it, but it does not work for me. The calculated values are still wrong. – André Sep 10 '15 at 15:48
  • 1
    "Calculate geometry" is planimetric only, not geodesic. Your original geopy coordinates are probably calculated in geodesic (or maybe spherical) space. The Google API coordinates are almost certainly calculated in planimetric space. The inherent reprojection into planimetric space that underlies "Calculate geometry" is probably altering your calculated coordinates. – blord-castillo Sep 10 '15 at 16:01

0 Answers0