Welcome to the documentation of the Teledata person matcher. Here you will find the following:
- An overall non-technical description of how is it working.
- Description of how to use the API for the Teledata person matcher.
- Finally a full description of match codes that gives information about how well a match went.
How is it working?
The teledata person matcher will try to find a person that matches the information provided. If there is not a perfect match it will try to find a person that could be the person requested. The specific matchcode for the matcher will reflect how good a match it was, and what kinds of liberties was taken to find the result.
Teledata person matcher matches on the following domains:
||Personer fra den danske telefonbog (også kaldet §34-data).|
The matching algorithm will handle incorrect spelling and typos in the input in order to find a match. See examples of this in the examples section below.
Using Teledata person matcher API
The API for Teledata person matcher follows the standard API for matchers.
To find a match using Teledata person matcher, you need to make a GET request that looks as follows:
As explained in the general documentation you pass the input to the Teledata person matcher in as the
in_* query string parameters. For Teledata person matcher you can use the following
||Phone number||Supply the phone number.|
||Name||This argument must contain the name of the person.|
||Kvhx||Use this argument if you have the kvhx or kvh. If you supply this, then you can omit the other arguments.|
||Kommune code||If used, this argument must contain the kommune code.|
||Street code||If used, this argument must contain the street code.|
||Stednavn||Stednavn is a town name that is used as part of a Danish address, when the street name of an address appears in multiple towns within the same post code.|
||Address||Use this argument if you have the entire address as a single text string. If you supply this, then you can omit the other arguments.|
||House number||If used, this argument must contain house number and/or letter. The argument can also handle floor/apartment number if this comes after the house number.|
||Street||If used, this argument must contain the street name. The street name can optionally be followed by housenumber/letter and floor/apartment number, but these can also be supplied as seperate arguments if desired.|
||Post code / City||If used, This argument must contain the post code and/or postaldistrikt/town/city name.|
||Apartment||If used, this argument should contain floor, apartment number and/or door specifier.|
If you have the entire address text in a single string, then it would suffice to use
in_adr. Otherwise use the more specific
in_* arguments above to supply the address you want to match.
You can add the following optional arguments as query string parameters:
vars— a comma-seperated list of ids of variables that should be returned in the output. If this is not supplied, all available variables are returned. If you for instance only want the (Danish) variables conzoom type and conzoom group in the response, then append
vars=cnztyp_g5,cnzgrp_g5to the URL. We recommend always specifying the variables you need in the
varsargument, rather than leaving it out.
cat— specifies how values of category variables are returned in the JSON output.
catcan be set to the following values:
id(default) — returns the ID of the category as a string value.
obj— returns the full category object as the value.
coords— specifies how values of point variables are returned in the JSON output.
coordscan be set to the following values:
xy(default) — returns the coordinates in the local UTM zone with an X and Y part.
latlong— returns the coordinates as latitude and longitude pairs using WGS84.
match_vars— Lets you specify which match variables you want to be returned in the match response. This argument can be set to:
main(default) — returns the main variables, which includes generic match variables and any detailed match variables, but not match information variables
all— return all match variables.
match_on— If your matcher has the ability to match on multiple domains, and you only are interested in matching on a specific domain, then you can supply the ID of that domain as a
match_onargument. E.g. if you only want to match on access addresses when using the Swedish Geocoder , then append
match_on=acadrto the query string.
The structure of match response is described here in the general documentation. For specific examples, see the example section below.
If you need to do multiple match requests, you can batch them using a batch request. This works in a very similiar way to the single match request.
The following example will try to match the person named Britt Pedersen on the address Vestergade 22, 8700 Horsens:
https://apps.conzoom.eu/api/v1/match/dk/tele_per?in_name=Britt Pedersen&in_adr=Vestergade 22, 8700 Horsens
The following example will try to match the person named Svend Otto Bryrup with the phonenumber 27326700:
In order to tell how good a match was, or the reason why no match was found, the Teledata person matcher returns the match variables.
A match variable outputs a category, which tells something about how good a match was. Below you can see the categories for the different match variables. Normally you only need to use one of them, unless you are investigating why a particular input is not matching as expected.
Detailed Match Variable
The detailed match variable is defined specifically for the Teledata person matcher. It would for most scenerios suffice to use this.
||Sikker familiematch, måske rigtig person|
||Mere end en person matcher|
Generic Match Variables
The generic match variables has some common categories that are shared among different matchers. These are useful if you are programming generically against different matchers, and want a common way of handling matches.
There is a generic match variable for each domain that is being matched. Therefore, these variables can be useful to inspect if you interested in matches on a particular domain.