|
|
Hamcall address field.png (88,000 bytes) |
|
|
The code is behaving per the specification right now. The specification says that the country line (the last line) of the address comes from field #209, which the API documentation describes as "mailing country". The lookup from WA9PIE yields no value for 209, so nothing is aded to the field. The DXCC country field (the undocumented #225 field) is also blank, so there's no way to compute a DXCC country. I don't see a way to do what you're asking. That must mean that you've actually intended to ask for something else. What is it? For example, the WA9PIE lookup returns "USA" for field #189, which the API describes as "Prefix Country". Should that value be used instead of the mailing country? |
|
|
I had it wrong in the version of the field mapping spec you're looking at. It later occurred to me that - if we're obtaining the country from the Country List... then it's a matter of putting the country name from the Country List as the last line in the address field. Sorry about that. I'm attaching an in-progress version of that field mapping spec that I'm using to keep track of the "as-built" mapping. You'll see this in the yellow high-lighted HamCall.net column. CallsignLookupMapping4x.xlsx (25,936 bytes) |
|
|
I don't think releasing a product with a specification that' described as "in-progress" is good process. If the code is changed to match what you're asking for here, the repro case provided still won't show a country name in the address because the call sign given doesn't offer a DXCC number at this data source. Is that what's desired? |
|
|
Put the country from the distilled results on the last row of the address field. |
|
|
Right now, code for each lookup source produces a set of name-value pairs. In this case, the HamCall lookup produces an "Address" name with the a value that has an address that doesn't include a country name. The country name isn't included because this source doesn't provide one. This arrangement matches the specification, where each column in the spreadsheet shows a set of mappings from source fields to logbook column fields. Since the HamCall lookup source (like all other lookup sources) atomically produces each named value it contributes to the results, we can't readily take one named value from the distilled results and use that value to edit the existing results from another value, from another source. The lookup code works this way so that each source standardizes its representation of the results in a way that can be readily combined, displayed to the user, and placed in a logbook database record. For that standardization, "ADDRESS" is the name of one of the values. While other values exist which might be part of the address, the "ADDRESS" value is computed by each lookup source for itself, using its locally-known fields and rules. Changing that would require removing the "ADDRESS" field and breaking it into component parts, standardized across each component, so that something added to the distillation step could consider different values from different sources when displaying the final "ADDRESS" value to users, or preparing COL_ADDRESS for the database. Until today, this approach was compatible with the specification. The approach is modular, isolated, readily exensible, easy to understand, and pretty flexible. Now that it's not, we're forced to consider alternatives -- and to do so just before a shipping deadline. My first suggestion for an alternative would be to consider different sources for the country name. First, use field #209 ("Mailing address country"), if it's available. If not, use field #189 ("Prefix Call") from this source, if it is avaialble. If not, use the DXCC country name based on looking up the DXCC entity number in field #225. Or, maybe there should be a different order. As this repro case shows, there are records from this data source which have neitehr #209 nor #225 populated. Since the specification says to ignore #189, the source ends up producing no country name in the address (or in the COL_COUNTRY field, or any of the related fields). If you'd like, we could have this component side-step the Coutry List component and have the country list produce a country name based on the prefix matching logic it has. If we take this approach, should it be done unconditionally without considering any other fields? Or should it be done only if certain fields are blank? In which order? |
- Anonymous
