Eastern Mass Group Forum

Paper parcels?

  • 16 Mar 2012 11:05 AM
    Quote
    Message # 860719
    Todd Consentino

    Hi,

    I'm looking for some info/advice on paper parcels.  Here's Belmont's situation:

    Belmont formats MAP_PAR_ID as MAP_BLOCK_LOT, for example, 29_68_C.

    Belmont formats PROP_ID as (MAP_PAR_ID)_UNIT, for example, 29_68_C_2.

    If there are two condos on the property, then they would be assigned PROP_IDs of 29_68_C_2 & 29_68_C_4, ideally.  In reality, if these are affordable housing units, the LOT component is overwritten in CAMA with an X, for example, 29_68_C_2 is exported from the CAMA database as 29_68_X_2.  This does not jive well with our geometry. 

    There happens to be another physical parcel named 29-68-B, with affordable housing condos.  It has a record of 29_68_X_1.  So, now it looks like 29_68_X_1 & 29_68_X_2 should live on the same piece of geometry, right?

    Belmont also has "floating" parcels.  Meaning, there are a few high rise condo units with hundreds of condos in them.  The MAP_BLOCK_LOT assigned to each of these parcels does not match any MAP_BLOCK_LOT in our geometry.  It's as if the BLOCK field has been ommitted and the record exists as MAP_LOT_UNIT, instead of MAP_BLOCK_LOT.  For example, 39_49_1 doesn't exist on a map.  39_28 does exist as the master parcel.  This floating parcel should be 39_28_49_1.

    So, I run a script that replaces the MAP_PAR_ID exported from our CAMA with the MAP_PAR_ID associated with the geometry for these records.  Once I've joined the CAMA data to my geometry and stacked the parcels, I then run a script to update the LOC_ID (X_Y) field.  It works, but it's inconvenient.

    In all, 4.5% of Belmont's parcel records do not automatically resolve to parcel geometry, by default.

    So, at long last, are my questions:

    1. Do your municipalities experience paper parcels, too?

    2. If so, then how do you deal with them?

    3. Is unreasonable to expect to match a CAMA ParcelID to a GIS ParcelID without manipulating the data?

    All input is greatly appreciated.

    Best,

    Todd

    Last modified: 16 Mar 2012 11:58 AM | Todd Consentino
  • 19 Mar 2012 8:48 AM
    Quote
    Reply # 862878 on 860719
    Adam Kurowski (Administrator)
    In Arlington, we have a lot of "floating" parcels.  When a multi-family residential is condo-ized or in most multi-unit apartment instances, each unit's Map Lot Block has been changed in the assessor database to a number that does not match the land parcel id.  The new Map Lot Block number represents a unique id specific to that unit/address.  Of course there are always exceptions.

    To improve my ability to match the assessor data to my GIS parcels, I have developed my address points (closest thing I have to a Master Address Table) to act as a translation table.  I theory, I will have a point for every address and unit. Each point will have a Map Lot Block number as in the assessor database AND the Map Lot Block of the land parcel it sits on.  I call this field "ParcelLink." This allows me to Relate my my address points with assessor join, to my parcels.  Probably not the best solution, but it works.  Also, I do not have stacked parcels, so I am trying to match one parcel to many assessor records.  However, stacked parcels are probably in my near future, especially once we implement PeopleGIS this spring/summer.

    In the future, I hope that our assessor will keep the same Map Block Lot for all units as the parcel they sit on, but use the Tax Bill ID as a unique ID for each unit.  Any thoughts on this approach?

    Adam
  • 20 Mar 2012 3:39 PM
    Quote
    Reply # 864300 on 860719
    Christopher Nelson (Administrator)
    First off: Woof.  The sound a dog makes when he tries to swallow the mess you've just described.

    Bedford assessors might have many quirks, but they format all their condo IDs as MAP_PAR_ID-UNIT, so it's easy to tell what condo is part of what parcel.  To me that seems pretty necessary.

    Trying to match condo IDs with GIS parcel IDs has always been a pain for me.  It's been easier now that we have (shameless plug) PeopleGIS's products, which necessitated a Master Address Table.  My MAT is a point shapefile where each address contains a unique CAMA ID to tie it to the assessors records, and a unique parcel id to tie it to the GIS parcel shapefile (in my case, the GIS ID is just the assessors MAP_PAR_ID, except for condos).  It's essentially a MAT and an intersection table in one.

    Creating a MAT is a pain, but as far as I'm concerned it pretty much eliminates the condo headache.  Well, assuming a sane formatting approach...

    Hope this helps!
  • 23 Mar 2012 12:06 PM
    Quote
    Reply # 866856 on 860719
    Todd Consentino
    Thank you for the replies.  Re-reading this thread a few times made me realize my need for a more pro-active approach.  I'm 7 pages in to creating a document that examines all of the floating parcels, what their uses are, how they are currently manipulated to correspond to a valid GIS MAP_PAR_ID, and a recommended permanent solution for each record, such as create a new GIS parcel or modify the CAMA record.  It's my hope that by clearly documenting this process, GIS and CAMA may grow to live in perfect harmony.  I'll let you know how it goes.
  • 26 Mar 2012 10:24 AM
    Quote
    Reply # 868577 on 860719
    Christopher Nelson (Administrator)
    I can definitely suggest keeping track of the decisions you and the Assessors make for each record / mismatch.  I've documented everything I did when I cleaned up Bedford's parcels, providing documentation listing all the agreements we made, and had the assessors come back later and ask why this record was a certain way or ask to change something.  Each time I dug up the decision we made and showed them why we made it, and they were fine with it.  I have a database of all the changes I've made, as well as the "official documentation" showing the reason behind the change and who it was sent to.  Lots of CYA, but it's worked well so far.

    Best of luck to you!
 

NEURISA serves Connecticut, New Hampshire, Maine, Massachusetts, Rhode Island and Vermont.
NEURISA is a not-for-profit [501(c)(6)] professional organization incorporated in Massachusetts.
NEURISA Privacy Policy | Contact NEURISA

Powered by Wild Apricot Membership Software