CityEngine, through the use of CGA rules, allows for mass modeling of cities. In the current software, GIS support is available in the advanced version of CityEngine. You can access values such as land use, building heights, roof type, tree heights, etc. from a GIS feature's attribute table and then use that value to drive mass modeling rules. Below is a screen shot from the CityEngine Inspector window that shows GIS attributes for a shape that has been initialized for use through a rule file.

Are you working to put together a migration plan for the transition to ArcGIS 10.1 for Server? Because there are significant changes in the software architecture at ArcGIS 10.1 for Server, a number of hints and tips have been put together to help you through the process.

Good to Know

At ArcGIS 10.1 for Server, service configuration files from previous versions will no longer work. (At previous releases, service configuration files would remain valid.) Version 10.1 uses a different mechanism for map services called the Service Definition (SD), which is not a text configuration file as it was in previous versions. Previously created map caches will remain valid.

ArcGIS for Server 10.1 no longer uses SOM and SOC. At 10.0, you had to manage accounts for each, but at 10.1, you’ll only have to manage one account.

The concept of a distributed installation with multiple SOC machines attached to one or more SOM boxes is also going away. Each GIS server is its own installation. GIS server machines and services may be clustered together using tools available in ArcGIS Server Manager to offer better computing power, but each ArcGIS for Server machine is effectively autonomous.

There is no longer a differentiation between the Java and .Net versions of ArcGIS for Server. Now it’s just ArcGIS for Server. The product installs with its own application server; this server should be dedicated to ArcGIS for Server and nothing else. Esri has created applications, called “Web Adapters,” that link your current server of choice (IIS or a J2EE application server) to the GIS server instance. These applications are small broker components that basically forward requests from your web server to the internal server used with ArcGIS.

When you create an administrative connection to ArcGIS for Server 10.1, you’ll have the option to package and copy data in the Service Definition and push the whole package up to a GIS server. This means that an SD is portable – a user in one location can create a service definition and ship it to the GIS server owner without having to worry about an account having access to data in the remote location.

Ways to Prepare

It’s important to maintain a parallel environment between your current implementation and an install of version 10.1. If you don’t have the budget to maintain multiple ArcGIS for Server machines, your organization should, at the minimum, stand up ArcGIS for Server 10.1 on a desktop class box.

DCOM in ArcGIS for Server is going away, which means that local connections will no longer be allowed. If your current applications use local connections for operations like editing in the ADF, you’ll want to plan on replacing those local connections with feature services.

There’s no longer an application builder in ArcGIS Server Manager as the ADF has been phased out. There are great options available in the Flex and Silverlight viewers. I especially like the Silverlight viewer. If you haven’t seen it, I recommend logging into the Beta Community and downloading it.

In preparing for the differences in ArcGIS for Server 10.1, we’d like to encourage you to get involved in the Beta Community and learn the new workflows, features and functionality. Take notes of what does and doesn’t work in your organization, and if you find an issue that you believe is a bug, report it to us so that we can confirm and log it. If nothing else, go ahead and replicate your current services in 10.1 so as to minimize any downtime associated with the transition to version 10.1.Randall W. - Server Usage Support Analyst

As we all know there is no “magic” button in ArcGIS for Desktop that will fix all the issues that you are having. In my time working in support, however, I have found that exporting data comes quite close and often returns magical results when working with corrupted data. Today we will be looking at using this method to resolve issues with an X,Y Event Layer.

Have you ever had an event layer show up beautifully in your map, but when exporting it to a shapefile you ran into an issue? Some of these issues could be receiving an error (such as “the data you are exporting contains one or more blob field”), getting a blank attribute table, or finding that not all of your fields are coming through to the shapefile. The steps below work, in most instances, to help resolve this issue. These steps walk you through the process of exporting a table to a DBF, displaying that DBF as an event layer, and then exporting that event layer to a shapefile.

4) Select the file folder to navigate to the appropriate output location.

5) Select the “Save as type” as dBASE table. And then click Save.

6) Select OK on the Export Data Screen.

7) When prompted, select “Yes” to add a new table to the current map.You will now have a new, and hopefully cleaner, version of your data in the map. 8) Right-click on the table you just added to the map and select “Display XY Data".

9) Select the appropriate X and Y fields as well as adding a coordinate system to your data (as you had done before). Finish by selecting “OK”.

10) Once your new event layer is displayed, right-click on it in the table of contents and select Data> Export Data.

And voila! You should now be able to create a shapefile or feature class!Juliana W. - Desktop Support Analyst

