Union of two point feature classes

1111
4
Jump to solution
05-14-2014 07:21 AM
deleted-user-ugCMpXci8bn5
New Contributor III
I have one large point feature class and another smaller point feature class.  The larger FC contains most, but not all, of the features that are in the smaller FC.

I would like to extract the few features in the smaller class that are not in the larger FC and append them to the larger FC, essentially  a union of the classes (but for point FCs, not polygons).  I would prefer to do this using attributes; the two FCs have some matching fields, but in this case, Select By Location is not precise enough (there are some matching features in the two classes that are not completely aligned with one another).
Ideas? Maybe I am overlooking something, this seems like it should be pretty simple.  Thanks, J
0 Kudos
1 Solution

Accepted Solutions
RichardFairhurst
MVP Honored Contributor
I have one large point feature class and another smaller point feature class.  The larger FC contains most, but not all, of the features that are in the smaller FC.

I would like to extract the few features in the smaller class that are not in the larger FC and append them to the larger FC, essentially  a union of the classes (but for point FCs, not polygons).  I would prefer to do this using attributes; the two FCs have some matching fields, but in this case, Select By Location is not precise enough (there are some matching features in the two classes that are not completely aligned with one another).
Ideas? Maybe I am overlooking something, this seems like it should be pretty simple.  Thanks, J


Nothing should be assumed to be simple in data comparisons and the approaches you have to take depend on several factors.

If you have a common unique ID value in both data sets to use for an Attribute join then it is simple.  Any unmatched unique values in the new points just get inserted to the original (as the last step).  Any features that can join Just do an attribute transfer with the field calculator where the two differ on attributes.  For the spatial changes you can add an X_Coord and Y_Coord field to both and select for any differences, then break the join, perform a relate on the common attribute so that both feature classes have the same selection of IDs and delete the points from the original and copy/paste in the points from the replacement.

