Latest Contributions by ErikLash1

Pro 2.6 clean default environment from fresh install. Conda'd clone. Conda installed Spyder 4.1.4. Spyder generates errors. Same result when Spyder conda'd in default environment.  ... View more

Spyder Notebooks looks great but still no go - Spyder keeps throwing errors in both clones and the default Pro environment. Was worth a try and at least uninstalling and reinstalling Pro doesn't take very long. spyder                    4.1.4                    py36_0 This time: logger.error('%', 1, stack_info=True) Message: '%' Arguments: (1,) May try installing prior verion of spyder. ... View more

The ArcGIS API for Python is a fantastic implementation but there are some places where it doesn't fill the gap.   Examples of these include creating scripts for use in toolboxes or chained and complex workflows. Use case referenced in this instance is a chained GIS workflow that is basically its own custom software application implementation which manipulates GIS features across a multi-database and multi-file store ecosystem resulting in a new data product that has to meet rigid controls for integration into a 3'rd party web application with a data package that gets deployed to testing and prod GIS server environments. The REST API part of that process is very minimal but extremely crucial component - which we are still trying to update from Py 2.7 to Py 3.6 so we can completely end our use of ArcMap and Py 2.7.   What we really want to avoid is having to code some parts of the process in different Pythonic environments or in combinations of multiple languages.  What brought about my post on this thread is that we would very much like to have Jupyter Labs and Spyder working with the ArcGIS Pro environment as a super great and elegant solution for this particular application development need but are stumped because while we were able to work with them in Pro 2.5, we are among those that are struggling for success in 2.6 Presently using a combination of PyCharm and VSSCode to work with Pros Py 3.6.10 environment. Would love for a unified approach to the foundational Pythonic components of the ESRI ecosystem (especially since Py 2.7 and Py 3.6 are incompatible and as Dan notes some 3.6 components are already retiring) and really see that as something very important to both successful adoption of the tools ESRI provides to the user base and strong user support for the ESRI products moving forward. ... View more

Will give it a try. Thx Dan. ... View more

Struggling here as well.  We require the new functionality of Pro 2.6 to support specialized geodatabase topologies but everything I try to do to make the scripting environment work properly in Pro 2.6 is ultimately unsuccessful.  Another challenge being faced in regards to working in Pro 2.6 is that REST API documentation is terribly outdated - still promoting scripting in Py 2.7x.  We are dilligently trying to move away from Py 2.7xx as we modernize. I'm unsure at this point if script tools I created for Pro in 2.4//Py 3.6.x for interacting with REST API (that worked fine in both Pro 2.4 and Pro 2.5) are failing in Pro 2.6 b/c of ESRI changes or because of Python.changes b/c of the other difficulties being encountered in working with the Pro 2.6 python environment. One thing that I think would help would be if ESRI sever ties with Python 2.7 entirely. It's time. Py 2.7 has been dead for a while already and the python multiple personalities/support for a dead code base is making it very very difficult to transition to modern workflows, especially since ESRI seems to be still promoting for Py 2.7 for working with their products in the API and it's still being delivered with their enterprise products at install. On a related note - I had Jupyterlab working fine in Pro 2.5 and it was spectacular - imho a necessary integration into to the platform. Attempts to get either Jupyterlab or Spyder working properly in Pro 2.6 have been completely unsuccessful. Both of them result in broken enviornments on my workstation. ... View more

Working for me using default Pro environment in Pro 2.6.   Followed guidelines from this stack exchange post. arcpy - ArcGIS Pro Python Interpreter Setup with Visual Studio Code - Geographic Information Systems Stack Exchange  Summarizing approach:  Make sure that Pyhon extension is installed in VS Code. Press CTRL + , (comma) to open VS Code settings > type "pythonpath" in the search bar > update the following to match the if doesn't already. Python > Auto Complete > Typeshed Paths : C:/Program Files/ArcGIS/Pro/bin/Python/envs/arcgispro-py3/python.exe Python > Jedi Path : C:/Program Files/ArcGIS/Pro/bin/Python/envs/arcgispro-py3/python.exe Python > Python Path : C:/Program Files/ArcGIS/Pro/bin/Python/envs/arcgispro-py3/python.exe ... View more

Looks like some issues may be fixed in Pro 2.6. What’s New in the Geodatabase at ArcGIS Pro 2.6  "GeoPackage editing Last but not least, GeoPackages have emerged in the last few years as a format used in mobile applications and as a standards compliance exchange format. We’re happy to share that data stored in GeoPackages is now fully editable within ArcGIS Pro 2.6, including undo and redo capabilities." Just ran a quick workflow - created geopackage in Pro, copied features and tables from SQL Server geodatabase into geopackage, edited/deleted/created geopackage spatial features and non-spatial tables in Pro. Exited Pro and opened in QGIS. Deleted/edited/created/saved features in QGIS and worked with non-spatial table data. Exited QGIS and opened in Pro. Everything is there as it should be. Didn't test direct script access. ... View more

