arcpy near analysis fails

2621
12
Jump to solution
07-19-2017 06:48 AM
TinaOosterom1
New Contributor II

When I run >>>arcpy.Near_analysis("ACN_Select","Derden","150 Meters", "NO_LOCATION", "NO_ANGLE","PLANAR") in the python window in ArcMap 10.4, it returns the correct numbers in the field NEAR_DIST.Results in ArcMap10.4

However, if I run the same in PyScripter:

import arcpy
arcpy.env.workspace = "C:\\Geoplay\\GLO\\Output.mdb"
arcpy.env.overwriteOutput = True


if arcpy.CheckExtension("Spatial") == "Available":
    arcpy.AddMessage("Checking out Spatial")
    arcpy.CheckOutExtension("Spatial")
else:
    arcpy.AddError("Unable to get spatial analyst extension")
    arcpy.AddMessage(arcpy.GetMessages(0))
    sys.exit(0)

ACN_Select = "C:\\Geoplay\\GLO\\GLO.gdb\\ACN_Select"
Derden = "C:\\Geoplay\\GLO\\GLO.gdb\\Derden"


#Near Analysis
arcpy.Near_analysis(ACN_Select,Derden,"150 Meters","NO_LOCATION","NO_ANGLE","PLANAR")

print "Ready!"

All the NEAR_FID and NEAR_DIST are -1.

Results from PyScripter

I tried creating layers and using those, but it didn't work. Also I tried setting the spatial ref with

spatRef = arcpy.Describe(ACN_in).spatialReference

but it did not change anything.

What am I missing?

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
DanPatterson_Retired
MVP Emeritus

the point closest to feature will not necessarily remain the same... if one is in decimal degrees and the other is in meters since the planar distance between two locations in decimal degrees is not constant but decrease as you head poleward.

At this stage, perhaps one of the files has been 'defined' wrong.  The only way that you can confirm this is to examine the layer extents.  I confirm visually by inserting a new data frame then add one file to it and examine its properties through the properties dialog and visually on the map.  delete that data frame and repeat with a new dataframe and layer.  If the extent indicates that the layer is in decimal degrees (-180 to 180 and -90 to 90 for X and Y ranges at most) but the file has been defined wrong, then you have to correct the definition.

On the other side, what if one file's coordinates were in meters and the other in feet? The numbers look like they are projected, but their values will be scaled by the conversion from feet to meters.  How to resolve? same process and see where it lands up on a map.

Subtle differences in projection can cause issues.  In my area, UTM and MTM are commonly used and it is not uncommon for them to be defined wrong or read wrong... To solve? same process and examine where they fall on the earth relative to where they should be.. Oh yes, there are imperial and metric versions for both.  A simple drop of a few bits of information when defining the coordinate system makes a huge difference.

In short, just because the definition of a file says it IS something, it doesn't mean that IT IS what it purports to be.

View solution in original post

12 Replies
DanPatterson_Retired
MVP Emeritus

Confirm the coordinate systems of both files.  Projection on the fly doesn't occur in standalone scripts since the data are not in a data frame

0 Kudos
TinaOosterom1
New Contributor II

Hi Dan, thanks for your suggestion. I did and they are both RD New (Dutch system) in the gdb.

0 Kudos
DanPatterson_Retired
MVP Emeritus

C:\\Geoplay\\GLO\\Output.mdb  **** mdb  should this be gdb???

if that isn't the issue don't specify any of the other optional parameters in the script since -1 means nothing was found.

This again assumes all files are within the extent and any selections are within the distance specified, so try not to limit the distance or increase it until you know it works

0 Kudos
TinaOosterom1
New Contributor II

Hi Dan,

I really appreciate your advice! The mdb is because, further on in the script, I export the tables from the altered ACN_Select to this mdb. I removed that from the script above, because it would make it confusing. But forgot to remove it as workspace.

However, I changed it to gdb for the results of the near_analysis, but the problem with the NEAR_FID and NEAR_DIST remain the same... So strange: it works fine in the Python window in ArcMap.

By the way, ACN_Select contains points and Derden contains lines. I try to get the distance from each point to the nearest line feature, being restricted to points within 150 meters froma line feature.

0 Kudos
DanPatterson_Retired
MVP Emeritus

That is why I wanted to see if it worked without the distance restriction.  If it still doesn't, then the problem lies elsewhere

TinaOosterom1
New Contributor II

Hi Dan, I removed the "150 Meters" and ran it through the Python command line and... the fields were filled. However, the numbers within the NEAR_DIST make no sense. Like the first row in my example is 149 meters, in the new table this comes down to 3145. I tried to find which unit would translate from this figure to the other, but çan't find it.

So it seems that in the map view the distance limiter works, because the distance unit of the map and the feature classes is meters, as it should be with RD New. But somehow, when the script is ran outside the map, it starts using different distance units (different projection ?). So perhaps I should look into setting the projection right in the script?

Also the NEAR_FiD is different. Which is strange, because, no matter which coordinate system one would use, the line closest to my point should remain the same. Shouldn't it?

0 Kudos
DanPatterson_Retired
MVP Emeritus

the point closest to feature will not necessarily remain the same... if one is in decimal degrees and the other is in meters since the planar distance between two locations in decimal degrees is not constant but decrease as you head poleward.

At this stage, perhaps one of the files has been 'defined' wrong.  The only way that you can confirm this is to examine the layer extents.  I confirm visually by inserting a new data frame then add one file to it and examine its properties through the properties dialog and visually on the map.  delete that data frame and repeat with a new dataframe and layer.  If the extent indicates that the layer is in decimal degrees (-180 to 180 and -90 to 90 for X and Y ranges at most) but the file has been defined wrong, then you have to correct the definition.

On the other side, what if one file's coordinates were in meters and the other in feet? The numbers look like they are projected, but their values will be scaled by the conversion from feet to meters.  How to resolve? same process and see where it lands up on a map.

Subtle differences in projection can cause issues.  In my area, UTM and MTM are commonly used and it is not uncommon for them to be defined wrong or read wrong... To solve? same process and examine where they fall on the earth relative to where they should be.. Oh yes, there are imperial and metric versions for both.  A simple drop of a few bits of information when defining the coordinate system makes a huge difference.

In short, just because the definition of a file says it IS something, it doesn't mean that IT IS what it purports to be.

TinaOosterom1
New Contributor II

I found out about the differences in distances. I am working with a map document that is stored on a share. One of my colleagues has been working with it too and imported the old  Derden FC in the gdb. The layer in the map, however, was the latest one. So everytime I used the layer, the distances were smaller, because this layer is more complete than the FC in the gdb and in this layer there are lines closer to ACN_Select. Sorry for wasting your time on this. I learned a lot, though.

I guess we must conclude that the distance limiter in the Near_analysis does not work for me, but I can live with that. I can filter the ones within 150 meters afterwards.

Thank you so much for your input. I would never have found all this without your help.

0 Kudos
DanPatterson_Retired
MVP Emeritus

No problem Tina... glad a solution was found in the end

0 Kudos