Latest Contributions by JoshuaBixby

‎05-28-2015

While interactively scripting in ArcGIS Desktop, I always noticed but couldn't figure out why most Python functions and methods would show something in the Python Help Window but not all functions and methods. At first, I thought some functions and methods lacked docstrings, which would cause the Help Window to be blank, but I often found those functions and methods actually had docstrings. It was a mystery but not one worth wasting time on. Serendipitously, I stumbled into the answer while sorting something else out this week. It turns out, the interactive Python Window doesn't properly show the __doc__ special attribute in the Help Window for Python classes or functions/methods within classes. For example, let's look at arcpy.FromWKT: You can see that ArcGIS Desktop is displaying the __doc__ special attribute in the Python Help Window. Now let's look at arcpy.Polygon: Although the __doc__ special attribute isn't overly verbose or detailed like with arcpy.FromWKT, there is nothing being displayed in the Python Help Window. For the longest time, I couldn't figure out what differentiated the former from the latter. The answer, Python classes. arcpy.FromWKT is a function defined at the module level whereas arcpy.Polygon is a class. Furthermore, for functions/methods defined within a class, the __doc__ special attribute isn't displayed either. For ArcPy itself, the impact is noticeable, but whether it is significant or not is debatable. The real issue arises because the interactive Python Window doesn't behave this way just for ArcPy but for all Python packages. For example, look at the multiprocessing module: For some Python packages, this bug/oversight has minimal impact, but there are other Python packages where a significant amount of useful documentation doesn't show up in the Python Help Window.

‎05-26-2015

Andrew Turner, thanks for the information and insight. I understand what you are saying from a technical perspective, but what makes sense from a technical perspective doesn't always make sense from a user perspective. Data providers could provide a link to static FGDB in the Description, but why have one format accessible under the Details tab while the rest are under "Download Dataset"? If there is a big blue button labeled "Download Dataset," I think most users will look there first, and possibly only there, for FGDB data. From a Desktop GIS perspective, I would guess 50% or more of ArcGIS Open Data users are also ArcGIS Desktop users. Why not support a format that works best for 50% or more of Desktop GIS users of ArcGIS Open Data? From an open data perspective, GeoPackage is more open than shapefile. I understand shapefiles are, or historically have been, ubiquitous, but making a standard publically available isn't the same as making an open standard. Shapefiles might still be needed for legacy purposes, but let's embrace open formats and look more toward the future. For a typical user, I don't think adding a couple additional download formats will be nearly as confusing as what those API links are or are not for. : )

‎05-26-2015

Regarding file formats, I find it a bit humorous that many ckan-based sites like the Minnesota Geospatial Commons already offer downloads as file geodatabases and geopackages when Esr's Open Data site is stuck with KML and shape files.

‎05-26-2015

Since "OID@" is a token for the ObjectID field, usually "ObjectID," what exactly are you attempting to do? Does your feature class have a different unique identifier field than "ObjectID?" You are starting an edit session, but it doesn't look like you have started an edit operation. Before any updating can begin, an edit operation needs to be started as well. See Editor example 2 from the Editor (arcpy.da) help.

‎05-26-2015

Looking at some relevant DBMS documentation: Microsoft SQL Server ORDER BY Clause (Transact-SQL): "The order in which rows are returned in a result set are not guaranteed unless an ORDER BY clause is specified." Microsoft Access ORDER BY Clause (Microsoft Access SQL): "ORDER BY is optional. However, if you want your data displayed in sorted order, then you must use ORDER BY." PostgreSQL SELECT (PostgreSQL): "If ORDER BY is not given, the rows are returned in whatever order the system finds fastest to produce." IBM DB2 Formatting the result table (Programming for DB2): "To retrieve rows in a specific order, use the ORDER BY clause. Using ORDER BY is the only way to guarantee that your rows are ordered as you want them." I know Oracle has similar statements too, but the Oracle online help was obtuse enough I couldn't find a reference right away. It is pretty clear the DBMSes themselves don't guarantee a result set order without using the ORDER BY clause. That said, do the ArcPy cursors (original and data access) do some default ordering after getting the result set from the DBMS? I have no idea because I have yet to find any ArcPy documentation that addresses the issue. Given that DBMS vendors clearly state there is no guaranteed ordering without ORDER BY, and Esri doesn't say anything about whether they order the cursors after getting the result sets, I always use the ORDER BY clause if I need the data to be in a certain order. Complexity isn't just defined by the number of records. If all one works with is file-based data, like shapefiles or file geodatabases, ordering of result sets might be predictable, but enterprise DBMSes allow for complex workflows along with plenty of data so I prefer being explicit rather than implicit when wanting a certain order.

