Enumerated Value lists Description written to the ISO 19110 output?

[palmerj]

I tried to translate a valid fgdc XML file to ISO 19110 XML and the enumerated values list descriptions were not being created. See file here https://gist.github.com/palmerj/5b04d52307f2a4d7c991759bc8ce77d9

[jlblcc]

Looks like the FGDC reader is assigning the first overall domain(first domain from first parsed attribute) to each attribute instead of the the first domain assigned to the individual attribute (the mdTranslator and mdJSON spec only support one domain assignment for each attribute).

Will adjust the logic to use the first domain assigned to each individual attribute in FGDC (I would think that having multiple domains assigned to an attribute is more of an edge case, excepting range domains which are handled differently). Look for the patch in v2.17.1. @palmerj Thanks for reporting this.

[palmerj]

Thanks heaps @jlblcc

[dwalt]

Just a heads up, but we quite often have multiple domains per attribute. This may be to account for coded values within a numeric field, resulting in a range domain and a codeset domain.

…

On Wed, Nov 6, 2019 at 6:05 PM Josh Bradley ***@***.***> wrote: Looks like the FGDC reader is assigning the *first overall* domain(first domain from first parsed attribute) to each attribute instead of the the first domain assigned to the *individual* attribute (the mdTranslator and mdJSON spec only support one domain assignment for each attribute). Will adjust the logic to use the first domain assigned to each individual attribute in FGDC (I would think that having multiple domains assigned to an attribute is more of an edge case, excepting range domains which are handled differently). Look for the patch in *v2.17.1*. @palmerj <https://github.com/palmerj> Thanks for reporting this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#218?email_source=notifications&email_token=ABPKCL6VAILRSL3FNHXWZTDQSOATFA5CNFSM4JIJ3QJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDIYVMQ#issuecomment-550603442>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPKCL7ZS3L4NWCCONAOXT3QSOATFANCNFSM4JIJ3QJA> .

[jlblcc]

@dwalt The FGDC reader handles range domains differently. In fact, they are not interpreted as "domains" at all. The mdJSON schema has the valueRange property which the CSDGM range domains map to. Therefore, if you have a single codeset domain and any number of range domains, you should not lose anything in the translation.

[dwalt]

Good to know, thanks for the clarification.

…

On Fri, Nov 8, 2019 at 10:31 AM Josh Bradley ***@***.***> wrote: @dwalt <https://github.com/dwalt> The FGDC reader handles range domains differently. In fact, they are not interpreted as "domains" at all. The mdJSON schema has the valueRange <https://mdtools.adiwg.org/#viewer-page?v=4-0-10-0-8-0-17> property which the CSDGM range domains map to. Therefore, if you have a single codeset domain and any number of range domains, you should not lose anything in the translation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#218?email_source=notifications&email_token=ABPKCL265KU3XIQ2F7NYGDLQSW46VA5CNFSM4JIJ3QJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDTD6RY#issuecomment-551960391>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPKCL77EJVISBITHDJNWF3QSW46VANCNFSM4JIJ3QJA> .