Latest Contributions by BillSchlatter

‎05-17-2019

I agree, and I would add that it would be very nice if there was an easier way to copy/access arcade expressions between layers and webmaps. I'm working on a series of maps right now that display the same basic information in a variety of ways, and I'm probably spending more time switching between AGO tabs, opening expressions, and copy/pasting code than most of the other phases of the project combined. One layer with a heavily-customized pop-up has 19 attribute expressions, a custom-configured pop-up that uses all of them, and Arcade-based styling. I use multiple versions of the layer at different zoom levels (zoom-based styling in AGO would also be nice, come to think of it), and keeping the pop-ups consistent between layers is increasingly labor-intensive.

‎05-17-2019

In short, feature layers don't cut it with larger datasets. My organization makes a lot of web maps and web apps showing data about our regional road network. This road network consists of over 250,000 road segments. Dissolving or unsplitting the network reduces the feature count and improves performance considerably, but we would lose a lot of precision regarding details like pavement condition and traffic counts in the process. Quite simply, the network does not display properly when we load it into an AGO map, and vector tiles would be an excellent solution in many cases if they could have pop-ups and/or some degree of filtering. One example we have online right now that uses vector tiles quite well can be seen here: https://maps.semcog.org/nfc/. Some of our other maps use a clumsy, difficult-to-maintain hybrid of raster tile layers when zoomed out combined with feature layers when zoomed in. That solution gets us pop-ups, though those pop-ups can be extremely labor-intensive to build and maintain because there's no easy way to copy pop-up settings and arcade functions from one layer to another, even if they're both instances of the same feature service. The fact (bug?) that one can't update pop-up settings on a tile layer, only rebuild the entire pop-up configuration from scratch, makes it even more aggravating.

‎05-17-2019

This is a big enough issue that my organization has dedicated a significant amount of manpower to creating a backup script to solve the issue ourselves. At present, it runs a nightly back-up of nearly all of our AGO data, with some limitations I'd have to talk to the developers to outline. Last I heard, they were working on cleaning up and generalizing the code enough to make a public Github repository. If/when that happens, I'll post a link here.

‎03-18-2019

Many organizations are happy to share large amounts of open data with the public, so long as they can clearly disclaim liability for members of the public using the data in unexpected or unintended ways. Items hosted in the ArcGIS Online Open Data Portal do already have a License field where such legalese can be included, but it must be actively clicked on by the user to view it. A disclaimer that can be so easily overlooked is less legally sturdy than one that users must actively click "I Agree" to acknowledge. Based on all that, it would be very nice to have some ability to configure a splash screen welcoming users to the Open Data Portal and requiring them to agree to a general license agreement before proceeding to the data. Even for organizations that do not have need of such license agreements, it would be nice to have some sort of ability to post a splash screen that would be seen by people who follow direct links to pages other than the front page of the Open Data Portal.

‎03-11-2019

I'm running it out of a file geodatabase, and it's on a network drive.

‎03-07-2019

I hadn't, just because I don't like ArcMap very much so it didn't even occur to me as a possible alternative. I have now tried it in ArcMap with the same settings as one of my fail test cases in Pro. ArcMap fails, too, and on an earlier cartographic partition than Pro does. ArcMap's memory consumption appears to be even lower at the time of failure, which isn't a surprise given the limitations of 32-bit architecture. 64-bit software like Pro should, in theory, be able to use far more memory than the 64 GB on my system, but I'm starting to wonder if there is a limit on how much Pro can use, whether by design or by accident.

‎03-07-2019

