image services

381
2
Jump to solution
06-07-2018 08:24 AM
tomwang1
Occasional Contributor

Hi,

I have very limited knowledge for rater data. We are starting to use image services on our web application. All basemaps are with 3857 Web Mercator and our raster data has all Spatial Reference 4326,  and landcover  with 

      PROJCS["Unknown_datum_based_upon_the_custom_spheroid_Sinusoidal",GEOGCS["GCS_Unknown_datum_based_upon_the_custom_spheroid",DATUM["D_Not_specified_based_on_custom_spheroid",SPHEROID["Custom_spheroid",6371007.181,0.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Sinusoidal"],PARAMETER["false_easting",0.0],PARAMETER["false_northing",0.0],PARAMETER["central_meridian",0.0],UNIT["Meter",1.0]]

I understand image services can be reprojected on the fly to 3857 for visualization in a web map, but for a performance reason I'd like to create mosaic dataset with 3857 Web Mercator to keep raster data as  their native. Then image services connect with the mosaic dataset will have a better visualization performance on our web application.

Here, I'd like to know whether would be any impact or distorted data when the image services are used for analysis, function?? or other issues or concerns?? 

Thanks,

Tom

Reply
0 Kudos
1 Solution

Accepted Solutions
PeterBecker
Esri Regular Contributor

3857 is equivalent to Web Mercator Auxiliary Sphere which is a projection based on WGS84 datum.

4326 defines that the data is non projected but defined in Long,Lat values also based on WGS84 datum.

When you create a mosaic dataset you define the projection for the mosaic dataset. The source data can be in different projections and the requests can be in different datums. The system will transform the data from the source to the requested projection. This on the fly projection is very fast and add very limited overhead. The projection of the mosaic dataset has no effect on the performance. The slight loss of performance is due to the reprojection from the source data to that requested by the client application. The projection of the mosaic dataset is not very important so long as the data can fit in the bounds of the projection. Unless your are working on areas near the poles, I typically recommend users use Web Mercator Auxiliary Sphere for the mosaic dataset, unless the vast majority of your data is in another projection. The one disadvantage of using 4326 is the pixels sizes (which define scale) are in fractions of a degree (vs meters) which can be more difficult for user to understand. When you add an image service to a map in desktop it will be projected to the current map projection. Similar in most web applications the data will be projected to Web Mercator Auxiliary Sphere, unless the basemap of the webmap is different.

In the above you also refer to your LandCover dataset which has a Sinusoidal projection, but does not have a Datum defined. This should be checked. It is likely that the scale is so small that it make no difference. If undefined ArcGIS will assume it is in the same datum as the client is requesting. Just be aware that you have not defined a datum. If a datum is defined then then the transformation between the datum is also handled as part of the reprojection. I would recommend against re-projecting this data to a more optimum projection as this would add re-projection artifacts. If added to the mosaic dataset then users can access in any projection. Changing the client to the same projection would reduce any reprojection artifacts. Also note that a property set by the image service client is the type of resampling to be performed when reprojecting.

View solution in original post

2 Replies
PeterBecker
Esri Regular Contributor

3857 is equivalent to Web Mercator Auxiliary Sphere which is a projection based on WGS84 datum.

4326 defines that the data is non projected but defined in Long,Lat values also based on WGS84 datum.

When you create a mosaic dataset you define the projection for the mosaic dataset. The source data can be in different projections and the requests can be in different datums. The system will transform the data from the source to the requested projection. This on the fly projection is very fast and add very limited overhead. The projection of the mosaic dataset has no effect on the performance. The slight loss of performance is due to the reprojection from the source data to that requested by the client application. The projection of the mosaic dataset is not very important so long as the data can fit in the bounds of the projection. Unless your are working on areas near the poles, I typically recommend users use Web Mercator Auxiliary Sphere for the mosaic dataset, unless the vast majority of your data is in another projection. The one disadvantage of using 4326 is the pixels sizes (which define scale) are in fractions of a degree (vs meters) which can be more difficult for user to understand. When you add an image service to a map in desktop it will be projected to the current map projection. Similar in most web applications the data will be projected to Web Mercator Auxiliary Sphere, unless the basemap of the webmap is different.

In the above you also refer to your LandCover dataset which has a Sinusoidal projection, but does not have a Datum defined. This should be checked. It is likely that the scale is so small that it make no difference. If undefined ArcGIS will assume it is in the same datum as the client is requesting. Just be aware that you have not defined a datum. If a datum is defined then then the transformation between the datum is also handled as part of the reprojection. I would recommend against re-projecting this data to a more optimum projection as this would add re-projection artifacts. If added to the mosaic dataset then users can access in any projection. Changing the client to the same projection would reduce any reprojection artifacts. Also note that a property set by the image service client is the type of resampling to be performed when reprojecting.

View solution in original post

tomwang1
Occasional Contributor

Super thanks Peter!

Reply
0 Kudos