Data comparisons that range from subtle to gross differences in both attributes and geometry are one of the most difficult things to do when no common unique ID is present to do an attribute join, unless points cannot overlap each other.  If no overlap is possible then in addition to creating an X_Coord and Y_Coord fields for geometry comparisons create an XY_Coord field that concatenates them together as text for an attribute join.  If no point overlap in the original data is possible, the XY_Coord field can be your unique join field.  Then you can compare attribute using a standard join and do the attribute updates.  For geometry differences, just find the set of points in the new feature set that has no points in the original and copy/paste them in (select for JoinedOriginalPoints.ObjectID IS NULL or apply Robert's suggestion).  The main difference in using this method from using a UniqueID is that you cannot know if any of the new points represents an original point moved to a new location, so in reality you could be duplicating points.

If there is no unique ID attribute value and multiple features can have the same XY coordinates in the original data then the complexity increases by many orders of magnitude.  I don't even want to begin describing all of the things you have to do to keep things straight.  It is basically a confused mess that now involves using Spatial Join with both the One to Many option and One to One option to distinguish unique point locations from overlapping point locations and a variety of cross checks to avoid false duplicates being added to your data.  About 8 to 10 major stages of operations are needed to deal with this situation.

These kinds of updates are why GlocablIDs and replication was created.  It took years for ESRI to develop that option and think through the implications of separately edited copies of a data set needing to synchronize.

View solution in original post

0 Kudos
4 Replies
RobertBorchert
Frequent Contributor III
use select by location. Select all the points in the smaller feature that intersect the larger.  Then do a switch selection.  you now have selected all the smaller point features that are not identical to the larger.



I have one large point feature class and another smaller point feature class.  The larger FC contains most, but not all, of the features that are in the smaller FC.

I would like to extract the few features in the smaller class that are not in the larger FC and append them to the larger FC, essentially  a union of the classes (but for point FCs, not polygons).  I would prefer to do this using attributes; the two FCs have some matching fields, but in this case, Select By Location is not precise enough (there are some matching features in the two classes that are not completely aligned with one another).
Ideas? Maybe I am overlooking something, this seems like it should be pretty simple.  Thanks, J
0 Kudos
RichardFairhurst
MVP Honored Contributor
I have one large point feature class and another smaller point feature class.  The larger FC contains most, but not all, of the features that are in the smaller FC.

I would like to extract the few features in the smaller class that are not in the larger FC and append them to the larger FC, essentially  a union of the classes (but for point FCs, not polygons).  I would prefer to do this using attributes; the two FCs have some matching fields, but in this case, Select By Location is not precise enough (there are some matching features in the two classes that are not completely aligned with one another).
Ideas? Maybe I am overlooking something, this seems like it should be pretty simple.  Thanks, J


Nothing should be assumed to be simple in data comparisons and the approaches you have to take depend on several factors.

If you have a common unique ID value in both data sets to use for an Attribute join then it is simple.  Any unmatched unique values in the new points just get inserted to the original (as the last step).  Any features that can join Just do an attribute transfer with the field calculator where the two differ on attributes.  For the spatial changes you can add an X_Coord and Y_Coord field to both and select for any differences, then break the join, perform a relate on the common attribute so that both feature classes have the same selection of IDs and delete the points from the original and copy/paste in the points from the replacement.

Data comparisons that range from subtle to gross differences in both attributes and geometry are one of the most difficult things to do when no common unique ID is present to do an attribute join, unless points cannot overlap each other.  If no overlap is possible then in addition to creating an X_Coord and Y_Coord fields for geometry comparisons create an XY_Coord field that concatenates them together as text for an attribute join.  If no point overlap in the original data is possible, the XY_Coord field can be your unique join field.  Then you can compare attribute using a standard join and do the attribute updates.  For geometry differences, just find the set of points in the new feature set that has no points in the original and copy/paste them in (select for JoinedOriginalPoints.ObjectID IS NULL or apply Robert's suggestion).  The main difference in using this method from using a UniqueID is that you cannot know if any of the new points represents an original point moved to a new location, so in reality you could be duplicating points.

If there is no unique ID attribute value and multiple features can have the same XY coordinates in the original data then the complexity increases by many orders of magnitude.  I don't even want to begin describing all of the things you have to do to keep things straight.  It is basically a confused mess that now involves using Spatial Join with both the One to Many option and One to One option to distinguish unique point locations from overlapping point locations and a variety of cross checks to avoid false duplicates being added to your data.  About 8 to 10 major stages of operations are needed to deal with this situation.

These kinds of updates are why GlocablIDs and replication was created.  It took years for ESRI to develop that option and think through the implications of separately edited copies of a data set needing to synchronize.
0 Kudos
deleted-user-ugCMpXci8bn5
New Contributor III
use select by location. Select all the points in the smaller feature that intersect the larger.  Then do a switch selection.  you now have selected all the smaller point features that are not identical to the larger.
  I mentioned in my question tht Selection by Location will not work in this case.
0 Kudos
RichardFairhurst
MVP Honored Contributor
I forgot one other option.  If no single field contains a common UniqueID for both data sets, then if the concatenation of several fields would constitute a common unique value for both data sets then you can concatenate those fields into a text field and do an Attribute Join on that field.  If none of those attributes changed and the concatenation is really unique for every record, the concatenated field will act the same as a single common UniqueID field.  If some of those attributes changed then you won't be able to join them and will probably end up duplicating the points, just like you would duplicate points based on having to use an XY concatenation join where the geometry no longer matched.

Anyway, if you are not using replication, preparing a meaningless common UniqueID that will not change and sending it out to the field is the ideal when changes to existing records can be made.  If both data sets potentially can make changes to common features at the same time then you also need a date time stamp that is automatically updated by some program every time a feature is updated on both data sets so that it can be used to determine which record is newer and the computers must use synchronized date times.  Otherwise you may replace newer data with older data.  Due to all of these complexities, disconnected parallel editing is best handled by replication, and even then conflict edits are possible that may require a manual validation process, like conflicts during a reconcile and post operation using versioned data.
0 Kudos