An interview with Desktop geoprocessing and Python analyst, Stephanie W.Bringing you another member of our support staff, we interviewed Stephanie who is a support analyst from the Charlotte, NC office. We talked with Stephanie about everything from her hobbies, a recent trip to the South East User Conference, and Stephanie's career at Esri after studying geography at UNC Chapel Hill.Support Services Blog: Tell us a little bit about yourself and how you got into GIS?Stephanie: Growing up I lived in Wisconsin and Michigan, but I would consider North Carolina my home. My dad got me into GIS with his career as a weather man. He is always working with maps and his passion for weather really inspired me and in turn got me interested in the environment. As I got older, I realized the environment was a lot more complex when you added humans into the mix. This helped me to develop a curiosity about geography and from there GIS was the ultimate tool to understand this connection.

SSB: What brought you to Esri?Stephanie: In my job search, I was always considering the companies I heard of while in school. Esri seemed like a good place to try since it was mostly what I learned GIS on and they are a leader in the GIS industry. I was very fortunate to meet some Esri employees at a career fair at UNC Charlotte and before I knew it I was showing up for my first day at work!SSB: Tell us a little bit about your role as a desktop support analyst and what you like best about being a support analyst.Stephanie: Since this is my first real GIS job, I had a lot to learn. It was a challenge from day one to absorb all the information about the parts of GIS I had never used or even heard of. But this challenge is one of my favorite parts about working in support, I am always learning every single day. In desktop, we work on a wide range of issues. My most favorite is working on geoprocessing incidents that come in as I enjoy figuring out suitable workflows for users or what is causing the tools to fail. Geoprocessing is what really led me to learn Python, which is now my favorite specialty. It really is amazing what things you can do with this simple language to automate your processes and workflows. It's also like a game to me to try and figure out the minor things that need to be changed or done to make the script work perfectly. I know, I know, you probably think I'm crazy to think coding would be any kind of fun!SSB: How do you describe to family members and friends what you do for a living supporting Esri products?Stephanie: I still don't think I have this worked out yet. Sometimes I try to explain that I work with maps for a living. However, when I tell people that I work in a support center, I often end up getting dragged over to my family member’s computer to fix random issues with their OS (usually having nothing to do with GIS!). It seems like it has always been hard to explain to people what one might do with geography and GIS, but if they would just think more about the connection place has with components of society and the environment, they would realize it is a lot more important that just knowing where things are on a map.SSB: So what have you been up to lately at work?Stephanie: Recently, I attended the South East User Conference in Orlando, Florida. It was like a mini-UC for any of you who have been. It was a ton of fun to meet GIS users face to face and help people directly face to face. It is also great to see all the cool projects that people are using GIS for in their day to day lives. And you’re probably thinking, "Orlando, Stephanie… tell us you went to Disney too!" Well how could I not! I was a girl on a mission and hustled around to three of the parks. I needed to get back to my desk just to have a break. But for those of you who've never been to an Esri conference, go! Even if you can't make it to the big one in San Diego, go. It's a great experience to meet people who share the same passion for GIS and to learn new things about what is happening in the world of GIS.SSB: Tell me a little bit about yourself outside of work. Are there any hobbies that you enjoy?Stephanie: Outside of work, I enjoy painting. I've been oil painting for over a year now at the civic center near my house. I love it because time just slows down and my brain can take a break from all the learning that I did throughout the day. I also just recently adopted a dog. He is a basset hound mix; you know the short legs, long body. He's a cutie. We enjoy taking long walks on the greenway near our house. I also enjoy photography; I do okay, with a good picture every once in a while.Previous “Getting to Know Esri Support” Interviews

Have you ever set up a workspace in CityEngine, copied your project into the workspace folder, but found that CityEngine didn't recognize the new folder? This can be avoided by following the import project workflow described below.

Have you ever had a 1:M relationship but did not want to perform a relate? You might consider using the Make Query Table tool to accomplish this task. Typically when performing a 1:M join, only the first record will be joined and the subsequent records will not. In instances such as this, I often recommend using a relate or relationship class instead of a join. However, using the Make Query Table tool is another option for performing this task and can also be an effective way of querying out matching records from two separate tables or feature classes.

You can access this tool by navigating to the ArcToolbox > Data Management Tools > Layers and Table Views > Make Query Table. To perform this, your tables and/or feature classes must be in the same location (the same file, personal, or SDE geodatabase).Steps

First add your table, then your feature class to the Input tables box.

Select the Fields you want in the resulting table view.*If you want to include geometry in the output and not just a table view, be sure to select the shape fields.

Click SQL. Write a statement similar to the one in the following graphic. This statement is basically saying, give me all records that match between the table and the feature class. Click OK.

Give your Table a name.

Select the option to use Virtual Key Fields.