‎05-23-2015

To follow on what Blake T says, most if not all DBMSes do not guarantee the ordering of results unless you use an ORDER BY clause. Even if you are not using GROUP BY clauses, you should use ORDER BY if you are processing results based on some type of order. Relying on an index to return a certain order without using ORDER BY is basically relying on chance, even if chance has worked most of the time in the past.

‎05-23-2015

What is your exact syntax? Your original syntax doesn't show any edit sessions. The error message indicates you either havent started editing after creating the edit session or you haven't started an operation yet. The help for arcpy.da.Editor has some really good examples.

‎05-21-2015

If you drag a feature class from any source into the interactive Python window of ArcGIS Desktop, it will show you the path. If the SDE connection file is in your "Database Servers" or "Database Connections" folder in ArcCatalog, the path will be relative to those folder, but the path will still be valid for the currently logged in user. Jeff Ward shows what a full path would look like.

‎05-20-2015

I am not suggesting the following will fix your overall issue, but I do have a comment regarding dictionaries. You speak of "copying the dictionary" and there is a code comment to "duplicate" the dictionary. Where are you making this copy? Line 12? Line 12 is not copying dictionary D, you are just binding another variable to the same dictionary. Python dictionaries have a copy() method for returning a shallow copy of themselves.

‎05-20-2015

I did notice a typo on Line 3 of my original code, so I went back and fixed it. Thanks. My answer to your question is touched on in my response to the OP. AFAIK, properties of ArcPy objects cannot be modified in place. Instead, users must get the property, modify the returned object, and then set the property. Trying what you suggest: >>> #Create temporary, in-memory feature class >>> fc = arcpy.CreateFeatureclass_management('in_memory','fc',"POINT") >>> arcpy.AddField_management(fc, "Example","TEXT") <Result 'in_memory\\fc'> >>> #Create FieldMap object and add input field >>> fm = arcpy.FieldMap() >>> fm.addInputField(fc, "Example") >>> fm.outputField.name u'Example' >>> #Try to change field name in place >>> fm.outputField.name = "Whatever" >>> fm.outputField.name u'Example' >>> #Change field name by getting, modifying, and setting Field object >>> fld = fm.outputField >>> fld.name = "Whatever" >>> fm.outputField = fld >>> fm.outputField.name u'Whatever' To footnote my own comment above, properties can be set directly if a user can construct or construct and modify the correct object without getting the property first. For example, properties that are strings can be changed by setting the property with a new string: >>> fld = arcpy.Field() >>> fld.name u'' >>> fld.name = "Whatever" >>> fld.name u'Whatever'

‎05-20-2015

Not sure how to comment on an announcement, so I am going with a new discussion thread instead. ArcGIS Pro 1.0.2. Was there even an ArcGIS Pro 1.0.1? Ah, maybe counting by twos is the new hip thing or something.... On a more serious note, a full download? 675 MB to address how many bugs? Oh yeah, 5 (ArcGIS Pro 1.0.2 Issues Addressed List). It seems the ArcGIS Pro Flawed Update Strategy discussion this past winter was just chitchat. I keep hearing incremental updates, i.e., not full downloads, are possible but where's the beef? Why bother with a built-in updater if all it does is download the entire application in the background. I can't wait until our users in rural offices start updating ArcGIS Pro over their T1s, that will be a fun experience for them, and all for 5 bugs.

‎05-18-2015

Paul Kroseman, you are interested in Personal/Desktop SDE, right? The links being provided are for Enterprise SDE or enterprise geodatabases. Personal SDE or desktop geodatabases don't require additional keycodes like workgroup geodatabases and enterprise geodatabases. If you are interested in desktop geodatabases, check out Database Server (Desktop) installation guide. I don't think setting up desktop geodatabases is as scriptable as enterprise geodatabases, but I haven't looked into it completely.

‎05-18-2015

