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
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
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 :)