Latest Contributions by EricEagle

I'm a newbie to the Portal API for Python, and I am just trying to figure out how to go from geojson loaded into memory (say, a WFS response object) to a feature layer on an ArcGIS Enterprise portal.  I'm happy to read documentation and follow examples, but everything I've seen involves messing around with CSVs and pandas (which then requires cleaning up field headings etc). Additionally all the questions seem to presuppose you have a geojson file sitting around, but what about when you want to avoid the IO overhead?  Seems silly to write the content out to a file, only to read it right back in again. Is there a more-or-less direct path to go from the data in the buffer, in json format, right to a new feature layer? ... View more

I have a custom geoprocessing tool that currently takes raster layers (DSMs and DTMs).  However, to scale it up and reduce the need for end-user research, I built large raster mosaics of the input data needed by users.  Then I published those as Map Services on ArcGIS Enterprise.  So far good to go.   However, nothing I've tried will allow my tool to set those loaded service layers as inputs to my tool.  Just for clarity, in the picture below I need to pull in the content annotated by the red rectangles.   For Parameter types, I've got: ['GPRasterLayer', 'GPRasterDataLayer', 'GPMapServerLayer', 'GPMosaicLayer']   but none of them will see the map service layer I'm trying to bring in.  How do I access this content as a parameter type? ... View more

Dear Esri, I would like to see the ability added to ArcGIS Pro to share out a geoprocessing tool without the hassle of running it and then publishing it from the geoprocessing history. When you share out the tool from GP history, it uploads all the data used for that particular run.  I believe this is a bad way to do things because first, you could have non-constant data that is very large.  For example, I tried sharing out a short tool to my Enterprise portal, but the data I ran the tool against was a mosaic on the large side (10s of GBs).  I do not need to publish the mosaic. I only want to share the tool. I do not think the answer "just run it against something smaller" is correct.  That actually highlights a flaw in the way this workflow is designed.  Ultimately we need something like this image:   Let me just share the tool. This would be much cleaner.  Unnecessary default values are left blank, and it is up to the analyst/dev to link to any constants (flat files, db's, service endpoints) in creating the tool.  There is no need to run the tool, generate a history record, and then publish from the record which feels very cumbersome. If the history record workflow cannot be changed, please at least offer users an option for which data NEEDS to be uploaded with the tool - all, some, or none.  This wouldn't be perfect but would be a big improvement. ... View more

I figure there's a post on this already but I couldn't find one.   As the presence of ARM processors grow (i.e., it's not just a Mac thing anymore), and now that Microsoft has a fully supported ARM64 version of Windows 11, I think it's time for Esri to look at releasing a version of ArcGIS Pro that runs natively on ARM64 runtimes.   If this is a duplicate idea I apologize - if so, please link me to it so I can support! ... View more

I'd like the ability to export the symbology of a layer in the ArcGIS Pro canvas as a python snippet.   When I'm writing a script tool that performs some loading and symbology of layers, I sometimes have to run the script over and over again to ensure that the symbology is what I want. It would be really cool if I were able to export symbology I'm happy with as a Python snippet that I could then just drop in a script tool with a little refactoring. Specifically, I see this working by using the hamburger (overflow) menu in the Symbology tab, click the menu, and then maybe an "export as python" (which would save it to a file) or "Copy python snippet" (builds/stashes the snippet in the clipboard for pasting into a script -- this is my preferred method). This would save a huge amount of time when it comes to the more tedious aspects of script tool construction (and symbology definitely falls in that category!) allowing analysts/devs to focus more on the core geoprocessing and worrying less about coming up with symbology code from scratch. ... View more

Portal connections should be managed in the main ArcGIS Pro application for all other Esri applications.  It does not make sense to add ArcGIS Portal connections in Pro, and then turn around and add the same connections in ArcGIS Earth.  Earth should just list portals that have already been added in Pro.  This would help tie in software that is otherwise very non-integrated with the rest of the ArcGIS desktop suite. ... View more