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; } } }

LGM : Addresses

BrianO_keefe

I'm trying to begin our cities FIRST Authoritative Address Database. I'm doing this in the LGM.

I used to be the Address Coordinator for the City and I have ties to that department still. Oddly enough their systems are powered by oracle databases containing the addresses only and they are not spatially located. SO... I have received a datadump of 200,000+ addresses that identify as rooftops. I (however) do NOT have building footprints but I am moving forward.

My question is this.

I have used the Toolbox Tool for cleaning up addresses (Standardize Addresses) and have been able to break these addresses up into their various components. With some quick feature class creation I have been able to clean up the prefix and suffix directionals. I'm ready to pop these addresses into the LGM... BUT...

From my experience with the LGM I have learned that some feature types have multiple feature classes to represent them... Streets for example has speed limit, centerline, simple, etc. that ALL contain the exact same spatial features but carry specific attributes of the feature in specific fields for those feature classes. (i.e. the StreetSpeedLimit feature class is just centerline feature class duplicated except its attributes are just the speedlimit). What I don't want to do is dump these addresses into the SiteAddressPoint and move on to my next process only to discover later that because I didn't ALSO dump these points into the XYZ feature class that now my LGM is missing functionality and it's 10x harder to fix this after the fact.

Other than the Address LGM Map/Application (which doesn't give you a step by step for importing address points) is there any good documentation on this or a video I could watch to get this figured out?

Find more posts tagged with

Local

Accepted answers

All comments

JoeBorgione

It may depend on who uses the data and how it's used. If you have everything in one field ( HN, Full Streetname) and match against that, there is very little if any wiggle room for error. Let's say your address point has 1234 S Main St and the user types in 1234 Main. I'm pretty sure there would be no matches.

On the other hand, if everything is parsed out, each component can take a piece of the hit, so with the example above you'd probably get a partial hit at least.

I use address points as Jeff describes as the first locator in a composite. It's followed by a US Streets locator with everything parsed out; If they miss the point, the fail-over is the street. I prefer points; to me an address is what it is. But I work with humans, and they (we) make mistakes soemtimes err, I mean sometimes....

BrianO_keefe

The 200k address had a spatial component. Thanks to a 3rd party process the points are all rooftop centerpoints.

JeffWard

If you use a point locator you only need the address field and optional city and zone fields.

JeffWard

I guess I thought you had a set of points you wanted to load into the LGIM. So are you taking your 200k addresses stored in a table with no geographic component and matching them against a centerline locator and then loading the result into the LGIM?

BrianO_keefe

Thank you Jeff. To answer your question...

Jeff Ward wrote:
Why do you need the PreDir Type etc. when you are matching against points?

Because the Address Locator built off of this table needs to be able to parse this, right?

JeffWard

Brian,

In my experience the LGIM Address Data Management Map is primarily used for creating new addresses for new developments, not for creating a new address points layer for existing addresses.

The newer version of the Site Address Points (released last year I think) doesn't parse the street name elements, there are just fields for full street name and full house number and full address; which makes sense. Why do you need the PreDir Type etc. when you are matching against points? All you really need is the house number for labeling and the full address for the locator to match against. The full street name is included for two reasons, 1- it is restricted to the FULLNAME field in your MasterStreetName table for quality control and 2- it is concatenated with the value in your ADDRNUM field to build the full address. The Address Data Management Map is set up with the Attribute Assistant add in to make creating new addresses a streamlined process, but you can modify the Attribute Assistant to meet your needs for creating new points for existing addresses. I have a map set up to use the attribute assistant to grab the house number from my parcel layer and the nearest street for the street name and then it concatenates the two to populate the full address field.

What I don't want to do is dump these addresses into the SiteAddressPoint and move on to my next process only to discover later that because I didn't ALSO dump these points into the XYZ feature class that now my LGM is missing functionality and it's 10x harder to fix this after the fact.

As far as I know there are no other layers that contain duplicated points with another set of fields for additional LGIM functionality.

Other than the Address LGM Map/Application (which doesn't give you a step by step for importing address points) is there any good documentation on this or a video I could watch to get this figured out?

The method I used was the Append geoprocessing tool, set the Schema Type parameter to "NO_TEST" which will then give you a list of fields for your target dataset in the Field Map parameter. You can then match up your fields by right clicking on the fields displayed and select the fields in your input dataset that match.

I hope that helps.

Jeff

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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