Latest Contributions by berniejconnors

Kimnet,         LERC is just one option for compressing your elevation rasters. We chose to use a lossless compression. No compression is also an option. Bernie. ... View more

Kevin,         If you check the number of views each day and then save that value to a file or table you will be able to calcualte the increase in views each day.  I would use a Notebook to do this job.  ArcGIS Notebooks have a built in scheduler to trigger the python script. Bernie. ... View more

Martin,         Is all of the data hosted on your own ArcGIS Enterprise Servers - including the basemap? When I did this 8 years ago I was using data hosted on my own ArcGIS Server combined with the ArcGIS Online World Topo basemap.  That might expalin the better performance you are getting.  Regardless, I would say the performance with reprojection on the fly is suitable.         I did notice this in the Survey123 FAQ, It may be helpful: "All basemaps used in the Survey123 field app must use the Web Mercator Auxiliary Sphere projection. Basemaps with other projections can only be used in the web app." Bernie. ... View more

Martin, The draw times will really suffer if you are reproecting a lot of data on the fly.  I recommend you try it both ways.  Create a copy of your data and reproject it to Web Mercator.  Create two web maps, one with the data in the local coordinate system and a second with the data in Web Mercator.  See for yourself how much slower the web map is with the local coordinate system data on a Web Mercator basemap. I had to do this myself about 8 years ago.  The performance was too slow in our local coordinate system.  I reprojected all of the data to Web Mercator. However, today my solution is to use our own basemaps that also use our local coordinate system.  If you create your own basemap you don't have to use Web Mercator. Bernie. ... View more

Nicauldron,         I don't publish map services very often any longer.  That job has been passed to one of my co-workers.  But I do recall there were several transformation methods to go between ours CRS (EPSG 2953) and WGS84.  If the wrong method was used there would be a ~ 1 metre shift when our data was combined with other data in a Web map.  To prevent this from happening I had to define the preferred transformation in the properties of the MXD I was using to publish the map service.  I expect there is a similar capability for ArcGIS Pro.         Here is a discussion of the NAD83 to WGS84 transformations that may help you decide if a similar problem exists for the BNG - https://desktop.arcgis.com/en/arcmap/latest/map/projections/choosing-an-appropriate-transformation.htm Best regards, Bernie. ... View more

We solved our own problem: After reopening the 3 vector tile web maps in map viewer classic and resaving them, the issue appears to have been resolved. Bernie. ... View more

Michael,         Are your users noticing performance problems?  If all you have is some graphs showing some slow response times you might still be satifying 99% of your users.  And just 1% of your users are doing stupid things and causing their own problems / slow responses.         To look into the problem I would look at the web adaptor logs.  My ArcGIS Server deployment has the web adaptors running on a separate Linux server under Apache.  On your single machine deployment your web adaptor is likely running under IIS but I am not certain.  Go into the IIS logs and at look at the incoming requests.  The web adaptor log file should include the duration of the request.  Examine the long running requests and identify what it is your user was trying to do.  The web adaptor log records should include the REST URL of the request.  Are they requesting a lot of data?  Are they trying to match a search term against all attributes in a map service instead of just querying against a single attribute?  Is there one service that is causing most of the slow requests?  Are all of your slow requests coming from the same web app?  Is someone trying to scrape data from your map services?  You should be able to get a lot of info from your web adaptor logs.         I find the web adaptor logs very useful for identifying long running requests.  Every day I run a report to identify all requests that exceed 60 seconds.  I usually have to examine about 100 records each day.  We get close to 1 million requests each day.  Most of the time I just look at the time stamp on the request: At midnight our services recycle.  At 1 am our server reboots.  At 2 am we update several map services with fresh data.          If I see a slow request outside of these times I will look more closely and try to determine why the request was slow.  I'll copy the ArcGIS REST URL from the log file and run it in my browser.  I'll examine all of the parameters in the URL and determine what the user was trying to do.  This helped me identify a Web App Builder app with a poorly configured Search widget.  It was one that I had configured myself. I hope this helps, Bernie. ... View more

+1 for this request. ... View more

I have a similar experience with the service recycling consuming 100% of the CPU.  And I also notice the response times are longer during the service recycle times.  But I have left the recycle times alone.  We have just recently changed our ArcGIS Server reboot schedule.  We have 4 servers and we previously rebooted daily but we have increased the interval to twice per week.  Each night at 1 am 1 or 2 of the servers are rebooted and there is a 3 or 4 day gap before a server is rebotted again.  Reboots occur on Sun, Mon, Tue, Wed, Thur, and Fri.  So far we have not noticed anything detrimental but we may still tweak this schedule. Server 1        1 am, Sun, Wed Server 2        1 am, Sun, Wed Server 3        1 am, Mon, Thu Server 4        1 am, Tue, Fri The primary reason for reducing the reboot schedule was because we sometimes found problems with communication between our web adaptors and the ArcGIS Servers following an ArcGIS Server reboot.  Hopefully, fewer reboots will mean fewer web adaptor issues. Bernie. ... View more

Good suggestion @ChadKopplin.  If you still have trouble publishing from a new map within the existing Pro project you may want to create a new Pro project from scratch and try again. Bernie. ... View more

imsail, It sounds like you are using an air photo basemap.  An air photo basemap would need a raster tile cache.  How many levels are in the raster tile cache for this air photo basemap?  Check the REST services directory for the basemap to see the scale for the highest level ID.  For the service in the image below it is Level ID 13 with a scale of 1:564.    When you zoom in to Street level you are likely exceeding the largest scale level in the raster tile cache. Bernie. ... View more

You should make sure your feature layers and map image layers are performing their best before trying to solve the problem with hardware.  We were able to improve the performance of our map image layer for our parcel data with scale thresholds and labeling improvements. Bernie. ... View more

That is an interesting idea.  So the layers widget would have radio buttons instead of check boxes.  Sorry, I don't have an answer for you.  It sounds like a custom widget is what you would need. Bernie. ... View more

I agree - we see a similar ~15 minute outage when we reboot a server. ... View more