Latest Contributions by danbecker

‎11-16-2020

ESRI- How are ESRI hosted basemaps delivered when a client downloads them in Collector? Is our on premise ArcGIS Enterprise deployment used as a proxy to the ESRI hosted tiled basemaps? I'm assuming all connections are using TCP? This info. will help me troubleshoot why slower connections are "timing out" on our XG firewall.

‎11-14-2020

Long story longer, about 3 weeks ago we switched to Sophos XG firewalls and there seems to be an issue with them. This morning, I pulled the XG Firewall and re-installed of pfSense firewall and the problem went away re: downloading maps over high latency connections. But, that doesn't fully explain the problem because in the last few weeks with the XG firewall installed, we were NOT having issues downloading raster basemaps. My opinion is that some type of timeout settings have been changed on the tiled basemap service that craps out slower connections. With our pfSense router (2x as fast compared to XG) that latency issue is minimized and the download from the tiled map service doesn't timeout.

‎11-13-2020

Has there been changes to ESRI hosted tiled basemaps this week? We're running Enterprise 10.8.1 and this week started having issues getting ESRI tiled basemaps to download as offline areas in Collector. All we get is an error "failed to download offline area". No errors in Server Manager log. I changed my password in AGOL to make sure it was long enough, it was "grandfathered" and only 6 characters long. I then copied this URL from a tiled basemap: https://tiledbasemaps.arcgis.com/arcgis/rest/services/World_Imagery/MapServer In Enterprise Portal 10.8.1 I Add Item from URL, enter that basemap URL, then store credentials. I then add that layer now listed as an item in Portal to a new blank map, set as basemap and share with Basemap group. The basemap then shows up in the Basemap gallery, just like the documentation here: https://enterprise.arcgis.com/en/portal/latest/use/take-maps-offline.htm When on Wifi we can download a webmap in Collector that uses the above basemap, no problem. But when on a cellular connection or Wifi network that is distant from our Enterprise deployment we get the error "failed to download offline area". Here's where it gets interesting. If we open that same webmap, then Add/Layer from Web and enter the basemap URL, and set as basemap, then try to download in Collector we are prompted for AGOL credentials. We enter the AGOL credentials and the download proceeds without issue regardless of cell or wifi network. What could have changed in the last week? Are stored credentials expiring or not working correctly when high latency connections are used?

‎11-13-2020

Enterprise 10.7.1, we cannot download offline areas when the latency between the remote user and the GIS Server machine is high. The remote Collector user get a generic error "Failed to download the offline area". We tried both Android Collector and new Field Maps apps. Users a few states away have issues even on Wifi. Any tips here?

‎11-13-2020

Same issue here, Enterprise 10.7.1. Seems like certain Android devices cannot download offline areas (Google Pixel 3) using the latest version of Collector. All our webmaps have Enterprise feature layers; postgresql 9.6

‎09-23-2020

Win 10 Pro is fully updated, version 2004 Win. control panel, uninstalled Pro, then rebooted. Clean install 2.6, opened the same Pro project as before, then the same local C:\ FGDB, the problem still persists. Installed 2.6.1 patch atop 2.6. Created a new blank project, accessed the same local C:\ FGDB, problem solved Closed new blank project. Opened same Pro project as before, then the same local C:\ FGDB, the problem still persists. Removed all items in geoprocessing history (147 of them), the problem still persists. Edit: testing continues.. Created new Pro project using an existing template we had. Had 2 instances of Pro open, the problematic project from above and the new one. I then copy/pasted the Pro map over to the new Project. In the new project, I now have the original map from the old project. I Field calculated the same local C:\ FGDB, the problem still persists. Created a new blank map in the new Pro project, I Field calculated the same local C:\ FGDB, problem solved So, this bug is related to the Pro map, project, which makes sense, because my Collegue and I are working on the "same" project/map. He opened the original and did a SAVE-AS, I'm still using the original. Edit: finally figured out the bug, it's related to a Hosted Feature Layer being present in the map. Steps to test attribute calculation: Select a record in attribute table. Right click on field, calculate field, specify a string to calculate, hit APPLY make sure and leave the field calculator floating window open change the selection in the table to a different record the field calculator window is already open, don't change anything except a new string to calculate, hit APPLY or OK, doesn't matter Steps to Repo the issue with calculating attributes when HFL is present in the map: Create a new blank pro project. Insert a new blank map. Add a single FGDB layer to the map. Perform the above "Steps to test attribute calculation". Everything will work as expected. Add a HFL to your map. We use Enterprise, I have not tested AGOL HFLs. Perform the above "Steps to test attribute calculation". You will see the problem where the incorrect record is calculated. Remove the HFL. Perform the above "Steps to test attribute calculation". You will see the problem where the incorrect record is calculated. Once the HFL is added, even after it's removed, the attribute calculation problem persists. It's not corrected until you create a new map.

