Dear Xander,
I wonder if it is possible to take width and length of the rectangle from a dbf table.. I have 24 rows with different length and width values, and hence I want to create 24 rectangles with different sizes according to width and length from the dbf table.
Best,
Tim
Solved! Go to Solution.
That's amazing thanks!! But it still doesn't work for me, when I execute the script it says:
Runtime error
Traceback (most recent call last):
File "<string>", line 69, in <module>
File "<string>", line 39, in main
RuntimeError: A column was specified that does not exist.
But I can't find the mistake..
The first part to look at would be the lines 12 - 15 where the input fields are defined. Do you have fields with these names in you DBF?
fld_X = 'X'
fld_Y = 'Y'
fld_width = 'Width'
fld_height = 'Height'
If not, change these names (the part between the single quotes) to reflect the field names in you DBF.
In case that does no resolve the problem, could you share the DBF? Or if not, post a screenshot that shows the field names?
Yes, I adapt it to the field names, whereby im not quite sure what 'fld_oid_out' was meant to be (? maybe just the ID for the output?)
it looks like tgis for my case:
... # edit these field names !!!
... fld_oid_in = 'OID@'
... fld_X = 'INSIDE_X'
... fld_Y = 'INSIDE_y'
... fld_width = 'width'
... fld_height = 'length'
... fld_oid_out = 'ID'
..And does it make a difference whether the dbf is stored in a GDB or not?
At first sight there doesn't seem to be anything wrong with the definition of your fields. It could have been something with reserved field names, whereas ArcGIS in some cases renames them in the process and puts an underscore behind it.
The other part that I can think of is that when you look at a table you see the alias (in many cases the same as the actual field name), however, a field may have a different name than the ones shown. The script will work with the field name and not the alias. To verify this, you could enter the properties of the table, in the Fields tab you will see the list of fields. When you click on a field, you can see both the alias and the field name. Make sure the field names in the script refer to the field names and not the aliases.
It should not be a problem to use a table store in a geodatabase. The fld_oid_in refers to the ObjectID or OID field in the input using the "OID@" token. It adapts to the data source.
The fld_oid_out is a new field to be created in the output featureclass that will hold the object ID's from the input and allow to join attributes from the table to the output featureclass.
If possible it would be nice to be able to have access to the actual data to see what is going on.
Hey,
You were right with the alias names (the fields were indeed renamed!). But still the same error message as before!
Would it be helpful if I send you my gdb (including the dbf file)?
Hi tiga_2 , sharing the data would indeed be very helpful to trace the error.
Hi Tim Gattinger , if you are going to share the data, you may also want to include some details about the ArcGIS Desktop version you are using.
Thanks in advance.
Hi Tim Gattinger , I just had a look at your data and I noticed that the fields in the table you use, are defined as:
... and that there are no X and Y fields. In your code you define your fields like this:
fld_X = 'CentroidPOINT.INSIDE_X'
fld_Y = 'CentroidPOINT.INSIDE_Y'
fld_width = 'NABU_1.width'
fld_height = 'NABU_1.length'
When you have a point in the field name, that is normally the result of a join applied in ArcMap. When you acces the data using the path to the datasource, the datasource will not be aware of any joins you may have defined in ArcMap and therefore throw an error that the field does not exist. If you are sure about the field names, you can run the code in the Python windows of ArcMap, but you will have to access the data using the name in the Table of Contents.
So your line:
tbl = r'W:\Gattinger_Tim\GDB\rect_py.gdb\NABU_1'
... should be changed to:
tbl = 'NABU_1'
The alternative is to export the table with the join to a new table and this will create a physical result with the field that can be accessed using the path to the table. Be aware that the names of the fields will no longer contain dots, so you will have to adapt those names.
In order to simulate the result using your data, I took the "gewannstruktur" featureclass, created the X and Y fields based on the centroid of the polygons, joined this featureclass to the NABU_1 table and exported the result to a new table (NABU_2):
I used this table to generate the rectangles, using the following field definitions in the code:
fld_X = 'X'
fld_Y = 'Y'
fld_width = 'width'
fld_height = 'NABU_1_length'
The resulting featureclass is attached.