You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue is the 2 source services have different spatial references. In the join service layer id 0 is a table and it has a single source pointing to the service with a spatial reference of 4326. Layer id 1 is a layer and is a multi-source service where the left side of the join is coming from the service with a spatial reference of 102100.
So what appears to be happening is we are pulling the spatial reference from the source of layer id 0. I believe we implemented this logic to account for how users can change the spatial reference on deployment and the need to keep views in sync with the source service spatial reference.
However, this is a unique case as the layer id 0 is a table and has no geometry so spatial reference of the source can be ignored. I believe we should update this logic to look at the spatial reference of the source service for the first layer (w/ geometry) in the service. So in this particular case we would take the spatial reference from the source service on the left side of the join for layer id 1.
The text was updated successfully, but these errors were encountered:
Can be reproduced by deploying this solution item:
https://localdeployment.maps.arcgis.com/home/item.html?id=111b98baa09742fc97651ae53f44dbc5
The issue is the 2 source services have different spatial references. In the join service layer id 0 is a table and it has a single source pointing to the service with a spatial reference of 4326. Layer id 1 is a layer and is a multi-source service where the left side of the join is coming from the service with a spatial reference of 102100.
So what appears to be happening is we are pulling the spatial reference from the source of layer id 0. I believe we implemented this logic to account for how users can change the spatial reference on deployment and the need to keep views in sync with the source service spatial reference.
However, this is a unique case as the layer id 0 is a table and has no geometry so spatial reference of the source can be ignored. I believe we should update this logic to look at the spatial reference of the source service for the first layer (w/ geometry) in the service. So in this particular case we would take the spatial reference from the source service on the left side of the join for layer id 1.
The text was updated successfully, but these errors were encountered: