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 Excelfile to get that 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 exaktly 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 updatet. 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 significant deviant. 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 tryed 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.
Many thanks in advance,
André
أكثر...
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 Excelfile to get that 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 exaktly 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 updatet. 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 significant deviant. 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 tryed 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.
Many thanks in advance,
André
أكثر...