|
POST
|
I see it on all the ones I've tried so far: 32 bit 10.3.1 64 bit 10.3.1 32 bit 10.4 Haven't tired any others.
... View more
07-15-2016
08:27 AM
|
0
|
2
|
3971
|
|
POST
|
Thanks, that seems consistent/confirms my findings: network instability to the SQL geodatabase.
... View more
07-14-2016
11:31 AM
|
0
|
0
|
878
|
|
POST
|
I've never seen anything that states arcpy should/must be imported first in order to not override other system modules. I only skimmed this document but didn't see anything specific, although their examples tend to imply it. However if you do a import-from on datetime BEFORE importing arcpy, then you're datetime import will be destroyed: >>> from datetime import datetime
>>> datetime.now()
datetime.datetime(2016, 7, 14, 12, 10, 12, 433000)
>>> import arcpy
>>> datetime.now()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'now'
>>> Either import datetime after arcpy or use the import-from-as syntax and give datetime an alias.
... View more
07-14-2016
11:14 AM
|
1
|
25
|
9991
|
|
POST
|
Thanks for the reply, but that's not really a option on a production server.
... View more
07-14-2016
11:04 AM
|
0
|
0
|
878
|
|
POST
|
I'm getting a very similar issue with ExtractByPolygon: ERROR 010060: Could not open and write to c:\PROGRA~2\arcgis\DESKTO~1.3\bin64\pol46. Did you ever figure it out?
... View more
07-07-2016
03:46 PM
|
0
|
4
|
878
|
|
POST
|
Alex, Thanks for following up. I get that error message if I set the "scratch workspace" to a folder. I get the other error when the scratch workspace is a file geodatabase. But both are about the same: the default output name is not valid for either workspace type. I suspect all the other "arcpy.sa.Extract..." methods will fail in the same way. Current workarounds are: 1. don't use a database with less than 4 characters 2. connect with an os account or schema owned account Neither of these were possible for me, given the production environment already exists. NOTE: renaming the database at the SQL level causes lots more issues. I can't connect from any ArcGIS client after renaming the DB. There might be some tweak that makes the read-only SQL account default to the data owner schema but I haven't figured it out. I'm trying this now... 3. use the data management tool to "clip" the raster down to temporary location then use the extract function. This one adds some extra processing time and there are few settings that need to be tweaked to get the exact pixel size and orientation as the original but should get thru. Cheers.
... View more
07-05-2016
11:57 AM
|
0
|
0
|
1527
|
|
POST
|
Hi Alex: Thanks for the reply. 1. Yes I have a connection file, it's not stored in the normal 'Database Connections" folder since that points to a specific user's document directory. We use a non-user specific folder for these. I edited the full path to the connection .sde file in the message details so it was easier to read and hid details of our setup. The connection file correctly finds the raster for other tools. 2. The database is SQLServer, ArcGIS 10.3.1 3. Esri support has verified the bug: BUG-000097536 Turns out it's very specific to the database name and connection setup but is easy to reproduce: 1. The database name has to be less than 4 characters. In my case the database name is GIS 2. The database connection user has to be a SQL account not an OS account and probably one that is NOT the table owner. Is my case, the connection user is a read-only SQLServer account that doesn't own the table schema. The combination of these two causes the default name for output to be "Extract_GIS.1" which is an invalid raster name and thus the tool can't complete. You'll notice in your test, neither of the two conditions are met and the tool produces a valid raster name: Extract_PAMA1. The connection user is able to "read" the specific table name, and use "PAMA" in the default name. If the connection user is not the table owner, the fragment used starts at the database name (probably makes sense, the table name is fully qualified if not the owner) and grabs the first 4 characters. In your case that would be "BUTL" and still produce a valid name. In my case it grabs "GIS.", the dot character being invalid. Seems like a simple oversight to exclude invalid characters or at the very least validate the default name. Fred
... View more
07-05-2016
09:59 AM
|
0
|
1
|
1527
|
|
POST
|
Hi All, I'm tracking on odd issue that's come up when I moved some code to the production environment. In that environment, the rasters used by the scripts are stored in an enterprise geodatabase. When running arcpy.sa.ExtractByMask with an input raster from an enterprise geodatabase the following error is thrown: Messages Executing: ExtractByMask GIS.DATACREATOR.dem watershed C:\...\Default.gdb\Extract_GIS.1 Start Time: Wed Jun 29 14:14:06 2016 ERROR 999999: Error executing function. The table name is invalid. No spatial reference exists. ERROR 010302: Unable to create the output raster: C:\...\Default.gdb\Extract_GIS.1 ERROR 010067: Error in executing grid expression. Failed to execute (ExtractByMask). Failed at Wed Jun 29 14:14:19 2016 (Elapsed Time: 13.04 seconds) The stock system toolbox tool (System toolbox\Spatial Analyst Tools\Extraction\Extract By Mask) generates the same error. It appears that this is caused by the "default output raster name". In this case, that string is 'Extract_GIS.1' - which is an illegal raster name. This is the typical GP default value: part tool name, part input dataset name. Since the input raster is from a database, it's name is fully qualified (database.schema.table): GIS.DATACREATER.dem and the default text string uses the first four characters including the dot character ".". It's unclear why the default name is not being checked as a valid name for the workspace... this seems to happen everywhere else in the stock GP tools. So...in the stock tool, modifying the default output name to something valid allows the tool to run correctly. BUT the arcpy.sa.ExtractByVersion does not take an "output dataset parameter". It only takes the input raster and mask features. It then creates some default scratch raster which, in the examples, is later saved to a specific name using the raster.Save() method. But b/c the default name is invalid, this arcpy function can never complete successfully if the input raster is from an enterprise geodatabase. Ugh. Things I've tried: 1. creating a layer file for the input raster with a clean name... the function still tries to use the FQN as the base for the default output name and fails 2. Changing the scratch workspace to a folder rather than the file geodatabase... Same name issue occurs with slightly different message but the file based name is still invalid as well....Again why is an invalid default name being chosen? Why is the method signature of stock toolbox tool and arcpy version different?
... View more
06-30-2016
09:30 AM
|
0
|
4
|
4578
|
|
POST
|
Hi All, Does anyone have some "best practices" or "lessons learned" they'd like to share on creating a complete US level SSURGO geodatabase in SQLServer? I'm creating an application that will hopefully be useful across the entire US but really hate the idea of coding a big fat 'if STATE='X' then GDB="X" to deal with the smaller data chucks that come from USDA. Handling user AOIs that overlap state boundaries gets even uglier... We've made an initial attempt at loading the dataset chucks and are close to 30M MUPOLGYON records and performance is not that great. Is ugly code better than an overtaxed database? Thanks in advance for any advice.
... View more
05-27-2016
02:22 PM
|
0
|
0
|
2155
|
|
POST
|
Jeff, The export item method 'should' bring back ALL the data from the entire feature service. I haven't tried it with attachments but did have a service with multiple layers and tables and got back a file geodatabase will all the items... use exportFormat as file geodatabase and leave the layers parameter empty.
... View more
03-28-2016
04:22 PM
|
1
|
0
|
3251
|
|
POST
|
Hi Angela: One more thing you can test: run python with the verbose flag. This will generate a lot of output in the window but should help figure out where the import in sticking: C:\>c:\Python27\ArcGIS10.3\python.exe -v
... View more
03-28-2016
08:46 AM
|
0
|
0
|
661
|
|
POST
|
Hi Angela: I'm running ArcGIS Desktop 10.3.1 on Windows 10.0.10586 (this is the November 2015 stable build i believe). I don't have any trouble running ArcGIS or ArcPY or need to do anything special ie compatibility mode for either. Do you get the same result with both the 32bit and 64bit version of python? C:\>c:\Python27\ArcGISx6410.3\python.exe C:\>c:\Python27\ArcGIS10.3\python.exe It does seem like something is a little off with the whole install. I'd probably uninstall ArcGIS Desktop, verify everything is removed from the "c:\Program Files (x86)\ArcGIS\Desktop10.3" folder and remove/delete the entire python C:\Python27 directory... just to make sure something older artifact is not lingering. Then reinstall ArcGIS Dekstop.
... View more
03-28-2016
08:41 AM
|
1
|
0
|
2601
|
|
POST
|
Thanks, I did give it a try but didn't make a difference from the version I posted, see below ... I looked in the UTM definition and the false northing is 0 so I tried that pair as well. That's when I noticed the scale value was identical to Y deviation: >>> ptg = arcpy.PointGeometry(arcpy.Point(500000,5000000), arcpy.SpatialReference(26918))
>>> ptg_1 = ptg.pointFromAngleAndDistance(0, 10000, "PLANAR")
>>> ptg_1.firstPoint
<Point (500000.0, 5009996.0, #, #)> Anyway, this is all good, but doesn't really explain what this function is supposed to do and what the result of the different options should be....
... View more
03-25-2016
02:17 PM
|
0
|
1
|
5663
|
|
POST
|
It could be a UAC issue... did you try using the Admin command prompt? Right mouse on the start button, select Command Prompt (Admin)
... View more
03-25-2016
02:03 PM
|
0
|
3
|
2601
|
|
POST
|
Ok, Using UTM Zone 18N and the false easting the X value stays constant but the Y value is not exact but that matches the projection "scale" factor.... >>> ptg = arcpy.PointGeometry(arcpy.Point(500000,0), arcpy.SpatialReference(26918))
>>> ptg_1 = ptg.pointFromAngleAndDistance(0, 10000, "PLANAR")
>>> ptg_1.firstPoint
<Point (500000.0, 9996.0, #, #)> So this function IS taking the projection into account AND NOT computing simple "planar" coordinates...X is not constant at an angle 0 everywhere in the coordinate plane (which seems off) Also why is the result for the function with "PLANAR" the same as the result for "GEODESIC" ? In the end, I'm trying to construct geometry in a similar fashion to the COGO editor which DOES understand the constant X --- see picture. I was expecting that the PLANAR option of these methods would allow for COGO type geometry construction but that doesn't appear to be the case.
... View more
03-25-2016
01:55 PM
|
0
|
5
|
5663
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 02-15-2024 10:18 AM | |
| 1 | 06-05-2025 08:06 AM | |
| 1 | 04-03-2024 08:47 AM | |
| 1 | 06-12-2018 03:16 PM | |
| 1 | 09-14-2023 01:54 PM |
| Online Status |
Offline
|
| Date Last Visited |
12-01-2025
12:52 PM
|