Latest Contributions by ChelseaRozek

Thanks for sharing your code! Using that originalfeature vs. feature geometry is the only workaround I've found too, but it's unfortunate that the rule still seems to fire all the time. My bulk attribute updates take forever and it's a hassle to wait until after hours, turn off the service, disable all the rules, and then do it... I've put in a ticket with ESRI, I'll post back here if anything productive comes from it. ... View more

Were you able to figure this out? I think I'm having a similar issue. I only have SHAPE as the triggering field, but making an attribute change still triggers it so I can't manually edit an attribute. ... View more

With a multirole locator with parcelname mapped to PIN: yes the intersection zoomed to 1:24.8. So does an address that’s one off from mine (that doesn’t exist), which I hadn’t tried before in my testing. My exact address zoomed fine, but when I recreated the locator without the address points locator as that result seemed to be coming from that locator (so only parcels and road lines left), everything is zooming to 1:24.8. My goal for the parcel locators is to be able to search by the parcel PIN or by the PROP_STREET in the parcel layer in addition to geocoding against the roads. Thanks for the document link. I was under the wrong impression that I would need an address range to map to the house number(s) with the Parcel role. I’ve modified a copy of the parcel polygons and created a locator with a role for Parcels against it (Name mapped to PIN, House Number mapped to STREET_NUM, Street Name to STREETNAME, city, state, zip) + the normal roads role. This locator is zooming me to 1:12.31 which is bad. I then recreated the locator minus the roads (so only the better mapped parcels), zoomed to 1:554 which is a little better. Obviously couldn’t test intersection or “off by one” address since it's only against the parcel polygons. I swapped the test and left only the roads locator in. All 3 test addresses came up at 1:1,231 which is great. Yeah, I’ve played with the Result Order before. I’m still wondering what controls which zoom level a result appears at, especially since these last two tests with only one role showed results at different zoom levels. I would think other users would want to be able to control this too. ... View more

Polygon parcels. Apologies, to be clearer, the Parcel Name maps to PROP_STREET which has 123 Main St. We do not have separate fields for street number and street name. I have a separate locator that matches based on the Parcel PIN. Correct Local Extra High and Global Extra High: same issue  I noticed in these two, when I search for my address, there are 2 results, one at 1:1,276 (decent) and the other at 1:28 (bad). In the original, GLOBAL_HIGH, the two results are both decent at 1:2,834 and 1:1,276. Combining A (Street and Point Address roles) with B (only Parcels) into a composite locator: intersection is fine at 1:1,890, my address is okay at 1:850 I am using ArcGIS Pro 3.5.2 So my workaround for now is to separate the locator for the parcels' street address into its own. I really appreciate your help with troubleshooting this! ... View more

- yes, there is an alternate name table - thanks for the clarification and doc links as I was unsure about the two IDs. we do have duplicate geometry as some address ranges are wildly different on each side of the street and contain odds and evens on the same side. they have the same street name. i'll remove the FEATUREID mapping. - precision = GLOBAL_HIGH - both offsets = 6.371, i don't remember editing this before - yes, I have multiple locators including the multirole one added to a composite locator. using just the multirole one also zooms in very far on intersection results. - zooming works fine on a single StreetAddress role locator. I stepped through removing parts and testing. it appears that the Parcel role is what is causing the issue. I'm not sure how that could be affecting an intersection search query. I've mapped STREET, CITY, STATE, and ZIP from the parcels. - yes, all our data is in 2253 ... View more

Hi @ShanaBritt , thanks for taking a look! I'm using a composite locator I've published to our unfederated server. I get the same result when I add just the one address locator with the road centerlines (from roads in WKID 2253) to my project. It says it is Release 3.5, compatibility release 3.0. Last built earlier this month.     ... View more

@SubaKrishnan They are non-reporting layers on the map for reference and are map server layers not hosted on ArcGIS Online. The app is here. If you zoom in (try bottom right corner), orange hatching and blue drain lines will appear. They should have very simple popups, but unfortunately everything is seen, like OBJECTID. Here's how it looks in the webmap, just 5 attributes with no OBJECTID on the orange hatching:    ... View more

Hi @SubaKrishnan ,  thanks for pointing that out to me, I appreciate it. I tried it out and can see popups now, however they don't adhere to the settings from the webmap. I have popups turned off on a layer, but they still show up in the Reporter app. I have only two fields showing in another layer's popup, but I can see them all in the Reporter app. I tried making a new Reporter app from the same webmap, and I see the same behavior. It's the same layers as before: a map service published to our own ArcGIS server. Let me know if you'd like some screenshots. ... View more

The documentation says "the selection layer is only useful as a temporary working dataset, for example, as an input into a geoprocessing model. It lists the FeatureIDs (FIDs) or ObjectIDs (OIDs) of the selected features. These are invalidated when the original data source is updated or changed." So I think your best bet is to make a more robust definition query or filter that you can use that won't change if the features are reconstructed. You may need to add attributes to your feature class with "regions" or whatever is applicable to your dataset. Then in the webmap you can bring in the layer multiple times and apply different filters to each instance. If you can make the data a hosted feature layer (like you're not trying to publish it from your own ArcGIS Server), you can create views of that hosted feature layer which would do the same thing except the end users can't turn the filters off to potentially edit outside of their region. ... View more

Looks like that bug is fixed, but you still can't sort tables alphabetically. Still hoping for that functionality... ... View more

Same here, I just got an alert that our "AGO Service Account" used up all its credits. I would love to know who used them all! Luckily, I had only allocated it a limited portion, but I would like to reach out to that user to chat about what they're trying to accomplish and what their best options might be. Right now, all I can go off is who signed in today and has the appropriate permission to do this, but it's still multiple people to go through. ... View more

@DougBrowning thank you so much for your comment! I've been combing through the field lengths, default values, and calculations for my huge survey without success. "wrong data type" made me think about the attributes I'm pulling from other layers. While the field lengths were fine, a few intersecting polygons had null values and THAT is what was causing this error in my survey. so happy to finally resolve this! ... View more

@mkaburis Yeah, that's the issue I'm running into. We have different enterprise geodatabases for different departments so they have full control over the layers they're the subject matter experts of. Thanks for confirming that it's not supported.  ... View more

@Jake_S , @ToddW_stl the view workaround would only work for immediate attribute rules traditionally versioned, right? We have branch versioning set up for the full benefit of attribute rules, which seems incompatible with this workaround as the view would need to be included in the published service to be referenced by the rule, which isn't allowed. ... View more