POST
|
Thanks so much for responding Gintautus. I guess calling the tool by the correct name "Management.AddXY" does make a difference. Your suggestion regarding reviewing the history is welcome. I was under the mistaken impression the name of the tool appeared in the GeoProcessing Window when you called the tool interactively. In this case "Add XY Coordinates". or when you look at the full tool box listing, it appears as: Thanks again.
... View more
07-27-2020
08:12 AM
|
0
|
0
|
424
|
POST
|
I hesitate to submit this, as the syntax for calling this geoprocessing tool from the Pro SDK would seem straight forward. The geoprocessing tool in Pro only appears to require an input feature layer to run. I have successfully navigated calling many other geoprocessing tools much more involved than this, so I did not anticipate any heartburn with this one. However, I have not been able to have it successfully execute. I am using the same basic pattern as with other geoprocessing tools. I have tried many versions of this pattern, assigning values to the env array and trying different values for the arguments (strings of paths to the feature class, output feature layers, etc) with no luck. The feature layer passed in is a point feature class in a file geodatabase. I can successfully run the tool in native pro on the feature layer with success. public Task<IGPResult> AddXYCoordinate4(FeatureLayer featureLayer)
{
var AddXY = @"C:\Program Files\ArcGIS\Pro\Resources\ArcToolBox\Toolboxes\Data Management Tools.tbx\Add XY Coordinates";
var args = Geoprocessing.MakeValueArray(featureLayer);
var env = Geoprocessing.MakeEnvironmentArray();
return Geoprocessing.ExecuteToolAsync(AddXY, args, env, null, null, GPExecuteToolFlags.None);
} I would appreciate it if anyone could kindly assist me with how this tool should be called. Thanks
... View more
07-24-2020
08:59 AM
|
0
|
2
|
485
|
POST
|
When Project CM Enabled: Map in Pro - Washed Out Layout in Pro - Washed Out API Generated PDF of Layout - Washed Out Native Generated PDF of Layout - Washed Out When Project CM Disabled: Map in Pro - Fully Saturated Layout in Pro - Fully Saturated API Generated PDF of Layout - Washed Out Native Generate PDF of Layout = Fully Saturated Additionally, the PDF output carries errant 'lines' in all combinations
... View more
03-10-2020
09:14 AM
|
0
|
3
|
1079
|
POST
|
Map color model is set to RGB Map Properties with Project CM Enabled Map with Project CM Disabled
... View more
03-09-2020
04:27 PM
|
0
|
5
|
1079
|
POST
|
My apologies for not reading your last response more carefully regarding checking the layout's color management properties rather than the project's. Once again I ran the application twice, one time with project cm set to enabled and once with cm disabled. I have included some screen shots showing the layout's cm. In both instances, the layout CM is set to the RGB Color Model. The first screen shot shows the washed out look of the layout in Pro with the Project CM Enabled. This results in the washed out PDF export result. The second screen shot shows the fully saturated layout in Pro with the Project CM disabled. The layout CM properties in both instances are the same. The PDF output from both carries the washed out look. Thanks again for your input.
... View more
03-09-2020
03:55 PM
|
0
|
7
|
1079
|
POST
|
The option was set to RGB. I haven't altered any of the default CM Settings. I am including this to display the other default values of the CM options.
... View more
03-09-2020
02:39 PM
|
0
|
9
|
2163
|
POST
|
Hi Jeff, Thanks for you input. I just replied to Jeremy's inquiry about the version of Adobe. Unfortunately, the washed out results were the same regardless of the Adobe version. I have tried enabling/disabling the Color Management option, but encounter the same results in the pdf regardless. However, I do see a difference in the Pro 2.5 Interface regarding the CM. When I disable the CM option, the layouts within Pro on the screen show fully saturated colors. When I enable the CM, the layouts have the washed out look within Pro itself as well. As I mentioned in my note to Jeremy, the pdf outputs carried the washed out results regardless of the CM setting or the versions of Adobe.
... View more
03-09-2020
02:27 PM
|
0
|
11
|
2163
|
POST
|
Hi Jeremy, Thanks for your inquiry. On the machine where I am running Pro 2.4 where everything works, I am running Adobe Acrobat Version 11.0.23 The Pro 2.5 version was relying on Adobe Acrobat Version 11.0.17. Following your question, I went ahead and updated my Adobe installation on this machine to the latest Adobe Acrobat Pro DC, version 2020.006.20034. Unfortunately, I am still getting the washed out results with 2.5 ,regardless of the color setting.
... View more
03-09-2020
02:05 PM
|
0
|
1
|
2163
|
POST
|
I have checked the attachments and the 2.5 Version does not reflect the 'washed out' look I am getting. Not sure why it is not rendering the same once I post it to this forum. Hopefully this screen shot render properly and illustrate what I am encountering.
... View more
02-27-2020
07:46 AM
|
0
|
3
|
2163
|
POST
|
I am encountering a problem when exporting a layout to a pdf through code at 2.5. The output pdf colors are seriously washed out. The same code has successfully worked in prior Pro Versions. The code itself, is quite simple and in fact was mostly lifted from ESRI. If I export the layout interactively through Pro itself, the output PDF is correct and does not have the washed out effect. I understand at 2.5 'Color Management' has been introduced. I have not touched any of those settings in Pro so it is running in 'default' mode. However, in code I notice the PDFFormat object has the property 'HasColorProflile'. In code I test this value and it returns true that the PDFFormat does have a color profile. As I am new to the 'Color Management' bit, I am not sure if this is related to this or not. I have looked at the available methods for the PDFFormat object and have not found anything that appears to allow me to intervene. Regardless, the output I am getting is not correct. The attachments illustrate the problem: Any input would be appreciated.
... View more
02-27-2020
07:33 AM
|
0
|
18
|
3451
|
POST
|
I have found that calling the project python script again, immediately after it fails, works on the second call. As mentioned above, the project command errors out when initially called .. "Failed to open raster dataset ..." as described in the initial post. In the C# Console application, when I call the for the python script to be executed again immediately after the first failure, the project command behaves nicely. Appears to be some type of timing issue, though not sure how to remedy. The first call results in the failure, the second call succeeds calling the same script, same parameters. ExecuteArcPyScript.run_arcpy2(@"C:\DopplerConsoleRasters\PythonScripts\TestingProject.py", strGridDirectory + @"\" + strFlippedVersion, strGridDirectory + @"\" + strProjectedVersion); ExecuteArcPyScript.run_arcpy2(@"C:\DopplerConsoleRasters\PythonScripts\TestingProject.py", strGridDirectory + @"\" + strFlippedVersion, strGridDirectory + @"\" + strProjectedVersion);
... View more
01-11-2019
05:04 AM
|
0
|
0
|
693
|
POST
|
Thanks for responding. Yes, quite confident regarding the syntax. The rasters are tifs. They are the output from the earlier python processing scripts.
... View more
01-10-2019
07:07 AM
|
0
|
1
|
693
|
POST
|
We are experiencing an arcpy error when attempting to execute the arcpy geoprocessing tool "arcpy.ProjectRaster_management" from a C# console application. The application is passing parameters to the python script . The returned message is: “Failed to open raster dataset: “ C:\DopplerConsoleRasters\Comp_20190106_1600PM_20190106_1620PM_GRID\p190106_1601.tif: No such file or directory Failed to execute (ProjectRaster) This gets a bit involved, but hopefully the following is written clearly enough. I appreciate anyone wading through it.. Prior to calling this python script, the same console application successfully calls python scripts that rely on "arcpy.conversion.ASCIIToRaster" and "arcpy.management.Flip". These python scripts accept arguments, build paths and names, and work without issue. The initial raster is successfully created from "arcpy.conversion.ASCIIToRaster". The second raster is successfully created from "arcpy.management.Flip" We followed the same pattern with "arcpy.ProjectRaster_management" script. This script relies on the raster created by arcpy.management.Flip as the input and is supposed to output the projected raster (p190106_1601.tif). From the error message cited above, the tool is complaining about opening the raster dataset that is the output of this project script. It recognizes the input raster, which was created by the flip process immediately before that. As a test, we ran the console application to the point of generating the initial raster and the flipped version and ended the console application. We then moved the code in the console application that calls "arcpy.ProjectRaster_management" python script to the beginning of the console application, with the initial raster and the flipped raster already generated from the earlier run. This initially failed. However, on a lark, we removed the LOG file from the directory and rand the console application again with the input rasters already baked up from an earlier run. This worked with the python script successfully generating the projected raster with no complaints. We found that the python script doing the projection would work with the previously established rasters already there as long as there was no LOG file in the directory. We thought the LOG file was somehow interfering with the project bit, so we altered the python scripts to remove the LOG file following the execution of the tool. However, the project bit still failed when it was run in the normal order. (following the "arcpy.conversion.ASCIIToRaster" and the "arcpy.management.Flip".) So a quick summary of all of this is that the project python script succeeds if the console app is run with the input rasters already baked up from an earlier run. It fails when it is called in the console app immediately following the creation of the input raster. The project command also appears to object to the LOG file being present as well. Initially, I I thought this might be a timing issue, and placed a sleep thread in the console application following the creation of the initial rasters and before when the project script was called. I have also tried removing he LOG file through the C# console app. It seems some remnant from the earlier process (convert, and or flip) that is interfering with Project doing its job. I have all of these processes successfully behaving in an ArcGIS Pro application. However, that is relying on the ProSDK. Any insight would be appreciated.
... View more
01-09-2019
03:08 PM
|
0
|
3
|
952
|
Title | Kudos | Posted |
---|---|---|
1 | 01-06-2017 09:29 AM | |
1 | 03-04-2016 08:45 AM | |
1 | 08-11-2016 02:39 PM | |
3 | 07-16-2018 10:11 AM | |
1 | 07-28-2017 11:06 AM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|