Short version: The Simplify Line tool is failing for me, throwing Out of Memory errors. I'm running this on a system with 64 GB of RAM, and the Task Manager reports never getting above about 14 GB used across all processes before the tool fails. Does anyone know why this might be happening, or how I could prevent it from happening again? Long-winded explanation: I have a series of 1-foot contour line datasets for several counties in my region. They are pretty heavy datasets, ranging from 1.7GB to 4.8GB apiece. I'm currently trying to use the Simplify Line tool to reduce their complexity, improving map performance and ease of distribution, but I'm running into issues with the tool. In particular, I keep getting Error 000426: Out of Memory (000426: Out Of Memory.—Help | ArcGIS Desktop). I have watched the system resource usage in Windows Task Manager, and it's not even close to running out. I'm running it on a remote system with 64 GB of RAM, and the highest I've seen the total system usage get before the tool fails is 14 GB, with 6-8 GB being far more common. I've double-checked with our IT department, and there's no limitations no how much RAM a single user can use on that system, and I have this problem even when I'm the only user logged in. I am using cartographic partitions generated using the Create Cartographic Partitions tool to try to reduce the amount of data in memory to a more reasonable size. I've tried generating minimum-size partitions (500 features per partition), and the tool still eventually fails, after succeeding at a number of low-density partitions. The same thing happens if I filter out 80% of the lines to show only elevation multiples of 5 and run it with those tiny partitions. Through trial and error, I've found that I can get the tool to complete successfully on the smallest, lowest-density county if I filter the features to show only elevation multiples of 25, hiding 96% of the lines. That is why I'm trying to figure out how to make these settings work - those results look good, while the output of the Generalize tool (which does complete successfully) looks jagged. Also, I don't want to have to merge together 25 result datasets per county, and that's a conservative estimate, because it's likely the larger, hillier counties would need to be filtered even further. I am using the following settings: Simplification Algorithm: Retain Critical Bends (Wang-Muller) Simplification Tolerance: 10 Feet Everything else (besides Cartographic Partitions) is default. Edit to add: I'm currently using ArcGIS Pro 2.3.0.

‎01-23-2019

We didn't get anywhere with technical support, either. They suggested attempting the updates using one of the Python libraries for interacting with AGO, which we didn't try because, at the time, none of our developers had any experience with those tools. We wound up doing it the hard way, re-making and re-uploading all of the error-throwing geodatabases to get versions onto AGO that we could update. We now have someone refining a Python-based backup script that lets us maintain offline backups of our AGO content, so we'd probably give the Python approach a try if the problem somehow recurred. Which it hopefully won't.

‎10-08-2018

I have tested the procedure with new gdbs made and uploaded through Pro, and that works fine. That's our long-term plan for maintaining these datasets, actually. We are mainly hoping to avoid the headache of checking all of our webmaps to be sure we don't break anything when we upload new versions from scratch at this point. I asked my managed about the gdbs, and was told that they are actually relatively recent, created using ArcMap 10.5, which is the version our office is still using. The data was pulled from our ArcGIS Server instance, though, and it's possible there was some weirdness introduced there. At this point, we've just decided to submit a tech support request, and assume there's a reasonable chance we'll have to do the upload-and-replace workflow we've been trying to avoid after all.

‎10-08-2018

I'm pretty much the new guy in the department here, and I'm the only person trying to use Pro for routine tasks so far, because I don't want to spend the time to learn two interfaces at once when one of them is, at least in theory, going to be obsolete in a few years. It's safe to say that the file geodatabases that were originally uploaded to AGO were made in ArcMap. As an experiment, I tracked down the original file geodatabase used to upload one of the services, and tried uploading it to my own user account through the AGO->Contents->Add Item interface, the same workflow used to upload the services I am now trying to overwrite. I then tried overwriting it through Pro, and I got a completely different error: "Service cannot be overwritten if Sync is enabled and replicas exist." After double-checking the settings in AGO, I can confirm that Sync is, in fact, disabled, and was disabled when I tried the overwrite. So now I'm very confused, and wondering if something is wrong with the original file geodatabases, even though the services they produced work fine in webmaps.

‎10-08-2018

That is correct. In Pro, I can see all the hosted feature layers, but most of them error out when I try to overwrite. In ArcMap, I see a much shorter list, consisting mainly of recently-uploaded datasets that don't need to be updated as of yet. And yes, I've been double-checking to be sure that I'm logged into the correct account in AGO, Pro, and ArcMap at every step of this process, and I have double-checked that the services in question do indeed belong to that account as Kelly Gerrow suggested.

‎10-08-2018

Double-checking ownership and currently logged-in accounts, everything still matches up. I don't think I'd even be able to see the services in question through the Catalog pane in Pro if I weren't logged into the correct account. The datasets in question were originally uploaded as zipped file geodatabases, which doesn't seem to create a service definition file on AGO. Some of them still have the original .gdb, some don't, which doesn't seem to affect whether they can be overwritten. Is there a serviceconfiguration.json file in a .gdb? I don't see anything like it, but I'm not sure if there's a way to view the entire contents to check. My manager is probably going to put in a tech support request soon. I originally posted here in case it was a common problem that I could get a quick answer to, but that doesn't seem to be the case. Thank you for your help!

‎10-04-2018

