Add an argument to Exists function to limit existence test on one type

[AlainRAVAZY]

Greetings,

Arcpy function Exists determines the existence of the specified data object. Tests for the existence of feature classes, tables, datasets, shapefiles, workspaces, layers, and files.

Unfortunatly, when it returns "True", you cannot know which type of data object (feature classes or tables or datasets or shapefiles or  workspaces or layers or files) has successfully validated the existence test.

There is a long time ago, in a very old software, there was an aml function Exists, which determined the existence of a specified data object regards to a type (Coverage, Workspace, etc...)

Cf :

[EXISTS <object>                {-FILE | -ADDRESS | -ANNOTATIONS{.subclass} | -ARC |                 -ASCONNECT | -ASDATABASE |                 -ASDBMSTABLE <database> <connection> |                 -ASHISTORY {datetime} {<database> <connection>} |                 -ASHistoricalVIEW {-DBMSTABLE | -INFOTABLE | -LAYER} |                 -ASINFOTABLE | -ASLAYER | -ASLIBRARY |                 -CLEAN | -COVER | -DEFLAYER | -DIRECTORY | -GRID |                 -IMAGE | -INFO | -LAYER | -LIBRARY | -LINE | -LINK |                 -NETWORK | -NODE | -POINT | -POLYGON |                 -REGION{.subclass} | -ROUTE{.subclass} | -SECTION{.subclass} |                 -STACK | -TAT{.subclass} | -TIC | -TIN | -VAT | -WORKSPACE}]

It would be interesting and usefull for end user that arcpy.Exists function can be enhanced in order to get in argument one the tested type : feature classes or tables or datasets or shapefiles or  workspaces or layers or files

Thank you to take this request in consideration about a function very usefull with Arc/Info and a bit truncated in Arcmap and ArcGIS Pro

Best regards,

Alain

[DuncanHornby]

Hi,

I don't understand your idea or am missing the point? If you call arcpy.Exists(r"c:\temp\test.shp") you know it is a featureclass, or arcpy.Exists(r"c:\temp\test.tif"), you know it is a raster that you are testing for the existence of?

[AlainRAVAZY]

Consider the program above :

arcpy.env.workspace = "D:\\support\\02160804\\test.gdb"
fcm = arcpy.CreateFeatureclass_management("in_memory","bbb","polygon","","DISABLED","DISABLED","","","0","0","0")
def tester(input):
...   if arcpy.Exists(input):
...     print ("exits")
...   else:
...     print ("doesnot exist")

Suppose you have also a raster dataset "bbb" in test.gdb. How you can know if the execution of tester("bbb") did find the raster dataset in the FGDB or the layer "bbb" in the TOC ?

This question was very important for one of my end user.

Best regards

[DuncanHornby]

If that really is the program that was being run then the function tester() is never entered as it is never called.

The input parameter would need to be "bbb". Exists() honours the workspace Environment Setting and as you have set it on the first line it would be looking in the file geodatabase. Your second line creates a polygon featureclass in the in_memory workspace so if you wanted to test for the existence of bbb in the in_memory workspace your input parameter to tester() would be "in_memory\bbb".

If you were trying to make it generic and just look for "bbb" you would ALWAYS need to set the environment setting Workspace. So by definition you know what and were you are looking when running the Exists() function.

[JoelDaroussin]

Hi,

I am the end user mentioned by Alain.

Consider you are in ArcMap and the TOC contains a layer named "aaa" that references any dataset, not necessarily a dataset named "aaa". Entering the following code in the Python Window:

if arcpy.Exists("aaa"):

  print "aaa exists"

else:

  print "aaa does not exist"

answers "aaa exists" but this answer is ambiguous: as long as "aaa" exists as a layer in the TOC, you'll never know if a dataset "aaa" exists or not.

Of course, there is a way to refine the answer by complementing this code with the use of arcpy.mapping.ListLayers, but this extends the code quite a bit.

My suggestion is to improve the Exists function so that it mimics its extremely useful and thoroughly used elder sister in the time of ArcInfo, which’s syntax used to be:

