Latest Contributions by JoshuaBixby

Guessing is right, I don't really have a clue what the OP is asking.  Also, is this just a different flavor of the Update Cursor. post from last week?  Sadly, the same OP never replied back to most of the suggestions people offered over there.  I am going to take a pass on this one. ... View more

Posting a specific error message is helpful.  There are lots of ways a Python function can fail. ... View more

A few comments: The error message, in this case, is fairly specific and descriptive.  You are putting one or more datasets as inputs multiple times to the tool.  Since I don't know your folder and file structure, I suggest you add some print statements to find out the files you are adding so you can see where the duplicative inputs are coming from. Python is case sensitive and Dict != dict, but Dict is pretty close to dict.  It is generally not a good idea to shadow built-in names, like dict. Although in this case Dict isn't shadowing the built-in dict, I think it is close enough to avoid using a variable with that name. ArcGIS 10.1 SP1 introduced a Walk function in the ArcPy Data Access module (arcpy.da.Walk).  The ArcPy Walk function is a geospatial aware version of os.walk, and I encourage you to use it instead. ... View more

I had success using third-party PDF printer drivers (Adobe, PrimoPDF, etc...).  I recently had a 8 1/2 x 11 map layout with a moderately dense polygon layer.  Regardless of the settings in ArcGIS Pro, I couldn't get the PDF size down below 25 MB, and there were oddities with the PDF like patches of missing or extremely slow drawing polygons.  Using a third-party PDF printer driver, I got a rather nice looking PDF for 1.75 MB. I suspect the issue has to do with rasterizing vector layers, or not rasterizing them.  When using a third-party PDF printer driver, it seems Pro is forgoing vectors altogether and rasterizing everything, hence why my PDF is only slightly larger than a PNG export of the same map.  When doing a PDF export straight out of ArcGIS Pro, it must be trying to hang onto most of the vector data, which would make sense for a really large map layout but not so much for an 8 1/2 x 11 layout.  Something similar happens with SVGs with small map layouts because I get huge exports of those as well when a dense map layer is involved. Honestly, I think it is just poor code that isn't taking the map layout into consideration when determining how dense the vector output should be when exporting straight to PDFs.  In ArcGIS Desktop, the issue doesn't seem to be as noticeable. ... View more

Dan Patterson​, given how much you like NumPy (who can blame you, it is pretty slick), you might also have fun with arcpy.da.SearchCursor._dtype and arcpy.da.SearchCursor._as_narray(). >>> cur = arcpy.da.SearchCursor(r'StateProvinceBoundaries_ESRI',                                 ["OID@", "SHAPE@XY"],                                 where_clause="NAME1 = 'Minnesota'") >>> cur._dtype dtype([('OID@', '<i4'), ('SHAPE@XY', '<f8', (2,))]) >>> cur._as_narray() array([(139, [205923.5657559298, 5264242.273746617]),        (140, [544608.9951297314, 5365824.304238412]),        (141, [221359.03653639136, 4966096.278488112]),        (142, [580541.5304663723, 5054285.671024574])],       dtype=[('OID@', '<i4'), ('SHAPE@XY', '<f8', (2,))]) >>> >>> help(arcpy.da.SearchCursor._as_narray) Help on method_descriptor: _as_narray(...)     _as_narray() -> numpy.record.     Return snapshot of the current state as NumPy array. That part of the API might not be published but Python is for consenting adults. ... View more

Python 2.7.10 documentation > 7. Compound Statements > 7.5. The with statement: The with statement is used to wrap the execution of a block with methods defined by a context manager (see section With Statement Context Managers). This allows common try...except...finally usage patterns to be encapsulated for convenient reuse. The with statement encapsulates code, but it encapsulates specific types of code within a class.  For someone using a class and not developing one, the with statement is more about wrapping code within a context manager. The variables defined within a with statement, including the target variable of the with statement, are wrapped and persist after the with statement: >>> with arcpy.da.SearchCursor(r'Default.gdb\StateProvinceBoundaries_ESRI',"OID@") as cur: ...    for row in cur: ...        pass ...       >>> dir() ['__builtins__', '__doc__', '__file__', '__name__', '__package__', 'arcgis', 'arcpy', 'cur', 'datetime', 'math', 'row', 'sys', 'time'] >>> type(cur) <type 'da.SearchCursor'> >>> type(row) <type 'tuple'> The with statement doesn't delete variables and the variables don't go out of scope after the with statement.  For this specific case, the with statement ensures the arcpy.da.SearchCursor.__enter__() and arcpy.da.SearchCursor.__exit__() methods are called, thus freeing some of the locks the cursor holds on the data source. Regardless of whether a with statement is used or not, the variables will all be cleaned up when the script ends. ... View more

