POST
|
The Esri Linear Referencing REST API samples, depicting tasks such as MeasureToGeometry and GeometryToMeasure are super powerful. The samples use an older version of the ArcGIS API for JavaScript, v2.7; however, exchanging the script tags for v.3.41 is painless and the examples still work. Although ArcGIS API for JavaScript underwent a major overhaul from v3 -> v4, such that the examples would need to be updated to become v4 compliant, would the Linear Referencing REST API still work if the Linear Referencing web service was published from ArcMap? Does the Linear Referencing REST API only work with v4 of the JavaScript API if the web service is published from ArcGIS Pro? Thank you! // ArcGIS API for JavaScript v2 (samples use this one) <link rel="stylesheet" type="text/css" href="https://serverapi.arcgisonline.com/jsapi/arcgis/2.7/js/dojo/dijit/themes/claro/claro.css"/> <script type="text/javascript" src="https://serverapi.arcgisonline.com/jsapi/arcgis/?v=2.7"></script> // ArcGIS API for JavaScript v3 (samples still work with this) <link rel="stylesheet" href="https://js.arcgis.com/3.41/esri/css/esri.css"> <script src="https://js.arcgis.com/3.41/"></script> // ArcGIS API for JavaScript v4 (would samples still work if code was v4 compliant?) <link rel="stylesheet" href="https://js.arcgis.com/4.24/esri/themes/dark/main.css"> <script src="https://js.arcgis.com/4.24/"></script> // Can these work in an JavaScript API 4 world? var soeURL = "https://[server] /rest/services/[folder]/[service name]/MapServer/exts/LRSServer/networkLayers/0/geometryToMeasure"; var soeURL = "https://[server] /rest/services/[folder]/[service name]/MapServer/exts/LRSServer/networkLayers/0/measureToGeometry";
... View more
07-06-2022
09:37 AM
|
0
|
0
|
442
|
POST
|
Although this doesn't have to due with Roads and Highways directly, this topic involves m-enabled datasets and I'm hoping someone here can provide an explanation or highlight whether the behavior described below identifies a bug in ArcGIS Pro since the RHUG community is well-versed in m-enabled datasets. When clicking an m-enabled point geometry feature class in ArcGIS Pro, the pop-up doesn't display the measure value. Instead, the measure value is left blank but it adds six m-related fields at the bottom of the popup. In a past version of ArcGIS Pro, it did display the measure value for the measure field (in addition to those six extra fields). Interestingly, it does display the measure value when you publish such a dataset as either a hosted feature service to ArcGIS Online or a LRS-enabled feature service to Portal for ArcGIS. However, as soon as you add either type of web service to ArcGIS Pro, it once again won't display the measure. In summary, this behavior is unexpected and differs from earlier versions of ArcGIS Pro, ArcMap and ArcGIS Online and Portal for ArcGIS which all correctly displayed the measure value. Is this a bug in ArcGIS Pro? Does anyone know what's going on? Test: Here's a publicly published feature service in ArcGIS Online (AGO) that works perfectly online, but when added to ArcGIS Pro, does not (use "milepost NMDOT" as search AGO parameters from the Catalog Portal tab inside Pro). https://nmdot.maps.arcgis.com/home/webmap/viewer.html?layers=ab88715f40614f7b868302ba837cd089 Thank you! Ed
... View more
05-16-2022
03:41 PM
|
1
|
0
|
751
|
POST
|
Hi Nathan, Noted and thank you for your response! Ed
... View more
02-24-2022
11:19 AM
|
0
|
0
|
1402
|
POST
|
Hi @NathanEasley Very late to this thread, but found it very helpful for demystifying what the activity codes meant. I understood you on your point that the Edit_log_table should never be edited manually. However, is it okay to create a coded-value domain and apply it to the ActivityType column documenting the 13 Activity Codes as shown by @RyanKoschatzky? Is there any risk to doing so? (e.g., possibility of future activity type codes in the future?). Thank you! Ed
... View more
02-24-2022
10:06 AM
|
0
|
2
|
1409
|
POST
|
We've installed ArcMap v10.8.2 along with the patched extensions at the same version: Roads and Highways, Data Reviewer and Workflow Manager (all had v10.8.2 patches). However, the other desktop extensions within the exact same ArcMap environment say that they are at v10.9.1 and when you inquire about the version using arcpy, it says v10.9.1 despite the GUI clearly saying v10.8.2 (Menu -> Help -> About ArcMap). Furthermore, a fresh install of ArcMap v10.8.2 is unable to occur on a machine with ArcGIS Server v10.8.1, yet an in-place upgrade of ArcMap v10.8.1 -> ArcMap v10.8.2 will proceed fine. Are these software bugs? Is Roads and Highways v10.8.2 compatible with Enterprise 10.9.1? If not, why does an error occur with ArcMap v10.8.2 and ArcGIS Server v10.8.1 when doing a fresh install? If not, why does the ArcMap environment give conflicting version information? Thank you!
... View more
02-17-2022
07:57 AM
|
0
|
2
|
1146
|
POST
|
Here's another addition to the thread in case it's helpful to others since this took me awhile to sort out scheduled tasks using ArcGIS Pro's Python 3 environment. Setup: Windows Server 2016 Datacenter ArcGIS Pro 2.5.1 Concurrent-use licensing "Authorize ArcGIS Pro to Work Offline" is not checked. Not signed into either AGOL or Portal (for sake of testing) Python version 3.6.9 ArcMap 10.7.1 Concurrent-use licensing Python version 2.7.16 *Yes, this particular server has both Pro and ArcMap and therefore Python3 and Python2, but only Python3 was set into system's path variable. Issue: Our Python 3 scripts worked correctly from both the command prompt or running them directly from an IDE, yet Windows task scheduler kept reporting an error was returned in the last run result: (0x1). Reason for Error: Windows task scheduler defaulted to running Python 2, causing scripts using Python 3 to fail. It took me awhile to catch this since only Python3 has been set inside the Environment's path variable, so I assumed that Windows Task scheduler would be running Python3 --- not Python2. (*** not sure about the message about the environment not being activated. ***) Helper diagnosing script: I created a dummy script using only Python 2 and used the sys module to report which version of Python was being called when the script was run through Task scheduler. The script revealed it was Python2, cementing that I needed to explicitly point to Python 3 installation. import os import sys from datetime import datetime def main(): try: basepath = os.path.dirname(__file__) os.chdir(os.path.join(basepath, 'Test_script')) with open("log.txt", "a") as f: f.write('hello world! @ {}\n'.format(datetime.now())) f.write('Python installation info:\n') f.write('major: {} minor: {} micro: {}\n'.format(sys.version_info[0], sys.version_info[1], sys.version_info[2])) except Exception as exc: f.write(exc) if __name__ == '__main__': main() Solution: I had to specify the path to Python3 for program/script and the fullpath to the script as an argument. Again, since my Python2 scripts just worked when I specified the path to the script (done on a different server with Python2 installation set in path), I thought it would work be the same for Python3. Python 3 Script (Server with python3 in path and without python2 in path) vs. Python 2 Script (DIFFERENT Server with python2 in path and without python3 in path)
... View more
05-15-2020
02:22 PM
|
2
|
0
|
1081
|
IDEA
|
The solution below does not perfectly address resizing a legend and have it scale proportionately while maintaining aspect ratio, but it allowed me to resize my legend and keep it dynamic rather than convert it to graphics. Resizing this approach does proportionately change the font sizes for the various legend items (e.g. Layer Names, Heading, Labels, Description), but it does not keep the aspect ratio the same. Change Fitting strategy to "Adjust font size". When I was initially trying to resize the legend, it was set to "Adjust Frame" and I couldn't resize the legend. #arcpro 2.5
... View more
05-14-2020
10:51 AM
|
0
|
0
|
2045
|
POST
|
I interrupted my script while it was compressing the GDB during some testing. Subsequently, I received ERROR 000837 when I reran it. After running the arcpy.ClearWorkspaceCache_management() function, everything worked fine again.
... View more
12-27-2019
02:55 PM
|
0
|
0
|
4602
|
IDEA
|
Yes similar, but with the addition of formatting date fields too, since they're treated differently from numeric fields.
... View more
12-16-2019
12:41 PM
|
0
|
0
|
948
|
IDEA
|
Yes similar, but with the addition of formatting date fields too, since they're treated differently from numeric fields.
... View more
12-16-2019
12:41 PM
|
0
|
0
|
530
|
IDEA
|
The following pop-up functionality of modifying attributes is already available in AGOL/Portal, but it would be helpful if these items were available when you publish web services from ArcGIS Pro: - number formatting - date formatting - change attribute order Example 1: Imagine you publish a map service that gets consumed from 10 different web maps. By default, AGOL/Portal formats numeric fields with 2 decimal places and uses commas to separate every three numbers (e.g. 108.56 or 12,345,678.90). If this is undesired (for us, it usually is!), you have to make a fix 10x, which is tedious and error-prone. This always needs adjustment for latitude/longitude values in decimal degrees, which are present in most of our point features. Example 2: You have a date field, say "Last Updated". By default, AGOL/Portal displays date fields with a time. For our purposes, time of update isn't necessary, but you have to modify this in each web map to turn off the time part. A work around I don't want to carry out is to do a conversion of just my date field to a new/separate text field with just the date that's used only for web map purposes. Note: It's possible to change attribute order via different approaches; however, to match AGOL/Portal, it would be nice to have the functionality of moving attributes up/down in the popup configuration window.
... View more
12-12-2019
08:35 AM
|
24
|
3
|
1244
|
IDEA
|
The following pop-up functionality of modifying attributes is already available in AGOL/Portal, but it would be helpful if these items were available when you publish web services from ArcGIS Pro: - number formatting - date formatting - change attribute order Example 1: Imagine you publish a map service that gets consumed from 10 different web maps. By default, AGOL/Portal formats numeric fields with 2 decimal places and uses commas to separate every three numbers (e.g. 108.56 or 12,345,678.90). If this is undesired (for us, it usually is!), you have to make a fix 10x, which is tedious and error-prone. This always needs adjustment for latitude/longitude values in decimal degrees, which are present in most of our point features. Example 2: You have a date field, say "Last Updated". By default, AGOL/Portal displays date fields with a time. For our purposes, time of update isn't necessary, but you have to modify this in each web map to turn off the time part. A work around I don't want to carry out is to do a conversion of just my date field to a new/separate text field with just the date that's used only for web map purposes. Note: It's possible to change attribute order via different approaches; however, to match AGOL/Portal, it would be nice to have the functionality of moving attributes up/down in the popup configuration window.
... View more
12-12-2019
08:35 AM
|
20
|
3
|
826
|
Title | Kudos | Posted |
---|---|---|
1 | 05-16-2022 03:41 PM | |
2 | 05-15-2020 02:22 PM | |
20 | 12-12-2019 08:35 AM | |
24 | 12-12-2019 08:35 AM |
Online Status |
Offline
|
Date Last Visited |
09-07-2022
06:07 PM
|