Select to view content in your preferred language

Updating Parcel Fabric.

3892
5
06-26-2012 10:35 AM
Labels (1)
MarkVolz
Frequent Contributor
Hello,

At our organization we historically updated our data by working in a production File Geodatabase and when needed copy the data to a publication File Geodatabase.  This worked very well when there were only a couple GIS users.  However, as more people in our organization are using GIS we are running into more lock issues.  I am trying to figure out the best workflow for our organization.  Recently we have purchased a server that will run ArcServer Workgroup, so this might change how we can update data.  Part of me would like to use SDE to host our data however there are several problems:

First,
It appears that there are several bugs when editing parcels in SDE.  I am having enough trouble dealing with other bugs related to the parcel fabric, so I don't want to invite any more if I can avoid it.

Second,
I was under the impression that it is quickest to work on a parcel fabric in a File Geodatabase on the local machine.  Is this correct?

Third,
We only have one ArcInfo license, all the others are ArcView.  I don't think we can justify another ArcInfo / ArcEditor license.  So we will still be required to update File Geodatabases for the people that edit generic GIS data in ArcView.


I am trying to decide what route to go.

1) Edit in File Geodatabases, use query layers to access a published postgis / postgresql database (not to be confused with SDE).  This way we dont need any special licensing to update the production Geodatabase, which is good for our ArcView users.  However, this might be hard to use if users have to learn how to use the shapefile uploader in PGAdmin.  I am trying to figoure out updates can be processed in a model via model builder.  Also, does postgis have locking issues, or can we reload a layer at anytime?

2) Is it possible to edit in a File Geodatabase, then push updates to ArcSDE without worry of other people connected to the SDE layer?  Each person would have to borrow the ArcInfo license to push out updates.

3) Start a versioned Geodatabase in SDE, create a child file geodatabase, edit the file Geodatabase (can we use Arcview at this point?), then use ArcSDE to reconcile the Geodatabase.

4)  Deal with the bugs and directly edit in SDE.  A versioned database would be used so that I can push updates to the publication database as needed....  This might work for parcels, but what about the ArcView editors?
 
Thank You
Tags (2)
0 Kudos
5 Replies
TomLucky
Occasional Contributor
SDE was created specifically to handle multiple editors, versioning and file locks.  You should probably look more closely at moving your organization to SDE because the solutions you describe which avoid SDE sound like they could cause some maintenance headaches in the future.

I have some questions about your parcel maintenance.  The parcel fabric at 10.0 & 10.1 is part of the local govenment information model and I believe would require at least ArcMap Standard (ArcEditor) to edit correctly.  Are you using an old version of land records maintenance?  Are you editing a true parcel fabric or simple polygons?

As for your problems:
There are some serious bugs in the parcel fabric at 10.0 that seem to be getting better with 10.1, but I am not aware of any that are specific to using SDE.  Are you using the latest version of the parcel fabric?

A local database is almost always going to be faster than going across the network, but a properly configured database with SDE should be plenty fast enough.  Some organizations are in production with over a million parcels in SDE and multiple editors.

I think new licenses might be unavoidable.  It depends on how much time you are willing to spend maintaining the system.  If your one ArcInfo license is being used by Bob who forgot to close ArcMap before he went on vacation, do you pull the plug on his edit session?  Are his edits saved and posted?  There are lots of chances for problems with multiple geodatabase replications and too few editing licenses.

Good luck,

Tom
0 Kudos
MarkVolz
Frequent Contributor
Tom,

Thank you for your reply.  To answer some of your questions, I am using the parcel fabric, and I did just upgrade to 10.1 from 10.1 pre release.  On the production side we convert the parcel fabric into a simple polygon feature, dissolve by pin #, and add attributes from our tax table.  All of our users connect to the simple polygon feature.

It would be possible for us to use SDE for editing, and for consuming by users.  However I have the following concerns:
1)  Some of my parcels are split into two or more pieces.  So I will need to figure a way to quickly join all those parcels with part connections.
2)  I think I could represent the attributes that I want to share by creating a layer file.  However, how would I update the attribute table in SDE?  Can I reload an updated attribute table that others are viewing, or would I still have lock issues....   There really is no point to upgrade to SDE if I will still have locking issues while trying to update.

Last,
I don't think our organization needs multiple copies of ArcInfo / ArcEditor.  I will just need to make sure that myself and the GIS Coordinator can use ArcInfo as needed to update.  Also I thought I came across documentation stating that you can create an SDE replica and save it to a File Geodatabase.  If that is the case can ArcView users edit that database and have someone  with an advanced license reconcile and post changes to SDE?  That might work out for us, as most of the users only need to use simple editing.
0 Kudos
TomLucky
Occasional Contributor
If your ArcView editors are only updating the parcel attibutes and not the geometry, you could split the attributes into a separate table which is then joined to the geometry in the geodatabase.  The edits could be done to the table and the only locks would be the standard database locks.  If you are editing geometries after exporting to simple polygons, then I'm not clear on the advantage to using the parcel fabric.

Have you looked at associating feature classes to the parcel fabric?  http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/About_associated_feature_classes_and_t...
That might allow you to edit the fabric and then have an associated publish feature class with your dissolved parcels.  You might not need to synchronize or export features.

Tom
0 Kudos
MarkVolz
Frequent Contributor
Tom,

To simplify I should mention that I am the only parcel editor, and I do it using the fabric.  The others edit simple features where all they really need is snapping, so ArcEditor would be overkill for them.  There only issue is locking when they update, but I wont worry about them for now.

Here is my basic workflow:

As needed I edit the parcels using the parcel fabric editor.
At the end of each month and if I am not in the middle of adding a plat, I export the parcel fabric to a simple [dissolved by pin] polygon layer.
Next, I take an Excel file with updated tax data, add it to my database, then join it to the dissolved parcels.
The database is then sent from a working parcel geodatabase to a published geodatabase.  If others are on the published geodatabase the update fails.

I could change my workflow so that all my edits are within SDE.  I would have to add part connections for multipart parcels.  Using versioning I could update the parcels lines to default as needed.  However, I still have to deal with the tax attributes.  I obviously cannot just reload the entire tax table as there would still be locking issues.  The Assessors don't interact with GIS, they interact with an old AS400 program, so were not going to be able to have them edit our tax data.  So I am trying to figure out the best way of reloading the tax data.
0 Kudos
TomLucky
Occasional Contributor
Your workflow is becoming clearer now.  It sounds like you are deleting and recreating the assessment data table when you get an update.  Anyone using the table will create a lock preventing updates.  Instead of replacing the table, could you select and delete all the records, then append the new data?  You can probably script the updates to happen at night so the users won't see the data disappear during updates.

I still think you will be better off keeping the geometry and assessment data in separate tables connected by a join.  If your users will get confused by a join, you can create a layer file with the join already done for them to use.

If you decide to migrate to SDE, you should create a version for your parcel edits and use default as the version to push out the finalized edits to the users.  Script the updates from default to replicate to your published data.  I am not an expert on scripting and database replication, so you may need to get some input from some others if you go that route.

If you haven't done it in the past, you should join the land records meet-up webcast.  There is a chance at the end of every meeting to ask some questions of the group and you might be able to get some good suggestions.  It is every other Friday at 2:00pm est (next meeting is June 29th).  Send me a pm if you are interested and I'll send you the details.

Tom
0 Kudos