Select to view content in your preferred language

How to load data into attribute tables of existing features?

1527
7
04-30-2013 12:14 AM
LigiaGafitescu
Deactivated User
I want to load data into existing features (not existing feature classes). Maybe it's really simple, but I have no idea how to do that now.

I appended some data into an existing feature class (let's call it B), but at the end, some fields from feature class A were not transferred, so I want to bring the data from those not-transferred fields (FC A)  into the existing fields of the existing features (feature class B). In other words I just want to fill in some cells in the attribute table of FC B with values from FC A.

Append tool won't help, Load Objects won't help, Simple data Loader won't help, xml import won't help, doing it manually won't help because we're talking about a lot of data and of various values.

Is there a "more automatic" way than Spatial Adjustment's Transfer Mapping?


Thank you a lot for you kind suggestions,
Ligia
0 Kudos
7 Replies
VinceAngelo
Esri Esteemed Contributor
What version of ArcGIS are you using?  What service pack?
In what type of geodatabase is the data stored?  If ArcSDE, which RDBMS?
Is there an attribute key on which you can join in both tables?

- V
0 Kudos
LigiaGafitescu
Deactivated User
What version of ArcGIS are you using?  What service pack?
In what type of geodatabase is the data stored?  If ArcSDE, which RDBMS?
Is there an attribute key on which you can join in both tables?

- V


Sorry, forgot to give details.

So its' ArcGIS 10.1 SP 1. It's an ArcSDE Geodatabase on PostgreSQL.
And unfortunately, no I don't have an attribute key to use for join. The attribute table is almost empty.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
It's a trivial task to update columns with a join key using SQL.  It's impossible
without a join key, so you need to make one.  You didn't say what feature type(s)
or how many rows were involved, which would make a large difference on your
options, but the general goal is to generate a table with rowids of the two tables
as a result of a spatial join, then use that to drive an UPDATE statement.

- V
0 Kudos
RobertGelner
Emerging Contributor
Ligia, perhaps you have already looked at this, but I didn't see it mentioned; have you verified the field properties are the same between the two feature classes for the fields that did not append?
0 Kudos
VinceAngelo
Esri Esteemed Contributor
In a similar vein, why not just delete the incorrectly joined rows (those with NULLs
in some key column) and re-append, paying close atention to field compatibility.
You could even append using SQL, which will be more forgiving on types.

- V
0 Kudos
LigiaGafitescu
Deactivated User
In a similar vein, why not just delete the incorrectly joined rows (those with NULLs
in some key column) and re-append, paying close atention to field compatibility.
You could even append using SQL, which will be more forgiving on types.

- V


1) Hello again. Re-appending would create new features, and I want to update the existing ones. the reason I insist on updating the existing ones, is because I've already run a procedure on them. More precisely, the features we've talked about are point FC and they have received a code which I later used in a polyline FC. The polylines are defined at ends by these point FC I'm talking about and by their codes.

But if there is no other solution, I guess I will delete them, re-append, recreate the geo-network and run again the procedure.


2) Feature type- point, number of rows: 2000.

3) I think the appending went wrong because it  was checked "NO TEST", so probably it was a compatibility between fields problem for sure. Can't remember what happened during the append, it's been a while.

4) The spatial join creates a new feature class, so that's not a solution I think.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Yes, a spatial join would produce a new table, but it would produce a new table
with attributes from both tables, from which you could do an UPDATE.

Since there are so few points, and they are points, you might just try a brute
force ST_GEOMETRY equivalence test (assuming the coordrefs are exactly
the same). 

- V
0 Kudos