Shapefile opens with SpatialReference Wkid-0 for well known SpatialReference

[DavidMillican]

I am opening a shapefile that was exported from another commercial software package and the spatial reference has a Wkid of 0. It looks like the spatial reference wasn't identified by the SDK even though I can see in the .PRJ file that it is a publicly defined projection system. The spatial reference appears to work except that shapefile tables can't be reprojected and I need it to be visible when I am showing other data in the publicly defined projection system. I am using  ArcGIS Runtime SDK for .NET 10.2.7. Any help with this would be appreciated.

[MelitaKennedy]

If the Esri projection engine is being used, it does an exhaustive check. Names must match (although there's some flexibility with underscores, white space, alias) and values must match. The name you have matches the Esri name, not the EPSG name (see http://www.epsg-registry.org). 

http://spatialreference.org has a superset of EPSG, Esri, plus whatever other information someone can find for a particular coordinate reference system, including plenty of duplicates as individuals add entries.The "ESRI WKT" string in the 32041 entry is in the Esri style, but the name is the EPSG name.

The EPSG Geodetic Parameter Registry (disclosure: I'm on the subcommitte that maintains it) and Esri both curate additions and changes to our sets of coordinate reference systems and transformations.

Melita

[dotMorten_esri]

This basic sample seem to work just fine with 100.2.1 so it might be shapefile specific

[dotMorten_esri]

Oh I just realized you're still using 10.2.7, and the simple example above does reproduce the behavior you're seeing with that version.

Anyway you should be OK, as the projection is understood. If you really need the ID, I'd encourage you to consider migrating to v100.x as this is where you'll see a lot of bug fixes and new innovation (10.2.7 is already in extended support which ends in November).

[dotMorten_esri]

...also if you update the .prj file to contain this instead, it seems to work ok:

PROJCS[\"NAD_1927_StatePlane_Texas_South_FIPS_4205\",GEOGCS[\"GCS_North_American_1927\",DATUM[\"D_North_American_1927\",SPHEROID[\"Clarke_1866\",6378206.400,294.97869821]],PRIMEM[\"Greenwich\",0.0],UNIT[\"Degree\",0.0174532925199433]],PROJECTION[\"Lambert_Conformal_Conic\"],PARAMETER[\"False_Easting\",2000000.0],PARAMETER[\"False_Northing\",0.0],PARAMETER[\"Central_Meridian\",-98.5],PARAMETER[\"Standard_Parallel_1\",26.16666666666667],PARAMETER[\"Standard_Parallel_2\",27.83333333333333],PARAMETER[\"Latitude_Of_Origin\",25.66666666666667],UNIT[\"Foot_US\",0.3048006096012192]]

The only difference seems to be at the very ends of the last few digits. Melita can probably confirm that the comparison has been improved since 10.2.7 to handle small rounding differences, but that seems to be what is happening.

[DavidMillican]

We would have switched to v100 early last year but it just started supporting WMS in December. Now we are a year into this project and have to deliver soon. Migrating will take months and will be a hard sell even after this release is delivered. 

[dotMorten_esri]

Aaah yes that's a good point. I believe 10.2.7 didn't reproject shape files (v100.x does).

I don't really have any other ideas than try and update the .prj files to something that works. The "correct" string is easy to get with 'new SpatialReference(32041).WkText`

[DavidMillican]

Ok. Thanks to both of you for your help on this. I have a better understanding of the problem now. It sounds like if I want something for now to work with 10.2.7 that I'll have to create some kind of conversion table mapping the same Wkid to multiple names. If you guys had a REST service that did this it would be great. The fact that v100 reprojects shapefiles will help me sell management on the upgrade so thanks for revealing that as well. Thanks again for all of the information.

-David

[DavidMillican]

So has the name change by EPSG then broken compatibility with older tools like Petra?