topic Re: arcpy.mapping.MapDocument (using "current" vs. file path) in Python Questions

arcpy.mapping.MapDocument (using "current" vs. file path)

MichaelKozub — Thu, 13 Aug 2015 02:31:00 GMT

Question for the Python folks.

I'm trying to add a feature class from my scratch .gdb and have been successful using arcpy.mapping.addLayer. I'm adding the feature class to the mxd which is set to the following:

mxd = arcpy.mapping.MapDocument("current")

The problem is I'm trying to publish a script tool to a web service, and I know I cannot use "CURRENT" so instead I use the file path of my MXD. While the script tool works, creates my feature class in the scratch .gdb, it does not automatically add the feature class to my TOC as the above line of code does.

Here's what I'm changing it to instead:

mxd = arcpy.mapping.MapDocument("C:\\users\\testUser\\desktop\\testMap.mxd")

The only difference in the entire script is where I'm changing the MXD path. Am I doing this wrong? Any suggestions or recommendations?

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

DanPatterson_Retired — Thu, 13 Aug 2015 03:50:09 GMT

did you make a feature layer from the feature class?

http://desktop.arcgis.com/en/desktop/latest/tools/data-management-toolbox/make-feature-layer.htm

Then do you add it to the project?

http://desktop.arcgis.com/en/desktop/latest/analyze/arcpy-mapping/addlayer.htm

see the code snippet in the latter link

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

Luke_Pinner — Thu, 13 Aug 2015 03:56:34 GMT

Do you have the mxd open when you run that code? Are you expecting changes you make to the mxd file on disk to appear in the currently open ArcMap session? Are you calling mxd.save()?

Basically "CURRENT" is for interacting with the currently open ArcMap session. arcpy.mapping.MapDocument(filepath) is for interacting with an mxd file on disk. If you have the mxd file open, any changes you make to the file won't be reflected in the open ArcMap session.

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

MichaelKozub — Thu, 13 Aug 2015 04:09:56 GMT

Basically I am creating a feature layer from the {where_clause} below, then copying that feature layer into the gdb, hence where the feature class comes into play (check the bold print below). Does that make sense?

1) MakeFeatureLayer_management (in_features, out_layer, {where_clause}, {workspace}, {field_info})

Then I am copying the feature layer to the scratch gdb

2) CopyFeatures_management (in_features, out_feature_class, {config_keyword}, {spatial_grid_1}, {spatial_grid_2}, {spatial_grid_3})

Then finally I am adding it to the map.

3) AddLayer (data_frame, add_layer, {add_position})

I'll try to post the code once I'm back on my work computer.

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

MichaelKozub — Thu, 13 Aug 2015 04:18:46 GMT

Yes I have the mxd open when I am running that code, and I did not know using the filepath method won't be reflected in the open ArcMap session. Thanks for that!

My only concern is that I need to publish the result to a web service, and I only know how to do that in ArcMap using the geoprocessing result window. From what I've tried, if the layers do not appear in the TOC in an ArcMap session, the outputs in the web service do not appear in the MapServer. Any tips for this?

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

KevinHibma — Thu, 13 Aug 2015 13:22:56 GMT

What is your end goal? Using arcpy.mapping.MapDocument has pretty limited use in a GP Service. Its mainly good for printing and exporting. If you're trying to use this workflow to update a map you have locally...well I dont see the connection. If you can explain what you want to do (not how you're trying to do it), maybe someone can suggest a workflow.

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

MichaelKozub — Thu, 13 Aug 2015 14:21:52 GMT

Hey Kevin thanks for the response. I originally posted my end goal in another thread, but I'll copy and paste it here as well.

Web Service - Invalid return value // Outputs not showing up in TOC

Here's the goal:

Pass through anywhere from 1-4 input parameters into a web service, and get the same number of outputs as inputs. These outputs will all be line features.

In Python I’m basically creating a feature layer and then copying that into a scratch .gdb. In ArcMap I created a script tool to have 4 optional string inputs and 4 optional feature-class outputs respectively. When running the script in the python window, or the script as a tool in ArcMap, it works and performs as I’d expect. I can pass 1, 2, 3, or 4 parameters and I’ll get the proper amount of outputs.

Problem I:

If I don’t set the output parameters to the scratch gdb in the script tool, the lines do not automatically show up in the table of contents. For example, the first output parameter will be set to %scratchfolder%\\Scratch.gdb\\line0. They still show up in this scratch gdb because I defined that in the script, but for some reason aren't automatically appearing in the TOC.

Problem II:

The web service only seems to work when each input has a value, but when I leave one of the four inputs empty, I get an 'esriJobMessageTypeError. Invalid return value: c:\…’ response.

Any suggestions on how to go about this? Again here’s the problem. The script tool works in ArcMap with 1, 2, 3, or 4 inputs (this is what I want the web service to do!). The web service only works when all 4 inputs are satisfied. I can post screenshots and parts of my script if needed... Thanks!

-Mike

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

KevinHibma — Thu, 13 Aug 2015 14:49:16 GMT

Ok, your 2nd problem. GP Services are very strict with their input and output params. Optional output params in a GP Service is well........ not straight forward. Outputs get hardcoded with a gp service. When you run your tool in ArcMap before publishing, this sets up the "footprint" if you will of what the service will be like. So if you had 3 outputs when you ran in AM, once you publish it the service will want 3 outputs. Not 2, not 4, but 3. So anytime you start playing the optional game you're going to get into trouble.

For the 1st issue - I dont really understand what you're saying here. I can only guess this is a "tool problem", that is how the tool has been setup/configured. You're having the problem here before publishing? Or this is the published gp service? You're expecting to get the result back from the gp service and it gets added to ArcMap? As long as the output is a featureclass in the tool, yes it should be automatically added.

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

MichaelKozub — Thu, 13 Aug 2015 15:11:12 GMT

Let's stick with problem II for now. Knowing I'll be passing one-four parameters into the service, are you saying I should set all four inputs to required instead of optional? And then doing the same for the outputs?

Any other alternatives to using a GP service? In the most basic form all I need to do is draw four distinct lines on a map.

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

KevinHibma — Thu, 13 Aug 2015 15:23:03 GMT

Could you output 1 featureclass, but have anywhere between 1-4 features/records in that FC? Build a layerfile that has symbology set for 4 features based on a given field. Then in the script, generate those features and in the script tool output parameter symbology, use the layer file. After you publish the service and run it in arcmap, it'll draw the features based on that layerfile.

Re: arcpy.mapping.MapDocument (using "current" vs. file path)

MichaelKozub — Thu, 13 Aug 2015 23:45:31 GMT

So I ended up creating four feature classes, then merging them into one feature class at the end per your suggestion.

Additionally, I had to add a field and calculate the field to make each of the records in each of the feature classes unique, but anyways I got a desired web service to do what I needed it to do. The service now accepts anywhere from 1-4 parameters and always has 1 output which is symbolized by a layer file. Thanks for giving me another approach to solve this, Kevin.

Thanks to everybody else who chimed in as well. All of this is great!