Issue showing data with offline TPK and offline feature layer.

BrianPlummer · ‎05-01-2014

Is it a requirement that offline feature layer's WKID match the base layer WKID?

I am having an issue with showing data when using both an offline TPK file and an offline feature service. The TPK file is copied to the device manually and if it is added first it displays correctly. It has a WKID of 102100 (WGS_1984_Web_Mercator_Auxiliary_Sphere.) The feature service is being downloaded as a geodatabase and has a WKID of 2868 (NAD_1983_HARN_StatePlane_Arizona_Central_FIPS_0202_Feet_Intl.) The geodatabase download works correctly and if the feature layers are added to the map first, they display correctly. The problem I have ran into is that after adding the tiled layer to the map, then the feature layer, the feature layer will not display.

These same services display correctly when getting them from ArcGIS Server in online mode.

I then tried downloading a different feature service as a geodatabase for offline mode. This service has the exact same data as the feature service above but has a WKID of 102100, matching the tiled service. The data displayed correctly.

ShellyGill1 · ‎05-02-2014

Hi Brian,

You will need to ensure that when you download the features from the feature service to the local geodatabase, that you specify the spatial reference you want - in this case you'll want it to match the tiled offline layer you're using as the basemap. You can use the setOutSpatialRef method on the GenerateGeodatabaseParameters class to set the spatial reference of the geometries in the new geodatabase, when you generate the geodatabase using a GeodatabaseSyncTask. I found that we don't have any documentation highlighting this (beyond the statements that this is possible), and we need to highlight when you want to be using this ability, so will make sure this is addressed for the next release.

BTW - when you add the offline feature layer to the map first, the reason you can see your features then is that the first layer added sets the spatial reference of the map. You'll find that you cant see the tiled layer if you add that afterwards, if it doesn't match the spatial reference of the first layer.

Hope this helps,

View solution in original post

ShellyGill1 · ‎05-02-2014

Hi Brian,

You will need to ensure that when you download the features from the feature service to the local geodatabase, that you specify the spatial reference you want - in this case you'll want it to match the tiled offline layer you're using as the basemap. You can use the setOutSpatialRef method on the GenerateGeodatabaseParameters class to set the spatial reference of the geometries in the new geodatabase, when you generate the geodatabase using a GeodatabaseSyncTask. I found that we don't have any documentation highlighting this (beyond the statements that this is possible), and we need to highlight when you want to be using this ability, so will make sure this is addressed for the next release.

BTW - when you add the offline feature layer to the map first, the reason you can see your features then is that the first layer added sets the spatial reference of the map. You'll find that you cant see the tiled layer if you add that afterwards, if it doesn't match the spatial reference of the first layer.

Hope this helps,

BrianPlummer · ‎05-02-2014

Thank you for the information.

I was able to solve my issue. I found that the problem was due to the extent I was supplying to the GeodatabaseSyncTask. I was capturing the extent of the map when online and supplying that. The base map was causing that extent to be in a different spatial reference than the feature data so the GeodatabaseSyncTask wasn't downloading anything.

To solve the issue I used GeometryEngine to project the envelope from the original map extent to the feature extent. I then supplied GeodatabaseSyncTask with the new projected extent and output to the original map extent. The data displayed correctly then.

Thanks for your help,
Brian

ShellyGill1 · ‎05-06-2014

Glad you got things working, thanks for posting back about reprojecting the extent too, that's a useful thing to highlight for any others dealing with similar situations.