How do you manage your mapservices?
Hi Everyone,
We are relatively new to the Geocortex world so please take it easy on us J
We are in the process of building some internal sites and we would like to know how other organisations manage the mapservices that they use within their sites.
We have an arcgis server with published mapservices and we currently use those mapservices in a number of ArcGIS mobile projects. We have tried to create our mapservices so that they contain related “themed” feature classes. For example we have created a mapservice called “Sewerage Infrastructure” that contains the sewerage mains and points. We then use this mapservice in a number of places, ie ArcGIS mobile projects and Geocortex sites and possibly ArcGIS Desktop. This allows us to maintain consistent look and feel of the data across platforms and if we need to change something, we only have to change it in one service.
How do people manage the situation where additional feature classes need to be added or schema changes have to be made to the mapservice for whatever reason? Do you create a v2 of the mapservice and then recreate mobile and geocortex sites with the new service? Or update the existing service and then go back and fix the broken things in the products, ie REST ID endpoint numbers in viewers and workflows etc? Only publish one feature class per mapservice? Are there any other strategies that people use?
Ultimately long term we would look at moving away from ArcGIS mobile and using the HTML5 off line capabilities if possible to simplify projects, but that is some time away for us.
I suppose this also depends a lot on the size of the organisation. For us I am only talking about 8 mobile projects and at this point only about 5 Geocortex sites and all mapservices published off the one ArcGIS Server.
I am just trying to get a feel for how other organisations manage these types of things particularly in a local government environment. As we are a pretty new Geocortex site I would like to try and work out a strategy that will cause us the least amount pain for when changes need to happen in the future.
Regards
Steve
Bundaberg Regional Council
-
I ended up creating one map service for each application. My thinking is that if a shared service fails or gets altered it would have repercussions across the dependent applications. Keeping a one service per application helps keep the troubleshooting and management simpler. We will keep this model until it does not work anymore.
Hope this helps.
Robert
0 -
Steve,
We are also a new user to Geocortex. I'm shifting our viewers over from the ESRI Flex Viewer. Like you, our map services are published by "theme" with an eye on the ability to "mix and match" map services to present the right mix of data for a particular viewer. That also gives us the ability to set different transparency levels per map service--at least that was useful on the Flex Viewer.
I am still learning Geocortex and am still in the process of adding all of our map services to a "kitchen sink" site that I will use to create our "real" sites that inherit the settings from the "sink". An issue I have to research a bit more is that when I view my site via the HTML5 viewer, any map service that is turned off when the site is initially loaded has all of the layers within the service unchecked as well. I typically have one or more layers pre-set to be visible when a user turns on a map service. This behavior adds steps to a user's ability to view a particular layer.
After taking the getting started class last week, however, I may be re-doing some of my map services due to the abilities within Geocortex for arranging layers. But that will depend upon what I find out about the layer visibility issue I describe above, because most of my users now know where to look for various data layers. I'd rather not derail that education if I can avoid it.
Brian
0 -
We have a hybrid situation going since we have map services for editing, map services with trimmed data for public, map services with full data for internal use and
map services for special groups such as public safety. I don't see this changing in the near future although we do need to consolidate and trim down a few of the applications.
0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
3 kommentarer