ShapefileTable.OpenAsync Error

[MichaelFaulcon1]

When calling ShapefileTable.OpenAsync(../file.shp) with a .prj file defining a custom projection, I get the error: "unknown wkt".

If I remove the .prj file, then the call succeeds but the result ShapefileTable has a spatial reference of 4326/WGS84 and the features do not seem to be rendered.

Might there be another way of specifying the spatial reference of shapefile data (with a custom projection)?

My approach follows the advice from another thread involving a workaround for the lack of shapefile projection on the fly.

[MichaelFaulcon1]

Update:

If I specify the Spatial Reference of the Shape Field of the projected Shapefile when I create it, then I get a slightly different error message:

Invalid argument : wkt.size() == 0

The .prj file does contain the proper wkt string and nothing else

[DanielRivero1]

I have the same issue, did you find a solution?

Regards,

[Anonymous User]

I had the same "Invalid argument : wkt.size() == 0" exception being thrown for me. In my case, the WK Text didn't match and was obviously something somebody named instead of using an actual WKT.  All I did to fix it was change the WKT to match (the rest was the same) and it opened properly after that.

[WlodzimierzSzafran]

This raises the question, though: why bother with the entire WKT when only the name of the spatial reference seems to matter?

One would think that when all parameters that are needed to construct a spatial reference are given (regardless of what name is used for it), the SDK should have no trouble doing so. Yet it doesn't seem to be the case for if the name itself isn't on the list of supported spatial references, an error occurs.

Regards.

[WlodzimierzSzafran]

I've encountered this as well.

So far the only solution, or rather a workaround, that worked for me was to find a spatial reference, with the exact same parameters as the custom one, on the official list of supported spatial references: Desktop Guide -> Reference -> Projected Coordinate Systems, and either use the number as the WKID or the text as the WKT, or place the text in the relevant .prj file.

Regards.

[HuyHo]

We just encountered this issue with one of our application that was running an older version of the SDK.  We tried it with the recently released SDK (version 10.2.7) and that seems to work now.

[MichaelFaulcon1]

After trying with 10.2.7, the issue does seem to be resolved.

Thanks