Problem with catalog file when creating S57 Exchange set

5140
8
Jump to solution
10-27-2013 06:30 PM
JohnWoodward
New Contributor
Whenever I create an S57 Exchange set for an S57 .000 file in "Create S57 Exchange Set" tool in ArcCatalog, the resulting ENC_ROOT structure is not recognised as containing the .000 file when trying to load into an ECDIS. Upon examining the content of the Catalog.031 file, it appears different to ones produced by our other production system. Has there been a patch for this?
0 Kudos
1 Solution

Accepted Solutions
GeoffreyGomez
Esri Contributor
John,
Thank you for the added info. I think I have an idea of what may be occurring. I noticed that "1B" actually relates to the Agency Code value of "0". (<AGENCY code="0" value="1B" description="UKHO test and sample datasets" />)

This made me think that the cause of the changed value may that it is being dropped on export. I turned to looking through configuration files and surprisingly I do not see an Agency for "AS". I see a NATO country abbreviation but not an agency. I also checked the IHO registry for that value and didn't find it there either. (I admit I scanned quickly)

Given your description I feel like the following is happening:

  • Your original cell has the agency and LNAM for all features set using "AS"

  • You import and it sets the value in the metadata which holds it as a string

  • Everything looks fine as you export

  • When actually writing the file it looks for the code equivalent of "AS" and cannot find it in the configuration file.

  • Finally it defaults to "0" which is 1B.

Without going into a long reply I do want to be certain that you were able to setup your properties and establish an agency value. This would ensure that new features are generated with the proper LNAM. I am curious if "AS" was in that list.

I think if you add "AS" to the product_config.xml found here, (C:\Program Files (x86)\ArcGIS\MaritimeCharting\Desktop10.2\Common) based on your install path, you may be able to have the value map back out when exporting. I don't know which code you will use to mesh with the IHO registry.


  • Within the file find the <PRODUCERAGENCY> tag.

  • Copy an existing entry like: <AGENCY code="10" value="AU" description="Australian Hydrographic Service (AHS)" />

  • Insert a line, paste and alter the text to be: <AGENCY code="Insert code integer" value="AS" description="Insert Description" />

Hope this helps!
Geoff

View solution in original post

0 Kudos
8 Replies
JohnWoodward
New Contributor
Problem solved after consulting help! The product must be "Published" before it is allowed to be exported as a valid Exchange Set.

However, this has led to the next problem as the "Production Agency" tag for the exported dataset defaults to "1B UKHO Test data" which no ECDIS regards as official data. I have set the "Production Agency" tag to our producer code and all features have the correct code associated with them in the "LNAM" field. Don't know if it requires a re-install of ArcGIS for Maritime or not...
0 Kudos
GeoffreyGomez
Esri Contributor
Hi John,

I will be happy to see if I can provide some help. I have a few questions first:

  1. I am just curious what version are you working with?

  2. Are you using the solution as Enterprise or Desktop?

  3. When you generated the product did you input the proper producing agency in the metadata form?

When exporting, I believe the default agency code is pulled from the initial metadata record made during the new product wizard. When exporting a new edition, you should be able to update it to the correct one and have it exported accordingly. Is this in line with what you see?

I look forward to hearing more,

Geoff
0 Kudos
JohnWoodward
New Contributor
Hello Geoff

- we are using ArcGIS 10.1 with Service Pack 1 and all current patches (7 I believe) under Windows 7.
- we have ArcGIS Maritime: Charting - Desktop
- during export of the product, the production agency is not editable - but shows the correct value - "AS" in our case

The curious thing is that if I re-import the exported product as "New Nautical Product - Import existing S57 cell", it recognises and creates the metadata with the "1B" UKHO producer code!

Thanks

John
0 Kudos
GeoffreyGomez
Esri Contributor
John,
Thank you for the added info. I think I have an idea of what may be occurring. I noticed that "1B" actually relates to the Agency Code value of "0". (<AGENCY code="0" value="1B" description="UKHO test and sample datasets" />)

This made me think that the cause of the changed value may that it is being dropped on export. I turned to looking through configuration files and surprisingly I do not see an Agency for "AS". I see a NATO country abbreviation but not an agency. I also checked the IHO registry for that value and didn't find it there either. (I admit I scanned quickly)

Given your description I feel like the following is happening:

  • Your original cell has the agency and LNAM for all features set using "AS"

  • You import and it sets the value in the metadata which holds it as a string

  • Everything looks fine as you export

  • When actually writing the file it looks for the code equivalent of "AS" and cannot find it in the configuration file.

  • Finally it defaults to "0" which is 1B.

Without going into a long reply I do want to be certain that you were able to setup your properties and establish an agency value. This would ensure that new features are generated with the proper LNAM. I am curious if "AS" was in that list.

I think if you add "AS" to the product_config.xml found here, (C:\Program Files (x86)\ArcGIS\MaritimeCharting\Desktop10.2\Common) based on your install path, you may be able to have the value map back out when exporting. I don't know which code you will use to mesh with the IHO registry.


  • Within the file find the <PRODUCERAGENCY> tag.

  • Copy an existing entry like: <AGENCY code="10" value="AU" description="Australian Hydrographic Service (AHS)" />

  • Insert a line, paste and alter the text to be: <AGENCY code="Insert code integer" value="AS" description="Insert Description" />

Hope this helps!
Geoff
0 Kudos
JohnWoodward
New Contributor
Bingo!!

Thanks Geoff, duplicating the AU entry to AS gave the correct Producer Code!
0 Kudos
GeoffreyGomez
Esri Contributor
Bingo!!

Thanks Geoff, duplicating the AU entry to AS gave the correct Producer Code!


Awesome! Glad it worked. Can you do a favor by clicking the green check mark to indicate that it has been answered.

Summary: Agency value assigned to features and metadata for a given product is being dropped upon export. A little digging uncovered that it is not contained in the product_config.xml which is used to map the characters to a valid code upon export.

Solution: Make sure that the product_config.xml file in the install location possesses a reference to the agency code being used. If it doesn't have an entry, add one to ensure the string is mapped to the metadata header upon export of the S-57 file. All client machines will need to have the updated product_config.xml since it is a local configuration file and not centrally managed in the Product Library.

As an aside: We maintain that list of agencies based on the IHO registry, if you have a value you would like to use and have captured in the COTS software, make sure to register with IHO.

G.
0 Kudos
JohnWoodward
New Contributor
Thanks Geoff,

as clarification - the problem lies in there being two difference country codes - not that ours was missing.

There is the NATO code AS for Australia and the IHO code AU. The same applies for the UK where it is GB and UK respectively. This is because AML is a NATO initiative and considered to be linked to the military and not charting. We have also had allocated AN for Australian AML production through the IHO.

As a production agency will typically only produce for itself, it is not a big problem to edit the file manually, but in principle the software should use a lookup table to work this out for itself.

thanks again

John
0 Kudos
GeoffreyGomez
Esri Contributor
John,

Thank you for the added information. You are correct the AML export should properly reference the listing of NATO codes. At 10.1 we altered the way we use metadata and write out the header information, since then there haven't been as many AML users on the newer releases as ENC so it most likely slipped by. I will reproduce this issue and log a bug to fix the problem. Again thank you for bringing this to my attention.

Regards,
Geoff
0 Kudos