Click OK.

Once this finishes running, export the output to a new feature class, as this is only an event layer and will not save outside of the MXD.

For more on this tool, please visit the Resource Center help page for the Make Query Table tool.Lucas D. - Desktop Support Analyst

Most of us here are relatively familiar with ArcGIS Server for .Net. However, in support our exposure to the Java product is relatively limited, simply because it seems that fewer customers have implemented ArcGIS Server for Java. In this post, I'll try to cover a topic that comes up every now and then in support, how to secure both OGC and Esri GIS Service endpoints provided by the same instance of ArcGIS Server. This concept is similar to but implemented differently than the ArcGIS Server for .Net help topic "Multiple ArcGIS Server Web Instances for Security".

Before we begin, lets review a couple of best practices (things that are good to know) that we should understand prior to engaging in any configurations.

First, have a quick look at the documentation regarding exporting the ArcGIS Server 10 for Java web service and REST handlers. The Tomcat web server that ships with ArcGIS Server for Java should be used for development and ArcGIS Server administration. It's not really meant for handling the load of production work. We recommend using ArcGIS Server manager to export your REST, web service, and token applications out to a standard .WAR file and then deploying those .WAR files to your favorite J2EE web server for production use.

It's important to recognize that there is no provision in the OGC spec for token based authentication with OGC services. This means that if you'd like to secure your WMS, WFS, or WCS Services, you'll need to use a more standard authentication mechanism other than the Esri provided token service, like HTTP BASIC or DIGEST authentication.

Out of the box, without deploying the GIS Server handlers to an external J2EE server, ArcGIS Server for Java will be limited to a single authentication mechanism. However, as we'll discuss below, we can work around this limitation by deploying multiple web services handlers - each with it's own authentication mechanism.

To accommodate this configuration, we'll use Tomcat 7 (either 32- or 64-bit is fine, just be sure that if you've got the same bit level Java installed as whichever Tomcat you choose).

While you're setting up Tomcat, since we'll be working with authentication, you'll also want to stand up HTTPS/SSL. Otherwise, your credentials and tokens will be passed in clear text over the wire. In my testing, I generally create a SSL repository and self signed certificate using the keytool command. SSL is required when working with the token service with ArcGIS Server for Java, and there is not a supported way to disable this requirement like there is in the .Net product.

After Tomcat is installed and configured with SSL, set up your security store. For this example, we'll set ArcGIS Server to use ArcGIS Token Authentication and enable security for your services. Test to verify that security is working.

Next, we'll export the SOAP (web services), REST, and token service handlers, and then deploy them to the external instance of Tomcat and test to verify that the services can be reached. When I export my web handlers, I usually stick with generic application names, like 'REST', 'Services', and 'Tokens'.

When you're configuring the SOAP and REST handlers, make sure that you enable authentication using the ArcGIS token service, and make sure that the token service URL is pointing to the token service handler deployed on the "external" instance of Tomcat.

After they've been successfully deployed to Tomcat, test to verify that you can reach your REST endpoints and service WSDLs. Keep in mind that unless a new context path is explicitly defined, these applications will deploy to the root of the web server. That means that your URLs to your service endpoints will look similar to these (using Tomcat's default HTTPS port):

https://myserver:8443/services?wsdl

https://myserver:8443/rest/services

Once you've tested to verify that the service handlers are working as expected, including requiring authentication to the secured services, it's time to deploy another services handler. This one we'll use to access our secure OGC services. In this case, since we know that OGC services do not support token based authentication, we'll configure the services handler to use basic or digest authentication. We can use the same security store created earlier when we secured the services, but we can't use the token service.

Export this application as a .WAR, and name it something like "OGC".

Keep in mind that since we're now using an external instance of Tomcat, we'll also need to make a quick modification to the tomcat-users.xml file. Otherwise, Tomcat won't be able to recognize the users and roles you set with the internal Tomcat and service handlers that were created using the ArcGIS Server Manager GUI experience. By default, you'll find that file here: C:Program FilesApache Software FoundationTomcat 7.0conf

Open Tomcat-Users.xml with a text editor and uncomment the users and roles section, then add lines to this file to match the users and you've created you created in the GIS Server security store, like this:

Finally, give the Apache Tomcat service a restart so that Tomcat recognizes the new users and roles.

You should then be able to pass credentials to reach your OCG services, like this:

To summarize, because OGC services do not support token based authentication, we essentially exported two sets of service handlers: one for our REST services using the token service, and another for our OGC services using basic or digest authentication. Services delivered over SOAP may be authenticated using either endpoint, depending on the requirements of the client application.Randall W. - Server Support Analyst