Latest Contributions by Andy_Morgan

I'd gladly take a generic version with all Floats having P: 6, S: 1 (example: 42.5) and all Doubles having the current default of P: 38, S: 8.   But we (organizational level) may be upgrading our version of Pro to something higher over the next 6-12 months as Enterprise gets upgraded and UN comes into the picture. Would it make more sense to target untools for 3.1 for the RC? I imagine our whole organization will be on Pro 3.1 or higher before the end of the year. I may jump ahead from 3.0.3 to 3.1 for UN prep. Thanks. I realized my thinking was a bit narrow in terms of precision/scale for a Float. There is a limit for those values, but not everyone necessarily wants scale of 1 for their Floats. I'm not sure how you'd decide what's best for the average need (a precision of  5 or 6, maybe, with a scale of 1 or 2 at most?). Maybe you're saying you define a universal P/S for those two types. It would definitely be an improvement. I'm trying to represent others out there, too, hopefully.    ... View more

OK, last response. I'll accept this as an answer, but my conclusion is that everyone who builds a Utility Network on SQL Server (and some other DBMS types?) has two options for using Float fields: Accept the fact that your non-integer numeric fields are going to be Double with the default precision/scale (38/8) If you really want Float data type fields and you want all your fields added in a specific order then you must omit them from the AP. After applying the AP, you could run a script to add all your fields with the numeric data types having an exact precision/scale defined during that stage. If, however, you were to export your EGDB UN to an AP to start fresh with an AP having the latest properties, you might not be able to use this AP for pushing updates.     In #2 I assume this situation will cause Apply Asset Package to fail: "Elevation" field data type in Asset Package  "Elevation" field data type in EGDB UN Device FC  Float Double   Who really wants to go with option #2, though. It somewhat defeats the purpose of using an AP to me. ... View more

Same result here with my version of SQL Server:  changes over to Double at the "f_07_01" field (precision > 6). This clearly illustrates what happens in general when manually creating new fields. I was mainly wondering if anyone out there can confirm "Apply Asset Package" still converts from Float to Double in later versions of Pro / UN schema (3.1+). If I need to upgrade one of our test computers and run through the whole process on it then I will, but there must be many users already on 3.1 right now who have tried this. I'm not totally clear if you're implying the answer is yes (3.1 and higher also convert Float to Double). If that's the case, then I'm confused on how Apply Asset Package is not "explicitly upcasting the field" and yet the field is in fact different in the target EGDB.       ... View more

Paul, I really do appreciate the quick responses on this board. I'm using SQL Server: Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64) While this is a development server hosted on a virtual Windows server, the SQL database is nearly identical to our production server where I'll eventually deploy our UN within 6 months. Here's the production server version: Microsoft SQL Server 2019 (RTM-CU19) (KB5023049) I'm trying to think if there is anything else special about what I'm doing. I don't want to waste anyone's time. Let me know if you think of anything else that might be different from the normal scenario. Even though FGDB don't support scale/precision, it still surprised me that it was casted differently for this particular process/tool. I will eventually upgrade Pro to 3.1 and could re-try this process, but I figured others out there with 3.1+ already know if it does or doesn't work. ... View more

First of all thank you so much for summarizing these steps and offering pointers for us newbies. I've been researching this topic and slowly preparing to migrate our water and sewer utilities from Geometric to Utility Network. I have a lot of work ahead over the next 6+ months, but at the moment I'm starting with a (virtual server) development level Enterprise/Portal environment and creating sandbox eGDB's to slowly walk through asset packages and data loading with workbooks. If you don't mind, I have a few questions on what you posted. Maybe a follow-up question or two. These types of "lessons learned" are so valuable. The documentation is vast, ever evolving, and quite confusing at times...not to mention the dreaded feeling of encountering an obscure geoprocessing error that cannot be found anywhere online to offer a solution. I depend on my IT GIS co-workers for applying production schema changes, and it must always be done after hours when services can be stopped, digging into my own personal time. For these and other reasons I'm really concerned that if we don't have it right with the correct sequence for any given workflow it could lead to disastrous, hair pulling, schema change sessions from deployment onward. I'm concerned about how long it may take to perform simple changes, too. With an empty Asset Package (no data) it takes a few minutes to do anything. I cannot imagine how long it might take to execute something significant with the "Load Data" option checked, considering all the data we'd push back and forth during each round of changes. First of all, for context, please describe your GIS environment: ArcGIS Pro version? Enterprise version? Utility Network version?   When you say "a fresh export is best" you're implying every time you want to make any changes to the eGDB it's too dangerous to assume the Apply Asset Package will finish properly. What if I need to edit my own copy and then give to our IT GIS group who stores the latest FGDB copies on their server? Or as a backup in case I mess up? There could be many reasons, but the point is that the renaming of the FGDB is a bad idea or is any copy of the original export (i.e. same file name but different folder) possibly going to get corrupted?   Stage Utility Network vs Create Utility Network: I found with Pro 2.9 and v5 UN that it seems to work fine to use Create Utility Network tool, then apply the package to create the initial domain network objects.   The D_Configuration table is starting to make a little more sense so far. As for the Configuration category domain values, you mention the "4: Always remove when applied" option. I'm held back to an older version of Pro and therefore untools package, so I don't have those new Configuration domain values. Not sure how this impacts all your steps.   Generally speaking, will your recommended workflow cover any "normal" schema changes such as adding, removing, renaming, or changing the data type of feature class fields; removing or updating a subtype; and adding/updating/removing an asset type in the domain? When, if ever, must we go to these great lengths in the link below to completely delete the entire eGDB and re-create (with the help of DBAs)? This is absolutely terrible if such steps are truly needed from time to time.  How to apply revised asset package to the same utility network I don't know who has it right between everything I'm reading. So many scenarios and opinions. Surely many other people feel equally concerned about understanding the sequence of steps and getting off on the right foot from day 1 of production deployment.  Thanks again. ... View more

