|
POST
|
I agree with Joshua's comment that this limitation is due to the maximum short int value. I would recommend either implementing logging to a file instead of messaging to the GP pane as he suggests, using a progress bar, or doing some sort of batching on your messages (ie: only print every 1000 messages using a counter to determine progress)
... View more
06-19-2017
01:40 PM
|
1
|
1
|
2009
|
|
POST
|
It can still be pip installed for 2.7, its just standard lib in 3.4+ -- but you're right, for base 10.x os.path is the way to go! I'm stuck in the Pro mindset
... View more
06-16-2017
10:23 AM
|
0
|
1
|
1840
|
|
POST
|
It seems like there are several possible error states you want to handle here: LogFile does not exist when trying to write to it Error thrown in 'Geoprocessing Stuff' section For the first point, the mode argument in open() can include a '+' character which will cause the file to be created if it doesn't exist. If the directory itself doesn't exist then you'll see a FileNotFoundException. This can be handled as such: try:
f = open(log_file, 'a+') # use 'a+' to append, 'w+' to truncate
except FileNotFoundException:
# handle the file system issues
Then for the second point, you'd want to handle the Geoprocessing Errors inside the with block as such: with f:
log_msg = ""
try:
# Geoprocessing Stuff
log_msg += do_gp_stuff_step1()
log_msg += do_gp_stuff_step2()
log_msg += 'Success!'
except Exception as e: # Be more specific based on your code
log_msg += e
finally:
# Clean up Geoprocessing stuff
f.write(log_msg) Obviously you'd want to make things more readable with string formatting, or can build log_msg in other ways, but this is the basic pattern that I would recommend.
... View more
06-15-2017
02:45 PM
|
1
|
0
|
2183
|
|
POST
|
Currently it's not supported, we are moving towards enabling that sort of environment creation as soon as possible but there has been a lot to change behind the scenes, since many different parts of Pro use Python in different ways. Currently the env needs to be within the Pro folder structure to find all the pyd/DLL files that arcpy needs to initialize. If all goes according to plan this should be fixed for 2.1. Currently you can use the 'prefix' switch on conda create (-p) to clone the env somewhere outside the Pro folder structure, but will have to ensure the system PATH variable includes all of the locations of the DLLs to successfully import arcpy, but its not something we're officially supporting since its a bit of a hack.
... View more
06-14-2017
01:06 PM
|
1
|
17
|
4923
|
|
POST
|
Good morning Mike, I just tried to replicate this on a fresh install of 1.4 but was unable: - Installed 'arcgis' package (installs Python3.dll) - Error as described above - Deleted Python3.dll - Reopened Pro, no error - 'import pandas' in the Python console in Pro & in python via cmd prompt both imported successfully I currently have pandas 0.20.1 installed, is yours a different version number? It may also be another package preventing pandas from updating. My 'conda list' shows: arcgis 1.0.1 py35_1 esri arcgispro 2.0 0 esri bleach 1.5.0 py35_0 colorama 0.3.9 py35_0 cycler 0.10.0 py35_0 decorator 4.0.11 py35_0 entrypoints 0.2.2 py35_1 freetype 2.6.3 vc14_1 [vc14] esri future 0.16.0 py35_1 html5lib 0.999 py35_0 ipykernel 4.6.1 py35_0 ipython 6.1.0 py35_0 ipython_genutils 0.2.0 py35_0 ipywidgets 6.0.0 py35_0 jedi 0.10.2 py35_2 jinja2 2.9.6 py35_0 jsonschema 2.6.0 py35_0 jupyter_client 5.0.1 py35_0 jupyter_core 4.3.0 py35_0 kerberos-sspi 0.2 py35_0 libpng 1.6.27 vc14_0 [vc14] markupsafe 0.23 py35_2 matplotlib 1.5.3 np111py35_0e [arcgispro] esri mistune 0.7.4 py35_0 mpmath 0.19 py35_1 msinttypes r26 2 esri nbconvert 5.2.1 py35_0 nbformat 4.3.0 py35_0 netcdf4 1.2.4 py35_0e [arcgispro] esri nose 1.3.7 py35_1 notebook 5.0.0 py35_0 numexpr 2.6.1 np111py35_0e [arcgispro] esri numpy 1.11.2 py35_0e [arcgispro] esri pandas 0.20.1 np111py35_0 pandocfilters 1.4.1 py35_0 path.py 10.3.1 py35_0 pickleshare 0.7.4 py35_0 pip 9.0.1 py35_1 prompt_toolkit 1.0.14 py35_0 py 1.4.34 py35_0 pygments 2.2.0 py35_0 pyparsing 2.1.4 py35_0 pypdf2 1.26.0 py_2 esri pytest 3.1.1 py35_0 python 3.5.3 3 python-dateutil 2.6.0 py35_0 pytz 2017.2 py35_0 pywin32 220 py35_2 pyzmq 16.0.2 py35_0 requests 2.14.2 py35_0 scipy 0.18.1 np111py35_0e [arcgispro] esri setuptools 27.2.0 py35_1 simplegeneric 0.8.1 py35_1 six 1.10.0 py35_0 sympy 1.0 py35_0 testpath 0.3.1 py35_0 tornado 4.5.1 py35_0 traitlets 4.3.2 py35_0 vs2015_runtime 14.0.25420 0 esri wcwidth 0.1.7 py35_0 wheel 0.29.0 py35_0 widgetsnbextension 2.0.0 py35_0 win_unicode_console 0.5 py35_0 xlrd 1.0.0 py35_0 xlwt 1.2.0 py35_0 zlib 1.2.8 vc14_3 [vc14] Let me know if that helps.
... View more
06-07-2017
11:48 AM
|
0
|
3
|
2446
|
|
POST
|
Good morning, A dictionary in Python is a built in data structure (not specific to ArcPy), similar to an array/list in other languages. Instead of referencing values by a numerical index as you would in a list, you are giving it custom index keys. In terms of tables, a list is like a table with a single column indexed by row number, and a dictionary is like a single row with many columns, indexed by column names. For example: >>> array = ['bob', 'chris', 'dave']
>>> array[0]
'bob'
>>> dictionary = {'name': 'bob', 'age': 42}
>>> dictionary['name']
'bob'
>>> # add a key/value
>>> dictionary['weight'] = 120
>>> dictionary
{'name': 'bob', 'age': 42, 'weight': 120} In what I'm describing in my above post, you would add key/values (similar to lines 8 & 9 above) to a dictionary that could be thought of as a table with a single 'correct values' row, with columns of each unique ID and its correct value in the cell. This dictionary would then be referenced for correct values when looping through the problematic feature classes. Admittedly I'm suggesting some fairly advanced usage of the concepts so it might be confusing at first if you're unfamiliar with dictionaries and cursors. It might help to see the documentation for them: Python dictionaries: 5. Data Structures — Python documentation Cursors with examples Accessing data using cursors—ArcPy Get Started | ArcGIS Desktop
... View more
06-06-2017
11:00 AM
|
1
|
1
|
1676
|
|
POST
|
No problem, I have had to create similar scripts in the past. Feel free to ask here if you run into any issues since I'm subscribed to this thread now
... View more
06-05-2017
03:30 PM
|
1
|
3
|
1676
|
|
POST
|
Instead of using the field calculator, it should be possible to use cursors in a Python script. A script could consume the table and your set of feature classes. First, use an arcpy.da.SearchCursor to read the values from the table into a Python dictionary (key of the unique identifier, value of the correct data). Once the dictionary is populated, loop through the set of feature classes, and for each fc create an arcpy.da.UpdateCursor. After creating the UpdateCursor for a feature class, loop through the rows - for each row, using the unique identifier again, check against the dictionary containing the correct values. If the value in your UpdateCursor for that row doesn't match the correct data in the dictionary, replace the value in the row. You're essentially 'joining' the UpdateCursor representing each feature class to the dictionary representing the table one at a time, then the field calculation is done one row at a time as you loop through the Cursor and check its value against the correct one in the dictionary. This should allow you to compare an arbitrary number of feature classes against the field with one run of the script (assuming there is some common unique ID per feature between them and the table).
... View more
06-05-2017
01:38 PM
|
2
|
5
|
1676
|
|
POST
|
That was the date that the .dll was compiled for the package which was causing the issue, not necessarily when it was installed in the env.
... View more
06-02-2017
01:19 PM
|
0
|
0
|
2446
|
|
POST
|
At the moment, arcpy and thus the underlying Python functionality in Pro is not a true site-package, the code in arcpy is laid down with the installation of Pro in the Resources directory. As such there are a few special files within Pro environments to temporarily set the OS PATH to include the location of arcpy when python.exe from within a Pro env is run. If those aren't present in a newly created environment then arcpy won't run successfully. You are correct that creating an additional environment will not affect the one which has the arcpy functionality - you should be able to switch between these without issue - however if you've installed Anaconda alongside Pro you have to be mindful of which conda.exe, python.exe etc you are calling. Since there are essentially two installations of the same program, you will only be able to access the envs associated with the executable that is being run. This is based off the system's PATH variable. The conda installation in Pro, including its envs, exists within Pro's folders. Any envs outside of that folder structure will not work with arcpy (we are working on improving this, but as of Pro 1.4 it is the case) Anaconda is aggressive in changing the PATH, so if you've installed it after installing Pro your PATH likely points to the non-Pro installation's executables. A handy command in the cmd prompt is 'where conda' - this will show a list of all the locations conda shows up on your PATH. The topmost one will be executed by calling that command on its own.
... View more
06-01-2017
01:49 PM
|
1
|
0
|
1892
|
|
POST
|
There is a utility in the %ProInstall%/bin/Python/Scripts directory called 'proswap.bat' - you can use this batch file with an env name as an argument to automatically switch the necessary registry keys. Since there is no environment in the drop-down, I'm wondering if the %ProInstall%/bin/Python/envs/arcgispro-py3 folder still exists? The UI should be able to read the package information from that folder without the registry being set. You may also want to check the PATH variable to ensure the Anaconda install isn't stealing your conda commands - currently we require envs to be within the Pro folder structure, so if they are in the Anaconda envs directory they won't work with Pro. They can exist side by side you just need to be mindful of the PATH.
... View more
06-01-2017
12:51 PM
|
1
|
0
|
1729
|
|
POST
|
There have been a few reports of Pro 1.4.1 crashing after packages which depend on the Jupyter/pyQT packages are installed via conda. This is due to a problematic DLL that shipped with conda which doesn't meet PEP 384. It is easy to fix, simply by deleting or renaming the culprit DLL in your active Pro environment's folder. In your %ProInstalDir%/bin/Python/envs/arcgispro-py3 folder (or equivalent if you have created additional environments), delete or rename Python3.dll - many people are hesitant to alter DLL files, but in the same folder you will see Python35.dll - this is the one which should be loading and will fix the issue. Once this file has been removed, reopen Pro and it should work as expected. This issue has been identified and fixed for Pro 2.0 and will not be a problem going forward. If you continue to experience issues please post to this discussion for additional support.
... View more
05-31-2017
11:17 AM
|
6
|
7
|
4670
|
|
BLOG
|
I would like to be clear since this is a new concept for many people and gets complicated quickly - You cannot use Python 2.7 with ArcGIS Pro. Curtis' blog post describes how to use conda environments with 2.7 in ArcMap which was technically possible for long before Pro was released. This is not the same thing as using 2.7 in Pro.
... View more
03-29-2017
09:57 AM
|
1
|
0
|
17631
|
|
BLOG
|
In Pro 1.3 and 1.4 it is possible to create new conda environments from the command line, however not from within Pro. This is being added as we speak and will be present in the next release. You are correct in that there are currently several requirements to run ArcPy and it can run into problems if you're using unsupported versions. New environments can be created from the command line, although they must conform to the package versions set on the default environment for the time being. There is a file called 'pinned' in the conda-meta directory of the arcgispro-py3 env which contains these version requirements. Conda-Forge conda-forge | community driven packaging for conda has been doing a lot of updating/packaging of out-of-date Python packages, perhaps check there to see if your package has been updated to support 3. For your 32-bit/memory issue, have you looked at the 64-bit Background Geoprocessing option? Background Geoprocessing (64-bit)—Help | ArcGIS Desktop This will allow for more of your memory to be utilized. Also you will probably want to research Generator Expressions in Python, which conserve vast amounts of memory when compared to using collections such as lists: PEP 289 -- Generator Expressions | Python.org
... View more
03-27-2017
09:39 AM
|
3
|
0
|
17631
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 11-23-2016 11:51 AM | |
| 1 | 12-27-2016 03:58 PM | |
| 1 | 11-28-2016 09:17 AM | |
| 1 | 12-08-2016 05:09 PM | |
| 1 | 12-28-2016 12:00 PM |
| Online Status |
Offline
|
| Date Last Visited |
11-11-2020
02:25 AM
|