Often times, the error messages from doing the replication in ArcMap using the normal GUI tools provide better, or at least different, information.  If you try to replicate (no pun intended) your example workflow through the GUI, does it succeed or fail?  If it fails, what error messages does it give? ... View more

The first change I would make is to pull your search cursor out of your update cursor.  The current code is creating a new search cursor for every record in the update table, and the same dictionary is being created over and over again. Give this a try: workspace1 = r"D:\ADC\Tool\Mumbai\PGDB For Reference\MVVNL_MAHMUDABAD\MVVNL_MAHMUDABAD.mdb"  workspace2 = r"D:\ADC\Tool\Mumbai\PGDB For Reference\MVVNL_MAHMUDABAD\Output.mdb"  searchFeatures = os.path.join(workspace2, "LTOVerHead_DTGISID")  updateFeatures = os.path.join(workspace1, "SecOHElectricLineSegment") with arcpy.da.SearchCursor(searchFeatures, ["TARGET_FID", "HT_GISID"]) as cursor:     gisiddict={}     for fid, gisid in cursor:          gisiddict[fid] = gisid  del gisid, fid, cursor with arcpy.da.UpdateCursor(updateFeatures, ["OBJECTID", "GISID"]) as cursor:      for oid, gisid in cursor:            if oid in gisiddict:             cursor.updateRow([oid, gisiddict[oid]]) del gisid, oid, cursor ... View more

Dan Patterson​, thanks for the KB link, I missed that one.  I have to laugh, though, because I don't see the sense in squirreling this information away in a Support KB rather than including it somewhere in the actual documentation associated with ArcGIS Pro, especially since searching the new ArcGIS Desktop ​documentation doesn't search Support KBs like the old ArcGIS Resources site for documentation.  Measuring progress in backwards steps! ... View more

It would be helpful if you stated what you expected the results to be versus what you are seeing.  Given the code you provided, people could assume what you expected for results, but it is just so much easier to explicitly state it.  That said, assuming has never stopped me.... I assume what is confusing to you is that you can continue to create the same table over and over in_memory and that it never generates an error.  Using a similar but slightly different example, it is illustrative to compare using in_memory in the interactive Python window (which is what I assume you are doing) and using in_memory in the accompanying, standalone Python interpreter. Interactive Python window: arcpy.CreateTable_management('in_memory', 'tmpTable') <Result 'C:\\Users\\jbixby\\Documents\\ArcGIS\\Projects\\MyProject\\MyProject.gdb\\tmpTable0'> arcpy.Exists('in_memory/tmpTable') False Standalone Python interpreter: >>> import arcpy >>> arcpy.CreateTable_management('in_memory', 'tmpTable') <Result 'in_memory\\tmpTable'> >>> arcpy.Exists('in_memory/tmpTable') True I am guessing, or should I say assuming, you and most others would expect the results from the standalone Python interpreter. Before getting to my main point, there are a couple of minor points to cover in the code examples above.  First, one can see that using in_memory in the interactive Python window is actually creating the table on-disk, not in-memory.  Given that in_memory means on-disk and not in-memory in the interactive Python window, it is possible to create the same table over and over because each call using in_memory isn't actually referencing the same place, well, the same object. Now the logical question is why in_memory doesn't actually mean in-memory with the interactive Python window in ArcGIS Pro.  The answer, which is basically undocumented, can be found by looking at the recently updated documentation on Foreground and background processing in ArcGIS Desktop. Using the in-memory workspace with background processing .... Background processing is a separate process from ArcMap or ArcCatalog. These processes cannot share memory (RAM). When a tool is executed, the data it uses must be opened by the background processes. So, an input feature class will be opened directly by the background processes, but layers in ArcMap must follow a different path.... Most of the Create tools, such as Create File GDB and Create Feature Class take two input parameters (a workspace and a name) to derive a new output. These tools allow you to input in_memory as the workspace. However, when executed in the background, the newly created output will always have the result returned as a location on disk, even if in_memory is used as the workspace. These tools are better used as part of a workflow in ModelBuilder or a Python script tool where the in-memory workspace can be used throughout the entire execution of the tool. It appears, and I say appears because I haven't found good documentation yet, that ArcGIS Pro uses something similar to 'background processing' in ArcGIS Desktop.  Unlike ArcGIS Desktop where the user can choose between foreground and background processing under the Geoprocessing options, there is no choice in ArcGIS Pro, or at least that I have found yet. ... View more

