(12) United States Patent
`Klein
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,092,957 B2
`Aug. 15, 2006
`
`US007092957B2
`
`(54) COMPUTERIZED NATIONAL ONLINE
`PARCEL-LEVEL MAP DATA PORTAL
`
`(75)
`
`Inventor: Dennis Klein, Mill Valley, CA (US)
`
`(73) Assignee: Boundary Solutions Incorporated,
`Mm Valley’ CA (US)
`
`( * ) Notice;
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 417 days.
`
`(21) APP1- N0-3 10/347:1 02
`.
`F1199?
`
`J311- 17: 2003
`
`(22)
`
`(65)
`
`Prior Publication Data
`US 2003/0140064 A1
`Jul. 24, 2003
`
`Related U.s. Application Data
`t
`.
`t
`.
`(60) Prowslonal apphcanon N0 60/353>656= filed on Jan
`18> 2002
`
`(51)
`
`Int‘ C1‘
`(200601)
`G06F 7/00
`(200601)
`G01 C 21/34
`(52) U.S. Cl.
`........................ .. 707/102; 707/4; 707/100;
`707/103 R3 707/104-13 701/214
`Of Classification Search ................ ..
`707/100, 104~1, 102, 103 R, 200; 701/200,
`701/202, 207, 208, 209, 123: 1, 29: 214;
`379/8817
`S99 aPP119a11011 1119 for 90111131919 5931911 11151013‘
`References Cited
`U.S. PATENT DOCUMENTS
`
`(56)
`
`......... .. 701/200
`9/1996 DeL0rme et al.
`5,559,707 A *
`8/1999 Gehani etal.
`.............. .. 707/10
`5,946,687 A *
`5,968,109 A * 10/1999 Isranietal.
`.............. .. 701/208
`6,263,343 B1*
`7/2001 Hirono .................. .. 707/104.1
`
`. . . . . . .
`10/2001 Israni et a1.
`6,308,177 B1 *
`6,498,982 B1 * 12/2002 Bellesfield et a1.
`6,529,824 B1 *
`3/2003 Obradovich et al.
`
`
`. . . .. 707/100
`....... .. 701/202
`...... .. 701/208
`
`6,539,080 B1*
`6,591,270 B1 *
`
`........... .. 379/88.17
`3/2003 Bruce et al.
`7/2003 White ...................... .. 707/101
`
`OTHER PUBLICATIONS
`Andre Frank, Data Base query Language for retrieval of geometric
`Data and their graphical representation, 1982, ACM Press, pp.
`199-20771
`
`(Continued)
`
`Primary Examiner—Shahid Alarn
`Assistant Examiner—Fred 1. Ehichioya
`(74) Attorney, Agent, or Firm—Lawrence Edelman
`
`(57)
`
`ABSTRACT
`
`,
`,
`,
`A National Online Parcel-Level Map Data Portal (NPDP) is
`PF?1V11f1e91:1g1at01§imiZf3S 0n1Tin«=ede11i1Vieryh0fIrI2r)r]c)«=r1)-level maps
`an
`i
`e
`attri ute
`ata.
`o
`o t
`s, t e
`manages a
`database of assembled and current vector based parcel data
`in a spatial format
`(GIS) that enables geocoded parcel
`boundaries to be linked to property tax records. A user enters
`a street address into an appropriate screen window to call up
`and View road right-of-ways, all parcel boundaries and the
`“exact” address location as a highlighted parcel area. In
`addition, a list of property record attributes such as Owner,
`use code, assessed value and year constructed can be dis-
`other 011 screen parcels can likewise be selected
`one wishes to View their linked attributes. Subscribers may
`customize the NPDP to perform a variety of spatial analysis/
`reporting functions. Under public/private alliances, agree-
`ments are negotiated with individual property assessor’s
`offices whereby they receive a portion of NPDP service
`provider revenue in return for parcel map database updates.
`Such on-going commerce between data sponsors and the
`NPDP service provider is utilized to assure a sustained and
`ex andin flew erinereasin 1 Com etem Cement
`1’
`g
`gy
`1’
`
`‘
`
`19 Claims, 11 Drawing Sheets
`
`103
`1
`JURISDICTION NOT
`FOUND IN PICKLIST
`
`DESIRED STREE1
`ADDRESS DEFINED
`I
`101
`
`NPDP Standard Fealureopsranon
`(Enter-an-Mdres:-Display-SIIrmurhiIng~PaIDeI-MaD)
`102
`
`(SEARCH NPDP
`JURISDICTION
`room, TABLE
`
`
`
`MATCHING
`"pp?
`
`m.3Dm.oN
`
`
`
`JLT
`
`104
`SEARCH PARCEL
`r
`RECORD DBMS ma
`MATCHINGADDRESS
`
`PRAD105
`I
`No PZEEEISSET
`NUMBER
`ENERED
`100
`I
`
`—
`
`NPDP SERVER
`
`MATCHING
`FARCELA1'|'RIBUTE
`REOORD
`YES
`10,
`r
`courrrv FIFS NUMBER
`AND AFN usED TO FIND
`MATCHING PARCEL
`
`°
`103 »- PGB:eE}rg%1ég|iREV
`RETRIEVAL AREA
`109 ’“ RETRIEVAL AREA
`
`INTERSECTED WITHUSA COUNTV MAP
`FORADDITIONAL
`JURISDICTIONS
`
`105
`I
`ALL I=ARcELs WITHIN ZIP
`CODE DIsI=LAv WITHOUT
`LINKED PARCEL RECORD
`111 A ALLSELECTED PARCELS
`RECORD DIsI=LAvED
`AND LINKED PARCEL
`
`110
`I
`ALL PARCELS IN
`ADDED TO SELECTION sEr
`ADJACENT JURSISDICTION
`YES
`’
`
`INTERSECTSADDITIONAL
`JURISDICTION
`
`
`
`
`No
`
`Page 1 of 22
`
`CORELOGIC EXHIBIT 1001
`
`

