不具合
The TomTom North America 2013 R1 StreetMap Premium composite zip4 locator published to ArcGIS GIS Server 10.1 returns more results than the latest version; 2017 R2.
| 不具合 ID 番号 | BUG-000111119 |
|---|---|
| 送信されました | January 25, 2018 |
| 最終更新日 | June 5, 2024 |
| 適用対象 | ArcGIS GIS Server |
| 見つかったバージョン | 10.4.1 |
| オペレーティング システム | Windows OS |
| オペレーティング システムのバージョン | 2008 R2 64 Bit |
| ステータス | Will Not Be Addressed |
参考情報
There were many changes made to the geocoding software between 10.1 and 10.4.1, and then also in the locators between 2013 R1 and 2017 R2. The software and the locators go hand in hand, and so newer locators are only officially supported in the currently released version of ArcGIS, and then one version back. The software and locators might still work in older versions of ArcGIS that are no longer supported, but they may behave differently. Similarly, older locators should still work with newer versions of the software, but may behave differently. Now regarding the three addresses, all three are pretty incomplete. If it Is assumed that the word following the number is the street name, then there can be multiple ties because that street and house number may exist in multiple cities within CA. In any case, the geocoding rules were changed along the way such that with these ambiguous addresses, the word after the number starts getting treated as the city name instead of the street name. This is shown in the "2013 R1 vs 2017 R2 locator comparison" section. For the first two examples, the word after the number is interpreted as the city name. In the first example for 2013 R1, it finds "Trent, CA" because it's a close match to "Treat, CA". But the rules tightened up by 2017 R2, and so it did not return any possible city match. Then in the second example, both the 2013 and 2017 locators find "Concord, CA". However, the third address tries to match to StreetAddress because there are two words (Walnut Creek) following the number. It even treats CA as an abbreviation for the city name. Also, in this section, there are more incorrect candidates listed for 2013 because the CAN_USA composite is being used, as opposed to just the USA composite for 2017. This rule change (treating the word following the number as the city name in these types of incomplete addresses) is also shown in the "2013 R1 Locator ArcGIS Server 10.1 vs 10.4.1" section. For the first two addresses, in 10.1 it is treating the word as the street name, but in 10.4.1 it is treating it as a city name. Then again, the third example is treated differently because there are two words. Lastly, in the "2017 R2 Locator ArcGIS Server 10.1" section, nothing is returned by the PointAddress locator for any of the addresses because the rules are tightened up for the PointAddress locator to reduce false positives (matches returned that are incorrect). So there's just not enough information in the address to get a PointAddress match, and the individual PointAddress locator only returns full address matches (no city name matches). So in the end, with the current software and locators, incomplete US addresses like these are treated differently than four years ago. Along the way, what became more important was reducing false positives. In other words, it is better to get a no-match than get a match that was wrong (a false positive).再現の手順
不具合 ID: BUG-000111119
ソフトウェア:
- ArcGIS GIS Server
バグのステータスが変更されたときに通知を受け取る
このトピックについてさらに調べる
関連情報の検索
このトピックに関連するトレーニングの検索
アイデアを探して、フィードバックを提供します
ArcGIS エキスパートのサポートを受ける
Esri Support アプリのダウンロード