How does the community feel about non-arcpy answers to arcpy questions?

Question

Background

Due do the nature of my current workload, I've been ending up at gis.stackexchange (instead of stackoverflow) more often.

Once here, I poke around the python and help someone out if time allows.

I've noticed many questions take the form "How do I do ABC in arcpy?". It's a perfectly valid question, but also one that feels prone to the XY-problem. To me, it seems very likely that someone internet search "how do I do ABC in python?" could easily end up at the arcpy-specific question (it's happened to me).

So in the spirit of adding useful info for the community, I've added a few non-arcpy answers (typically using geopandas b/c geopandas is awesome).

I don't expect the OP to accept the answer or even upvote it. I just think that a lot people searching for python-related answers could end up at arcpy questions, and a sizeable portion of those people won't have access to arcpy.

I always put some explanation at the top of the answer along the lines of, "I know the OP is looking for a solution in arcpy, but if you don't have arcpy, you could do it this way:". I've received a couple of downvotes from people who either didn't read the disclaimer, or did read it and think that the answer was bad or harmful nonetheless. But I don't care about the reputation, my 32k from python/data-related tags on SO scratches that itch for me.

So my question:

Is there any reason I shouldn't add non-arcpy answers to arcpy questions?

Answer 1

In my experience most people using the arcpy site package would be more than happy to learn about potentially more efficient or cleaner approaches using open source python tools. I always keep in the back of my mind the idea that we are building a repository of Q & A's for future users, so I agree with @PolyGeo in that we need to make sure the Q&A's are focused.

With that said, if I see a question tagged as both arcpy and python, I consider that an open invitation to post open source python solutions using tools such as geopandas. However, if I see a question tagged with only an arcpy tag then I will usually add a comment saying something along the lines of "Are you interested in an open source python solution?". If they agree, then the python tag can be added and the answer posted. Another alternative would be to first answer the arcpy question and then add a secondary, open source approach in the same answer. In my opinion, answers that describe two or more ways to achieve the same goal are the most beneficial.

Answer 2

I learned python by learning arcpy (or its predecessors), and so many of the solutions I came up with to perform my tasks used the arcpy tools. This wasn't always because it was the best way to do something, but because it was the easiest for me to find help for. The local Esri support, the Esri forums, plus my search terminology all lead me to arcpy related help.

As I grew more familiar with python itself I came to realise that the arcpy way to do things wasn't always the best/quickest/most efficient, and I am grateful to those who showed me there were other ways to get the desired result. These were not the "dump ArcGIS and use XYZ instead", these were more along the lines of "this part of your arcpy code could be improved if you use this non-arcpy method". (And of course many times I found that arcpy had a more efficient solution than the non-arcpy method I was using to start with, since it was built with GIS in mind)

I see no problem in providing alternative solutions that compliment the software being used (rather than replace it). GeoPandas can certainly compliment arcpy, particularly when the arcpy scripts are getting longer and more complicated. i.e. do something with GeoPandas then pick up the output with some arcpy, or vice-versa.

Answer 3

It can be very confusing for a beginner in python to get an answer targeting another package; although GDAL, geopandas, PyQGIS, shapely etc. can do 'XY' the python novice may have absolutely no idea of how the code works - I've seen this many times where a user has copied a snippet and tried to customize it to meet their needs but lacks the understanding of what it is the code actually does. If someone is asking for an arcpy answer it's best to keep it to arcpy despite being simpler or faster in another lib.

Also consider that in some environments users cannot install any site package without working through their I.T. department, who may have an unfair bias against open-source libs and refuse to install a package without an in-depth cost/benefit analysis. It would not be unusual for users in government, defense or large companies to have no write permission to their system drive except for their user profile.

That said, you can ask in the comments if they have access to and/or experience in a different package.. many users will just want something that works and not be too fussy; I would also see no problem in answering with an arcpy solution and then a better solution in a different lib in the same answer as an alternative.

Answer 4

Yeah, it makes your answers far more difficult to find.

Instead, you should make your own question and then answer it yourself that way you can share knowledge QA style. Doing this will make that knowledge far more accessible.

Keep in mind that there are people using uncommon or less common technologies for their GIS scripting needs that simply will not see arcpy questions because they do not care at all about arcpy.

How would you feel if the only major source of information about your congressman's voting record was in a specific car manual? This is literally the same thing.