Is there a way to post only specific features to a parent version?

[JonathanBailey]

I'm working on a system with a client that has the following workflow:

1. The production version of the data is maintained in the DEFAULT database version.
2. Periodically, an update is received in the form of either a PDF document or a CAD dataset.
3. Updates from the PDF document or CAD dataset are applied to the data in a child version of DEFAULT.

Now, when a change is made to the DEFAULT version, it triggers a whole bunch of (potentially expensive) changes in the downstream process. So, obviously, the client would like to limit the changes that are made to the DEFAULT version. One approach is to apply a tolerance to feature geometries -- if the changes to feature geometries are within a specified tolerance, then this is considered "not a change" for production purposes, and should not be posted to the DEFAULT version. However, some other changes in the child version should be posted to the DEFAULT version.

Is there any way that only some of the changes made in a child version can be posted to the DEFAULT version?

Thanks,

Jon.

[BrianOevermann]

Jon,

I don't think you can pick and choose which changes get posted versus not. All of the changes are saved into the delta tables, and a reconcile/post process simply operates on all of the outstanding changes, pushing them to default.

Occasionally I have a similar need, typically related to the timing of when the changes are made official, so I am interested in also finding out if there is a way to do this. But I suspect such a process would be a bit convoluted to pull off.

Brian

[JonathanBailey]

Hi Brian,

What workarounds have you used in the past when you've needed to do this?

Thanks,

Jon.

[BrianOevermann]

Jon,

The situation where this arises for us is with addressing. I am sometimes asked to calculate house numbers and then there is some sort of delay necessary before making them official. We are usually not incredibly busy from an addressing standpoint so most of the time I can simply delay the post to default.

There have been a few times that in the interim another address assignment or two has come up that needs to be posted right away. At that point, we discuss and make one of two decisions:

- Post everything but delay the official announcement. Not ideal if I get a data request for our site address layer before everything is official!

- Move the unofficial addresses to a separate layer and delete them from the primary layer so that posting can commence. The danger is that I might forget to add them back when they get officially announced.

I've contemplated the idea of creating a separate version for every address assignment or group of addresses (i.e. all of the newly assigned addresses for a subdivision), but the number of times this issue occurs doesn't seem to warrant adding that extra layer of complexity. That might be different if there were more than one editor for this data.

I may be reading too much into your initial post, but are you saying that for a particular unit of work (i.e. the PDF or CAD dataset) only a portion of the features might be desired to be posted? Or are you saying that you may only want to post the edit for one dataset even though you have a requirement to enter all of the datasets? I know some organizations use versions to capture working alternatives and some of those never become the end result but are still used in the analysis/review stages of their project. Multiple versions would work for the latter scenario but not for the former. And I suspect that you've already evaluated that workflow.

A thought that just popped into my head is: Are you able to evaluate beforehand which features should be posted and which should not? If so, maybe splitting the work into different versions could work. We don't know enough specific info about what you are dealing with to really say if that is viable or not, but you can evaluate that idea for appropriateness. I don't know, either, if that may create feature conflicts where the conflict resolution process is invoked.

Brian

[JonathanBailey]

Hi Brian,

Thanks for your thoughtful response.

It's the former case -- a version will represent an entire unit of work (for example, a new set of survey data). We wish to preserve that in its own version for record keeping; however, only some of the surveyed features represent changes to the features in the DEFAULT version, and only those should be posted.

I suppose that your thought could work -- the entire survey could be loaded into its own version; we could perform an analysis to determine which features are "changed" and these could be copied into the appropriate feature classes in another version which is then posted in its entirety to the DEFAULT version.

Thanks,

Jon.

[BrianOevermann]

Jon,

I hope others take the time to offer additional ideas. Admittedly, shifting features around from one version to another is a hackish workaround. I'd like to think someone else has approached this from a slightly different angle that is more efficient!

But maybe that's just wishful thinking...

Brian