Latest Contributions by CalvinHarmin

‎09-11-2025

Ah hah, thank you for clarifying. Here is the commit charge level from resource monitor. I think you've helped me exhaust the necessary steps to confirm things are fine. I'll consider this issue resolved and make sure ArcGIS Monitor doesn't scream from that pagefile metric on this machine. I appreciate your detailed answers, thanks again!

‎09-10-2025

Thank you that is an excellent collection of information and explanation. This machine has ~111GB of C:\ disk space allocated, currently at ~73gb free. So it seems the 1/8th cap (~13 to 14gb) you described isn't being hit. (EDIT: however, virtual server clusters can be weird, where although it has an 'allocation' of 111GB, it might not actually have that 'dedicated' to it on the server node unless the machine actually uses it all. Not sure if that could have any relevance here). EDIT #2: my postgres tablespace for my databases are on a secondary .D: drive (same ssd pool of the server node as the C: system drive). I'm not sure if that introduces any weirdness into the discussion. Postgres itself is installed on the C: drive. Here are the results of the wmic pagefile list /format:list command I checked Event Viewer and it seems there are no System log entries relating to low virtual memory condition. I tried manual review, and also specifically filtering for Event ID 2004 in the entire history, but I didn't come up with anything. I also filtered for all warning/error/critical level events and thankfully found nothing of note that has any relevance so far that I can tell. So that seems good that windows isn't screaming behind the scenes! Your note on the dynamic allocation base size is interesting though. It seems in theory, since my utilization remains above 90%, and that I haven't hit a cap of either 1/8 the hard disk volume, or 3x the physical RAM, that it should be automatically expanding the base size in my circumstance? But since there are no System errors being logged, it's not actually hitting a cap in a way that causes issues? One big gap in my understanding still is if postgres is holding on to this allocation without using it, or if the OS is independently holding on to it for some other reason/cause. I am not even at a level where I can ask the right questions about postgres' behavior this since this level of software/database architecture goes far beyond my level of understanding.

‎09-10-2025

Is the expected behavior to 'batch' the data using the maxRecordCount as each batch size, and it would just draw in slowly but surely? Or will the server literally stop responding with any more features?

‎09-09-2025