`
`US 7,092,957 B2
`Page 2
`
`OTHER PUBLICATIONS
`
`Alan C. Richter, Geo-coding- an application in a local governmental
`information system, 1968, ACM, pp. 117-131.*
`Shashi Shekhar et al., Data Models in geographic information
`stsyems, Apr. 1997, ACM, pp. 103-111.*
`Andre Frank, Map Query, ACM 1982, pp. 199-207.*
`Kasturi et al., Information Extraction from Images of Paper-Based
`Maps, IEEE 1988, pp. 671-675.*
`Kasturi et al., Map Data Processing in Geographic Information
`Systems, IEEE 1989, pp. 10-21.*
`Becker et al., Spatial Priority Search: An Access Technique for
`Scaleless Maps, ACM 1991, pp. 128-137.*
`Shibata et al., Current Status and Future Plans for Digital Map
`Databases in Japan, IEEE 1993, pp. 29-33.*
`
`Han et al., Construction of Multimedia Map Database Using Urban
`City Images, IEEE$ 2001, pp. 325-328*
`Claussen et al., Status and Directions of Digital Map Databases in
`Europe, IEEE 1993, pp. 25-28*
`Roman Gruia-Catlin, Formal Specification of Geographic Data
`Processing Requirements, IEEE 1990, pp. 370380.*
`Arcieri et al., Italian Cadestral Information System: A real-life
`spatio-tempoaral DBMS, 1999, STDBM’99, LNCS 1678, pp.
`79-99.*
`Werner Kuhn et al., National Center for Geographic Information
`and Analysis, 1991, NCGIA, pp. 1-44.*
`University of Massachusetts, Parcel Mapping Using GIS, 1999,
`Commonwealth of Massachusetts, pp. 1-103?‘
`
`* cited by examiner
`
`Page 2 of 22
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 1 of 11
`
`Us 7,092,957 B2
`
`
`
`
`
`
`
`
`
`s_§w<a>>O._n_zémommwzo_._.<mwn_On_n_n_zV.O_n_
`
`mo<u_~m:z_Em:
`
`
`
`
`
`nEn_zI._._>>
`
`Bn_om>moE<_§oomes).
`
`
`
`228“.E225n_on_z.m_
`
`
`
`
`
`V#50:mmw
`
`cozsmaoa$28.28
`
`m_mm_~_owm:m
`
`
`
`8m<n_z<5n_Ez
`
`
`
`
`
`><._n_m_oE8n=Nz=:._>>m._mom_<n_._._<
`
`
`
`
`
`Eoommdog».8%:501:;
`
`
`
`BzzmammwafiEmmaBgwmo
`
`
`
`
`
`
`
`
`
`8%:n_z<mdomé853%._._<
`
`
`
`
`
`8><._%aEoomx._momE
`
`
`
`
`
`m_mE<E2058._<_._.<n_m
`
`._<_._.<n_m
`
`oz_mmmooE
`
`
`
`><._n_w_n_58$.
`
`
`
`
`
`>Ezm_zo_5:Emz_oz_mm_ooE
`
`
`
`
`
`8:980Eamfl28.5wnamz_<
`
`NmmsozHa
`
`oz_:E<s_
`
`
`
`m5m_m_._.._.<._mom_<n_
`
`Eoomm
`
`
`
`E8....=N._.zmz:.mmn_
`
`emzzm~_mms5z
`
`
`
`
`
`n_m_o<o._<._.<oBmmomo<_.<n_
`
`
`
`
`
`nEn_zo»z_mohmaozmsn.EOE
`
`
`
`mohmmo_._m:n_
`
`
`
`<._.<o$o_>oE
`
`55%ozmi
`
`
`
`m:<n_%mmo_>oE
`
`Em__5mm:m
`
`Emsfiomzm
`
`
`
`co_.m=.ao8cm:oE_m_>_w:o___m_=co<Eman_on_z.o
`
`
`
`
`
`mE8:mum
`
`Bmézfim
`
`
`
`8m<IwwEoEnEn_zu_ozO_._.mon_
`
`
`
`
`
`mmowzomw<.—<n__._._._>>5%
`
`Page 3 of 22
`
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 2 of 11
`
`Us 7,092,957 B2
`
`FIG. 2
`
`NPDP Standard Feature Operation
`(Enter-an-Address-Display-Surrounding-Parcel-Map)
`
`NO
`
`
`
`MATCHING
`NPDP
`JURISDICTION
`
`YES
`
`104
`
`102
`
` SEARCH NPDP
`
`JURISDICTION
`LOOKUP TABLE
`
`
`
`
`PRAD
`
`
`
`SEARCH PARCEL
`RECORD DBMS FOR
`MATCHING ADDRESS
`
`
`
`103
`
`JURISDICTION NOT
`
`FOUND IN PICKLIST
`
`DESIRED STREET
`
`ADDRESS DEFINED
`
`101
`
`105
`
`
`107
`MATCHING PARCEL
`
`COUNTY FIPS NUMBER
`AND APN USED TO FIND
`
`
`
`
`
`0 RECORD DISPLAYED
`
`NPDP SERVER
`
`110
`
`
`
`
`ALL PARCELS IN
`.
`ADJACENT JURSISDICTION
`
`ADDED TO SELECTION SET
`
`PARCEL BOUNDRY
`
`USED TO DEFINE
`
`RETRIEVAL AREA
`
`
`
`
`
`RETRIEVAL AREA
`
`
`INTERSECTS
`INTERSECTED WITH
`ADDITIONAL
`USA COUNTY MAP
`
` FOR ADDITIONAL JURISDICTION
`
`JURISDICTIONS
`
`NO
`
`103
`
`109
`
`USACM
`
`Page 4 of 22
`
`ALL PARCELS WITHIN ZIP
`CODE DISPLAY WITHOUT
`LINKED PARCEL RECORD
`
`I II
`
`ALL SELECTED PARCELS
`AND LINKED PARCEL
`
`105
`
`PERTINENT
`
`
`
`MATCHING
`N0
`ZIP CODE
`PARCEL ATTRIBUTE
`NUMBER
`RECORD
`ENTERED
`
`
`
`
`
`
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 3 of 11
`
`Us 7,092,957 B2
`
`USA County Boundary Map (USACM)
`for Retrieving Parcel Data From Multiple Counties
`
`USA County
`Boundary Map
`(USACM)
`
`
`
`
`.
`B°;g:'n9
`
`\ FIPS
`/ Numbers
`
`Page 5 of 22
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 4 of 11
`
`Us 7,092,957 B2
`
`
`
`
`
`EmEQo_m>mowco=mo__qq<E0630
`
`wow
`
`
`
`oz_mmm_oom_n_._<_._.<n_w
`
`
`
`><._n_m_oSsmmm
`
`_.oN
`
`mom
`
`
`
`_n_<n_n_n_z
`
`»zm_s_n_od>m_o
`
`
`
`_n_<n_n_n_2
`
`8N
`
`mmmaommam
`
`Hzmzjomzm
`
`
`
`Em:mmmaommsm
`
`m_o<n_~m:z_
`
`
`
`.mmE<m:_>_O._.mD0
`
`>Ezmzo:o:Emz_
`
`Now
`
`EN
`
`V.O_n_
`
`Sm
`
`mom
`
`wow
`
`mzo_5:Emz_
`
`._<>m_Ema
`
`
`
`><.#_m_o<55
`
`
`domiom_>m__Emm
`oz_mmm_oomn_-4<:<n_m-
`
`
`
`mm_>mm_mnaaz
`
`2:
`
`Page 6 of 22
`
`
`
`
`
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 5 of 11
`
`Us 7,092,957 B2
`
`
`
`
`
`Efimoimocm:mE_ms_cam:o:_m_:co<San.n_n_n_zm.O_n_
`
`
`
`
`
`mom
`
`mm>
`
`
`
`n_n_n_zI._._>>
`
`
`
`mom<oz<._.w
`
`
`
`»z<:n_s_oomo<s_
`
`OZ
`
`<»<o
`
`
`
`I._._>>._.Z<_._n=>_OO
`
`mom_<oz<5.En_z
`
`oo_.
`
`
`
`«m_>~m_mn_n_n_2
`
`Sm
`
`
`
`nmaofi<._.<Q
`
`naazO._.z_
`
`Sm
`
`mom
`
`
`
`mohmmo_._m5n_
`
`<29mm_o_>oE
`
`mom
`
`
`
`mopommo_._m:n_
`
`
`
`mm:<on5mmo_>oE
`
`
`
`
`
`mokommo:m5n_s_oE
`
`ommmomo<53
`
`Page 7 of 22
`
`mom
`
`
`
`mEoEn_Ezmozo_Eo¢
`
`
`
`_.E>>xo<m8m<:m
`
`mmomzona<20
`
`
`
`
`
`
`
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 6 of 11
`
`Us 7,092,957 B2
`
`FIG. 6
`
`Standard NPDP Address Match Feature
`
`(Enter-an-Address-Retrieve-a-Parcel Map-and-Linked Attribute List)
`
`-
`
`~
`
`'
`~
`=
`Reque-s_ted
`" Add rcss Displays i
`In CEMBY 07
`Parce|—Lev
`
`Result of
`Selecting state,
`city, street
`Name 8: Number
`
`5
`
`,
`
`,
`
`=
`
`.,
`‘
`Q
`
`1
`
`,
`
`Metadata
`Listing
`Descri bcs
`Data Quality
`W,
`
`Page 8 of 22
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 7 of 11
`
`Us 7,092,957 B2
`
`FIG. 7A
`Spatial Query using a Boolean Argument Across Multiple Attribute Fields
`
`.4.’
`
`lllll
`
`llllllla‘-E §=f:l,“.'llli£lllilll.l§‘§:
`,\
`g
`:;.&.i3:|!I!lLY|\\:é%!g
`.4
`{IE illlfilfllkfi ‘,',',‘{?.3iii§ii§‘.‘.’.“'.. Efifiraaxa ,
`'J“-'-
`151112315191 1;,
`l
`1I§ii‘ii[i]i:s:Iii}§s:t-12": 3'
`%
`»
`it ma
`‘nil
`"' '59» {NH _-5
`
`_
`
`V;
`
`l uminim!
`ultlbilllflxl
`- ,
`an,
`.
`:-.:';:;::,;r:cҤ .,
`5‘: 4I:::1ltxl' -0
`
`§.;|w.i.m:
`
`f'‘’‘'.
`
`Page 9 of 22
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 8 of 11
`
`Us 7,092,957 B2
`
`FIG. 7B
`
`Thematic Mapping on a Single Attribute Field Value
`
`’
`
`.
`
`-
`‘
`é$§,5,‘§[£
`
`,
`
`QIIKIIIIII
`minim-
`
`3 mmnlllin
`Ell
`Itmllllfll
`IIIIIIIIFIIE
`'
`_
`1
`ms
`W %=:.,
`’
`'
`3
`n
`=
`a- w-
`Etttta ‘
`Iallll ‘
`
`%_
`
`ii Illllllllnlliu --
`illlltlltltfimfijg
`ragvgfillll, mun II
`{ aumm
`
`=
`
`' lfllliiiilll
`lumlllllll
`
`Page 10 of 22
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 9 of 11
`
`Us 7,092,957 B2
`
`FIG. 7C
`
`Comptex Thematic Mapping - Graduated map of feature
`previously selected by query
`
`CUSTOM FEATURE: Assessmentverification
`
`Compare Assessed Value per square foot of Improved Area of all other parcels
`with the same use code to SEE if property you own or are about to purchase is
`over assessed
`
`.::~
`,2 Véfl
`' W
`
`Page 11 of 22
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 10 of 11
`
`Us 7,092,957 B2
`
`FIG. 7D
`
`Search & listings of polygonslpoint-in-poiygon (within, crossing, touching)
`
`More Accurate Due Diligence
`
`Street Centerline Based VS. Parcel Based Environmental Due Diligence
`
`
`
`Parcels Found Using Industry Standard Search Methods
`Contaminated Parcels Possibly Missed Using Industry Standard Search Methods
`
`Page 12 of 22
`
`

`
`U.S. Patent
`
`Aug. 15,2006
`
`Sheet 11 of 11
`
`Us 7,092,957 B2
`
`FIG. 8
`
`NPDP Business Relationships
`
`404
`
`402
`
`403
`
`
`
`
`SERVICE
`INTERNAL
`SUBSCRIBER
`USER
`
`
`
`
`EXTERNAL
`USER
`
`400
`
`
`
`NPDP
`SERVICE PROVIDER
`
`
`
`
`
`SPECIALIZE
`CONTENT
`PROVIDER
`
` DATA SPONSOR 401
`
`Page 13 of 22
`
`

`
`US 7,092,957 B2
`
`1
`COMPUTERIZED NATIONAL ONLINE
`PARCEL-LEVEL MAP DATA PORTAL
`
`This application claims priority to U.S. Provisional Appli-
`cation Ser. No. 60/353,656 entitled Computerized National
`Online Parcel-Level Map Data Portal, filed Jan. 18, 2002.
`
`5
`
`BACKGROUND OF INVENTION
`
`2
`
`The NPDP can be customized by service subscribers of
`the NPDP for their own subscribers/users to perform a
`variety of spatial analysis/reporting functions.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a flow diagram showing actions required to
`establish and maintain the NPDP.
`
`Up until now, GIS (Geographic Information System)
`basemaps have been based on a national street centerline
`map originally produced by the federal government in the
`’70s. Today, there is a need for the additional detail, accu-
`racy and currency possible only from parcel-level map data.
`Though hundreds of local governments have finished digi-
`tizing their parcel maps, a single national parcel map source
`(portal) does not exist. The National Online Parcel-Level
`Map Data Portal (NPDP) remedies this problem by provid-
`ing the first national repository of parcel data for use by all
`industry sectors. Potential NPDP subscribers include title
`companies, property insurance companies, major
`land
`developers, retail, hotel, and restaurant chains, utility engi-
`neers, environmental consultants, government agencies such
`as FEMA, and a wide variety of location based service
`subscribers desiring the greater accuracy, detail and cur-
`rency of parcel-level map data.
`
`SUMMARY OF THE INVENTION
`
`To build the NPDP, a parcel-level digital database of
`urban jurisdictions must first be assembled. More than 70%
`of the major American metropolitan areas have so far
`completed digital parcel-level map databases, and are will-
`ing to share them with industry. Under a wide range of terms
`and conditions, this data can be acquired and loaded into a
`centralized server system consisting of one or more server
`computers, the data normalized to a standard format.
`In the data collection phase, each local agency is asked to
`provide a standard release to allow the use of their spatial
`data. As needed, negotiations can be conducted to assure the
`unconstrained use of such data on the NPDP server system.
`An outreach program can be maintained by the NPDP to
`encourage release of spatial-level data by sponsoring agen-
`cies and to add this data to the NPDP as it becomes available.
`
`As required, individual property assessor’s offices of local
`governments can be paid data update fees in return for
`electronic copies of all changes to their agency’s electronic
`parcel map database.
`The collected GIS content added to the NPDP graphic
`database is an assemblage of current vector-based parcel
`map data stored in an online GIS format in which parcel
`boundaries and geocodes are linked to a non-graphic data-
`base of property tax records.
`An end user, utilizing an assigned password, begins the
`NPDP process by logging on from a computer terminal to an
`intranet or intemet start page of the NPDP, and enters the
`state, city, street and number of a desired address. The NPDP
`address database is searched for a matching tax record. If
`there is a match, the NPDP displays the road right-of-ways,
`all parcel boundaries within a select distance, the “exact”
`address location highlighted, the pertinent parcel polygon
`changing the color to a brighter or different color from
`surrounding parcels also displayed. In addition, a list of
`property record attributes such as owner, use code, assessed
`value and year constructed can be displayed for the selected
`parcel. Other displayed parcels can also be selected and their
`linked attributes viewed.
`
`10
`
`15
`
`FIG. 2 is a more detailed description of the NPDP
`standard feature operation.
`FIG. 3 is a USA county map used as spatial index for
`retrieving GIS map data from multiple counties.
`FIG. 4 depicts a custom application development pro-
`gram.
`FIG. 5 depicts a NPDP data acquisition and maintenance
`program.
`FIG. 6 is a screen display of a standard NPDP address
`match feature.
`
`FIGS. 7A—7D are exemplary screen displays of custom
`NPDP functions.
`
`20
`
`FIG. 8 depicts the inter-relationships of the various parties
`utilizing the NPDP.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`The following definition of terms will be used throughout
`in the discussion of the invention, but should not be con-
`sidered limiting thereof. Reference is made to FIG. 8 in
`connection with these definitions to better illustrate the
`
`interrelationships between the various parties.
`NPDP: National Online Parcel-Level Map Data Portal, an
`internet warehouse that optimizes online delivery of parcel-
`level maps and linked attribute data.
`NPDP Service Provider (400): The entity that establishes
`and maintains the NPDP internet warehouse, collects data,
`updates the databases, enters into arrangements with data
`sponsors, and service subscribers, and develops specialized
`applications for service subscribers.
`Data Sponsor (401): A local governmental entity, be it at
`the city, county or other geopolitical level which provides
`electronic parcel maps for use with the NPDP, as well as
`private entities who are sources of specialized spatial data
`and/or maintainers of private databases.
`Service Subscriber (402): That entity which links to the
`NPDP internet warehouse, having subscribed to the service
`made available by the NPDP service provider. The service
`subscriber may provide access to the NPDP to its in-house
`staff and to third parties which may separately subscribe to
`the services offered. In addition, the service subscriber may
`develop it own customized data services (with or without the
`assistance of the NPDP service provider) to apply the NPDP
`database to its special needs.
`User (alternatively, End User): The service subscriber’s
`internal users (403) who from a computer terminal visit the
`service subscriber’s provided intranet site, or its external
`users (404) who electronically access the NPDP over the
`internet. These end users may access for free, for a sub-
`scription fee, or on a per transaction basis depending upon
`the modality of access, and the program and features being
`made available by the service subscriber. End users may also
`access the NPDP directly as individual subscribers.
`Specialized Content Provider (405): A third party provider
`of layers of information used to supplement geographic
`information. Through various business arrangements, com-
`panies and organizations that specialize in providing these
`specific data layers on CDs and online enable end-users to
`
`Page 14 of 22
`
`

`
`US 7,092,957 B2
`
`3
`View and/or attain tl1e parcel layer from the NPDP server
`on-the-fly and/or by downloads and CDs.
`The data structures within the NPDP follow common
`
`industry standard spatial data specifications as described
`below relative to the discussion of the basic data structure.
`
`5
`
`The overall operation of the national parcel-level map data
`portal consists of two different components. The first, NPDP
`warehousing,
`is the gathering and storing of parcel-level
`map data from multiple sources formatted to a single pro-
`tocol suitable for online access and use. The second is the
`
`creation of NPDP application programming interfaces
`(API), a set of basic and custom spatial transactions per-
`formed by NPDP service subscribers to support their work
`processes.
`
`Basic Data Structure
`
`Parcel-level GIS is a mature technology. Industry stan-
`dards have emerged over the years until an almost universal
`spatial data structure for property ownership maps has
`evolved. According to this spatial data structure, the end
`points of each segment of a parcel boundary segment are
`assigned identical XY coordinates as the end points of other
`boundary segments that start or stop at each of its end points.
`As a result, there are no gaps or overshoots, thus defining
`each parcel by an area surrounded by a “closed” polygon
`made up of such boundary segments. Each segment
`is
`encoded with its parcel’s unique identification number,
`commonly known as the Assessor’s Parcel Number (APN).
`A parcel boundary segment that is common to two parcels is
`assigned two APN’s, one for the parcel to the right of the line
`segment (relative to its direction from its start point to its end
`point) and one for the parcel to the left of the line segment.
`The geocode value of the boundaries of the parcel’s
`polygon is assigned the same Assessor’s Parcel Number
`(APN) as the number assigned to the parcel in the indexing
`field of the Assessor’s supporting tax record system. The
`parcel’s tax record contains data based on the assessors’
`rolls. The data is assembled in tables where the columns
`
`represent fields such as owner; year built; assessed value;
`etc, the rows containing the individual parcel data records,
`arranged by field. This non graphic database is associated,
`parcel by parcel, with the graphic database, stored iii the
`form of a single DBMS file, the records either generated by
`public providers or by commercial sector sources.
`This configuration of graphic boundary segments and
`textural attribute assignments makes automated search of a
`digital spatial database possible. When a tax record with
`matching address values is found, the APN in the attribute
`table’s index field is used to access the graphic database (all
`the parcel boundary segments) to find all boundary segments
`with this matching geocode. The XY coordinates of the
`vertexes of these boundary segments are used to find all
`other boundaries within a prescribed search radius of the
`matching parcel polygon. All these boundary segments are
`then displayed or1 the computer screen to fon11 the parcel-
`level map. By placing the cursor in another parcel polygon,
`a spatial analysis function (point-in-polygon) determines the
`set of boundaries in which it is located and its APN geocode.
`This value, in turn, is used to access the tax record database,
`find the record with the matching APN number in its index
`field and display the attributes contained in this record on the
`computer screen.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`
`NPDP Warehousing
`
`The digital assemblage of parcel-level databases from all
`the sponsoring agencies is stored in a server system accord-
`ing to a standard protocol. The process begins with the
`acquiring of the raw parcel-level data from various data
`sponsors. In most
`instances,
`the desired data is usually
`limited to the agency’s parcel boundaries and “geocode”.
`This geocode makes it possible to associate a parcel’s tax
`record (a flat text string within a data table) to the parcel
`boundary as an extended set of parcel attributes. All spatial
`data files are stored in a single location according to a single
`indexing scheme where:
`parcel and street overlays are given the same theme name
`indexing fields link the boundary to an attribute record
`given attribute name
`all features are given the same color, line font and naming
`conventions
`
`street armotations are provided in theme size and orien-
`tation of text
`
`view names are given a consistent naming convention.
`Each incoming file is processed as needed to adopt it
`according to this protocol. Those files that require a pro-
`hibitive level of processing are set aside, their sponsors
`notified of the shortcoming and encouraged to modify their
`procedures so that the resulting data files can be made
`compatible with NPDP protocols.
`
`NPDP Operations
`
`In one embodiment, with license from the NPDP service
`provider, the service subscriber is assigned a number of
`passwords that enables users designated by the subscriber to
`perfomi both basic fimctions (as next described) and custom
`functions. The service subscriber can in mm establish a site
`
`for internal use by its employees/member companies (inter-
`nal end users). In another embodiment, the service sub-
`scriber can by way of the intemet make the NPDP available
`to third party subscribers (external end users) as a function-
`ality to be included as part of a general subscription fee, as
`a special feature requiring additional fee, on an “as used”
`basis or some combination of these revenue generating
`options.
`
`Basic Functions
`
`In an embodiment of the invention, as part of the basic
`filnction, an end user seeking only a subset of parcel-level
`data, enters a street address including the city, state, street
`name and/or the number of the desired parcel into a window
`displayed on a computer screen. According to the state
`entered, a folder is electronically accessed containing all
`spatial data files for that state including supporting tax
`record databases for each agency for which there is stored
`spatial data.
`If there is an address match, the pertinent parcel displays
`as a highlighted polygon in the center of the screen along
`with surrounding parcels. In addition, the parcel’s linked tax
`record is displayed. Also, a metadata record describing the
`quality of the data set can be displayed to inform the
`subscriber of the relative quality of the data. The subscriber
`can pan and zoom and/or select other visible parcels to view
`their linked tax records. Alternatively, subscribers can use
`the cursor to select groups of parcels and see tax records in
`a tabular report.
`If data is available for the desired jurisdiction but there is
`no address match, the subscriber is notified with a message,
`
`Page 15 of 22
`
`

`
`US 7,092,957 B2
`
`5
`such as “No address match found.” The user may be further
`prompted: “Would you like to View all parcels in Zip Code?”
`If the user answers no, the transaction ends. If the user
`answers yes, all parcels in the pertinent zip code area are
`displayed. The user can then zoom up to View the specific
`area of interest and determine the parcel of interest and by
`using a cursor select various parcels to View linked tax
`records. If there is no data available, the user can be notified
`that “no data is found”.
`
`Custom Functions
`
`In another embodiment, additional, custom functions can
`be provided. These functions are determined according to
`the needs and objectives of the Various service subscribers.
`Each is tailored to the service subscriber’s specific opera-
`tional requirements as negotiated under a “setup” fee paid to
`the NPDP service provider as compensation for both uncon-
`strained access to all NPDP data and the development and
`maintenance of the subscriber’s specialized online GIS
`application requirements.
`Applications uniqucly supported by NPDP for different
`industry segments are Varied. For example, for online loca-
`tors, more accurate address locations are enabled. Yahoo &
`AOL’s MapQuest, Switchboard.com (Online telephone
`book) and Maporarna.com operations can benefit by the
`Vastly improved locational accuracy possible from the use of
`parcel-level data compared to street centerlines. Such sub-
`scribers would not require access to tax records since their
`end users’ only interest is in seeing the parcel boundaries to
`more precisely determine the exact location of an address.
`Thus in the case of AOL type service subscribers,
`the
`“custom” function is actually a stripped down Version of the
`“basic” function,
`i.e. only the parcel boundaries display.
`Linked attribute data does not.
`
`Supported custom functions utilizing the NPDP can
`include title company flood disclosure determinations. A
`polygon-in-polygon application can streamline such flood
`insurance disclosure determinations, as for example whether
`or not a parcel is in the flood zone by determining if its
`boundary is in or crosses a flood zone boundary polygo11. An
`address list of all addresses for which flood insurance
`
`determination is desired is used to retrieve the corresponding
`parcel boundaries and spatially compared to the pertinent
`flood zone polygons to see if it is in, partially in, near or not
`in the flood zone. The resulting finding is written as a
`Value(s) to an automatically generated flood determination
`report. An image of each resulting screen display is captured
`and archived in a storage directory for future reference as
`needed to Verify the above machine generated flood deter-
`mination.
`
`The polygon-in-polygon approach of the NPDP can also
`be used to streamline home and business insurance premium
`rating determinations. Lists of addresses of every home and
`business insurance policy holder within a jurisdiction can be
`used to retrieve each of the corresponding parcel boundary
`polygons. Each of the retrieved polygons is spatially com-
`pared with multiple layers of spatially distributed risk con-
`ditions from which insurance ratings are established. Such
`boundary layers can define fire, fault, flood, tidal wave,
`subsidence, mold and other risk zones for homes and busi-
`nesses. Determinations whether a parcel boundary is in,
`partially in, near or not in any category of such zones is
`written to a database record subsequently used to generate
`rating Values that contributes to the establishing of the price
`and other terms of an insurance policy.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`Utilities can also benefit from having access to NPDP type
`parcel 1naps with displayed attribute data for utility network
`modeling. Specialized applications can include (a) backdrop
`maps which can be used to expedite utility network map-
`ping,
`(b) network demand-generation maps
`in which
`attribute Values such as land use codes, assessed Value and
`year-built of parcels served by a network device are assigned
`to that device to calculate service demand Values that drive
`
`network simulation (design optimization) models, and (c)
`gas line notification in which a buffer around a gas pipeline
`generates a parcel owner listing used to satisfy required
`annual notifications of adjacent land owners.
`The NPDP database can be used by telecommunications
`companies to optimize telecom facility site selections. For
`example, multivariable queries of attributes assigned to all
`parcels in the Vicinity of a new tower site (determined by
`facility optimization application of the service subscriber)
`can be used to identify the parcel in which the optimal tower
`location falls. Owner’s phone numbers assigned to each
`parcel can be used to automatically contact pertinent prop-
`erty owners. Where the number of stories of buildings is
`included in the assigned parcel attribute list, and thus used
`to generate height constraints, line-of-site assessments can
`also easily be conducted.
`In yet another potential NPDP application, state, federal
`and local environmental assessments and compliance can be
`expedited. For example, by using the polygon-in-polygon
`function,
`intersecting parcel boundaries with pollution
`plumes and hazard zones can easily be determined, thus
`streamlining environmental impact analysis and notification.
`With reference to FIG. 7D, hazardous waste locations cur-
`rently displayed as a “dot” (point) are displayed by the
`NPDP as a highlighted parcel instead to improve impact
`assessment accuracy. Finally, a buffer of prescribed distance
`from the parcel’s boundary can be intersected with bound-
`aries of all surrounding parcels. Addresses of all contami-
`nated parcels within or touching the buffer can then be
`written to a report
`that
`includes APN numbers, nearest
`distance from subject parcel, hazardous waste conditions
`present, history and remedial action.
`Still other specialized applications are possible. Without
`intending to be limited, it is further noted that the NPDP can
`help retail, restaurant, and hotel chains with numerous
`locations in major markets greatly enhance existing in-house
`cross-regional facility location applications in the following
`ways:
`(1) Alternative Site Selection. All parcels in the
`Vicinity, neighborhood, community, or region for which a
`new facility is to be sited are subjected to a complex query
`of their assigned attributes to highlight all parcels with
`compliant zoning that are big enough and cheap enough to
`be an alternative candidate site for further consideration (See
`FIG. 7A).
`(2) Site Compatibility Assessment. Thematic
`maps of assessors’ Valuations, year built and use codes
`generated of surrounding areas so candidate sites can be
`evaluated for relative compatibility compared to the other
`surrounding parcels (See FIG. 7B). (3) Over-Assess111ent
`Testing. A thematic map displaying total assessed Value per
`square foot of improved area of surrounding parcels with the
`identical use code of the subject parcel are compared to the
`that assigned to the subject parcel to see if its total assessed
`Value is generally greater, the same or less than that of all
`nearby parcels of the same use code assignment (See FIG.
`7C).
`
`Page 16 of 22
`
`

`
`US 7,092,957 B2
`
`7
`Detailed Description of Specific Methodologies
`
`FIG. 1 provides an overview of the NPDP Development
`and Operations Program. The overall effort to establish and
`maintain the NPDP is broken up into three program devel-
`opment and maintenance components: (A) NPDP Standard
`Feature Operations, (B) NPDP Custom Feature Develop-
`ment & Operations, and (C) NPDP Data Acquisition and
`Maintenance Operations. Each of these operations will now
`be described with reference to FIGS. 2 to 5.
`
`NPDP Standard Feature Operations
`
`FIG. 2 provides a detailed explanation of the individual
`computerized steps involved for the NPDP to automatically
`perform its
`standard feature operation of retrieving a
`requested map area around a parcel based on an entered
`street address. The basic components of the NPDP standard
`feature operations are shown shaded in FIG. 2. FIG. 6 is a
`screen shot of a sample result of an address match.
`The National Parcel-Level Map Data Portal Server
`(NPDP SERVER) 100 is constructed on an industry standard
`internet server platform. As noted before, the center of the
`NPDP design is the placing of each jurisdictional database
`(county, city,
`town,
`township, administrative unit, place
`name, etc.) into an individual directory assigned a name
`equal to the FIPS number (Federal Informatio