‎09-22-2020

I created a new FGDB on local C, created new poly feat class with 1 field. Digitized 2 non-overlapping polys. Same result, the incorrect record is calculated, just like the initial steps. So, this has nothing to do with the location of the FGDB (local vs. network share)

‎09-22-2020

The video uses a simple FGDB on a Win Server 2016 network share; I wanted to simplify the environment, but in our case (2 different workstations, 2 different Pro licenses) it doesn't matter. A feature service, SDE Feature Class or FGDB all produce the same result as shown in the video. We have to be REALLY careful when calculating attribute values.

‎09-22-2020

I renamed both those folders to _old, then re-opened Pro, and navigated to the same FGDB for the test calc's, the issue still persists.

‎09-22-2020

I had to split the video into 2 parts; pretty basic but illustrates the issue. This is really bizarre.

‎09-22-2020

I have never done a clean install, I've upgraded several versions atop each other. I installed 2.6, then 2.6.1 (the SP), the update was not a clean install. A co-worker was able to repo. the issue, he also did not clean install, actually, can't because I'm the person with admin. privs to run installs.

‎09-22-2020

When I documented the steps above, I was using an SDE GDB (postgreSQL 9.5), unversioned, archiving enabled. So, I created a new FGDB on disk, found a random poly feature class from a different FGDB, copy/pasted it into the new FGDB, then completed the above steps. Same result. The first selected record is calculated.

‎09-22-2020

Is this expected behavior on 2.6.1? This is VERY DANGEROUS. Select a record in attribute table. Right click on field, calculate field, specify a string to calculate, hit APPLY make sure and leave the field calculator floating window open change the selection in the table to a different record the field calculator window is already open, don't change anything except a new string to calculate, hit APPLY or OK, doesn't matter Notice what happens…you would expect that the record selected in step #3 would be calculated, i.e. the one currently selected, but it actually calculates the formally selected record, i.e. the selection in step #1.

‎07-27-2020

Enterprise 10.8, Server is installed on Win Server 2012. Portal and Datastore are installed on seperate Ubuntu 18.04 machines. I get an error that the Win (ArcGIS Server) machine can't access the BACKUP_LOCATION path I specified, obviously because it's in a Linux format. All machines can reach the BACKUP_LOCATION, but I need to specify it using 2 formats...tricky. Any work around for this? I just want to run the webgisdr tool to clear out the portal logs so I can get rid of that nag in the Portal log. thanks.

‎07-17-2020

confirmed working. Thanks everyone.

Online Status	Offline
Date Last Visited	a week ago

My Ideas

Latest Contributions by danbecker

Re: Change to ESRI Tiled Basemaps, Access from Enterprise?

Re: Change to ESRI Tiled Basemaps, Access from Enterprise?

Change to ESRI Tiled Basemaps, Access from Enterprise?

Failed to download offline area - over slow connections

Re: "An error occured downloading the map area" - New Collector

Re: 2.6.1 - field calculator with selection, dangerous bug

Re: 2.6.1 - field calculator with selection, dangerous bug

Re: 2.6.1 - field calculator with selection, dangerous bug

Re: 2.6.1 - field calculator with selection, dangerous bug

Re: 2.6.1 - field calculator with selection, dangerous bug

Re: 2.6.1 - field calculator with selection, dangerous bug

Re: 2.6.1 - field calculator with selection, dangerous bug

2.6.1 - field calculator with selection, dangerous bug

webgisdr - mixed Linux/Win Environment

Re: Survey123 feature report - anticipated fix?

Re: Portal for ArcGIS upgrade from 11.5 to 12.1 no...

Re: Azure Files premium file share - SLOW File Geo...

arcpy layout.export - hosted feature layers not sh...

Re: Survey123 Date Only shows incorrectly on Repor...

PostgreSQL - Important Backup Info