David, The idea behind std_elt was to map standard-specific name (FGDC, OASIS) to locator inputs - to transparently handle addresses formatted according to those standards. This is not yet supported. search_context defines a named search context that elements of the corresponding text will be associated with; this context can then be used with a result tag. For instance: < alt selector = " supportsIntersections " fallback_score = " 10 " > < field_ref ref = " Street " /> < elt ref = " FullStreetName " search_context = " leftStreet " weight = " 40 " separator_list = " .,;- " /> < elt ref = " intConnector " /> < elt ref = " FullStreetName " search_context = " rightStreet " weight = " 40 " separator_list = " .,;- " /> < elt ref = " multilineZone " weight = " 30 " separator_list = " .,;- " /> < result tag = " StreetInt " > < method ref = " intersection " > < parameter > < search_value ref = " leftStreet " original_values = " true " /> </ parameter > < parameter > < search_value ref = " rightStreet " original_values = " true " /> </ parameter > </ method > < format_ref ref = " format_intersections " /> </ result > </ alt > - here is the grammar for intersection addresses (“Main St & 1 st Ave”). The geocoding process needs to collect two sets of candidates and then find if any of them intersect (have common nodes). The elements that will be included in “FullStreetName” and affect the search context (i.e. StName) for the “left” part of the address will be associated with “leftStreet” search context, and for the “right” part – with the “rightStreet” context. Then, after the parse is done, result of this parse will be calculated using “intersection” method, which in turn will receive the search_value (result of the search using named search_context) for “leftStreet” and “rightStreet”, respectively. <alt> `[0-9]{4}` </alt> is not supported, unfortunately it’s an error in the whitepaper. Regular expressions should be used with caution, as sophisticated expressions tend to affect parsing process in non-obvious way (think of it as a parser within a parser) If <ref_data_style> contains <multiline_grammar>, it replaces the top-level <multiline_grammar>. The same applies to <inputs> and <default_input>. <mapping_schema><standardization> section is only used for standardization. The standardization is invoked in two workflows: when locator is built (reference data is processed as it is being submitted to the locator build processes); this is governed by <build> subsection when StandardizeAddresses geoprocessing tool is used (<tool> subsection) GeocodeAddresses_geocoding() works on a table of addresses. Single addresses are not supported in Python. Sergey
... View more