[EXISTS <object> {-FILE | -ADDRESS | -ANNOTATIONS{.subclass} | -ARC | -ASCONNECT | -ASDATABASE | -ASDBMSTABLE <database> <connection> | -ASHISTORY {datetime} {<database> <connection>} | -ASHistoricalVIEW {-DBMSTABLE | -INFOTABLE | -LAYER} | -ASINFOTABLE | -ASLAYER | -ASLIBRARY | -CLEAN | -COVER | -DEFLAYER | -DIRECTORY | -GRID | -IMAGE | -INFO | -LAYER | -LIBRARY | -LINE | -LINK | -NETWORK | -NODE | -POINT | -POLYGON | -REGION{.subclass} | -ROUTE{.subclass} | -SECTION{.subclass} | -STACK | -TAT{.subclass} | -TIC | -TIN | -VAT | -WORKSPACE}]

In the ArcPy environment, the syntax of the Exists function could be improved by similarly adding an argument, which would allow specifying the type of object to test for existence of.

The default option for this argument could be e.g. "ANY" so that any current Python code would not have to be upgraded to comply to that new syntax as the "ANY" value for that argument would mimic the current behaviour of the function.

Argument values such as "DATASET" would allow refining the test to, in this case, "any type of dataset" as opposed to "any type of data object" as is the case with the current behaviour of the function which causes the above demonstrated ambiguity.

Argument values could be refined down to specific data objects so that any ambiguity could be raised if necessary. The range of objects to test could thus be extended not only to "feature classes, tables, datasets, shapefiles, workspaces, layers, and files in the current workspace" as mentioned in the documentation but also to the whole range of object types managed by ArcPy.

I am quite sure this would be a real improvement making this function much more useful for ArcPy programming.

Regards.

[DuncanHornby]

Using the example:

if arcpy.Exists("aaa"):
  print "aaa exists"
else:
  print "aaa does not exist"‍‍‍‍‍‍‍‍‍‍‍‍

As the full catalog path is not provided, nor has the workspace been set then this is asking if a layer exists and as it is in the TOC then it would be True. Python has it's own way of checking if objects exists as discussed here.

May be the issue here is that old school AML had a stack/heap of objects and using EXISTS with it's optional parameter allowed it to query from the heap of objects (I'm just speculating to as how it works)? The current arcpy.Exists() does not require that as to make it function correctly you have to supply the path either in the parameter or as the workspace? By doing that you know already know what type of object it's going to test for.

Whilst your idea of adding an optional parameter should not break existing code I would be surprised if they implement it. What you are asking is the same as how the Delete (Data Management) tool functions but the data_type parameter is not actually used, it's for "display purposes" what ever that means...

[JoelDaroussin]

Using either the temporary ws or a arcpy.env.workspace will not make any change: the answer will still be ambiguous, won't it? You still will not know if dataset "aaa" exists or not as the answer will stand for layer "aaa" in the TOC. Unless you explicitely specify a pathname to the dataset, in which case, I agree with you that it means you already know the type but only wether it is a dataset rather than a layer, not wether it is say a raster rataset rather than a feature class.

Unless I am misunderstanding something.

And you're right, the Delete function despite its argument has the same problem.

[DuncanHornby]

Aah! The penny has dropped!

In a file geodatabase if you had a dataset called aaa then yes you are right the Exist tool would say True/False but you would never know if it was a raster or vector dataset. You would need to use the Describe() function and check the datasetType property.

[JoelDaroussin]

Glad you finaly agree.

Yes, for sure one can find turnarounds to raise the ambiguities of the Exists function: Describe to distinguish a raster from vector or even from a table, ListLayers or a full pathname to distinguish a Layer from a dataset, and so on) but you can you imagine how complicated it could get to implement a general purpose function that could handle all situations, including generic handlers such as ANY or DATASET or SHAPEFILE, etc.? Whilst having all possible situations directly at the level of the function would make it so simple (just as the good old EXISTS ArcInfo function used to).

Regards.