nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Address points not on actual structure , but are on end of driveway

NikkiHill

There is an app my County elections office hosted on ArcGIS Online. This app and the assessor’s office app have one fatal flaw, the address points created by the County 911 are placed at the end of the driveways. When using this address point layer as the search layer which is the most comprehensive layer database my county has, creates the problem because boundaries for jurisdictions usually follows the parcel lines. And if the address point is outside of the parcel at the end of the driveway the return district/precinct/levee can be wrong.

One major undertaking between myself, the County 911 will be coming up with a way to get one addressing layer with all address points on the structure. That way when I go to create an application, the district, levee, or area I am looking for would be accurately represented when I put in an address.

I am not experienced in scripts, let alone know where to even enter it in ArcPro. Is there a way to do this less painfully than moving my 35000+ address points to be located on top of the structure instead of at the end of the driveways?

Finde mehr Beiträge mit dem Tag

Federal State Local

Accepted answers

All comments

MikeVolz

How about creating a point at the centroid of the building footprint and then spatially joining it to address points to get a vast majority of the points. Then manually move only the more complicated address points that fall outside the parcel.

Are you going to stack address points for apartment buildings?

JoeBorgione

Do your building footprints already have an address on them?

NikkiHill

Unfortunately, I do not have a building footprint layer. I have been searching for one with address, but no luck.

Cheers,

Nikki R. Hill

GIS Coordinator

Jasper County, MO

417.237.1015

Jasper County Courthouse

Outlook-rylrpu23.png

NikkiHill

It looks like there are no building footprints in our database. Is this shapefile necessary to complete this task?

Cheers,

Nikki R. Hill

GIS Coordinator

Jasper County, MO

417.237.1015

Jasper County Courthouse

Outlook-n2p44ktp.png

JoeBorgione

How about your parcels layer: do they have a 'Location Address' that can be used?

NikkiHill

Yes I do.

Cheers,

Nikki R. Hill

GIS Coordinator

Jasper County, MO

417.237.1015

Jasper County Courthouse

Outlook-1svwizcy.png

MikeVolz

There is a free Building Footprint layer that you could use as a start.

https://github.com/Microsoft/USBuildingFootprints

From here you would download building footprints into a zip file for the entire US. (The data is not perfect as it is dated with missing structures as well as structures that have been modified and or demolished and this would vary from one area to the next.)

You would unzip this file and then add the data to Pro (I think ArcMap has a hard time processing all the data).

Then use your jurisdiction's boundary to only clip out building footprints for your jurisdiction which would leave you with building footprints with no addresses. Since you do not already have building footprints I guess you would be using aerial photos to determine building location, but without the vector building footprint polygon layer I'm not sure how you would automate the process.

You can then add a new address field(s) to the new building footprint layer and then spatially join to the parcel layer and field calculate the address into the building footprint layer. Then you could create a point at the centroid of the building footprint. Then spatially join the address point to the building footprint centroid point that provides a corrected address point location with an address. If you already have address data for the address points, you would need to compare this address data to the parcel based address data as they may be different and you'll need to determine which address is correct. This will not get addresses for all points (As you say some address points fall outside parcel boundary which you can manually fix, but it should hopefully be a small subset of the original data).

JoeBorgione

You can turn your parcels polygons to points; be prepared for a firestorm of sorts migrating from the points you have now to something else....

MikeVolz

Seems like you would need a Production Mapping license for this workflow.

Even generating points at the centroid of a polygon might be a licensing issue, as it is only available with the Advanced license and this tool would be critical to the workflow I have outlined above.

BrianOevermann

For polygon centroids check out ET GeoWizards. There is a point to polygon tool and can even force it to create the centroid within the polygon (for those oddly shaped polys for which the centroid would fall outside). No Advanced license needed.

BrianOevermann

I'll ask another question: What other attributes are stored in the address point data? You somewhat imply that the 911 address data is used by the Assessor (or maybe I should read that as "the Assessor has the same problem as I do"?). Perhaps a parcel ID has been added to the 911 data for Assessor use?

This is likely wishful thinking but if a parcel ID is in the address data then your process just got 1000% easier.

NikkiHill

Oh yes! I have PINS. The Accessor and 911 use the same data.

Cheers,

Nikki R. Hill

GIS Coordinator

Jasper County, MO

417.237.1015

Jasper County Courthouse

BIM_CAD.png

ChristinaMcCullough1_0-1653421560861.png