This maybe different in your version of Pro (i'm on 3.2.5) so take this for what it's worth. Sharing a map as a web map will basically make your whole map layer contents into a hosted feature layer, or hosted tile layer, depending on if you choose the configuration for exploratory/editible or the visualization option. I think if your map layers contain a raster image (e.g. your hillshade) then it doesn't give you the option and instead it will default to creating a Tile Layer. Although you can drill down and configure some properties of the Tile Layer that it creates, it seems it locks you into using the Tiling Scheme of the current basemap of the map you're publishing from. Maybe that's fine, as long as you get to choose the LOD you need: --- Alternatively sharing certain groups (or individual) layers as a Web Layer means you potentially have more control; you can have different layers that you publish from different ArcGIS Pro maps, to become separate hosted feature layers or hosted tile layers items in AGOL, and then you can choose what you want to add to a web map in AGOL, rather than having them all bundled together. I would generally highly recommend this if you tend to have different versions of web maps or need to republish map layers for various reasons as you're developing a map/app product. You won't be throwing the baby out with the bathwater, so to speak, if you find most of the layers are working the way you intended and only need to modify or republish certain ones.

‎09-09-2025

Ok just for a real quick test, it looks like when publishing a web layer and choosing 'Tile' you are presented with some Configuration options. If I pick auto-suggest, it seems to present a maximum LOD of 18 in my case. However, ArcGIS tiling scheme should let you go to level 23 (1:71). If you need an even higher LOD, or a different projection, you'll have to create your own Tiling Scheme which is not incredibly hard but it's a separate process. I had to do that, for example, for a custom basemap for some of my users to be able to zoom into features that are relatively close together, in order to be able to distinguish the features and their labels where necessary.

‎09-09-2025

Were you the user who originally 'published' or 'uploaded' this to ArcGIS Online? Do you recall the process that was used to do it? Edit: sorry I forgot you said that in the original post info. I have a feeling there must be a step in the creation or publishing that would have 'baked in' this LOD setting. I think there are a few different ways of creating a Tile Layer in ArcGIS Online, but if you remember your exact process then maybe there's a step along the way that can be modified to prevent this from happening. I'll see if I can test publishing a Tile Layer on my end from Pro and see if I can find anything that might help.

‎09-08-2025

I'm a relative newcomer to postgres but it is working well for us after migrating our data from SQL Server to Postgres about a month ago. Our organization does not have a DBA, so I'm it! In order to upgrade ArcGIS Enterprise 11.1 to 11.4+ we needed to upgrade our SQL Server licenses but that won't be done for another year from now at least; I had actually been planning the postgres migration for more than a year ago for this reason, and I finally did it. This also gives us (GIS) more isolated administrative control and ability to monitor performance of our data instead of it being squished on a SQL Server instance that is shared with loads of other databases from the organization. First and foremost, we are not experiencing any noticeable degradation in performance. Everything is running smooth. However, I did notice that Windows' pagefile utilization on the postgres machine is ~95% persistently, so I'm generally just asking if that's normal or expected? Should put it out of my mind, or is this something I need to address? --- Our postgres server is a virtual server on our local server cluster that was already pretty darn fast, and then we just upgraded our nodes recently, so it's even better. The OS is Windows Server 2019 Datacenter. The machine has 4 vcores and 32gb RAM. Our postgres database use case is fairly simple and straightforward, and not very intense. We have a few Enterprise Geodatabases, with one main production db that houses, for example, our core utilities and municipal datasets that we generally serve out as map/feature services for internal use. We generally use Traditional versioning rather than Branch. Only myself and my GIS coworker hit the database directly in ArcGIS Pro, or with various automations with Python (mostly using arcpy). We do multiple backups a day with pg_dump (for each db) & pg_dumpall (for global objects only) and I've done disaster recovery testing and restoration using ESRI's recommended process and everything checks out. The only config customizations I did for postgres was to set shared_buffers to 25% of physical RAM, so 8GB, per a lot of general recommendations I could find. All that is to say that we don't have an extreme burden on the postgres server. It runs pretty cool between 5-20% CPU with a few sustained few spikes to 40-50% (never seems to get saturated). About 30-40% of RAM is persistently 'In Use' with nearly the rest of the RAM is listed by windows resource monitor as on 'Standby'. Since so much RAM is available, I'm wondering why Windows (or postgres) isn't 'releasing' the pagefile, if that's the right term? Is it normal for postgres to reserve that pagefile for use? Windows is set to manage the paging file size automatically. The machine has been through at least one reset recently but the pagefile persistently is 'utilized', according to ArcGIS Monitor metrics. This Monitor alert is how I realized there even may be an issue, otherwise I would not have thought to check on the pagefile since we are not having any performance issues. Thanks for any info or tips.

‎09-08-2025

Looks like a sub-layer in there (the Tile Layer itself I guess) still has a visibility range set: Even if you change the visibility in the map viewer, the service may still be honoring the Tile Layer's settings from its creation (publishing). Can you show the method/settings you used to create/publish the Tile Layer? If I look at the REST service information for this Tile Layer, it shows a scale limit that will affect everything within it: https://tiles.arcgis.com/tiles/iiEO9Ir7FRiWwFTn/arcgis/rest/services/Saddle_Butte_WTL1/MapServer EDIT: woops @RhettZufelt beat me to it 😆 ... and I was looking at the wrong map service, but it appears they are both published with the same settings.

‎09-08-2025

According to this thread https://community.esri.com/t5/arcgis-online-questions/where-is-the-label-placement-property-for-lines/td-p/1356010 Line label placement options were added around Q2/Q3 of 2024. So I wonder if 11.3 Portal map viewer was buttoned up before that option was implemented? EDIT: It seems if you compare the 11.3 to 11.4 documentation, 11.3 does NOT include the note about line label placement. https://enterprise.arcgis.com/en/portal/11.3/use/configure-labels-mv.htm For point and line features, click the Placement selector and choose a different placement location of the label in relation to the feature or cluster.

‎09-08-2025

If I had to guess, the for each action is being provided an empty array [], so it is skipping the action since there are no items to iterate over. My suggestion is to look at the 'outputs' of one of your flow attempts: Fetch updates action Does the body of the outputs for this action actually contain a reference to a polygon feature? If not, you'll need to diagnose that to understand how and when it actually pulls info of a new feature If so... Get data from feature layer Does the output body have an array of 1 or more intersecting features?

‎09-05-2025

I commented on your idea post, but just for posterity for others, this is the expected behavior. Documentation does mention this: https://enterprise.arcgis.com/en/portal/latest/administer/windows/share-content-with-collaboration-participants.htm This doesn't mean syncronization is totally broken if you change the schema, for example by adding or deleting a field in the source data. Rather, the adds/updates of features simply will ignore any values that do not have matching fields from Portal source to AGOL. As you mentioned in the other post, you would have to un-share and re-share the item to your collaboration group, which would wipe out and recreate the item on AGOL side. However, it should retain the same item ID and the same service URL on AGOL side (at least from my testing). It would, unfortunately, remove any customizations to summary, description, tags, symbolization or popup customization, etc. on the AGOL item if you had made any such customizations. So it's probably always safest to customize the Portal item and not the AGOL item.

‎09-05-2025

I suppose the key phrase here is schema changes. This includes field changes (add, delete, alter fields), any domain changes, etc. These are not replicated after the Enterprise (Portal) hosted feature layer is shared, if initially shared with distributed collaboration workspace that is not set to 'reference' the Portal hosted feature layer, but rather creating a replicated copy of the hosted feature layer in ArcGIS Online. Does that sound correct? I guess it can be confirmed by looking at the service URL of the hosted feature layer item on AGOL side. If that's correct, I wonder if it is possible to simply 'reference' the Portal hosted feature layer rather than make a copy on AGOL side? Or do you need the AGOL to have a copy for purposes of external users hitting the AGOL servers, rather than users directly hitting your local Portal/Enterprise Server (through the AGOL reference)? I imagine having the option of replicating schema changes to between a source Portal hosted feature layer and an AGOL copy through distributed collaboration would be a significant change. If we think about it as a hosted feature layer being essentially a feature class in a postgres database in the backend, analyzing every sync for schema changes would entail more computes to do comparisons of every field, every domain, etc, every time it syncs. As it stands, I think globalid's of features are the primary key for the replication process and I have to assume edit/update/delete checks for features... I guess that's still fairly compute-intensive... but I also assume database indexing of just two or three fields makes it pretty efficient, and it doesn't care if your source schema doesn't match the replicated schema, it'll just append the values that it has matching fields for and ignore the rest. Schema change analysis may be less efficient and entail a wholly different set of processes when it does find changes? I'm just thinking out loud about the rationale that while schema updates can be done, it might entail a lot more compute power en masse for this part of the AGOL cloud infrastucture and maybe that's why it hasn't been implemented? I'm kind of rambling... all that said, I would absolutely welcome this capability, and in my case I am interested in replicating schema changes from Feature Services in Portal as well (that create a hosted feature layer copy on AGOL). Removing a share and re-sharing to recreate the hosted feature layer copy is not ideal, however I did notice from brief testing that, fortunately, the AGOL hosted feature layer service URL does not change and the item ID's match between Portal and AGOL. So if you focus on only making metadata changes on the Portal side (summary, description, tags, etc), then you wouldn't have to recreate them on the AGOL side.

‎09-05-2025

For what it's worth, I also know organizations that even have mixed-OS deployments where certain Enterprise machines are Linux while others are Windows. Although ESRI won't recommend or explicitly support this (there can be complications if ArcGIS Servers on different OS want to point to the same config file, for example), since the machines communicate over HTTP on the backend it is somewhat OS-agnostic, if that makes sense.

‎09-05-2025

To clarify: are you saying the csv is the true 'source' of all data that you want displayed in your AGOL hosted feature layer? Does the CSV contain all the features you want shown in the feature layer, or does the CSV only contain new records that need to be 'appended' to the feature layer?

‎09-05-2025

When you say shared as a map layer, are you saying you created a map service, feature service, or did you create a hosted feature layer copy on Portal or AGOL? If publishing a map service or feature service from ArcGIS Pro, you could potentially use the Symbology pane > Symbol Layer Drawing tab and set the draw order here, and I believe the map viewer should honor these draw settings. If publishing a feature service, it might warn you that not all advanced symbology options may function, but I think you can just ignore it in this case. Symbol layer drawing also lets you join/merge (or not) the sub-layers within each symbology so things blend together. But you can disable that function by changing Join to No Join. Feature Services sometimes simplify those multi-level symbologies so I think that's what it's warning you about. Anway, by default, I think the ArcGIS* behavior is that draw order is done by ObjectID (newest drawn on top) unless these other strategies for draw order are configured. But I could be mistaken.

Online Status	Offline
Date Last Visited	yesterday

My Ideas

Latest Contributions by CalvinHarmin

Re: Windows PostgreSQL server for Enterprise data: pagefile utilized ~95% persistently, system managed (8gb currently)

Re: Windows PostgreSQL server for Enterprise data: pagefile utilized ~95% persistently, system managed (8gb currently)

Re: Issue with Missing Features on Map in Survey123

Re: Can not zoom in online webmap

Re: Can not zoom in online webmap

Re: Can not zoom in online webmap

Windows PostgreSQL server for Enterprise data: pagefile utilized ~95% persistently, system managed (8gb currently)

Re: Can not zoom in online webmap

Re: Map Viewer Line Label Placement

Re: How to update attributes of features within a newly created polygon?

Re: Field descriptions and value types do not persist over distributed collaboration

Re: Enable option to retain attribute table configurations across distributed collaboration

Re: ArcGIS Enterprise on Different Versions of Windows Server

Re: Sending data from CSV to feature service

Re: Drawing order not maintained in web layer

Re: Make use of free Power Automate connectors?

Re: Analyze PDF Report cuts off questions

Re: Replacing geometry of multiple features

Re: Migrate/Convert ArcGIS Users to SAML

Re: Fastest way to convert date and time data to a...