A link to provide feedback does exist, as you point out. You state you have used it, I have used it, and I am sure others have as well. It would be interesting to know how much users do use it, or don't as the case may be. As much as providing a link for feedback is a first step, there are other companies that went a step or two farther with their online documentation years ago. Regardless of what one thinks of the content quality, the Microsoft Developer Network (MSDN) structure is quite a bit more robust than the structure of Esri's documentation. For example, when looking up information on something SQL Server 2014 related, there is a link at the top of the page for "Other Versions." When deploying and managing numerous versions of software within an organization, which I think is fairly common for larger organizations, it is quite handy to see the documentation from earlier versions via a simple link rather than searching on an entirely new subdomain like we have now between ArcGIS 10.3.x and earlier versions. In terms of feedback, MSDN offers a "Community Additions" section at the bottom of pages. The Community Additions section isn't just for people to provide feedback to MS about their documentation, but also for users to provide information to other users. As much as I can start a new GeoNet post to share information I have learned about how an ArcPy method really behaves, I think having that feedback right in the documentation makes it much more accessible.

‎05-17-2015

Vince Angelo, thanks for the comments, I know you have a long history with SDE and spatial operators. Your background and perspective is always good reading, even if we aren't always in perfect agreement. Regarding your first paragraph, I completely agree. It seems I may have failed to put what was in my head down in writing. When it comes to the ArcPy Geometry Classes specifically, which is really what I am selfishly most concerned about, I expected the Geometry.within() method to return the same results as the Select Layer By Location tool, but that isn't the case with a line on a polygon boundary. With no reference to Clementini or DE-9IM, I expected to see results consistent with Esri's definition but the line on boundary results from Geometry.within() are consistent with Clementini instead.

‎05-17-2015

Background processing was just the example I chose to make a point that incomplete, or worse inaccurate, documentation leads to confusion and wasted time and resources for users. In the case of open source software, the fallback is the source code itself when the documentation isn't up to par. Unfortunately for closed source software, that isn't an option. Documentation costs money, I get that, but the savings upstream from poor documentation have a cost downstream. Whether documentation is good or poor, someone is paying for it, and I think Esri can still do better. None of the examples I gave involved 64-bit Background Geoprocessing. Are there additional issues when 64-bit Background Geoprocessing is installed? I am not sure, and I didn't want to complicate the discussion by introducing 32-bit/64-bit interactions into the mix. I agree, though, that 64-bit Background Geoprocessing offers some very real advantages over regular 32-bit geoprocessing, foreground or background. I understand that executing code out-of-process, 32- or 64-bit, involves marshaling of resources that can require changes to code to make it all come together. When changes are required and behaviors differ between code running in-process and out-of-process, it is nice to have it documented. What really struck me as odd was how some geoprocessing tools, like CopyFeatures, behave exactly the same whether background processing is enabled or not while other geoprocessing tools behave different. Looking at the in-memory workspace specifically, I consider it notable when something named "in-memory" isn't in memory anymore when background processing is enabled. I think most experienced ArcPy scripters figured that out through trial and tribulation, but why make new scripters learn it the hard way as well.

Online Status	Online
Date Last Visited	yesterday

My Ideas

Latest Contributions by JoshuaBixby

Blank Help with Interactive Python Window

Re: Improvements people would like for Open Data

Re: Improvements people would like for Open Data

Re: RuntimeError: cannot open feature class

Re: Field calculation with python

Re: Field calculation with python

Re: make all of the data in fields uppercase

Re: make all of the data in fields uppercase

Re: Troubleshooting a loop utilizing a cursor and a dictionary to write to a table

Re: fieldMap.outputField referencing describe object, not field object

ArcGIS Pro 1.0.2: 675 MB Download to Address 5 Bugs

Re: Create geodatabase on desktop SDE

Re: What's in a Name: When Known = Unknown

Re: What's Within: When Esri + Clementini = User Beware

Re: What's in a Name: When Known = Unknown

Re: azure, arcgis enterprise 11.5 and poor browser...

Re: New ParameterArray container

Re: New ParameterArray container

Re: What is the fastest way to add a new machine t...

Re: ArcGIS Enterprise Kubernetes / GIS Functionali...

Esri Forestry Group (EFG)

Python Snippets