Hi Jack, What about developers who have nightly automated processes like Python scripts and/or .NET console apps that update attributes or other data in UN feature classes? Will ESRI allow us to purchase an extra UN user type extension for a "headless (service) account"? It would not be used anywhere other than for a few scripts that run once a day. I understand headless accounts are prohibited in terms of sharing a license to multiple individuals, but if we need to have a separate account other than our own, with a password exposed in a script, that would mean the need for a service account, per se.    ... View more

Apologies for borrowing this thread, but this question seems relevant: I cannot find any definitive answer or documentation when it comes to relying on DojoConfig for package loading. I'm in the middle of migrating a large ASP.NET / ArcGIS Javascript application from 4.21 to 4.27. I'm really hoping DojoConfig will be supported throughout the remainder of the 4.x lifecycle to buy me a few years of doing the following. It's mainly for my own folders.   let locationPath = location.pathname.replace(/\/[^/]+$/, ''); window.dojoConfig = { async: true, parseOnLoad: false, packages: [ { name: "appJavascript", location: locationPath + "/js" }, { name: "appJavascriptClasses", location: locationPath + "/js/classes" }, { name: "appHtml", location: locationPath + "/html" }, { name: "dojo", location: "../../4.21/dojo" }, { name: "dijit", location: "../../4.21/dijit" } ], has: { "esri-native-promise": true } }   The last two lines for /dojo and /dijit are really just examples of possibilities. I'm actually trying to cleanse my code of any Dojo references and only use plain vanilla Javascript. This must remain in AMD design, not ES modules. If I'm able to rid the code of all Dojo classes, I'd still need to make use of DojoConfig which appears to be necessary for the Require.js part of the SDK. Unless someone knows how to replace DojoConfig with vanilla Javascript...? I could not piece together a solution without loading require.js and using the "data-main" attribute, which I'd rather avoid.    ... View more

Same problem with me. I'm using Portal (Enterprise 10.9.1), not AGO, and query results selection doesn't flash. It only Zooms. I've tried adding many back-to-back Flash actions. It never flashes the point. Frustrating. I just need to show the users the selected feature somehow. Does this work for anyone? ... View more

Thanks @DougBrowning for staying with me and offering more explanation and links. After some experimenting I see it's possible to get attributes transferred over. I never would have thought you can do a loop within Field Maps to call it with a URL from the popup. I don't like how you have to click the target GPS layer again when it reloads, but I saw in a separate thread ESRI did it by design for layer templates. I suppose this type of solution is better for what I need and more customizable all around. Certainly not an obvious workaround, and unfortunately a lot of effort that could have been avoided if attributes could simply be copied across various geometry types.   ... View more

I really do want to follow you, but again I'm not clear. It's not that I don't understand how to write code, it's that I don't understand how to implement what I think you're suggesting: to generate a custom URL in a field value that'll display within the polygon popup...and the click event for this URL will somehow trigger a function to send all the selected polygon attribute values to the new GPS feature ($feature) through Arcade. That's a giant stretch from what I thought was even possible in an AGO web map + Arcade. Is this something people are already doing with examples, or something you suspect is possible but haven't actually done yourself? Just wanted to be clear. It may seem quick and easy , but that's because you already know how to do it. There are at least two steps in this workflow for which I'm not able to find ESRI documentation, so it's not obvious to me yet. ... View more

Absolutely no pressure to keep going with this conversation, but just to clarify the desired starting point for copying attributes is the user clicks on a parcel boundary (polygon) to indicate which feature they want to use for transferring the many field values we need in the new GPS point. Polygon attributes -> GPS point using "Copy attributes" isn't possible out of the box in Field Maps. I'm not following when you say "you'd have the popup of the point...". The goal is to not be clicking on a parcel centroid point like I have it now. I'd like them to click on parcel boundary polygons and exclude the centroid points layer entirely. They will clutter the map, since I have a separate meter point layer that will be used as well. Our field staff likely prefers to click on polygons instead of finding the appropriate point in the center. The problem is that the point to be collected by GPS isn't always inside the polygon. Regardless of whether there is anything else to add, any input is much appreciated!  ... View more