Latest Contributions by KevinHibma

Make sure the box on the left side "show desktop content" has been checked ... View more

It looks like the guys from Boston did recompile agssom for 10.1 and presumably 10.2. I'm not 100% sure if agssom needs to compile against a particular version with the changes from 10.1/10.2 compared to 10.0. Anyways, agssom and the ArcGIS Administration Toolkit can be found here: http://www.arcgis.com/home/search.html?q=agssom&t=content In short, both these samples build off the command line tools idea that Steve posted, but leveraging the API via .NET or Python. ... View more

[I got here following this post: http://forums.arcgis.com/threads/94059-Does-creating-a-FeatureLayer-speed-up-arcpy-processing-Looks-like-it... ] Chris, Your code sample isn't correct. When you're changing schema on a featurelayer, you're changing schema on the source. Thus the featurelayers built off that will have a new field available. A featurelayer is much more like a pointer to data than it is data itself. However a featurelayer honors selection, like you've shown. import arcpy arcpy.MakeFeatureLayer_management(r'D:\temp\gpKML\data.gdb\points',"lyr1","FIELD1 ='aaa'") arcpy.MakeFeatureLayer_management(r'D:\temp\gpKML\data.gdb\points',"lyr__2","FIELD1 ='bbb'") #add to lyr1 arcpy.AddField_management("lyr1", "NEWLONG","LONG") #calc that new field on lyr__2 arcpy.CalculateField_management("lyr__2","NEWLONG", 222, "PYTHON") print "fields..." for field in arcpy.ListFields("lyr__2"):     print field.name print "   values for lyr1:"    with arcpy.da.SearchCursor("lyr1", ("NEWLONG")) as cursor:     for row in cursor:         print row[0] print "   values for lyr__2:" with arcpy.da.SearchCursor("lyr__2", ("NEWLONG")) as cursor:     for row in cursor:         print row[0] OUTPUT: fields... OBJECTID SHAPE field1 NEWLONG    values for lyr1: None    values for lyr__2: 222 I'll just make a general statement about performance.... in general, layers (feature layers, table views, etc) are faster to operate on because "they're open". A very crude test would be to buffer 100,000 points 50x. If you had this as a layer the gp operations dont have to go back and re-open the data every execution vs if you were referencing the featureclass itself. Of course I'm talking about the performance of buffer, not any of the costs of creating the layer. But hey, if you're doing the same operation 50x you probably wouldnt be re-constructing the layer 50x, just once, right? (remember, this is an in-general statement. There's probably exceptions depending on machines, data, and functions being used) ... View more

Yes. Python toolboxes can be published as a GP Service. ... View more

OR MAYBE THIS, IF YOU LIKE IT BETTER: (either way, pathnames are assembled out of text passed in) >>> import os >>> os.path.join(workspace, GetPolyFC) '\\\\myServer\\myGDB.sde\\my user-defined value' >>> 100% use os.path.join. Please dont "add (+)" paths together. Scripts and publishing of those scripts aren't guaranteed to work as we might not be able to find data. Using the OS methods as you describe is the way to go. And you're doing great with the explanation. I tried to help over here: http://gis.stackexchange.com/questions/72719/field-does-not-get-updated-with-geoprocessing-service/72723 but I'm still not 100% sure the goal of this project. Wayne has done a good job explaining the different input methods with GP Server, but I'm still confused if ionara_wilson is wanting to provide features to the GP Service, or if the data is already on the Server. The Service Editor may modify the input parameter's input mode when publishing based on what we think you want when you have an unsupported input type. Simply pressing the "publish" button without checking and ensuring the input type is correct might be whats going wrong here. To sum up how it works one more time, because I'm not sure what the desired goal is besides "calculating a value". --feature class as input is not supported with GP Server. If your model/script is taking a featureclass as input, we change that to FeatureSet in the Service Editor. Your only other option would be to hardcode it by setting it to "constant". --FeatureSet is a supported input type. If you've set to featureset, we leave it as featureset. FeatureSet allows you to digitize features and send them. If you're using REST, you can send a GPFeatureRecordSet, which is basically just the JSON representation of the features you want the service to use. --Using a layer as an input the the tool, it gets mapped to Choice List in the Service Editor. A choice list means that and any other layers which are checked off will be available for use in the service. Your "select" them by name when consumed via REST. Looking at that parameter in the REST end point, you'll see that choice list of layers and the name you'd choose. Based on the last script you've posted, it seems you want to update a featureclass. At the risk of confusing everything, I've modified the script to make use of LAYERS which get name matched from the tool. (thats how they're found). I suggest this as its a performance gain and the better way to work against data (vs. continually going back and re-opening it at the source: sde). If this doesn't make sense then go the way you are, just change this: "Database Connections\\Connection to tfsgis-iisd01IWILSON.sde\\%s" %Input_Points to this: os.path.join("Database Connections\\Connection to tfsgis-iisd01IWILSON.sde", Input_Points) import os, sys, arcpy, traceback, arcgisscripting # DELETED WORKSPACE AND REFERENCE TO SDE FILES # Script arguments Selecting_Features = arcpy.GetParameterAsText(0) value = arcpy.GetParameterAsText(1) stewardship =  arcpy.GetParameterAsText(2) # DELETED MAKE FEATURE LAYER.... #Drag the layer from SDE you want into ArcMap. Its this layer: #Connection to tfsgis-iisd01IWILSON.sde\sars.dbo.CITYTEST #Name that layer in the TOC "CITYTEST" #You'll have a variable in the script which references that layer, here: myLayerToModify = "CITYTEST" #When you run this script, in ArcMap, it will look for a layer called CITYTEST when you use the myLayerToModify variable. A name matching occurs. #This variable "myLayerToModify" will be used in the script. You don't need MakeFeatureLayer. # Process: Select Layer By Location arcpy.SelectLayerByLocation_management(myLayerToModify, "INTERSECT", Selecting_Features, "", "NEW_SELECTION") # Process: Calculate Field #arcpy.CalculateField_management(myLayerToModify, "City, '"' + value + '"', "PYTHON_9.3") with arcpy.da.UpdateCursor(myLayerToModify, ("City")) as rows:         # row comes back as a tuple in the order specified here, so Office is row[0], Forester is row[1]         for row in rows:             row[0] = value                        rows.updateRow(row) Either approach you take, I don't see any reason why you can't reference the same sde layers here in the GP Service which would also be the same layers the feature service runs off of. Fast forward to about 28minutes into this video: http://video.esri.com/watch/1658/creating-geoprocessing-services Scott explain's parameter transformation and datastore, then I do a demo which uses SDE data that is consumed both from a FeatureService and a GP Service.  (edits made the to FS impact the result of the GP Service) ... View more

While the help mentions Modelbuilder, the true is same for scripting. In ModelBuilder, you can use the Select Data tool to extract specific layers from the group layer and the Make_Feature_Layer tool to create a feature layer from the output of the Select Data tool. I find it easier to run it in ArcMap once to figure out what layer you want from the group, then write the Python for Select followed by either Copy Features or Make Feature Layer (depending on the goals of your task). ... View more

In response to your first paragraph: Exactly! 🙂 Yeah, I'd guess at this point you need to get into a custom web app (javascript, silverlight, etc). There aren't any plans in the near future (to my knowledge) to bring GP Services into a WebMap. Since a GP Service can have any number of inputs or outputs, doing so requires the process to be pretty flexible. That is code to scan and examine the GP Service, then write the proper code to consume it in a WebMap. I know for example, we have the Sivelight builder which constructs web apps: it does exactly this for a GP Service. When building, it has code to examine a service and construct the behind the scenes code to add a gp interface into the application. To go back to your question about GP + WebMaps: it's a good thought, I'll drop a note to the particular team, but like I said, to my knowledge it's not on the radar so it's hard to say if/when we'd do it. ... View more

I've got no experience trying what you proposed, so I couldn't even hazard a guess if it would work or not, but I have this: Backing up and restoring your ArcGIS Server site configuration Backup utility It might be worth investigating and giving a try. ... View more

Jake, Is your map service externally available and fully qualified? like: http://mygisserver.mycompany.com/arcgis/rest/myservice The analysis services will work on regular ArcGIS Server map services. For example, you could use this map service as input: http://sampleserver6.arcgisonline.com/arcgis/rest/services/Census/MapServer ... View more

A Map service (not feature, but map) can use data from different sources: workgroup (sql express), enterprise (sql server), file based (shapefiles, grids, etc), local geodatabase (file geodatabase), etc. It can use one of these file types, some or all at the same time. It doesn't matter. The technical details is when you're publishing this particular service you need to setup the data store entry, else it'll copy you data over to the server. But that's just a technical detail, it shouldn't impact your decision on the version of server you need. My question to you is how do you want to display it and have them download it? There's a common workflow involving geoprocessing: you put any/everything you could want a user to download in a map, and publish the map + geoprocessing service. The GP Service "Clips and Zips" the output, allowing the user to extract the layers and area they want. You can build a web application to do this, or they can consume it back in ArcMap. This would require the Standard version of Server, but sounds like it may do what you want? If you're looking into a geodata service this is mostly for geodatabase replication. Read this small help topic, it should quickly tell you yes or no if thats fits into your workflow. Also note, your question 7, you say "...post a web map and use a geodata service, and go with a lower level of Server (ie. Basic)..". Answering based on what I think you want, the answer is probably "no", as Basic server supports geodata and feature service, but not map services. This help topic outlines some of the high level differences. You could create a web application to consume the feature service, but you don't have raster support and I'm not sure how you'd "get the data". Your questions on the imagery extension should be answered in the Functionality Matrix found here (pg8). I guess to sum up, I go back to my question on how it is you want to display and have them download. Based on the points of differing data types and formats, I assume you'll be using a map service (which requires Standard). Read some of the technical notes here regarding feature service deployment. A couple of the key points being: "All data must be from a single geodatabas"e and "Raster datasets not supported in a feature service." It's important to fully understand the difference between feature service and map service as you move forward. Hope this has answered some of your questions as you plan you deployment. ... View more

From the previous testing I've done, the following should do what you want: Log on to the machine, open ArcMap, and sign in (make note of the account you logged into Windows with) Make sure you've checked the automatic sign in on the Portal sign in box. Create your scheduled task (it must run under the same windows user account from above) The key here is to log in once, have it be remembered, then have the task run under the user account which had logged in previously. Of course, make sure the SignInToPortal tool has been commented out. If I get time later this afternoon I'll give this another go. ... View more

Danik, Erik, With the 10.2 release, the authentication method for Portal has changed, as such the SignIntoPortal tool is no longer necessary. We're currently investigating why the tool is causing these sorts of issues. (It should have just passed through the tool with a warning message indicating you need to Sign In from the ArcMap menu) To get around the issue for now: Dont use the SignIn tool in your script/workflows Any machine you want to run this script from, must first open ArcMap, and use File > Sign In with the automatic option checked ... View more

Glad to hear! This particular issue looks to be fixed in 10.2: NIM085149 -Python toolboxes crash ArcCatalog when previously run Python toolbox tool results are saved with the application. ... View more