Outlook-b3zs4vxj.png

BrianOevermann

Create your parcel centroids. If the process doesn't populate a field containing the PIN from your parcel layer, intersect your centroids with the parcel polys to get the PIN into your centroid layer. Add all of the relevant fields from your address layer to the centroid layer.

Now, do a join from the address layer to the centroid layer using the PIN as the key. Then use the Field Calculator to calculate the values of the fields in the address layer to the centroid layer fields.

The centroid may not be over the actual structure but it will at least be within the parcel. You can optionally move the centroid over the structure based upon imagery if that is a goal.

Edit [to add missing info]: Once you've calculated the values into the centroid layer fields you can remove the join. Doing a spatial join to get the relevant data across would also be a valid--more than one way to get from point A to point B!

NikkiHill

Thank this worked!

Cheers,

Nikki R. Hill

GIS Coordinator

Jasper County, MO

417.237.1015

Jasper County Courthouse

Outlook-xsizssba.png

JoshuaBixby

Typically E911/911 address points at the end of the driveway is purposeful. As much as I see the issue that causes for the types of analyses you want to do, changing the address point to the middle of a structure can create some grave consequences is rural areas with large lots and long driveways. What if the shortest distance between a structure and a road isn't the driveway? Are the first responder and police suppose to go off-road to get to the structure?

Before moving an address point, I suggest you consider creating a second address point instead of trying to make one address point rule them all. I personally would put operational and safety concerns above analysis issues when deciding where a single address point should be located.

NikkiHill

This is a really great point. Thank you!

Cheers,

Nikki R. Hill

GIS Coordinator

Jasper County, MO

417.237.1015

Jasper County Courthouse

Outlook-31u3bnno.png

BrianOevermann

Joshua makes some great points regarding why the address points are at the ends of driveways but there are ways you can mitigate some of the concerns he brings up.

My former job was with a rural county in Montana with some large lots, long driveways, and structures not even visible from the road. My current job is with a city in Washington State with lots of trees where some homes even on smaller lots are not visible from the street. Different environments but similar issues.

In both of these organizations we created driveway segments for structures where access from the road was not very obvious or simply confusing. And at least in my current job, I created a "Street class" field to classify the streets for better/easier symbology, including completely filtering out certain types of streets. This makes it easy to completely drop the driveways on maps where their inclusion is unnecessary and simply clutters up things. These driveway segments have zero address ranges and a discrete intersection node is NOT created where it connects to the street (no slicing and dicing of the street segments just to accommodate driveways).

Another possible method is for you to create your "analysis-capable" address points as discussed in earlier messages (purely as a means to do what follows), create X,Y fields in the data and calculate the values of the point into those fields. Then add equivalent X,Y fields to the existing 911 address point layer and cross those "analysis X,Y" fields over. Now whenever you need to perform analysis you would create an event layer using the analysis coordinates and then perform your analysis. This would eliminate you needing to maintain two address point layers that must be kept in sync but realistically adds some process overhead, particularly if you plan to do much analysis. I admittedly would not choose this method if at all possible but I understand that some organizations might have some constraints for which this might be the only way to accommodate needs.

You definitely want to gather all of your stakeholders and have a discussion of the pros and cons of various methodologies if your aim is to maintain a single address point layer that will meet everyone's needs.

John_RMellor__GISP

I would be cautious. The bulk of your join should be fine, but I have experienced where there are multiple structures on a single parcel and sometimes they share an address and sometimes they are separate addresses. It sounds to me like your join may only take one structure into account. If a home were to have an unattached garage, would your join be a one to many? Think of apartment complexes and mobile home parks. In our case, the Parcel IDs were supposed to be unique, not recycled and specific to a single parcel polygon; however in some cases there were multipolygons that shared an ID - it was a single record but graphically showed multiple polygons, each with the same Parcel ID.

As long as your methodology for data clean up after your join is thorough, you should be fine.

Since you are at your beginning stages, another workflow process to consider might be ESRI's Address Data Management solutions; https://solutions.arcgis.com/local-government/help/address-management/

You might want to also consider a multipoint feature. So, this would be an environment where you would have a graphic point to represent the driveway entrance, another point for centroid of the structure and another one for the main entrance to the structure and one for the side entrance to the structure and one for the unattached garage; but would be a single record in your table. While this workflow sounds intense, it may make sense for a base for your feature as you work through issues in years to come.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.