|
POST
|
1)For scripts being run on a scheduled basis, what determines which is used? Is it just the first one listed in sys.path? >> on a default install, Python doesn't get put into the PATH. What happens is the last Python (32 or 64 bit) that gets installed is the one file associations are set to. So if you double click a script in Explorer, whatever the last Python (Arc* product) installed is what it'll run under. 2) Can standalone scripts on the ArcGIS server use the server installation, or do they have to use the Desktop installation? >> yes. You can control what Python you execute against. See this blog topic. It's on 64bit Background, but the same applies for 64bit Server. http://blogs.esri.com/esri/arcgis/2012/11/12/python-scripting-with-64-bit-processing/ 3)Do geoprocessing services always use the server installation no matter what? (I assume yes) >> yes. 4)I notice that my 10.1 server by default installed server10.1.pth in the c:\python27\ArcGISx6410.1\Lib\site-packages whereas the desktop10.1.pth is in c:\python27\ArcGIS10.1\Lib\site-packages. Is this really best practice or should I have both use the 32 bit version? >> You need both. You have and need a 32bit and 64bit version of Python. If you modify those files bad things may happen. "Dont cross the bits!" 🙂
... View more
10-10-2013
04:55 AM
|
0
|
0
|
664
|
|
POST
|
[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
10-04-2013
09:49 AM
|
0
|
0
|
1352
|
|
POST
|
Yes. Python toolboxes can be published as a GP Service.
... View more
10-02-2013
12:56 PM
|
0
|
0
|
1603
|
|
POST
|
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
10-02-2013
12:18 PM
|
0
|
0
|
589
|
|
POST
|
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
09-25-2013
07:33 AM
|
0
|
0
|
1658
|
|
POST
|
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
09-19-2013
04:52 AM
|
0
|
0
|
1861
|
|
POST
|
You'll want to read the first paragraph here and the section on Input URLs here. Because your services are either not fully qualified, or just not exposed to the "internet", it sounds like the features inside your services cannot be sent over to the arcgis.com analytic servers for the data to be crunched. I guess think about it this way, if you go home and try to consume the services and can't get to them, thats the same situation as the servers which do the processing.
... View more
09-17-2013
04:21 AM
|
0
|
0
|
1861
|
|
POST
|
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
09-16-2013
09:48 AM
|
0
|
0
|
514
|
|
POST
|
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
09-13-2013
06:21 AM
|
0
|
0
|
1861
|
|
POST
|
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
09-11-2013
05:27 AM
|
0
|
0
|
648
|
|
POST
|
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
09-10-2013
08:34 AM
|
0
|
0
|
2190
|
|
POST
|
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
09-10-2013
07:19 AM
|
0
|
0
|
2616
|
|
POST
|
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
09-10-2013
06:10 AM
|
0
|
0
|
1539
|
|
POST
|
Ok, looking through our bug queue, these are issues we've fixed in 10.2 or 10.2.1 (which we're working on right now, its not released yet). However, they're easy enough to work around by deleting a file When ArcCatalog opens, the tree opens to one particular folder. Make sure there are no PYTs in that folder. If there are any, move or delete them. You can find what directory this is by looking if the registry if you aren't sure: HKEY_Current_User\Software\Esri\Desktop10.1\ArcCatalog\Settings\LastLocation or Try deleting the ArcToolbox.dat found here: C:\Users\[USER NAME]\AppData\Roaming\ESRI\Desktop10.1\ArcToolbox\ArcToolbox.dat (this will reset your ArcCatalog profile) Hope one of these helps Joseph: could you post your PYT here for us to look at? thanks
... View more
09-10-2013
05:46 AM
|
0
|
0
|
1539
|
|
POST
|
In what directory did you create that PYT? Is there any other toolboxes in the same directory, like a regular toolbox? If you delete the PYT will ArcCatalog open? The circumstances of this crash sound familiar, but I dont exactly recall when we fixed it. I thought it was fixed in 10.1 sp1.
... View more
09-10-2013
05:07 AM
|
0
|
0
|
1539
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 09-20-2023 06:37 AM | |
| 1 | 09-18-2025 07:07 AM | |
| 3 | 09-18-2025 06:52 AM | |
| 1 | 03-23-2023 12:07 PM | |
| 1 | 10-21-2024 12:40 PM |
| Online Status |
Offline
|
| Date Last Visited |
09-30-2025
06:25 AM
|