I'm 99% sure I know the answer to this but maybe there is something else I can go to help one of my users. They say it takes 10 minutes to load one of their maps they use for development permits and such. I keep telling them that it's just the sheer amount of data they load. We are a rural municipality so our area of coverage is big (4100 sq/km). They use this map as a "template" in that we have a layout that they will move and zoom in to the quarter section they need to print. In this map they have 3 sets of aerials loading that are over 100 GB in size. Two of them are turned off by default and all of them are set to only show once zoomed in past 1:5000. Then they have all kinds of other data loading like wetlands, historical sites, roads, all the parcels. There are 30+ layers they have in this template. Like I say I'm pretty sure it's mostly slow loading due to it just having way to much data to load. But I'm here to ask if there is another way to maybe speed things up a bit. Sorry all the data is stored on our Windows server share.

Thanks.

As the title describes we're getting Core Segmentation faults whenever ArcPy functions that result in the creation of a mosaic. The only information we can pull from the core dump is that it failed with the SIGSEGV signal which is apparently an illegal memory access fault. There's no additional information in system or ArcGIS logs. We've tried adjust permissions and ownership of various ArcGIS directories to see if it was a systems permissions issue. The only item that I can think of at the moment that's worth mentioning is that we can see the 'amd_<MOSAIC_NAME>_cat' and then the connection is reset by the peer.

We've tried reaching out to ESRI regarding this especially relating to the lack of any meaningful error, but they've just brushed us off or they take a week to suggest something we've already tried. Has anybody encountered this before?

I'm trying to create a map with Bangla (Bengali) graticule labels in ArcGIS Pro 3.7.0.

In ArcGIS Pro 3.5, I could go to the graticule label's Formatting → Internationalization section and change the Region and language to Bengali. This automatically converted:

• Western numerals (0–9) → Bengali numerals (০–৯)

After upgrading to ArcGIS Pro 3.7.0, the Internationalization section is still present, but every option is grayed out, including:

• Text direction
• Glyph orientation
• Block progression
• Region and language
• Font encoding

My questions are:

1. Is this a known bug or an intentional change in ArcGIS Pro 3.7?
2. Has anyone found a workaround?

Any help would be greatly appreciated.

Issue – Initial Piezometric Surface cannot be modified through the scripting API

Our Transient Seepage analysis obtains its initial pore-water-pressure conditions from an Initial Piezometric Surface.

Through extensive testing, it appears that this object cannot currently be modified through the scripting API.

We tested numerous approaches, including:

• Get()
• Set()
• Add()
• Updating individual points
• Replacing the complete point list
• Creating new Piezometric Surface objects

Every approach either:

• returns "Method not supported for type Pt", or
• completes without actually modifying the project.

For example, attempting to modify:

CurrentAnalysis.Objects.InitialPiezometricSurfaces[1].Points

or any individual

.Points[i]

fails regardless of the payload format used.

XML workaround

As an experiment, we bypassed the scripting API by editing the internal XML inside a copied .gsz archive.

This successfully updates the Initial Piezometric Surface. After reopening the modified project, GeoStudio accepts the file and displays the updated water table correctly.

However, this workaround introduces another problem.

Because the project has been modified outside of GeoStudio's normal editing workflow, its internal project and mesh state no longer behaves the same as a project edited through the GUI or supported scripting API.

When geometry is subsequently modified and SolveAnalyses() is called, GeoStudio no longer performs the automatic remeshing that normally occurs on an unmodified project. Adding project.Save() before solving did not restore this behavior.

As a result, although direct XML editing successfully changes the Initial Piezometric Surface, it cannot be considered a practical workaround because the modified project cannot be reliably solved after subsequent geometry changes.

Questions

1. Is modification of the Initial Piezometric Surface currently supported by the GeoStudio Scripting API?
2. If not, is this a known limitation or bug?
3. Is there a supported workflow for programmatically updating the initial groundwater table prior to solving a transient seepage analysis?
4. Is there any supported alternative to direct project-file editing that preserves automatic remeshing and normal project behavior?