Calculating the X and Y coordinate automatically for the point layer

[JamalNUMAN]

Calculating the X and Y coordinate automatically for the point layer,

I’m not sure why the ArcGIS does calculate:

1.     The area and parimeter in the polygon layer;

2.     The length as a polyline layer

3.     BUT doesn’t create the X and Y coordinate in the Point layer

 

I do know that there is a tool to calculate the XY coordinate, but I’m wondering why they are not calculated by default!!! In this case, for example, if we move one of the points, then we need to manually update its XY coordinates!!!

Is there any logic behind this?

Regards

Jamal

[IngmarAlbinson]

A 3D point layer should have current X, Y and Z in attribute table.

Note: If layer is presented in other coordinate system the original coordinates + transformed coordinate should be in attribute table.

[ChrisFox]

One thing to consider is that a point feature class can also be a multi-point feature class which means each row could contain the definition of x number or points.

[LeeDavis1]

I like the idea. The ShapeX & ShapeY and ShapeZ coordiantes could display the current values in the current coordinate system and projection. For multipoint the coordinates would be the XY of the centroid formed by the pionts.

[RobertKlein3]

I would like to have these coordinate fields automatically calculated too -perhaps we're all missing something, since the unseen parameters of the feature geometry certainly already contain the information:  how else would the feature be sketched on the map view?  There must be some sort of VB or Python expression we could set as the default value for a given field to automatically insert the right value; question is, would it update if the feature geometry was edited?

[CoryWilliams]

I agree with this. Unless there's a plan to only have Multipoint features (as opposed to Point and Multipoint as two separate feature types), having the X,Y,Z automatically calculated would be extremely useful!

[LukeBehling]

This would greatly help the PLSS monument maintenance workflow where points are moved and in our case reports are generated. Right now we have to manually populate the XY fields or recalculate the entire point dataset.

[PatrickMcKinney]

I agree that the X and Y value should automatically populate while editing features.  We have field teams who will be capturing point data through the ArcGIS Android app, consuming a feature service from SDE.  It would be nice for the lat/long to automatically populate while they are editing.
 
As it stands now, we will have to calculate the lat/long back in the desktop environment.  I know that setting a field calculator to !shape.firstpoint.x! and !shape.firstpoint.y! pulls the lat/long from the SHAPE field for point layers.

[JohnDye]

Geodabases Feature Classes automatically create a Length and Area fields in the Attribute Table of a Feature Class as appropriate for the given geometry and the values displayed in these fields automatically recalculate and update without any action from the user whenever the feature is edited.

Why doesn't the Geodatabase do this for the X, Y coordinate pair of the feature as well? I would love to see X, Y or LON, LAT fields in the table that update automatically whenever a feature is moved. For lines and polygons, and multi-type geometries, it could just use the centroid.

[RichardCitkowicz]

Yes i agree, I understand the shapearea and shapelength updated automaticlly but not the XY. If these would get automaticlly populated would be great also with the customization of what output desired.

[RichardFairhurst]

Attribute Assistant, which comes with the Local Government Information Model (LGIM) downloads, does this behavior through the X_COORDINATE and Y_COORDINATE rules and lets you choose if you want the centroid, start or end of a line/polygon outline.

It also does much more automation, including maintaining sequential numbering using Max values or the GenerateID table, field caluculations thta can maintain date stamps or other values, user name stamps, validate values from a lookup table, maintain other related fields affected by lookup values in another field, etc.  These rules are set up in the DynamicValues table, which must be added to the map where you want Attribute Assistant to follow the rules.  A non-versioned GenerateID table can keep track of sequential numbering, and a MasterStreetName table can validate street names for centerlines/addresses.

All DynamicValue table rules can be controllled to respond to feature/record creation, attribute updates, geometry updates, or manual triggering, or any combination of those triggers.  Rules fired by the same trigger are processed in the order that they were entered in the Dynamic Values table, so multiple rules can operate in sequence on one field if needed.  All feature classes/tables referenced by the DynamicValues table must be within the map for the rules to work, otherwise the rules that follow a missing item will not fire.

You do not need to use the LGIM schemas or set ups to use the Attribute Assistant.  Here is the Address Data Managment model download (click the OPEN buttton) as an example that contains the Attibute Assistant and some common rules set up in the DynamicValues table to support that edit flow.