Bug Report: ArcGIS Geocoding Fails for Valid Results with Decimal Confidence Score

Summary

Device geolocation via the ArcGIS provider fails to populate Country/City/coordinates whenever the ArcGIS findAddressCandidates API returns a decimal confidence score (e.g. 96.82). Only results scoring a perfect, whole-number 100 are accepted. This affects the vast majority of real-world addresses, since ArcGIS almost never returns an exact integer score.

Environment

• Product: Observium (Pro/Community — specify edition)
• Version: SVN branches/stable, revision as of 2026-08-11
• Deployment: Docker (custom build from SVN checkout)
• Geocoding API: ArcGIS (World/GeocodeServer/findAddressCandidates)
• PHP version: 8.3

Steps to Reproduce

1. Set a device's sysLocation (via SNMP) to any real, valid address that ArcGIS can geocode with high confidence but not a perfect match, e.g.:
   Ziedo g. 14, Ukmerge / R08 (KS33)
2. Ensure Geocoding is enabled with API = arcgis in Observium settings.
3. Run discovery in debug mode:
   ./discovery.php -d -h <device_id>
4. Observe the debug output.

Expected Result

Since ArcGIS returns a valid, high-confidence candidate (score 96.82, correct address, correct country/city/coordinates), Observium should accept this result and populate the device's Location Place (Country, City) and coordinates.

Actual Result

The result is rejected outright, and the device's geolocation stays "Unknown" despite ArcGIS returning fully correct data. Debug output shows:

 

{{Response [96.82] not valid: [candidates->0->score] regex [^\d+$]
Array
(
[candidates] => Array
(
[0] => Array
(
[address] => Žiedo g. 14, 20126, Ukmergė, Ukmergės miesto, Ukmergės rajono savivaldybė, Vilniaus apskritis
[location] => Array ( [x] => 24.736808270559 [y] => 55.252513273271 )
[score] => 96.82
[attributes] => Array
(
[City] => Ukmergė
[Region] => Vilniaus apskritis
[Country] => LTU
)
)
)
)}}

Note the candidate data is entirely correct and usable — it is only rejected due to the score's decimal format.

Root Cause

File: includes/definitions/geo.inc.php Line: 351

 

'response_test' => [ 'field' => 'candidates->0->score', 'operator' => 'regex', 'value' => '^\d+$' ],

The regex ^\d+$ only matches whole integers. ArcGIS's documented score field is a float (0-100 with decimal precision), so this validation incorrectly rejects the overwhelming majority of valid, high-confidence geocoding results — anything short of an exact 100.

Confirmation the API Itself Is Not at Fault

Direct curl testing against the exact same ArcGIS endpoint/query Observium built confirms the API returns a correct, well-formed response with a valid (decimal) score:

 

curl -s "https://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer/findAddressCandidates?SingleLine=Ziedo+g.14%2C+Ukmerge%2F+R08+%28KS33%29&outFields=Country,Region,Territory,StName,Subregion,City,PlaceName,Type,Score&f=json&langCode=en&maxLocations=1&token=<key>"

Response (abbreviated):

 

{{{
"candidates": [
{
"score": 96.82,
"attributes":

{ "City": "Ukmergė", "Country": "LTU" }

}
]
}}}

This confirms the issue is entirely within Observium's response validation logic, not the ArcGIS API or the API key/configuration.

Suggested Fix

Update the regex to accept decimal scores, optionally with a sensible confidence floor (example uses ≥ 70):

 

'response_test' => [ 'field' => 'candidates->0->score', 'operator' => 'regex', 'value' => '^(7[0-9]|8[0-9]|9[0-9]|100)(\.\d+)?$' ],

Or, for a minimal fix that just allows any decimal (matches existing intended behavior more closely, only fixing the format issue):

 

'response_test' => [ 'field' => 'candidates->0->score', 'operator' => 'regex', 'value' => '^\d+(\.\d+)?$' ],

Impact

• Affects any device relying on ArcGIS forward geocoding where the address doesn't score a perfect, whole-number 100 — which is the overwhelming majority of real-world addresses.
• Silent failure — no error is surfaced to the user in the UI beyond "Unknown" location; the actual cause (a validation regex bug) is only visible in discovery debug (-d) output.