|
IDEA
|
I realize the following will not get much attention within Esri Community because most Esri Community members are not on the IT service delivery side of GIS, but change has to start somewhere.... Still in 2025 with ArcGIS Enterprise 11.5, installing ArcGIS Server requires the 'Desktop Experience option' on Windows Servers. From ArcGIS Server 11.5 system requirements - ArcGIS Enterprise | Documentation for ArcGIS Enterprise: Note: The Desktop Experience option is required on all versions of Windows Server. Why oh why is Desktop Experience still required with Windows Server installations after 17 years since Microsoft introduced Server Core with Windows Server 2008? Infrastructure as code (IaC) is far from a new idea, and Esri already supports several automated on-premises deployment patterns (script-based silent installation, Chef cookbooks, PowerShell DSC), so it is time for Esri to remove a Desktop Experience requirement for a product that does not require a GUI to deploy, configure, and manage.
... View more
06-08-2025
03:44 PM
|
3
|
2
|
1211
|
|
POST
|
Very much undocumented from the Esri side; however, a couple Esri staff did chime in on comments from a non-Esri blog post over a decade ago: From Exploring ArcGIS Server 10.1 Logs (Part 2) | Geodatabase Geek: Trevor H on 04/06/2013 at 09:08 said: Looks like the setting (in 10.2 at least) adds some additional usage monitoring. It adds INFO level entries such as the following; outBytes=9928; numObjects=1; costUnits=1.000000; taskName=export So I assume they are AGOL related. The outBytes could be useful for capacity planning. Also still no mention of this option in the help at 10.2. Vivek Gupta on 16/07/2013 at 06:38 said: The usage metering enables the user to log information about usage for billing purposes. When you enable this option ArcGIS Server logs information at the INFO level about the usage parameters which includes cpu, bandwidth, number of features/request etc… This information then is reported to the owning portal. Portal administrators can then use this information to bill the consuming users and users can view their usage.
... View more
06-08-2025
11:24 AM
|
2
|
0
|
928
|
|
POST
|
It is better to state what issue you are running into specifically than ask how to turn a functionality on or off. The handling of relative paths in ArcGIS Pro is more complex than in ArcMap, and there is no single check box to enable/disable. If you share what you are trying to do and what isn't working than community members can offer suggestions on workflow changes as well as software configuration. And I assume you have already read Re: How can I "store relative pathnames" in ArcGIS Pro? Although you are interested in not using relative paths, that discussion dives into the general topic of relative paths in ArcGIS Pro.
... View more
06-07-2025
07:53 AM
|
0
|
0
|
819
|
|
POST
|
I think leaving it here makes the most sense since the issue wasn't with Arcade code itself but how a published service was behaving with Arcade.
... View more
06-05-2025
03:38 PM
|
1
|
0
|
1891
|
|
POST
|
Is the data versioned? If so, the query that ran for 53 seconds is not comparable to the query from ArcGIS software because ArcGIS software will be using the versioned data and not base tables. If the data is versioned, what does the state tree look like?
... View more
06-02-2025
09:36 AM
|
0
|
1
|
1729
|
|
POST
|
The results indicate the issue isn't with using arcpy.env.extent with a polygon. The fact a polygon filter took twenty minutes while a simple "REGION='REGION1'" query took two or more hours tells me: 1) the dataset is quite large (which you already indicated), and 2) the REGION field probably isn't indexed or indexed correctly if the operation is taking that long. At this point I would run the same attribute test outside of ArcGIS. If you see comparable relative differences when connecting to the database from a client outside of ArcGIS, it points to more a data structure and database performance issue than an ArcGIS software issue.
... View more
06-02-2025
07:04 AM
|
0
|
0
|
1764
|
|
POST
|
Calling Get Count on an entire dataset is fast because it is basically a metadata lookup and not actually counting records. Twenty minutes does seem a bit long for Get Count, even on 5 million records, but enterprise geodatabase connections are very sensitive to latency as well as the usual factors that impact database performance. How long does a Select Layer By Attribute take when you run a query like "WHERE region = 'name'" ?
... View more
05-31-2025
08:31 AM
|
0
|
2
|
1838
|
|
POST
|
You have $feature.SignSymbols wrapped in quotes, which makes it a string and not a reference to the feature.
... View more
05-30-2025
09:57 AM
|
1
|
1
|
1250
|
|
POST
|
You don't even need a code block for this, a Python 6.13. Conditional expressions in the expression block will do the trick: "Ramp type is blank" if !ramp_type! is None else !ramp_type!
... View more
05-29-2025
11:04 AM
|
1
|
0
|
1341
|
|
POST
|
Great question, my organization is very interested in this issue as well.
... View more
05-27-2025
06:27 AM
|
2
|
0
|
986
|
|
POST
|
To be fair , adding SQL support in Calculate Field to file and mobile geodatabases is new in Pro 3.5. There is a big difference between an issue with new functionality versus functionality that is mature and been around for a while. I don't agree with how Esri is handling the update service issue, especially if it is only because of this issue.
... View more
05-26-2025
06:36 AM
|
0
|
0
|
2294
|
|
POST
|
Stripping the test down to the most basic steps and removing IPython, I see equality checking costing quite a bit more than identity checking. C:\>python -m timeit -n 1000000 -v "value = None; value != None"
raw times: 34.2 msec, 34.1 msec, 33.6 msec, 33.7 msec, 33.4 msec
1000000 loops, best of 5: 33.4 nsec per loop
C:\>python -m timeit -n 1000000 -v "value = None; value is not None"
raw times: 21.9 msec, 21.9 msec, 21.9 msec, 21.9 msec, 22.3 msec
1000000 loops, best of 5: 21.9 nsec per loop Granted, both equality checks and identity checks are extremely fast for Python built-in constants, so on a practical level the choice would not make a difference in the overall performance of a Python function or code block. I only mentioned performance to point out there is no performance benefit to go against best practice. I agree that PEP008 should not be followed dogmatically, but I cannot imagine a Python core developer advocating for an equality check over an identity check when it comes to a singleton. This might just be an-agree-to-disagree situation, but the discussion is good to have regardless.
... View more
05-25-2025
09:59 AM
|
2
|
1
|
9951
|
|
POST
|
Although SQL NULL gets mapped to Python None, they are not logically identical because Python by default does not implement three-value logic. Whereas SQL logical operators in most systems support TRUE/FALSE/NULL, Python logical operators only support True/False. From 6. Expressions - Python 3.y.z documentation: In the context of Boolean operations, and also when expressions are used by control flow statements, the following values are interpreted as false: False, None, numeric zero of all types, and empty strings and containers (including strings, tuples, lists, dictionaries, sets and frozensets). The issue isn't that your logic is incorrect, or that the code is incorrect (although it may be), it is that you are trying to interpret results for Python logical expressions as if they were SQL logical expressions.
... View more
05-24-2025
09:46 AM
|
0
|
0
|
10027
|
|
POST
|
From both a practice ( https://peps.python.org/pep-0008/ ) and performance perspective, checking for None should be done using "is" or "is not".
... View more
05-24-2025
09:23 AM
|
1
|
3
|
10034
|
|
POST
|
For someone who has designed, configured, and managed many ArcGIS Enterprise deployments supporting upwards of tens of thousands of GIS services, using multiprocessing in a geoprocessing service comes with enormous risks to the stability of the service and the application as a whole. Depending on how the multiprocessing jobs are setup, and how the GP service is configured, it would be very easy for a single GP service to overwhelm all of the resources on an ArcGIS Enterprise deployment. Maybe this has already been thought through and discussed with the OS admins, but I mention it here as a general warning to others who might come across this thread.
... View more
05-22-2025
07:38 AM
|
1
|
0
|
1266
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 3 weeks ago | |
| 2 | 07-06-2026 12:29 PM | |
| 1 | 07-06-2026 12:00 PM | |
| 2 | 06-05-2026 10:30 AM | |
| 1 | 05-29-2026 08:22 AM |
| Online Status |
Online
|
| Date Last Visited |
8 hours ago
|