Problem reading wkts in utm feet, bad key_nm

[joel4370]

I am using CS_wkToCSEx to decode wkts into a key_nm like this. CS_wktToCsEx (csDef,dtDef,elDef,wktFlvrEsri, chText,0) I am having problems with utm feet. The csDef units indicates that the wkt is in feet, but the key_nm returned is for meters. I am working with utm 16N NAD83 US foot, but have also tried it in zones 15 and 18 with the same result. The key_nm should be UTM83-16F, but it returns UTM83-16. Thanks for your help.

[joel4370]

Utm 16N NAD83 US Foot prj example

[Norm Olsen]

I believe what is happening here is that CS-MAP:

1> Identifies the WKT as being of the ESRI flavor, 2> Looks up the name of the CRS in the NameMapper, 3> Finds a match and returns the CS-MAP name associated with the ESRI CRS name.

The remainder of the WKT is essentially ignored when the above procedure works.

I suggest changing the name of the WKT to something like "NAD_1983_UTM_Zone_16N_Foot_US" and see if that doesn't correct the problem.

[joel4370]

Replying to NormOlsen: I tried changing the name as you suggested but it didn't work. The behavior did change. Before it was recognizing the wkt and returning a valid key name (the one for meters). After I changed the name it would not give me a valid key name. I tried different combinations of underscores and where the US went, but it never worked. It reads the parameters correctly including the units, but it does not return the correct key name. Unfortunately all I use is the key name. I use CS_csloc(key_nm) to initialize cs_Csprm_. It would be nice if it would override the name with the units specified in the parameter section. If the only way to do this is changing the name, that would work also, but that doesn't work now either. Let me know if I can test anything else. Joel

[Norm Olsen]

Sorry for the delay in responding. We've been in the last trhoes of a product release and things have been crazy at work. With the changed name, CS_wktToCsEx will return valid definitions. The key_nm element of the coordinate system definition will not, in this case, be the name of a dictionary definition; but the when taken as a whole, the returned cs_Csdef_ sttucture is valid.

Thuis occurs for the reasons described above. CS-MAP recognizes the flavor of the definition to be ESRI and tries to map the name from ESRI form to CS-MAP form. Since the name in the WKT is not in the mapping table, the key name portion of the returned cs_Csdef_ structure remains unaltered.

If you change the name and then turn on the "binaryFallback" option of CS_wktToCSEx (set the sixth argument to 1), CS_wktToCSEx will do a (linear) search of the coordinate system dictionary file and return the definition (with a valid key-nm element) which matches that extracted from the WKT. This will probably fix this issue for you.

This is a feature which was added by someon else, so I was not familiar with it. Otherwise, I would have suggested this first time up.

I'll try to be more responsive in the future. Maybe I'll be able to figure out how to get an e-mail whenever sone one posts something to this Trac site.

Norm

[joel4370]

Replying to NormOlsen:

Sorry for the delay in responding. We've been in the last trhoes of a product release and things have been crazy at work. With the changed name, CS_wktToCsEx will return valid definitions. The key_nm element of the coordinate system definition will not, in this case, be the name of a dictionary definition; but the when taken as a whole, the returned cs_Csdef_ sttucture is valid.

Thuis occurs for the reasons described above. CS-MAP recognizes the flavor of the definition to be ESRI and tries to map the name from ESRI form to CS-MAP form. Since the name in the WKT is not in the mapping table, the key name portion of the returned cs_Csdef_ structure remains unaltered.

If you change the name and then turn on the "binaryFallback" option of CS_wktToCSEx (set the sixth argument to 1), CS_wktToCSEx will do a (linear) search of the coordinate system dictionary file and return the definition (with a valid key-nm element) which matches that extracted from the WKT. This will probably fix this issue for you.

This is a feature which was added by someon else, so I was not familiar with it. Otherwise, I would have suggested this first time up.

I'll try to be more responsive in the future. Maybe I'll be able to figure out how to get an e-mail whenever sone one posts something to this Trac site.

Norm

I tried turning on the "binaryFallback" option of CS_wktToCSEx, but it did not give me a valid key-nm. I tried it both with the modified name and the original. You mentioned that the cs_Csdef structure is valid. Is there a way to use that directly to set up a cs_csPrm? If there is a way to have the trac system email let me know. I forget to check back, and suddenly it has been two weeks since your response. Joel

[Norm Olsen]

Oops!!! I forgot to check back in as well. I did, finally, get a chance to look inot this. Couple of things:

1> With the name unchanged, CS-MAP is simply mapping the ESRI name to a CS-MAP name using the NameMapping facility, thus the name gets changed to the meters equivalent of UTM83-16. CS-MAP is assuming (perhaps incorrectly) that all ESRI definitions are uniquely named; I guess this is not true.

2> With the name changed to, for example, NAD_1983_UTM_Zone_16N_FT, CS_wktToCsEx produces a valid cs-Csdef_ structure, but the key name in the result is a manufatcured key name that doesn't really mean anything. Since the NameMapper has no record of it, it remains invalif keyname. The cs_Csdef_ returned is valid, however. This can be used to set up an new cs_Csprm_ structure using the CScsloc1 function which accepts a pointer the the cs_Csdef_ structure as its only argument and returns a properly initialize cs_Csprm_ structure. This assumes, of course, that the datum (and/or ellipsoid) mapping has been properly completed.

3> If the bRunBinaryFallback argument to CS_wktToCsEx function is set to 1 (i.e. non-zero), the binary fallback will search the dictionary for a definition which matches (numerically) the cs_Csdef_ structure which was extracted from the WKT. It returns the first one it finds, in this case it is BLM-16. This is probably not the most desirable one, but it is the first one (since the dictionaries are maintained in alphabetci order.

Thus, the solutions are: 1> Adjust the name and the NameMapper to recognize the UTM in feet series as valid ESRI names.

2> Use the returned cs_Csdef_ structure and CScsloc1 function to obtain a usable cs_Csprm_ structure.

3> Turn on the binary fallback feature and accept whatever name it finds.

The first option would probably be the most reliable. Unforunately, every writer of WKT seems to do things their onw way. There is no standard which specifies exactly how projections are parameterized, the names assigned to projections, the names assigned to parameters, and (most importantly) any standard names for datums. Thus, any application which processes a WKT which it didn't write is susceptable to strange errors which are difficult to track down.