For those who aren’t familiar with the concept of State Zero, this means getting rid of all of your Esri versions, compressing the geodatabase to move your edits from the Add & Delete tables to the base tables, and then most often un-versioning your geodatabase which completely removes the Add & Delete tables. See how SSP All Edits State Zero (currently rebranded to SSP Replay).
Curious about how SSP Replay works? View the full SSP Replay product overview here. If you want to see SSP Replay in action, see how the SSP tool helped MTEMC perform critical geodatabase maintenance while at State Zero.
Hi I'm Skye Perry with SSP Innovations. I'm here to talk a little bit more advanced use of SSP All Edits technology. We got another great video sort of explaining the basics of All Edits. We are going to talk a little bit on how we've expanded on the usages into a product that we call SSP All Edits State Zero.
This is really evolved out of geodatabases that have a lot of versions. This is more about processing all those versions at once and getting to State Zero as opposed to doing individual versions as we talked about in the core SSP All Edits product. The key part here in the versions is that you might have 30 of these. We have other clients (we are working with one right now) that has 8,000 of these. Perhaps you need to keep a wide variety of these versions that are related to various other processes in the organization. Whatever the case might be, our first step is to implement the All Edits product, again check out the other video for details there. Key point here is that it creates these All Edits tables and feature classes that do exist in your database.
As a reminder, you these are not related to the rest of your business data: land, electric, gas, water, telecom. This is a separate standalone that sits out here by itself. SSP All Edits State Zero uses automation along with the SSP All Edits product to extract these versions out into these feature classes (all in one fell swoop). There are plenty of error handling if there are any issues there. The key is to take all the data from the versions and place it into our format of the All Edits tables and feature classes. Now this is a little bit scary, and I realize that when I talk about it, but our next step in the process is usually to come in and fully delete all those versions within the geodatabase. Where they can fire a compress, which fully takes this geodatabase to State Zero. Now State Zero is kind of a holy grail for many years, and we couldn't get to it because of all these versions combined with a geometric network requirements within the utility and telecom space. First, solving the problem of extraction to get to State Zero was of utmost importance.
Why do we need to get to State Zero? That's probably your next question, if you don't already have your own reason. I've listed out some of the common reasons here on the right. Examples of changes requiring State Zero. This is not a comprehensive list, but this will give you some good ideas. A lot of relating to networks in our case. Adding a new populated feature class into your network. Maybe you are adding new alternative energy points or solar points that already has data in it. To do that, we need to get to State Zero to add that in the network. Other example changes include: removing weights from the network, removing feature classes from the network, and various topology items. Topology is more used if you think about parcel editing (parcels with topology with the neighboring parcels).
There are other couple of interesting examples during the time of working with customers and at one point, a partner. The first one was a challenging one: re-projection of the data. We had a client that still had data in NAD 27. They wanted to move to NAD 83. So, that their data will better align with Esri ArcGIS online. It must be in State Zero to do that. It will not handle versions. They got 8,000 versions or maybe 30. You got to take care of this, and do it in a sequence. The next and more recent case is conflation. We have a partner, Ramtech. They are good friends of ours. They are the conflation experts. We partnered with them because they said "we really need to be at State Zero for these large geodatabases to inform conflation." Again, rectifying all your database with many points on the earth. So, each of our challenge is to get them to this point. In either case, here back on this side, we've gotten to back to State Zero which allows you to do your State Zero activities. Whatever those activities are, you will then go about and doing them. As we’ve noted here, you might have other reasons around data migration, model changes, you name it. There's about 50 or 100 other uses that we've found here. So, you make those changes to your core geodatabase at State Zero - drop it in the network or you can re-create in the network.
The next piece of the SSP All Edits State Zero is to take the data back from the All Edits tables and feature classes and to take that data and re-create the versions as they've existed before. The second process is to extracts data out of those versions and replay right back into the versions as they have existed before. Thus, re-creating those versions. They will have the same name, we handle that via backend. We handle all the synchronizations. As an example, Schneider Electric designer users have XML files that have pointers to all those records. We are re-creating that data from scratch and we re-synchronize all the XML. So that your users come back, and they do not realize anything has changed. We can take the case here where we did the re-projection of all the data, took it to State Zero, re-projected the data, and re-created the versions. The users come back in the following Monday. They won't know anything that has changed. That's what we want to hear from our users in our system (seamless transition).
The final piece to talk about here is how do we do these two things, and what is different between this and All Edits (the product). The key point here is to both process and extract these versions to the tables. Following up with a re-creation from the tables is based on the SSP Nightly Batch Suite as we abbreviate it to NBS extension for All Edits. We have Batch Applications to do this along with reporting, tracking, and allows us to do this in a repeatable fashion. With this pattern, we solved the All Edits State Zero problem to allow you to do any of these operations or many others without having to lose that versioned data that you've worked so hard to capture over time.
Thanks for your time, hope this proves to be an inspiration to get you to State Zero.