Tag Archives: ArcGIS for Server
Recently Microsoft Windows Azure announced the General Availability of Virtual Machines. This allows you to start a virtual machine in the Windows Azure cloud (similar to what you can do with Hyper-V) while leveraging Windows Azure cloud features. It also means that you can now deploy ArcGIS 10.1 for Server on a Windows Azure virtual machine.
The ArcGIS for Server team is offering a workspace on http://ideas.esri.com under the name “Using ArcGIS 10.1 for Server on Microsoft Windows Azure”. You can join this workspace to find documents on how to deploy ArcGIS for Server on Windows Azure virtual machines. The workspace is also a great place to provide information about your interest in Windows Azure, give feedback, ask questions, and learn about the latest updates.
Although Windows Azure is not currently an officially supported platform for ArcGIS 10.1 for Server, Esri Support can still take your calls and will attempt to duplicate any issues on a supported platform. If the issue can be duplicated on the supported platform it will be logged for further investigation. See the Esri Supported Environment Policy for more information. Esri is looking into offering more extended support for Windows Azure virtual machines in the future.
Contributed by Marwa Mabrouk of Esri Product Management
Harnessing data quality feedback on a daily basis is a great way to keep your GIS data up-to-date and relevant. Of even greater value is the ability to extend your data quality workflows to include participation from the public, who … Continue reading
We recently released Service Pack 1 of ArcGIS 10.1 for Server, and we encourage server administrators to upgrade their instances to this release as soon as possible. You can watch this video to see benefits and features in the service … Continue reading
This post describes an easy way to deploy web mapping applications using Amazon’s Simple Storage Service (S3) to take advantage of the benefits of cloud computing. But first, let’s review some background information about using ArcGIS for Server in the Amazon cloud. Continue reading
It can take a long time to create an ArcGIS Server map cache that covers large scales over a broad area. This post describes some of the biggest factors that affect caching speed. You can read other more detailed considerations in Tips and Best Practices for Map Caches. Continue reading
Building a cache of tiled map images can be a great way to speed up your map services, especially detailed basemaps that give your application a geographic context. If you’ve attempted to build a map cache before, you’re probably aware … Continue reading
Although ArcGIS Server has been supported in the Amazon Elastic Compute Cloud (EC2) for several years, it gets a lot easier to build an ArcGIS Server site in the Amazon cloud at 10.1. This is thanks to a new application … Continue reading
You can try the application here:
This application allows a client to upload a CSV file onto the server and to draw counties based on an attribute from the uploaded file. As part of that process, the application executes a geoprocessing task which converts the CSV file into a table in a file geodatabase, then sets a join and a renderer to a sublayer in the dynamic map service layer. Note that every draw request that goes to the map service needs to include the full definition of the join and the renderer because requests are stateless. Continue reading
This post describes how we at the Esri Technical Marketing group addressed the architectural challenge of frequently updating web applications hosted on the Amazon Elastic Compute Cloud (EC2). Because you may encounter similar scenarios when hosting your own ArcGIS Server applications on the cloud, we wanted to share our approach.
Esri Technical Marketing maintains an Amazon cloud based, load balanced, scalable, application server that hosts web mapping applications. These apps require high amounts of revision due to the nature of the type of applications we generally work on. Many of our apps are built to provide information about emergency situations. These apps are released very soon after the emergency, allowing for little testing beforehand. Between the bugs inherent in fast development and the changing nature of the emergency situations, the apps experience a lot of iteration.
Updating these apps with traditional methods would require updating the staging instance, generating an AMI, and then launching new instances to replace the existing live instances: a tedious and time consuming task. Another option would be to manually update each machine individually, but this can lead to human error on live machines. In a load balanced environment like we use, this results in different experiences for users and it can be difficult to determine which machine is the cause of the problem. These solutions are not practical for our release cycle, which often consists of several changes per week or even per day. We needed a way of updating multiple live instances seamlessly, while maintaining the ability to scale our servers as demand increases. Continue reading