Make Query Layer suggests wrong projection SRID, but is it really wrong?
The SDE geodatabase I inherited has an odd feature class (FC) that always behaved weird. The FC and feature dataset it is in, are both in the same projected coordinate system SRID: 2248, which is expected and what most of the data in the SDE is in. When I view the FC in Pro maps, or as a service in Portal, it correctly reprojects as needed to align with other records.
However, when I create a Query Layer in Pro (for example with a SQL join on a stand-alone table of related data), the Query Layer tool always suggests SRID: 2893. with the result that the geometry of the whole Query Layer is off by about one foot. For my use of the layer, that doesn't really matter, but these two things always nagged me, especially why Pro keeps thinking the data is SRID: 2893. If I set the SRID to 2248 in the Query Layer wizard, none of the data shows at all! So that's odd.
So today, I went down into the basement and knocked around in the SQL Server DBMS to see what is going on. What I found really surprised me.
The Shape.STSrid property of the geometry field thinks all the features are in SRID: 2893. But Pro definitely still thinks the FC is SRID: 2248. I created an arbitrary new feature in this table in Pro, checked the DBMS and the SRID still showed up 2893. Upon further inspection, it appears there are more FCs in this DB like this.
What is going on? Is this meaningless? I checked a few other feature classes, and none have this issue.
