Latest Contributions by ChristopherBowering

Hi @Jianxia, Thank you for the helpful EB roadmap and for taking time to answer so many of these posts. The basic viewability (not editing) of related records is the single most paramount function my organization relies upon within our current Enterprise Portal WAB apps. I'm quite discouraged to see that this function won't even be making it to AGOL EB until Q4 this year, meaning it will be even longer until it is in Enterprise EB (I'm guessing not until at least 11.4 at this rate). I can't in good faith move our users to EB - which ESRI is strongly encouraging - when this ability doesn't exist. The fact that WAB is moving closer to retirement and there is no related table viewing function on the horizon for Enterprise is jarring. I feel as though users in my position are being painted into a corner, so to speak. It is difficult to keep up with ESRI's recommendations when such vital functions are often lagging behind. I thought it was important to make this known. Thanks for all of your efforts!

Thank you for your thoughts @Justin_Greco . I rarely use ArcGIS Online so I didn't realize this function just came out last month. The key word is 'eventually'! I've seen quite the lag time in the past with seemingly basic functionalities making their way from Online to Portal. I'll add this to my list of hopefuls for 11.3 and beyond. Thanks!

It would be helpful if a sketch layer and its corresponding features could be included in the legend within the Portal (new) map viewer.

In ArcGIS Online, you are able to duplicate selected sketch layer features. You are also able to create a new sketch layer from selected features. Neither of these functions are available in the Portal version of the (new) map viewer. The sketch layer documentation for 11.2 indicates as much. These would be very helpful functions to bring over to the Portal (new) map viewer. Without them, you are stuck recreating and reconfiguring identical features if you need more than 1 of a kind. This is quite inefficient.

‎03-19-2024

I 100% agree with @cbp-geus, this really should be a mandatory function. It's difficult to convince my users to use a Dashboard when they can't even sort the data.

‎03-19-2024

I completely agree that allowing table sortability would be very impactful. If basic attribute tables in Pro allow field sorting, it should be a no brainer to include that function within the Dashboard table element. When trying to get users to work with a Dashboard - particularly the table element - it doesn't help my case when they get better function out of a simple spreadsheet due to the ability to sort columns.

‎11-13-2023

@Jianxia I understand that you are "the messenger" and I'm sure we all appreciate the responses you have been providing. On that front, thank you! I continue to be very disappointed, in general, with ESRI's handling of related tables across its apps. Despite their usefulness and how users rely on them, related tables are often one of the last components to be addressed. It is frustrating how highly touted EB and Instant Apps are despite lacking such crucial functionality, often with no known timeframes for inclusion. Almost all of our heavily used datasets involve related tables where the data needs to be displayed. Therefore, EB and Instant Apps, in Enterprise, are essentially non-starters for us. There are even basic related table issues in WAB that I am still dealing with. I also find it interesting that related table editing in EB will be available before simple viewing and configuration is available. This seems quite backwards in my opinion. Please feel free to add these additional comments to the backlog issue you mentioned. Thanks!

‎11-07-2023

@Jianxia I'm coming from a 10.9.1 Enterprise environment so I'm a little behind. Within 10.9.1, related table functionality as a whole within Experience Builder - and Instant Apps for the most - barely exists. I saw your comment about related table editing coming in 11.3; is basic related table usage such as viewing/configuration available in 11.2 for EB/IA? Or, is everything related table-wise being incorporated at once in 11.3. Thanks!

‎05-26-2023

I am glad that this idea already exists. I also believe it would be quite beneficial to be able to separately track data/attribute edits from geometry edits. I am constantly QC'ing data recorded or edited by other users and knowing what component of a dataset was edited would make it much more efficient for me to know what to look for during my review.

‎02-06-2023

Are your 50 points either along the exact flow accumulation path and/or is your snap tolerance when using snap pour point tool set to a non-zero value? I often have to "fudge" my points to fall within a raster cell along the flow accumulation path or set a larger snap tolerance value when using tool or else my output raster will be empty. Rarely does my desired delineation point precisely match up to where the flow path is...just the margin of error when using rasters.

‎10-27-2022

I am testing within SDE. There are no other attribute rules in play and both fields are identical in properties (text, length 10). I'm assuming the intended attribute rule is 'Immediate Calculation'. As I mentioned, the code is doing what it's supposed to if the table record has a matching GUID value. Even if I create a new record and manually paste in a corresponding GUID the Field_B will populate. Can you confirm that it works for you upon adding a new related table record (when there isn't already a related record present for the corresponding feature)? It's almost like it's trying to run the attribute rule prior to the record being generated instead of the other way around. var asset = FeatureSetByName($datastore, 'OCGIS.OCGIS.DPW_TESTING'); var globalid = $feature.Related_Asset var filterStatement = 'GlobalID = @globalid' var related_data = Filter(asset, filterStatement) var cnt = Count(related_data); var results = ""; if (cnt > 0) { for (var row in related_data) { var line = row.Field_A; results +=line; } } else { results = "No related record"; } return results;

‎10-26-2022

I apologize for the couple weeks' delay in responding. I have been playing around with this today. It is partially working. I am able to get text to carry over when there is already a record in the related table which has a GUID value matching a GLOBALID value from the feature class. However, when I attempt to 'add new to relationship' (new related record), I receive an error. I have all 3 triggers set in the attribute rule. Similarly, I get the same error when I attempt to remove a record from the relationship (although 'delete' oddly works fine). When I use the script as a pop-up expression, it also works without issue; so, the problem lies when editing and trying to add a new record. Thoughts about this? Update: I closed out of Pro and went back in to try again. Now I am no longer receiving the message above, rather I am receiving this message below. "Field_B" is equivalent to the "Site_WH" from your example. It's odd because the field that this error pertains to is the one that should be populated by the attribute rule...so it shouldn't even be able to be 'invalid'...

‎10-13-2022

Thanks for the further explanation! I didn't realize you had used an alias for the GUID field - I thought 'Related_Asset' was a placeholder for a value/name from my own data. I'm still having a bit of trouble 'dumbing down' your example since I don't need the 'else/if' statements in there (I'm also very new at this in general!). If I just want to simply bring a value over from the feature class field to the table field, what would that look like? I'm not sure how much of your code is needed for something that basic. Thank you!

‎10-03-2022

Thanks for sharing that! In your example, it looks like the "globalID" field in both the feature class and related table is used as the relationship key. In the majority of my relationship classes, I use "globalID" from the feature class and a "GUID" field from the related table. This seems to be the most efficient way to handle one-to-many relationships without having the manual update attributes to make sure the key fields are the same. Is it possible to use your scripting if the key fields are not the same? I'm working with a very 'dumb' testing point feature class and table so I can get it right before applying to my real work. If my parameters are simply: Feature Class has Field_A Table has Field_B Relationship Class 'Origin Primary Key' (Feature Class) is GlobalID; 'Origin Foreign Key' (Table) is GUID All I want is for the attribute in Field_A to populate Field_B in the related table. How would this look in your example code?

‎09-26-2022

Currently, there is a known limitation where pop-up field (re)ordering done in Map Viewer (Beta) does not translate to the pop-up when viewing in Field Maps. ESRI's 'solution' is to make pop-up field order changes in Map Viewer Classic. However, saving any changes in Map Viewer Classic will wipe out custom forms created thru the Field Maps WebApp. Therefore, the 'solution' essentially erases your Field Maps forms if you've gone on to configure those after creating the WebMap. I was told - via BUG-000139509 - that this will not be addressed (!). If you attempt to make other pop-up changes in Map Viewer (Beta) - such as date/time format, alias names, field inclusion/exclusion, etc - these changes do translate to Field Maps when viewing the pop-up but this also will wipe out your custom Field Maps forms. This functionality paradox has significant workflow ramifications and destroys any flexibility once you've set your original pop-up configuration (and have spent time configuring Field Maps forms thru the Field Maps WebApp). If you wish to add a new field to your dataset (andWebMap), change the alias name of a field, reorder your fields, etc - basically any adjustment to pop-ups - your options are to go ahead with the changes, knowing you'll have to recreate all of your custom Field Maps forms or just do not make any changes. I do not think these are acceptable options. I have run into this paradox numerous times; it would be great to only have to configure a WebMap once but that expectation is not realistic. I have intentionally limited myself with Field Maps because I can't afford to be continuously recreating custom forms whenever my organization inevitably requests changes. I am hoping ESRI will take this significant flexibility/efficiency limitation seriously at some point.

Online Status	Online
Date Last Visited	2 hours ago

My Ideas

Latest Contributions by ChristopherBowering

Re: ArcGIS Experience Builder 2024 Roadmap

Re: Portal (New) Map Viewer Should Allow Sketch Layer Features to be Copied/Duplicated

Portal (New) Map Viewer Sketch Layer Show in Legend

Portal (New) Map Viewer Should Allow Sketch Layer Features to be Copied/Duplicated

Re: ArcGIS Dashboard - Table Widget - Sort Columns

Re: Sort Capabilities for ArcGIS Dashboard Tables

Re: What's Coming in ArcGIS Enterprise 11.2

Re: What's Coming in ArcGIS Enterprise 11.2

Re: Tracking Data Edits Independent from Geometry Edits

Re: Snap to pour point

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Re: Attribute rule to actively transfer data from a related table to it’s parent feature class and vice versa

Map Viewer Classic and Map Viewer (Beta) Pop-Up Configuration Paradox in Relation to Field Maps (WebApp)

Re: ArcGIS Experience Builder 2024 Roadmap

Portal (New) Map Viewer Sketch Layer Show in Legen...

Portal (New) Map Viewer Should Allow Sketch Layer ...

Re: What's Coming in ArcGIS Enterprise 11.2

Re: What's Coming in ArcGIS Enterprise 11.2