Map Viewer Classic and Map Viewer - Layer alignment issues

1941
3
Jump to solution
04-19-2021 09:05 AM
Labels (2)
DavidColey
Frequent Contributor

Hello - has anyone noticed certain large polygon layers (Parcels over Lots, for example) will not align correctly since the ArcGIS Online update on 4/15?  The misalignment is occurring in both the Map Viewer & Map Viewer Classic on AGOL, AND in both Map Viewer & Map Viewer Beta 5 in the 10.8.1 Portal.

The layers are posted to my 10.8.1 portal and sent to AGOL via distributed collaboration as reference.

Because the hosted or referenced collaborated layers do not misalign in a Pro 2.7.3 web mercator map page, I suspect the map viewers.  It feels like a 'lag', like the new layers won't 'snap' into place -

It's as if the transformation is not happening when overlaying certain FL State Plane West HARN (WKID 2882) layers over the current web mercator basemaps. 

Thanks,

David

1 Solution

Accepted Solutions
DavidColey
Frequent Contributor

Hello all - I figured out what has been happening.  Turns out this is not an Online or an Enterprise issue but rather a Pro issue at 2.7.3.  And it's not really an issue, just a setting change that has occurred.

I use the sharing module in Pro to create sddrafts, sdfiles and then upload those files either by the api or through the sharing modules arcpy.UploadServiceDefinition_server().  My Aprx's maps are all native State Plane coordinate system. 

However, beginning at 2.7.3, it appears that you need to set the transformation as an 'Additional Transformation' property from State Plane HARN NAD 83 to WGS84.  In our case, its the NAD 1983 HARN To WGS 1984 2 transformation. 

Once I did this, I no longer see a shift in my data.  

View solution in original post

Tags (2)
0 Kudos
3 Replies
EllenNodwell_IntegraShare
Occasional Contributor

Hi David,

One thought - and you might have already considered this, but if not, we can review something that might be causing these issues...

Before you published, did you conduct the re-project geoprocessing operation on each of your "to be published" data layers, using the geoprocessing tools in ArcGIS Pro, re-projecting from their existing CRS/projection into Web Mercator? 

You likely know this, but to review this concept, inside of Pro (or ArcMap), whenever you add a layer to an existing map that is in a certain projection, there is a transformation that occurs with any layers added to the map from their CRS/projection to that of the map.

However, the data itself isn't re-projected in this operation.  Re-projection requires a deliberate geoprocessing operation in order to re-project the data from it's current CRS/projection into a different CRS/projection system.  Those tools are in the data management geoprocessing tools.

Sometimes, the misalignments and inability to view results after publishing, are due to these projection misfit issues.  This can happen when sharing from desktop application, maps or features, where layers in the maps may be of various CRS/projections, and have been transformed on the fly, to align for viewing in the given map. 

When sharing published map services or feature services, it can be problematic if certain steps are not taken ahead of time with the data itself to prepare for publishing.  Usually, however, if there are mixed projections in the map or features being shared, an error is noted in the analysis ahead of publishing, when this is an issue.  

For publishing to web services, what I typically do, since most layers need to work in Web Mercator, is to make a re-projected copy of my layer(s) that will be published as web services. 

  • I keep the originals in their original working projection, as my base data, which I will use for re-projecting to the required CRS/projection for specific purposes. 
  • If the data is edited, I can re-run this again if I save that geoprocessing task in a Model Builder model. 
  • I have found that it's also helpful to note all of this information in the layer's metadata, for later reference or for others, to understand what operations have been undertaken and the original data source's CRS/projection.

If you have covered all of these bases, then it could be something else.

In the meantime, I will see if this is an issue in any of my maps created in Map Viewer Classic, that I open up in the new Map Viewer. 

With change always comes an amount of change management.  The new #MapViewer has lots of cool features and is still missing some old favorite features in Map Viewer Classic, but, continuing to  communicate what we need is part of the adoption process.

Hope it helps!

0 Kudos
DavidColey
Frequent Contributor

Thanks for the reply Ellen.  Yes I've covered all of these bases long ago.  Because of OpenData, we keep all of our Enterprise hosted feature layers in their native coordinate system - I do no re-projection from State Plane to Web Mercator at the source in Pro. 

We allow the map viewer to handle the reprojection on the fly, where it has always worked well in both Classic/Beta Beta/Viewer.  As I said, this only recently started and only with a couple of large parcel layers and is now present in both Online viewers

I like the Beta/New Viewer and I understand change management.  Regardless of this hiccup, I continually recommend to staff that they migrate any of their web maps that they can.

Thanks for looking into this- nice to get a reply!

David

0 Kudos
DavidColey
Frequent Contributor

Hello all - I figured out what has been happening.  Turns out this is not an Online or an Enterprise issue but rather a Pro issue at 2.7.3.  And it's not really an issue, just a setting change that has occurred.

I use the sharing module in Pro to create sddrafts, sdfiles and then upload those files either by the api or through the sharing modules arcpy.UploadServiceDefinition_server().  My Aprx's maps are all native State Plane coordinate system. 

However, beginning at 2.7.3, it appears that you need to set the transformation as an 'Additional Transformation' property from State Plane HARN NAD 83 to WGS84.  In our case, its the NAD 1983 HARN To WGS 1984 2 transformation. 

Once I did this, I no longer see a shift in my data.  

Tags (2)
0 Kudos