I am trying to figure out the 'pattern' to obtain APN to polygon mapping of parcel in datasets...so my code can query by "APN" for a polygon.

APN as in: https://en.wikipedia.org/wiki/Assessors_parcel_number

"An assessor's parcel number, or APN, is a number assigned to parcels of real property by the tax assessor of a particular jurisdiction for purposes of identification and record-keeping. The assigned number is unique within the particular jurisdiction, and may conform to certain formatting standards that convey basic identifying information such as the property type or location within the plot map."

I downloaded Balitmore,MD parcel: https://data.baltimorecity.gov/Geographic/Parcels/rb22-mgti

When clicking a polygon I get:

blocklot:8455 001
fulladdr:4511 WINDSOR MILL ROAD

What column is considered the APN?

  • 1
    You don't describe what an APN is, so this is a guess, I suspect you want the the pin field ..as to me that appears to be "the parcel number", which is a value generally used to join a GIS parcel geometry record to a CAMA (computer automated mass appraisal) tabular record. If APN means something else, though, this is a meaningless comment. FWIW, notice that the pin value incorporates both the blocknum and the parcelnum values. A complete parcel number is often a concatenation of a few different fields in the CAMA.
    – elrobis
    Jun 17 '16 at 14:17
  • @elrobis updated. so a APN is a combination of "blocknum"+"parcelnum". ok. is there a 'standard' way to review this..you state its 'often' a concatenation of a few different fields. i assume there is some sort of standard/pattern to get a full APN across parcel data sets?
    – Jeryl Cook
    Jun 17 '16 at 18:28
  • @elrobis,i was able to resolve my question based on your comment. If you wanna post it as an answer I will accept. Thanks
    – Jeryl Cook
    Jun 19 '16 at 13:20

Jeryl, I'm glad you found a solution. Here's an expanded answer based on my earlier comment—

It sounds like you want the pin field...to me that appears to be what I would call "the parcel number", which is a unique value used to identify a parcel in a taxable landbase, and which is often used to join an Assessor's CAMA (Computer Assisted Mass Appraisal) tabular record to a GIS parcel geometry record.

Some Background Info on Parcel Numbers

Notice that your pin value incorporates both the blocknum and the parcelnum values. A complete parcel number is often a combination of a few different fields in the CAMA. It's important to realize there is not a uniform standard here—various governments/taxing authorities may use a different combination of fields as components in their parcel numbers. And on paper, parcel numbers often appears with a sequence of dashes - or dots . delimiting the different number parts. As an example, consider this parcel number for a property in McDonald County, Missouri:


In this case, I happen to remember the 22 corresponds to the PLSS Section number the parcel is located within. 003 was some kind of "block" value (beware: not necessarily a census block). 006 refers to a large, legacy parcel you might think of as a "parent parcel" many smaller parcels were clipped from, and 006 was that parent's "parcel number" (beware: this means "this parcel number includes a parcel number!"). And finally, 005 refers to this. exact. parcel. in this particular system's parcel patchwork. As for the other values, I forgot what they represented, but if you were to look at that county's parcel dataset, you should find each of those number values represented in one column or another.

..while we're on the topic of "numbers", be warned that parcel number is a misleading term. Most parcel number parts are indeed numbers, but it's not uncommon to encounter letters. So it is more universal to think of a parcel number as a Character Varying (i.e. VarChar) datatype, rather than a number. For instance..

Many parcel datasets also contain odd prefixes and suffixes that further distinguish less common property types. Consider a parcel of land with a mobile home on it. The parcel itself may have a "normal" parcel number (relative to that dataset), but the mobile home located on that parcel may also have a parcel number, one that perhaps starts or ends with a letter M to distinguish it as a unique property type. So when you are trying to understand a new parcel dataset, you should comb through the records and look for weirdos among the parcel numbers. In my experience, mobile homes tend to be the most commonly occurring weirdos, but I expect there are other varieties of weirdo, like Easements, or water-based "improvements" like ..houseboats, private docks? Etc.

One last caveat about these "weirdo types" ..when I have seen them, the oddball prefix or suffix values have a tendency to be the ONE parcel number component part that might not be mapped back to a field/column in the CAMA database. Why this happens I don't know, because it's a terrible way to categorize a record. So the emphasis here is this—expect some strangeness lurking among parcel numbers.

Now. Something Consistent About Most Parcel Datasets

With the context I provided above, there is one thing you can look for that tends to appear in most/all of these parcel datasets—a fully-assembled parcel number. Let's call it a "pre-cooked" parcel number. Like I mentioned earlier, on paper most parcel numbers include a variety of dashes - or dots . delimiting the number parts, but in a database (DB), since it's inefficient to require the DB to continuously build together parcel numbers from their component parts (i.e. string concatenation), most/all CAMA designers include at least one field in the table that contains a fully-assembled parcel number. Sometimes you also have a fully-assembled parcel number complete with its dashes - and dots . ..we call this a "formatted" parcel number. Obviously then, the parcel number without dashes and dots is an "unformatted" parcel number. In situations where a dataset has just one or the other, 90% of the time they will have an unformatted parcel number field.

Now let's apply this knowledge.. When I'm looking through parcel data, like the record you provided, I tend to look for a field with consistently-long values that appear to correspond to smaller values found in other fields throughout the record. If you reconsider the parcel number I presented earlier, then, I would notice 175022004003006005 in a column of similarly-long values, and that's hint #1, mostly because it's just a long value—think about it, what normal thing would a number like that describe? ..particularly if it has a column name like pin? :) Next, I would look at other field values within this record, I would particularly scan for 004, 003, 006, and 005, and if I find them, like I would expect to, then I think, "okay that's probably the parcel number field".

And that was exactly how I evaluated your data. When I spotted a relatively-long value that included parts of other values ..particularly when it's called pin, or maybe, pnum, etc., I figured that was it. That said, your blocklot value is also the parcel number, but it is the formatted parcel number (the format in this case being the space between the values). When in doubt, I prioritize the field with the unformatted value. Finally, that tag value is interesting ..at first, honestly, I expected that to be the parcel number because it is the longest value in the record; however, when I realized the numbers in tag did not appear elsewhere in the record, I disregarded it. FWIW, I wouldn't be shocked if you said the actual APN is tag + pin, but if someone were to make me bet on it, going on this one lone record from the dataset, I'd bet tag represents something else ..in fact, just hazarding a wild-@$$ educated guess, it might stand for "tax appraisal group", in which case it's a value that groups this parcel into a block of similar parcels for appraisal disputes and/or comparative sales research.

Welcome to parcel numbers! Ciao :)

  • @elbrobis I am building another startup up based on parcel boundaries. I think your expertise could help alot & partner. can you send me an email? jeryl.cook@vanity-soft.com.
    – Jeryl Cook
    Nov 21 '17 at 12:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.