Published Services and their Spatial References in Portal

Q&A
1

Lately I’ve been rethinking how to best configure feature services in my Portal. Nearly all services are referenced back to SQL databases rather than hosted. This is causing DynamicMappingHost errors. For the dataset that do not change regularly, I will be publishing them as hosted. By doing this the dynamic datasets won’t be conflicting with them.

The second part of this question is about spatial references. Naturally local city data is in NAD83. Portal and ArcGIS Online will project to WGS84 on the fly. Publishing a services in WGS84 is more efficient since the system won’t have to convert them. That leads into the question of: How does everyone manage this? I was thinking about having 2 feature classes, such as City_Limit_NAD83 and City_Limit_WGS84 in my database. Or I could have a temporary file geodatabase for the reprojection.

Thanks for the input.

2

Ah, yes. The DynamicMappingHost error, my old enemy. It sounds like a solid plan for getting around that particular issue.

For the CRS, we publish a number of hosted layers in state plane, and our web maps do not seem adversely impacted by doing so. I think breaking out a few hosted services is a good move, but I’d really be surprised if reprojecting it before publishing will be worth the trouble.

But let’s suppose that it is, just to get some ideas going. I would advise against a second standalone feature class in the database itself, as that becomes another thing you have to update and keep in sync. If the source data is in a database, how about a view layer?

I don’t know what RDBMS you’re on, but you could have a view layer to handle the reprojection,[1] and then publish / overwrite the hosted layer from that.

SELECT
  field1,
  feild2,
  -- and so on
  ST_Transform(geometry, 3857) AS geometry
FROM your_table

Our Usual Approach

At Kendall, we have a number of hosted layers that are disconnected from their original source, which we publish specifically for our web maps. I like to think our update process is pretty streamlined.

To keep things in sync, we make sure that

  1. The hosted layer includes a GUID field to hold the source GlobalID
  2. The source layer has some kind of editor tracking enabled

At regular intervals, a python script will

  1. Look for recent edits in the source layer
  2. Identify corresponding rows in the hosted layer, using the GlobalID / GUID fields
  3. Make some adjustments, like changing fields or reprojecting geometry
  4. Apply edits to the hosted layer in place

It might be a little more to set up, but has the benefit of never needing your hosted layer to be fully overwritten, and is easier on the source layer database / hosting server, since the edit volume may be fairly low. No need to republish features that haven’t changed since the last update!

  1. that’s ST_Transform in PostGIS ↩︎