Hi Melita, We are currently having a discussion internally about orchestrating this transition. Has there been any update on releasing the files? And will they be released for both ArcMap and Pro or just Pro? Erik ... View more

Voted up. Toolkits to work with data are the most valuable foundation for good mapping practices. X-Ray has established itself as a community need. Would be great to be able to work with it in Pro. ... View more

Further information related to associated MS IE/Edge bugs (unverified by me, just adding it to the discussion): It appears this problem is related to crossing security zones.  Because the on-prem deployment is part of the Intranet and AGOL is not Edge/IE (now only Edge in my case). When the application is redirected across security zones, the session storage and local storage are cleared. When the session storage is cleared, this state is lost and hence results in broken experiences. Known issues on Internet Explorer and Microsoft Edge (MSAL for JavaScript) - Microsoft identity platform | Microsoft Doc…  window.open handle lost when redirecting across internet and intranet zones - Microsoft Edge Development  Local and session storage dropped when going between internet and intranet zones - Microsoft Edge Development  --- Also appears could maybe be an issue with the window.close(): usage in postsignin.html that triggers Edge automatic script blocking.  ... View more

Tech assist went as far as they could and we begrudgingly accepted closed with the resolution that we have to add "arcgis.com" to trusted site for every GIS user who authenticates on our services with IE or Edge when they are used in AGOL web maps. End users should NEVER have to suffer through getting this message: Just because our case closed doesn't mean the software isn't broken. It just means there is a hugely expensive workaround resolution that we have to go through. Additional information: In testing we temporarily fixed it internally by moving the Web Adapters to the machine on which the GIS Enterprise component is installed and running IIS rewrite rules to that machine from the public Gateway. In our case having the Webadaptors on a Gateway appears to contributing to the problem (or possibly creating it).  When the WA was on the component machine everything behaved normally. We also messed with our IIS headers at the gateway in testing. It appears the Web Adapter when installed on the gateway IIS is creating a condition where there are multiple headers being injected into the web stream, not just the ones from the IIS configuration. We set up and tested the the custom header for CORS "Access-Control-Allow-Origin" value="*" on the IIS even though this shouldn't be necessary if there are no restrictions required.  It completely fixed the IE/Edge issue with AGOL. Unfortunately, it broke everything else, all other authentication to the GIS services from other domains stopped working - everything except AGOL using IE/Edge.  Assessment of the web stream indicated a 2'nd CORS header being delivered from the IIS with a web adaptor installed on it.  One header turning into two as if a second CORS header was already set up. ESRI needs to hop on this one and get it fixed.  This is certainly a problem for which their expertise and some software tweaking can contribute to a global solution. ... View more

Also install Root and any Intermediate certificates that come from you CA signing authority in each of your GIS Enterprise software components.  Authorities like Go-Daddy use secondary signatories to do the work for them and if the Intermediate certificates containing the secondary signatures aren't installed into the chain, Trust won't be granted (in some instances but not all).  We have also found that ArcGIS Enterprise components have real problems ingesting Go-Daddy IIS formatted certs (.p7b) that come standard in Go-Daddy Microsoft certificate downloads. To work around the .p7b problem in a MS server house running IIS our method for implementing certs: - Install Root and Intermediate certs to the IIS Server machine using Microsoft Windows formatted certificates from the signatory. - Install the .PFX on any web servers hosting Web Adaptors and any Gateway machines and configure HTTPS bindings in the web servers. - Install Root and Intermediate to each Microsoft Server Machine OS on which the GIS Enterprise components are installed using the Microsoft Windows formatted certificates. - Switch to the Linux formatted certificate package.    - Install Linux versions of Root, Intermediate, and PFX to each ESRI Enterprise software component that requires certs. Datastore only gets a .pfx. Note in the diagram below from the 2019 ESRI UC that specific trust is required in any federated configuration. Switching to all Linux versions of the certificates used inside the ESRI software components themselves completely cleared up the SSL trust problems we'd been experiencing intermittently over several versions of the GIS Enterprise. ... View more

Thanks! Super helpful. ... View more

Similar and possibly related issue on our domain with ESRI URLs after upgrade to 10.7.1. Microsoft shop. Had to add the URLS to end-user IE trusted sites to get AGOL to function properly when utilizing secured services being hosted on our domain in Microsoft browsers. No problem with browsers that stand alone from the OS. No problem before upgrading from 10.6.1 to 10.7.1 or with any of the earlier server versions. ... View more