In addresses resource, add a value property to a fault record about ols-geocoder HOT 8 CLOSED

I will need to test if this affects the data prep scripts that batch geocode and canonicalize street names for the site vetting process. The scoring logic is dependent on interpreting fault patterns, so it may need to be tweaked. It is possible this could also affect other users that parse out fault details.

from ols-geocoder.

We could make fault values conditional on a request parameter like includeFaultValues:Boolean with a default of false for backward compatibility.

from ols-geocoder.

This is implemented now in my local dev environment, on our next deploy to gazelle we can test the affects on the scripts.

from ols-geocoder.

The FME site candidate fault parsing logic is unaffected by this change

from ols-geocoder.

Presently this change is only output in JSON format - we need to consider if and how we want to output the value in other formats such as CSV and shape. Presently the faults are output in a single field in all other formats, with a structure such as:
LOCALITY.isAlias:1;UNRECOGNIZED.notAllowed:3

I propose a format such as:

Vancouver:LOCALITY.isAlias:1;BACK ALLEY GARBAGE:UNRECOGNIZED.notAllowed:3

It should be noted that any users who are parsing this field from a non-JSON output would potentially be affected by this change. (this includes the FME site candidate logic mentioned above).

from ols-geocoder.

Is there a format that wouldn't require a change to current parsing? Maybe:

Vancouver:LOCALITY.isAlias:1;UNRECOGNIZED.notAllowed:3;Value:BACK ALLEY GARBAGE

from ols-geocoder.

We will not add the "value" field to the fault output in formats other than HTML and JSON at this time. This will ensure we do not cause any backward compatibility issues with these other formats.

from ols-geocoder.

Validated in Geocoder 4.1-Gold (DLV) in JSON, HTML, XHTML for "1175 Douglas St, Saanich, BC"

from ols-geocoder.