Offset Address Points From Centerline - Address Data Management Template

3758
2
Jump to solution
06-06-2015 01:10 PM
Labels (1)
JeffWard
Occasional Contributor III

Hi,

I'm trying to fine tune the Address Data Management template from the local gov solutions.  I really like the ability to create both address points and site address points at the same time while using the "Add Site Address Point" tool.  Is there a way to place the address point at the actual driveway cut, or along the curb at the center of a vacant lot instead of right on the centerline feature?  If I try doing this the tool only creates an address point that has no attributes, the Attribute Assistant doesn't fill any of the fields for the address point and it doesn't create a site address point.

I am assuming this is something in the code for the Add Site Address Point tool.  Is it possible to modify this code?

Thanks,

Jeff

Jeff Ward
Summit County, Utah
0 Kudos
1 Solution

Accepted Solutions
RichardFairhurst
MVP Honored Contributor

The address attributes are all being filled in using reverse geocoding and getting a single correct position on the Centerline is essential to that operation.  It probably doesn't use any buffering option and requires snapping so that it never uses the wrong street for the address or the wrong position on the centerline.  As a result the tool will never derive more than one address for any point you place (unless a user intentionally clicks on an intersection point for multiple roads).

There is no way that the tool would ever recognize the lot line geometry to derive correct normal angles relative to the actual lot you are targeting without a complete rewrite of the tool.  The tool actually doesn't register that there is any lot line feature class at all.

Using a simple tolerance or buffer around a point on a lot line is also a bad approach, since it will often return too many possible roads and address numbers (especially for corner lots and curved roads) or the tolerance will  be too small and miss too many centerlines as road widths vary.  A cross street of a local road with an Arterial Highway would typically assign the address to the local road for any driveways near that corner, even if the driveway orientation was toward the Arterial Highway, since the local centerline will be closer to the lot line for some distance along both lot frontages.

Having done a lot of geometry programming the current centerline snapping option is exponentially easier to implement than any option that would allow for buffering or the use of actual lot lines to determine the normal angle to the closest centerline position.  So I fully understand why the programmer did not even attempt to handle the complexities that arise from a tool designed the way you want.  For these reasons, I doubt there are any ways to alter the behavior of the existing tool.

View solution in original post

2 Replies
RichardFairhurst
MVP Honored Contributor

The address attributes are all being filled in using reverse geocoding and getting a single correct position on the Centerline is essential to that operation.  It probably doesn't use any buffering option and requires snapping so that it never uses the wrong street for the address or the wrong position on the centerline.  As a result the tool will never derive more than one address for any point you place (unless a user intentionally clicks on an intersection point for multiple roads).

There is no way that the tool would ever recognize the lot line geometry to derive correct normal angles relative to the actual lot you are targeting without a complete rewrite of the tool.  The tool actually doesn't register that there is any lot line feature class at all.

Using a simple tolerance or buffer around a point on a lot line is also a bad approach, since it will often return too many possible roads and address numbers (especially for corner lots and curved roads) or the tolerance will  be too small and miss too many centerlines as road widths vary.  A cross street of a local road with an Arterial Highway would typically assign the address to the local road for any driveways near that corner, even if the driveway orientation was toward the Arterial Highway, since the local centerline will be closer to the lot line for some distance along both lot frontages.

Having done a lot of geometry programming the current centerline snapping option is exponentially easier to implement than any option that would allow for buffering or the use of actual lot lines to determine the normal angle to the closest centerline position.  So I fully understand why the programmer did not even attempt to handle the complexities that arise from a tool designed the way you want.  For these reasons, I doubt there are any ways to alter the behavior of the existing tool.

JeffWard
Occasional Contributor III

Thanks for the help Richard. 

I was afraid this would be the case.  I have one mxd set up with the Attribute Assistant that I use for existing addresses that grabs parts of the address from surrounding and intersecting features that works pretty well.  With that setup I do need to run some QA/QC methods to catch corner lots getting the wrong street, but it's not too difficult. 

I was hoping to be able to keep placing address points at the edge of the road and still be able to use the Add Site Address Point.  I may have to figure out another setup to account for placing address points at the edge of road for new address creation.

Thanks,

Jeff

Jeff Ward
Summit County, Utah
0 Kudos