The Create Replica tool has more usage footnotes, possibly the most, that I have seen for a tool.  Some of the usage notes get into the weeds, e.g., "data that you wish to replicate must be versioned, but not with the option to move edits to base."  Given there are 16 notes and sub-notes, it never hurts to go back and double check them all. Beyond verifying all of the conditions to run the tool have been met, the specific error (000582) can crop up when the validation process for a tool's parameter values fails.  Let's look at one of your calls to the tool: #include parameter names and requirement status as comments arcpy.CreateReplica_management(featureList,            # in_data (required)                               "ONE_WAY_REPLICA",       # in_type (required)                               outGDB,                  # out_geodatabase (required)                               replicaName,             # out_name (required)                               "FULL",                  # access_type (optional)                               "PARENT_DATA_SENDER",    # initial_data_sender (optional)                               "ALL_ROWS",              # expand_feature_classes_and_tables (opt)                               "",                      # reuse_schema (optional)                               "",                      # get_related_data (optional)                               "",                      # geometry_features (optional)                               "DO_NOT_USE_ARCHIVING")  # archiving (optional ?) While most geoprocessing tools include the default argument for optional parameters in the syntax table, the Create Replica documentation only provides that information for half of the optional parameters, which is not only unfortunate but a documentation bug in my eyes.  What is even more odd, and another documentation bug, is that archiving isn't stated to be optional but yet it is at the end of the parameter list (required parameters can't come after optional ones) and a default argument is stated. Getting back to the example at hand, I strongly discourage passing empty strings to optional parameters.  Unless the default argument is an empty string or the documentation states empty strings are handled in a special way, passing an empty string will lead to the code/tool to bypass the default argument and use the empty string instead.  It could very well be that passing "" to reuse_schema is causing the issue because the two arguments that parameter accepts are "DO_NOT_REUSE" and "REUSE" .  Since it looks like you want defaults for the last 4 parameters, what is the result of trying the following: #include parameter names and requirement status as comments arcpy.CreateReplica_management(featureList,            # in_data (required)                               "ONE_WAY_REPLICA",       # in_type (required)                               outGDB,                  # out_geodatabase (required)                               replicaName,             # out_name (required)                               "FULL",                  # access_type (optional)                               "PARENT_DATA_SENDER",    # initial_data_sender (optional)                               "ALL_ROWS")              # expand_feature_classes_and_tables (opt) ... View more

The issue can be isolated down to a single table with a single long integer field.  In ArcGIS 10.3.1, exporting that table to a DBF will show a "Long Integer" field but viewing that same DBF in ArcGIS 10.2.2 or ArcGIS 10.1 shows "Double."  With ArcGIS 10.3.1 and 10.2.2 showing different data types, it is unclear which one is "correct."  Looking to outside tools, MS Access shows the data type as "Double," so it seems ArcGIS 10.3.1 is altering the data type but still sees it as unaltered. Not sure if this issue is related to the ongoing discussion about truncation. ... View more

Multiple except clauses work fine as long as the catch-all "except:" statement is last.  From the 2.7 Python docs on Handling Exceptions, which is the same as the 3.5 docs: A try statement may have more than one except clause, to specify handlers for different exceptions. At most one handler will be executed. Handlers only handle exceptions that occur in the corresponding try clause, not in other handlers of the same try statement. .... The last except clause may omit the exception name(s), to serve as a wildcard. Use this with extreme caution, since it is easy to mask a real programming error in this way! It can also be used to print an error message and then re-raise the exception (allowing a caller to handle the exception as well): ... View more

Can you show the rest of your Make Query Table screen, e.g., the Key Field Options and Key Fields settings?  Also, have you tried "ADD_VIRTUAL_KEY_FIELD" instead of "USE_KEY_FIELDS"? Also, the documentation states "All input feature classes or tables must be from the same input workspace."  Are both your tables in the same input workspace? ... View more

Is there a bug number or something else that will be documented at 10.4 so users know whether the "unintended consequences" were dealt with or not?  Similar to SciPy being announced for ArcGIS 10.3.1, with some fanfare, and not quite making it into the release; it would be good if there was something users could track on to know whether changes that are announced/planned for this issue in 10.4 are actually addressed in 10.4. ... View more