POST
|
Hi Justin, I've come across situations when the names of bands were Layer_1, Layer_2, etc., it does not always have to be Band_1, Band_2, etc. Perhaps try to list the individual bands programmatically as shown here: python - Access individual bands and use them in map algebra - Geographic Information Systems Stack Exchange The main idea is to set your main raster dataset as a workspace and then use arcpy.ListRasters() function. Filip.
... View more
09-05-2017
12:20 PM
|
1
|
0
|
17
|
POST
|
Hello Jay, You may get some valid but confusing answers because it depends on the frameworks you use in your app and whether you use asynchronous module loading, which you should use. The simplest way to reference (aka import or load) another js file into your page is to add another <script src="my/script2.js" /> into your HTML page. The problem is that this is not asynchronous so it will lock the browser (not too much of a problem for small js file with a few utility functions). A bigger problem with this approach is that things may execute in wrong order and you app will not work. That's were the "require" function and asynchronous module loading come in. Coincidentally, somebody asked a related question just recently so I recommend you explore the links there: load custom modules in JSAPI 4.3 And also around here: Create a Re-usable Widget | Guide | ArcGIS API for JavaScript 3.20 Filip.
... View more
03-23-2017
01:48 PM
|
1
|
2
|
34
|
POST
|
Hi Jose, I think there is no harm in publishing the two (or more) services from a single map document. As far as I understand, ArcGIS for Server will convert it in to service definition files (.sd) for each service separately. The services will use the .sd files stored in internal ArcGIS server folders and the original .mxd will not be used by the services directly anyway. See PublishMSDToServer—Help | ArcGIS Desktop Filip.
... View more
03-23-2017
01:34 PM
|
1
|
0
|
14
|
POST
|
Hi Michael and Joseph, The initial piece of code demonstrated how one would go around solving the problem but there are things one needs to add to make it more bulletproof. If I added them in the first place, the code would be too long and hard to understand. One important assumption in the initial code is that all feature classes in the geodatabase have the same columns. Why else would you want to join them all into one result? I suspect Joseph is seeing the error because the script encountered a feature class that does not fit this assumption. When it comes to empty feature classes, i.e. feature classes with no rows, the code the `for row in rows` loop should not raise an exception as long fc has all the expected columns. The subsequent `del row` statement may raise an exception though. You can to comment out the `del row` statement. One way to deal with these strange cases is to add some try-except statements and handle the failing feature classes in some other way. I'll leave that up to you. Cheers, Filip.
... View more
03-08-2017
02:51 PM
|
2
|
1
|
10
|
POST
|
Hi Jonathan, You are quite right and I owe you an apology. I am glad you pointed this out because it indeed did not make sense to me why one would have to specify the parameter name of field_names when it can be inferred from the position. Anyway, I see the discussion has moved on quite a bit. Filip.
... View more
03-08-2017
02:35 PM
|
0
|
0
|
23
|
POST
|
Hi Eddie, I haven't used the tools you mention much but perhaps the root of the problem you see could be in what was discussed in this thread: https://community.esri.com/thread/159997 Filip.
... View more
03-07-2017
01:45 PM
|
2
|
1
|
20
|
POST
|
I am just guessing here but it does not sound like you're hitting limit on the volume of a response, if there even is any. You could try to adjust the maximum number of records the service should return from a query to something like 10 or less and try your queries again. Have you tried running Check Geometry and Repair Geometry tools on your polygon feature class in ArcGIS for Desktop? Also, exporting the data to GeoJSON in ArcMap may reveal where the problem is. If your polygons are not massive (i.e. if they don't have many vertices), I would try looking at them in GeoJSON also in the Python window like this: import arcpy fc = r 'c:\path\to\polygons.shp' with arcpy . da . SearchCursor ( fc , "SHAPE@JSON" ) as sc : for row in sc : print ( row [ 0 ] . __geo_interface__ ) See also Converting geometries between GeoJSON, esri JSON, and esri Python , especially the last contribution. Filip.
... View more
03-07-2017
01:27 PM
|
1
|
0
|
40
|
POST
|
Hi Michael, Jonathan Quinn has a very good point about formatting code on GeoNet but he's not quite right about why you are seeing the error. In fact, the variable that refers to the list of fields is called fieldnames consistently throughout the script. I suspect the error is raised by the call to arcpy.da.SearchCursor. It should not be, but anyway, try to replace with arcpy . da . SearchCursor ( fc , fieldnames ) as sc : with this: with arcpy . da . SearchCursor ( fc , field_names = fieldnames ) as sc : Filip.
... View more
03-07-2017
12:56 PM
|
0
|
2
|
23
|
POST
|
Hi Graham, Nice to see the good old British National Grid but boy this is a loaded question. Almost all the advanced topics in one. I suggest some changes in the attachment but you still have a long way to go. Some key points are: Result of a geoprocessing tool run is not the output variable but a result object from which you need to pluck out the appropriate variable (hence the .getOutput(0)). In order to return a value from a geoprocessing python script you need to setParameter. I would stay away from in_memory workspaces until you get everything working and then you can experiment with it. ArcGIS Server should handle the creation of new workspace and scratch workspace for you and then get rid of it after a few weeks or whatever the settings are. The way it is now, result of the script will be a path to the output near table, but I suspect that will not return the content of the table as a result of the REST service. I thing you would need to read the table with a search cursor into something like a RecordSet and return that or dump it to json, then to text, set the text as an output parameter of type Text and then parse this as JSON on the client side. Well... not to discourage you. I did this kind of thing before and it kinda worked, but we never used it in production. It was like scratching your left ear with your right hand behind your head. You may want to consider publishing both the data and the Generate Near Table tool as services and using these in the client fully over the RESTful interface. Best wishes, Filip.
... View more
03-06-2017
12:17 PM
|
1
|
1
|
29
|
POST
|
Hi Mitch, Thanks for sharing, my favourite is this one https://github.com/NERC-CEH/arcapi I use it all the time. There is also a GeoNet place for that here ArcAPI Filip.
... View more
03-06-2017
11:30 AM
|
2
|
0
|
18
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|