Latest Contributions by RobertKrisher

See @NicoleJohnson 's response. ... View more

I'm not sure if deleting unnecessary attribute rules for view only data is going to provide any benefit, unless those rules reference objects that aren't in your read-only instance. It`s not a bad idea to apply different levels of post-processing after creating our read-only instance, but just make sure they're providing good value. ... View more

From my previous response: "The feature service definition doesn't support the full capabilities of the web map, so you'll always need a web map to create full-features web/mobile applications". That is why you get that warning when you overwrite a feature service. There are known issues and limitations with trying to put the full configuration of a web map into your feature service definitions. The most common example is that this can cause subtypes and coded value domains to stop working. ... View more

@jsarthur There is a lot of nuance, pro/cons to the questions you are asking that you're going to have to work through. The easiest, most reliable, and often fastest way to move a whole dataset is by doing a database backup/restore. This creates a 1:1 duplicate of your database. You can also use feature services to synchronize data, python scripts, FME workbenches, etc. But you'll need to find the right approach that meets your requirements of complexity to implement/maintain, performance (of transfer and final system), and functionality of the final system. As you pointed out, if you are just trying to view and query data in this other system, you don't need to bring over the utility network. But if you do bring over the utility network, the data will need to be versioned. ... View more

@D_Atkins the best practice is to put the majority of your definitions for symbology, labels, etc in a web map instead of the service. The feature service definition doesn't support the full capabilities of the web map, so you'll always need a web map to create full-features web/mobile applications. Additionally, putting all your configuration in a feature service means you're limiting yourself to only supporting a single user experience. A single feature service supporting multiple web maps uses less server resources and is more scalable than creating a bespoke feature service for each web map. ... View more

I don't immediately know the answer to this one, please log a case with support. ... View more

@Brian_Laws while you can explicitly define editing templates in a specific map, the recommendation is to use shared editing templates because this allows an administrator to manage a single set of editing templates in the geodatabase then each web map can reference them. Think about the implications of realizing you need to override the default value on a particular attribute in certain editing templates. If you do everything exclusively in web map, that means you need to open and review each web map to try and find (then update) that template. If you store them in the geodatabase, then you edit it in one place and all the web maps benefit. ... View more

@kvincent there needs to be something done, and while it could be done manually it could just as easily be done through Python or Arcade (if you are proficient with those languages). The problem with doing all this work directly against the versioned data is that history is going to accumulate, and you don't have the degree of separation between your live network data and the historic of your asset registry. ... View more

Is there a reason why you need to put it on the hydrant itself instead of using a separate point class that represents the inspections? If you are setting/updating a flag on the hydrant (or any other feature) that represents its inspection status you're going to need to push multiple updates to each of those features every year (resetting the flag saying it needs to be inspecting, marking the feature as inspected, then updating the last inspected date). Because the UN data is versioned, all these edits are tracked and archived forever. A more sustainable approach for inspection is to manage the history, status, etc using separate tables. Not just for hydrants, but for any kind of asset you are performing preventative maintenance/inspections on (valves, pump, etc). It also solve the problem of what to do when a hydrant is abandoned or removed and you don't want to lose the history of the asset for liability reasons. ... View more

My experience has been that if the layer already has field properties explicitly defined and saved in the map (which it won't until you change something and save), the field will appear at the end of the layer's field properties. If the layer doesn't have field properties explicitly defined, then fields will appear in the same order as the feature service. One of the things I like to do for fun/paranoia is set up the Schema Report tool to run on a weekly basis in my major geodatabases, then I will periodically use the Compare Schema tool to check for any data model changes that may have been 'forgotten' to be communicated/documented. I will then go through and chase down who made the schema change (pro tip, check the GP metadata history) then make sure that these changes are accounted for in any of the relevant maps/services (do users in group X need to see this field? does it need to be highlighted? what order should it appear in?). ... View more

@strmside please log an issue as this may be specific to the data/configuration you have in your asset package. Mike is out of office right now, but my guess is that having sample data will help. I have some concerns about the data model I see in this spreadsheet (no field reuse, haven't paired back expanded model, etc) but I'm going to hope that's because you've had to regenerate your mapping sheets. Remember, if you implement the expanded model you need to make sure you remove anything you don't need (fields, asset types, etc) otherwise you will end up with a large, less performant model. If you plan on just adding your existing data model onto a foundation, start with the essentials model then just make sure that you're reusing fields (achorsize, structuresize, etc). ... View more

Creating database views isn't a viable option because the data is registered as versioned. However, in the past the way I've tackled this a few different ways. One way is to have the inspection information be a feature class, whose geometry is populated when a user clicks the hydrant they want to inspect. The other way is to create all the inspections ahead of time, with the geometries and status you want. This approach has the benefit of being able to symbolize the status in the map and provide a dashboard breaking down inspect, uninspected, and exceptions for the year. ... View more

I'm a little late to the part on this question, but I was looking for some other CP related info and I've found the Understanding Cathodic Protection article from @TomDeWitte to be very useful for answering these questions. ... View more