I hadn't tried that - I honestly hadn't realized it was possible. I'm fairly new to the GIS field, and have been focusing my training on Pro in anticipation of ArcMap eventually being deprecated. To be perfectly honest, I find ArcMap's fields of tiny buttons and menus within menus within menus to be pretty hard to decipher. I think I tracked down how to do it in ArcMap - File->Share As->Service->Overwrite an Existing Service. Unfortunately, that solution doesn't seem to work, either. When I get to the list of services that could potentially be overwritten, the vast majority of the services in the account do not appear. Only one item out of about 50 in one of our larger folders is on the list, for example. The services that do appear (mostly in other folders) are all displayed with underscores instead of spaces, regardless of how their names were actually typed. Removing all whitespace from the non-displaying services doesn't make them start appearing on the list, either. Once again, the behavior appears to be confined to the account that hosts most of our organization's data - overwriting from ArcMap works fine, as far as I can tell, for datasets that have been in my user account since before the issue arose. Thanks for the feedback! Do you (or anyone else) have other ideas?

‎10-02-2018

My organization is currently getting ready to update a large portion of our data on ArcGIS Online, and in order to minimize the updates necessary to our various webmaps, we're trying to use the ArcGIS Pro feature Overwrite Web Layer. However, the user account that hosts the vast majority of this data can't seem to make it work. It doesn't seem to be user error - an identical workflow produces the expected results when done using my own user account. Whenever we try overwriting to our main hosting account, however, we get this error message (Screenshotted in the attachment): "Cannot overwrite <layer name>. Please configure that you are signed in as the web layer owner and the location of the item has not changed." (The odd word choice is accurate, as you can see in the screenshot) We are logged into the correct account in both ArcGIS Pro and ArcGIS Online. The location of the item has indeed not changed since being uploaded. We've tried a variety of fixes, many based on other questions from people having trouble with the Overwrite Web Layer feature. These include: Renaming layers and/or folders to remove all spaces, moving the layer to the account's root directory in AGO before trying to overwrite, and changing ownership of the layer in AGO to my user account. None of theses options have worked, and in the last case, only layers moved from our main hosting account threw the error message - datasets uploaded directly to my account can be overwritten without issue. We know that we can always upload the datasets anew, but since many of them are referenced in active webmaps, that creates a lot of extra work tracking down and updating all the webmaps as necessary. Also, the Overwrite workflow is one we expect to be using repeatedly in the future if we can get the issues worked out, so we'd like to know how to make it work reliably. Does anyone have any experience with this problem? Or suggestions for workarounds?

‎07-16-2018

I'm currently working on a webmap for display using ArcGIS Online, and I've been asked to include a heat map layer based on the data. There are too many data points for AGO to render the heatmap efficiently, so I'm trying to create a tile layer in ArcGIS Pro to speed up performance (using Sharing -> Share as Web Layer). It technically works, but there are display errors along the edges of tiles at some zoom levels. I've attached a few screenshots of examples. I understand that this problem is similar to another question from a while back: How do you fix heat map 'tears' after exporting from ArcGIS Pro? The key difference is that I want a tiled output result for use on a webmap, so workarounds that involve converting to .jpg don't seem to solve the problem. Has anyone else encountered this problem? And has anyone found a way to make this kind of map display correctly?

Online Status	Offline
Date Last Visited	‎03-17-2025 07:37 PM

My Ideas

Latest Contributions by BillSchlatter

Re: Save Arcade Expressions

Re: Vector Tile Popups

Re: ArcGIS Online Back-ups - hosted feature layers and web maps/apps

Splash screen for Open Data Portal

Re: Simplify Line Tool throws Out of Memory errors at under 25% usage

Re: Simplify Line Tool throws Out of Memory errors at under 25% usage

Simplify Line Tool throws Out of Memory errors at under 25% usage

Re: Why is the Overwrite Web Layer operation failing?

Re: Why is the Overwrite Web Layer operation failing?

Re: Why is the Overwrite Web Layer operation failing?

Re: Why is the Overwrite Web Layer operation failing?

Re: Why is the Overwrite Web Layer operation failing?

Re: Why is the Overwrite Web Layer operation failing?

Why is the Overwrite Web Layer operation failing?

Is there a way to "fix" rough edges on heatmap tile layers for online display?

Hub Outage?

Re: Download Issues - Consistent File Generation i...

Re: Why is the Overwrite Web Layer operation faili...

Re: Why is the Overwrite Web Layer operation faili...

Why isn't Create View Layer working for some layer...