|
POST
|
You are correct that the Multiple Attributes option will only create a legend based on the unique combination of values from the set of fields you choose all used together. It is not possible to create unique lists for multiple fields that remain separate from the other field values and that stack on top of each other in a single layer. A separate layer is required for each unique value list for a single field to do that arrangement. However, you do not need to create separate shapefiles for each column to create separate layers for each column. You can copy a layer that points to a single shapefile as often as you like and set each new layer to use a different column for its legend categories. You can rename each layer and legend heading to fit your needs. One shapefile can be used by as many layers as you want in your map.
... View more
03-18-2015
07:34 AM
|
1
|
0
|
1412
|
|
POST
|
Most over-night batch programs that perform nightly updates are hardcoded, since all user inputs were predefined during the program creation for a specific implementation and it is not desirable to wait for user input at run time. The mid-level stage that converts all hard-coded values to variables is best for that code, since changing the code in response to database design changes are relatively easy to implement as long as the core function of the batch job is not changed. That level of code also can be easily adapted as a template for other batch jobs. Error trapping and validations are normally designed around the possibility of system level failures (a server went down) and log them so that recovery can be performed, However, anything that needs an interactive interface has to go beyond hard coded values. In many cases, once user input is involved the code devoted to validation and error trapping can become much larger than the code that actually performs the task the program was designed to do, since users are unpredictable and may fail to do anything that your program expects and may violate every rule it follows.
... View more
03-14-2015
12:05 PM
|
2
|
0
|
6803
|
|
POST
|
I don't really have a website to refer you to, but I can give a very simple example. Here is some hard coded python code: import arcpy
from arcpy import env
# Set hard coded workspace
env.workspace = "C:/data"
# Set hard coded copy inputs
arcpy.Copy_management("majorrds.shp", "C:/output/majorrdsCopy.shp", "")
arcpy.AddIndex_management("C:/output/majorrdsCopy.shp", "STREET_NAM", "StreetIndex", "UNIQUE", "ASCENDING") With this code I have hard coded all inputs. To change the inputs I have to find every place I use a given value and replace it with a new input. So all of the paths have to be on any computer than runs this (both "C:/data" and "C:/output") and the new file I create "C:/output/majorrdsCopy.shp" has to be found and replaced twice. Also "majorrds.shp" has to contain a field named "STREET_NAM" in order for it to be in the output copy so I can index that field. Below is the same code but it uses variables that will make it easier for me to change different parts of the inputs before I run the code by just changing the variable values. However, these variables are still based on hard coded values, because the actual string values are written in the code: # Import system modules
import arcpy
from arcpy import env
# Set local variables
inwksp = "C/data"
outwksp = "C:/output"
in_data = "majorrds.shp"
out_data = "majorrdsCopy.shp"
out_data_full = outwksp + "//" + out_data
data_type = ""
field_name = "STREET_NAM"
index_name = "StreetIndex"
unique_option = "UNIQUE" # use "UNIQUE" or "NON_UNIQUE"
ascending_option = "ASCENDING" # use "ASCENDING" or "DESCENDING"
env.workspace = inwksp
arcpy.Copy_management(in_data, out_data_full, data_type)
arcpy.AddIndex_management(out_data_full, field_name, index_name, unique_option, ascending_option) Every variable can have its values substituted with another string value at the top of the program without having to find where it is actually used in the code (finding all the lines of code that use a hard coded value can be much more difficult as the program gets longer). This makes it easier for me to test the code with different inputs during the testing phase. Now here is the code where nothing is hard coded and it assumes there is a user input interface (like a tool) where the user chosses all of the variable inputs at run time: # Import system modules
import arcpy
from arcpy import env
# Set run time variables
inwksp = arcpy.GetParameterAsText(0)
outwksp = arcpy.GetParameterAsText(1)
in_data = arcpy.GetParameterAsText(2)
out_data = arcpy.GetParameterAsText(3)
out_data_full = outwksp + "//" + out_data
data_type = ""
field_name = arcpy.GetParameterAsText(4)
index_name = arcpy.GetParameterAsText(5)
unique_option = arcpy.GetParameterAsText(6) # use "UNIQUE" or "NON_UNIQUE"
ascending_option = arcpy.GetParameterAsText(7) # use "ASCENDING" or "DESCENDING"
env.workspace = inwksp
arcpy.Copy_management(in_data, out_data_full, data_type)
arcpy.AddIndex_management(out_data_full, field_name, index_name, unique_option, ascending_option) Unlike when I change the variables, because the user is providing every input I cannot be sure that every input makes sense. This program would require validation of the inputs in the tool set up by configuring the inputs to only accept certain values, setting up the Tool Validator to test for valid path and file name combinations and perhaps with validation steps set up as part of the code shown.
... View more
03-14-2015
11:05 AM
|
2
|
0
|
6803
|
|
POST
|
Hard coded (not hardcorded) means that actual values that the user cannot change are used in the code rather than variables that can be changed at run time to match user inputs. So if I hard code a path, file name, and field names that work for one of my data sources on my computer in the code, then it will not work for you unless you have an identical path to the same file name with the same field names on your computer. If on the other hand I replaced those hard coded values with variables that take user input at run time, then the path, file name, and field names could be chosen by each user for their particular computer at run time. Programming with hard coded values is usually done first to test the code to make sure that the core program function is working properly for a known input. After that is established the hard coded values are frequently replaced by run time variables that generalize the program to work for any valid inputs that meet the minimum criteria of the program. Often many additional tests have to be written for run time variables to ensure that the program validates the run time user inputs to make sure they meet the minimum requirements that the hard coded input met before allowing the program to use them.
... View more
03-14-2015
09:52 AM
|
3
|
2
|
6803
|
|
POST
|
There probably could be a 10.0 version if I was able to compile it on a machine with ArcGIS 10.0 installed, However, no one has that version where I work now, and I don't have administrator rights to install it myself. I don't have a good case to ask IT to install if for me that relates to my work. If you can upgrade to 10.1 or 10.2 I think it is very much worth it. Either of those versions is much more stable and has much better performance than 10.0.
... View more
03-12-2015
01:29 PM
|
1
|
1
|
5000
|
|
POST
|
Select the County first with any selection method you want (Click on it with the selection tool, select a record in a table view, select by attribute, or select by location based on some other feature). Then use the County layer as the Source layer and check the option to "Use selected features". The example below is using a county layer with 13 county polygons within it, but I have selected just one of them, and by checking the Use selected features option, only that one selected county feature will be used to select all of the overlapping items in the Targel layer(s) I choose.
... View more
03-12-2015
08:00 AM
|
1
|
0
|
4684
|
|
POST
|
In general I agree. Also, if this is about creating labels from a set of related tables that have a 1:M relationship then do the technique shown in my Blog on that subject. it is fast enough and much easier to maintain the data than violating the data normalization pattern even more than you already have with 500 separate tables. My blog approach is based on a table structure exactly like what Vince suggested and can respect the subset query he suggested for each surface type so that all 500 tables can combined into a single table with 3 or 4 fields and still create the labels as though they were in a single row with many field columns (even better since it creates no wasted field columns ever and can maintain a data sort for you that is nearly impossible with columns).
... View more
03-10-2015
06:14 PM
|
1
|
0
|
2137
|
|
POST
|
The practical example helps and I was using "table relationship" in the broad database sense to mean what does the data in the feature class have in common with the data in the table. My confusion now is how do you combine 500 separate tables and end up with less than 500 fields? I can only image that there is overlap in the table field names. Or else, you do not really intend to combine all 500 tables together at all, and instead you want to end up with 500 separate feature classes where any given feature class could have up to 60 fields from just one of the 500 tables.
... View more
03-10-2015
08:21 AM
|
1
|
0
|
6655
|
|
POST
|
Well 60 fields is somewhat manageable. However, I am still not understanding what you are working with. Ignore the tables for a moment. What is the feature class like that relates to these 500 tables? Does it contain 500 features? If the 500 table contain different field names then you could still end up with a huge number of fields. Combining all tables together into a single feature class would result in 500 tables * 60 fields each = 30,000 fields.combined. Do you intend to end up with 500 separate feature classes, or do all 500 table contain the same set of fields? If they contain the same set of fields, why did you create 500 tables in the first place? It would help if I had a clue what kind of data this is and a practical example of one table relationship to your feature class. I.e, There are n features which are agricultural fields and each table contains separate monthly sample data by crop type. Leaving everything abstract is not helping me even imagine a scenario that would produce the kind of data you are working with.
... View more
03-10-2015
08:05 AM
|
1
|
2
|
6655
|
|
POST
|
Are you saying you want to combine 500 tables, 500 rows and at least 3 fields per row into 1 row? That is 750,000 fields in a single row. The maximum number of fields you can have in a dbf table or shapefile is 255 fields. The maximum number of fields you can have in an FGDB table or feature class is 65,534 fields. So you cannot do what you seem to have described regardless of the tools you use. Additionally, even if you could do this, once you get beyond about 30 rows transposed, it becomes virtually impossible at a practical level to write any SQL logic against the table or compose a label expression to make selective use of specific fields based on the values they contain. So even if you can create what you say you want, it may turn out to not work at a practical level in the end, depending on what you intend to do with this feature class/table.
... View more
03-10-2015
07:17 AM
|
0
|
7
|
6655
|
|
POST
|
Please add code comments to explain why you did each step and what each step is accomplishing to reach the desired output. There is nothing about this code that is transparent or obvious to anyone that has never used this set of interfaces. I don't know this set of interfaces and I cannot understand why you did what you did or even what the results are. Nothing can be called elegant or scalable if I have to go read the Python help docs to get anything out of the code you posted.
... View more
03-09-2015
02:16 PM
|
0
|
0
|
713
|
|
POST
|
Actually, line 230 is a print statement. Are you sure it is executing? You should break that whole expression down to multiple prints statements so you are certain exactly what arguments are being passed to the query and calculation. For example, you could try: print "OBJECTID={} AND CustomerID={}".format(updateRow[3], updateRow[0]) print "{}".format(updateRow[1]) print "{}".format(updateRow[2]) Then, if all of those inputs makes sense, execute the fl.calculate outside of a print operation. There are some details to pay attention to. If CustomerID is numeric and the value makes sense, then the SQL should be fine. But if CustomerID is a string value then the SQL should fail, since the value is not within quotes. For a string CustomerID you would need: "OBJECTID={} AND CustomerID='{}'".format(updateRow[3], updateRow[0])
... View more
03-03-2015
11:32 AM
|
1
|
1
|
1663
|
|
POST
|
I am not clear which part of the code is causing the problem and which field name is for an integer and which is for a string. Generally to use Python to write to a string field you have to enclose non-strings in the str() method. For converting strings to integers you must always test that the string is actually an integer and use Null (or some other default value for blank numbers) when the strings is not numeric. For example, " " is not an integer and will fail if you try to convert it to an integer. Potentially Null will also cause a problem. Anyway, any time type conversion is involved in a script it is easy to produce errors and unexpected results until you include enough logic to handle both the values that can convert and the values that can't convert at each conversion step. To confirm for yourself what is failing you should include a print statement in your try except block to show you the actual value read from the source field that you are trying to write to the field that is rejecting the value or producing bad results.
... View more
03-03-2015
09:18 AM
|
0
|
3
|
1663
|
|
POST
|
Just to be clear, which lines in your example screen shot are considered more accurate? The brown lines or the black lines?
... View more
03-02-2015
04:22 PM
|
0
|
1
|
2368
|
|
POST
|
A screen shot of a sample area would help. Do all sources share the same coordinate system? Did you try the tools with geodatabase feature class versions of your data as opposed to shapefiles? How many lines are in each file for your area of interest? Did you attempt a smal scale test to determine if the tool works for even a small set of lines from these two sources (100 lines or fewer in each input source)?
... View more
03-02-2015
01:57 PM
|
0
|
3
|
2368
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-24-2026 11:37 PM | |
| 1 | 03-24-2026 08:01 PM | |
| 7 | 02-23-2026 08:34 AM | |
| 1 | 03-31-2025 03:25 PM | |
| 1 | 03-28-2025 06:54 PM |
| Online Status |
Offline
|
| Date Last Visited |
4 weeks ago
|