Latest Contributions by RichardFairhurst

Here is a sample label expression that works with the Pivot Table approach when a maximum or 4 potential pivoted text values are joined to a feature class: Function FindLabel ([LABEL_Pivot.LABELS1], [LABEL_Pivot.LABELS2], [LABEL_Pivot.LABELS3], [LABEL_Pivot.LABELS4])   Output = ""   If [LABEL_Pivot.LABELS1] > " " Then Output = Output & [LABEL_Pivot.LABELS1] & vbcrlf   If [LABEL_Pivot.LABELS2] > " " Then Output = Output & [LABEL_Pivot.LABELS2] & vbcrlf   If [LABEL_Pivot.LABELS3] > " " Then Output = Output & [LABEL_Pivot.LABELS3] & vbcrlf   If [LABEL_Pivot.LABELS4] > " " Then Output = Output & [LABEL_Pivot.LABELS4]   FindLabel = Output End Function Only the minimum number of label rows would be created in the stacked label to show text values that are not blank.  The patterns just repeat to expand the label to handle additional label fields generated by the pivot.  The labeling speed is not really noticeably different from labeling using the fields of the point features themselves. ... View more

I have seen the code for the OneToManyLabels developer sample.  If anybody could find me a screen shot of the property page form layout from the original VB6 project I may be able to convert it to an Add-In extension for ArcGIS 10.1 using VB.Net.  I have never had VB6 and I have never seen the original code in use, so I currently I would have to attempt to reverse engineer the property page form based on the code without a screen shot.  I have not attempted to create property pages using VB.Net add-ins before, so I don't know what challenges updating the code will cause, but in theory this code should be able to be converted to an add-in.  Additionally, reviewing the comments on the tool it looks like some bugs were already appearing by ArcGIS 9.2 sp4.  I am not sure if the bug in the ArcObjects class has been resolved by 10.1 or not. However, for those with an advanced license, performance of the Pivot table approach is likely to perform much better, since the 1:1 join should be faster than the multiple queries run using the OneToManyLabels tool.  For end users that only view data that is not being updated live, the Pivot table approach is better.  If an editor can live with labels that are not refreshed until he does the above script as part of the editing process, the Pivot Table approach is probably also better.  However, if an editor needs labels generated on the fly as they create features or related records, the OneToManyLabel approach is the only one that would maintain a live label association. The Pivot Table approach also generates better labels in my opinion, because it always sorts the records of the related table with many records into a meaningful order.  The OneToManyLabels script does not do this step, because a sort would significantly slow down the labeling process.  As a result the many related records are labeled only in the order they are stored in the related table when that script is used, which can be entirely arbitrary and random.  The only way to correct that behavior effectively with the OneToManyLabels script would be to replace the original related table with a permanently sorted version that is updated from time to time (which would involve a process identical to that part of my process for the Pivot Table). ... View more

I know there once existed a tool/script titled "OnetoManyLabels" which created labels based on a one to many relationship. Does anybody know a workaround/script/add in to produce labels from such a relationship? I have been trying to build some advanced label expressions but is just getting ridiculous! I have found so many posts related to this topic so hopefully somebody knows of or can help me find a solution! Since I have an advanced license I use the Pivot Table tool to transform a 1:M relationship into a 1:1 relationship where the rows are converted to field columns for each feature.  Here are all the steps in Model Builder to automate it. 1.  The join field and all of the label field values need to be sorted, so first I sort the rows to a new table by using either the Sort tool or the Summary Statistics using both the join field and the label field(s) I want pivoted as unique case fields and at least one summarized field. 2.  I add a Long field to the sort/summary with a name that will make sense as a field name when the pivot occurs and calculate the objectIDs of each summary row into that field. 3.  I Summarize the previous Sort/Summary again with the Summary Statistics field, but this time I make just the join field a unique value per row and get the Min value of the ObjectIDs values I calculated in the new field. 4.  I create a Tableview of the first sort/summary. 5.  I add an attribute index on the join field of the tableview of the first sort/summary. 6.  I add an attribute index of the join field of the second summary. 7.  I perform a join of the first sort/summary Tableview to the second summary on the join fields. 8.  I use the field calculator and recalculate the field I added to be sequential numbers using the formula: First_Summary.Labels - Second_Summary.Min_Labels + 1 9.  I use the Remove Join tool to break the join of the two summaries. 10.  I use the Pivot table tool to transform the rows into columns using the join field as the unique case, the Labels field with the sequential numbers to create the field names, and the actual values I want to appear in the labels as the pivot value field. 11.  Add an attribute index on the join field in the pivot table. 12.  Join to the original feature class that is the 1 portion of the 1:M relationship and build a label expression that uses the multiple field columns of the pivot to create a label. ... View more

I have a database of 22,000+ signs that contains the offset from centerline along with a distance to/from the edge of pavement to a specific intersecting road for each sign.  I also have a street centerline layer and pavement polygon layer with edge of pavements.  I'm trying to create point features for the signs based on the offset from centerline and the distance from the nearest intersecting roadway.  Looking for some ideas on what tools to use for this analysis (buffer, selectlayerbylocation, etc?) [ATTACH=CONFIG]25644[/ATTACH] This is something I do every day using Linear Referencing.  The basics of Linear Referencing is that you would derive a Route feature class from your Centerlines based on each street name and combine all related lines into a single feature.  Each Route feature has a unique identifier known as a RouteID or RID, which can be either a number or a string (typically based on the road name, but made unigue in some way if two road features are named the same in different parts of your jurisdiction).  This road feature stores a Polyline M feature type.  The M stands for measure and is added to the polyline feature in addition to the X and Y coordinates stored as part of the shape.  Measures for your type of problem are based on the length of the road and are typically stored as feet or miles in the US or meters or kilometers elsewhere in the world typically matching the units of offset reported in your data.  When a separate table stores a RID value and one or two measure values that fits within the length of the road, that table can be made into a Linear Referncing event table.  With one measure value you can create a point along your Route centerline at the measure location (like for a sign), and with two measures you can create a line segment along your Route centerline (like for pavement management segments). To solve your problem you also need a set of intersection points derived from your Centerlines.  I have a point feature class with one unique point at each intersection storing the street names concatenated together in alphabetical order.  I derive from that a table of every unique street name pair combination in every order concatenated together at each intersection that stores the associated RouteIDs and measure value of the first street name of the pair for that intersection location.  By using joins of concatenated pairs of street names from my input data I can transfer to my sign events the fixed position of the intersection based on the linear referencing RouteID and measure. To deal with the offset along the road it is just a matter of either adding or subtracting the offset distance of your sign from the intersection.  I store a field that contains a 1 or a -1 as a multiplier that translates north/south or east/west into the appropriately signed value.  Typically for road systems in the US measures should increase from south to north or from west to east.  As a result, typically south and west offsets equal -1 and north and east offsets equal 1.  To get the actual measure of the location of the sign along the road the formula is then: Intersection_measure + Direction_Multiplier *  Offset_Distance Once the Routes and intersection tables are created, the procedure to locate your signs goes as follows.  Calculate a concatenated street name pair in the sign event table as a join field.  You then join them to the table of intersection pair names with RouteIDs and measures of the intersections and use the field calculator to transfer the fixed intersection RouteID and Intersection_Measure to the events.  You can manually finish this step for thousands of signs in just a few minutes.  Break the join.  Then in a Direction_Mulitplier field on your sign event you calculate a -1 for south and west offset signs and a 1 for north and east offset signs using two separate selections and calculations.  Now in a field holding the actual measure of the sign do the above calculation.  Make the sign table into a Linear Referencing Event table and all of your signs will now be located along the centerline at the described locations. Additionally, Linear Referencing supports side offsets as well.  Similar to offsets along roadways, determining whether a point or line segment offsets to the right or the left of the line is represented by a positive or negative side distance offset value.  So I have a Side_Multiplier that contains a 1 or -1.  The determination of whether the side mulitplier is positive or negative is dependent on the direction of travel faced by the sign. In a perfect world the actual geolocating operation can be finished in under 15 minutes using my set up if all of the inputs fit my assumptions.  Unfortunately this is far from a perfect world.  Faulty input data or disconnects between reported field conditions and your centerline network result in false or failed matches that have to be examined and corrected.  For example, roads that curve back on themselves can reverse everything about the way field conditions are reported.  Fortunately Linear Referencing supports an angle field that can be generated for the intersection locations which can be used to detect and select for reversed or ambiguous road orientation issues.  I have a set of SQL statements that let me find and fix these issues using angle field ranges that do not normally fit the reported direction or my assumptions. The time consuming aspect of this process is the same as any other geocoding operation.  The most common problem is that field workers do not use standard street name suffix values or correct suffix values.  RD and DR are reversed as much as 40% of the time.  Silent letters and double/single letter spellings or spellings with spaces or no spaces between name parts cause issues, etc.  The Street Name pair table has fields for the street names separately for this reason so I can do validation using Like statements to find close but not exact pairs.  Other geocoding techniques can be used to match your network to your reported field data as well. This post is long because it took me a long time to figure this all out on my own.  Almost no help exists to set this up correctly and is only recently getting some support from ESRI.  I have only scratched the surface of what I have scripted and automated to get this set up, but I am willing to help and can point you to other posts where I have offered this help.  My sign database is 45,000+ signs.  I use this technique with Pavement Management, collisions, traffic signals, sidewalks, curb ramps, road improvement projects, etc.  basically it can be used for every aspect of street inventory. ... View more

Thanks a lot. The code worked wonderfully for three shapefiles. As for delete fields, I am thinking if wildcard will help in this condition. (The field names of the three AddJoin bird range are  "FID_1; GID_1", "FID_12; GID_12", and "FID_12_13; GID_12_13") Therefore, I replaced the gp.delete with the following code. # delete Field  (need to clean up with a lot more ID fields that the code you have below since now there are 50 GID values.) gp.deletefield (out_shape, "FID_*; GID_*") The code worked well, but none of the three FID and GID fields were deleted. Please kindly help and thank you. (It is the first time my problem can be solved so quickly. Thanks greatly.) Try this instead: fieldList = gp.ListFields(out_shape) for field in fieldList:     if field.name[1:3] == "ID_":         gp.deletefield (out_shape, field.name) ... View more

I just checked the 10.0 help and that paragraph is new at 10.1.  It was not there at 10.0.  This should have been in the what is new with 10.1, but it isn't.  For me this feature is a big deal. I redid my model to use the FeatureClassToFeatureClass_conversion tool instead of the Copy Features tool and it worked also.  I outputted to the local Default.gdb, in case that makes a difference, but the inputs were from a network gdb. ... View more

I am not seeing the behavior described in red below.  I have a point feature class related to many records in a table.  After performing the AddJoin, and then a FeatureClassToFeatureClass_conversion, I am not getting multiple point records as expected.  I thought there was  a NIM relating to this, however I am not able to find it. One-to-many and many-to-many relationships When using data where a one-to-many or many-to-many relationship exists, you should use a relate or relationship class to establish the relationship between the datasets.  However, it is possible to create a join under these circumstances.  When you create a join in such a case, there are differences between how tools and other layer-specific settings work depending on the data source.  If you are using geodatabase data to create the join, all matching records are returned.  If you are using nondatabase data, like shapefiles or dBASE tables, to create the join, only the first matching record is returned. This means that if you have created a 1:M or M:M join with geodatabase data and you generate a report, you see multiple records in the report, one for each corresponding match.  The multiple matches are also seen when using a join field while symbolizing a joined layer, labeling, identifying features, generating a graph, and using either the Find or Hyperlink tool. If you are using the joined layer as input to a geoprocessing tool or in an export operation, the multiple matching records are used. This is the first time I have ever seen that.  I am using 10.1.  I just tried it and it worked as it says.  I created a model where I used a geodatabase feature class as an input to the Male Feature Layer tool, used a geodatabase table with a 1:M relationship with the Join tool, used the Select by Attributes tool to select a set of the joined records, and then used the Copy Features tool to output a new feature class.  The 1:M relationship outputted points that had become a 1:1 set of points relative to the joined table. This is something I had never seen before, but I was so used to this not working at prior versions I never thought I would see the day this happened, so I had never tried it before with 10.1.  I have no idea how many versions back this applies to, but at 10.1 with build 3143 and the Advanced license it worked. It worked the same way using a joined layer in ArcMap with the same selection that I exported to a geodatabase feature class using the layer's Export context menu.  So now there is finally a reason to do a 1:M or M:M join that I can use. ... View more

I know this is an older post, but I'm running into a similar problem... I'm wanting to run the Calculate Field too on a combination of fields from both the table where the join table will be joined to and the join table itself.  For example, I have a layer of Pipelines (the layer to which the join table will be joined) and a layer called Pipeline_Stats (the table to be joined to the input layer (Pipelines)).  But when I run the Calculate Field tool, and choose the Pipelines layer as the Input Table, I only see fields originally contained in the Pipeline layer, and none of the fields from the joined Pipeline_Stats table.  I could copy the data over I suppose, but I'm not sure which tool to use to accomplish this.  Plus, that somewhat defeats the purpose of the Join, I guess. This will be run inside a Model, so I can automate the process if it'll take multiple steps to get it accomplshed -- although the simpler/easier would be best... Thoughts? The prior response is in error in implying you can use the field calculator on the joined table itself. Only the primary layer/table can be altered using the Field Calculator, not the table joined to it.  Besides, you cannot derive statistical summary data using the field calculator across multiple records. You could transfer the joined summary data into a field in the Pipelines themselves using the join you have set up and the field calculator.  But you probably don't need to do that and are already getting what you need by doing other calculations based on those joined values without transferring the values themselves. To calculate values into the Pipeline_Stats, you would need to reverse the join so that Pipeline_Stats is the primary table.  However, I assume more than one Pipeline relates to a single stat row.  In that case first use the Summary Statistics tool against the Pipelines to summarize down to values on one record per the join field value of Pipeline_Stats.  To do this keep the field that Pipelines shares with the Pipeline_Summary as the unique case field (a separate field list from the summary field list).  Then perform summaries on the other fields, like counts, sums, min, max, mean, std dev, first, last, etc.  Join the created summary output to the Pipeline_Summary table and update its fields based on the new summary of the Pipelines using the Field Calculator.  If the Summary_Statistice tool does what the Pipeline_Stats calculation would do, you could consider just replacing Pipeline_Stats by rerunning the Summary_Statistics tool model as needed. ... View more

I just tried creating a Model Builder model where I did three successive joins.  For the second and third join I had to use the qualified field name of the original layer feature class.  So the loop probably needs to be modified to keep track of the first time a join is done and all other times the join is done. ################################################## ######################## ##AddJoin feature layers to a feature layer ##Elaine Kuo ##01 July 2013 ################################################## ####################### #Import standard library modules import arcgisscripting import os #Create the Geoprocessor object gp = arcgisscripting.create(9.3) gp.QualifiedFieldNames = "UNQUALIFIED" #Set the input workspace workingfolder= "H:/temp_D/test" gp.Workspace = workingfolder #Set the output workspace outputfolder= "H:/temp_D" outWorkspace= outputfolder source_fc = "H:/temp_D/testt/A_grid.shp" Entity = "H:/temp_D/test/geoc0283.shp" #Get a list of the featureclasses in the input folder fcs = gp.ListFeatureClasses() gp.Toolbox = "Data Management" # Make a FeatureClass layer    gp.MakeFeatureLayer_management (source_fc, "source_lyr") $ A counter to separate the first time through the loop from all other times counter = 0 # Loop through every item in the list that was just generated for fc in fcs:     if counter == 0:         # set up first Layer for AddJoin         gp.AddJoin_management("source_lyr", "GID", fc, "GID", "KEEP_ALL")     else:         # set up second and following Layers for AddJoin         gp.AddJoin_management("source_lyr", "A_grid.GID", fc, "GID", "KEEP_ALL")     counter += 1 # convert a layer to a featureclass out_name = gp.Describe("source_lyr").name out_name = gp.ValidateTableName(out_name, outputfolder) out_shape = outputfolder + "/" + out_name + ".shp" gp.CopyFeatures_management ("source_lyr", out_shape)     # delete Field  (need to clean up with a lot more ID fields that the code you have below since now there are 50 GID values.) gp.deletefield (out_shape, "FID_1; GID_1") # Don't bother removing 50 joins, just kill the layer # clear memory of layers gp.Delete("source_lyr")     gp.AddMessage(gp.GetMessages()) print gp.GetMessages() ... View more

I agree with you, getting the path (and slashes) correct seems to be a common problem out there.  In fact a great number of people I come across incorrectly think that this is a back slash ("/") and this is a forward slash ("\"), which in fact is the opposite. There is actually a fourth case that works (although it is unnecessary since the other 3 path syntax formats you gave work more elegantly) 4.) raw string with slashes = r"H:/InfoRequest" In essence it is the same as just using slashes, but nonetheless it will work and not throw an error if it is used.  So it technically is a 4th working case, even if it is not recommended. ... View more

While the core of your loop was contained in the code you wrote, only the join belongs within loop.  Now that I know what you really want at the end try this (not sure it will work, since I never tried 50 joins in a loop before). ################################################## ######################## ##AddJoin feature layers to a feature layer ##Elaine Kuo ##01 July 2013 ################################################## ####################### #Import standard library modules import arcgisscripting import os #Create the Geoprocessor object gp = arcgisscripting.create(9.3) gp.QualifiedFieldNames = "UNQUALIFIED" #Set the input workspace workingfolder= "H:/temp_D/test" gp.Workspace = workingfolder #Set the output workspace outputfolder= "H:/temp_D" outWorkspace= outputfolder source_fc = "H:/temp_D/testt/A_grid.shp" Entity = "H:/temp_D/test/geoc0283.shp" #Get a list of the featureclasses in the input folder fcs = gp.ListFeatureClasses() gp.Toolbox = "Data Management" # Make a FeatureClass layer    gp.MakeFeatureLayer_management (source_fc, "source_lyr") # Loop through every item in the list that was just generated for fc in fcs:     # have Layers for AddJoin     gp.AddJoin_management("source_lyr", "GID", fc, "GID", "KEEP_ALL") # convert a layer to a featureclass out_name = gp.Describe("source_lyr").name out_name = gp.ValidateTableName(out_name, outputfolder) out_shape = outputfolder + "/" + out_name + ".shp" gp.CopyFeatures_management ("source_lyr", out_shape)     # delete Field  (need to clean up with a lot more ID fields that the code you have below since now there are 50 GID values.) gp.deletefield (out_shape, "FID_1; GID_1") # Don't bother removing 50 joins, just kill the layer # clear memory of layers gp.Delete("source_lyr")     gp.AddMessage(gp.GetMessages()) print gp.GetMessages() The error you reported is due to the fact that you were not doing a single fc, but a loop of all the fcs.  I also would just assign a name for the final output rather than deriving it from the layer, since that step only runs once now to create a single shape file at the end. If this code does not throw an error and creates an output, do not be surprised if the output only contains one join or no join.  That is the part I am not sure about when you do multiple joins on top of each other and a possibility related to the error you reported in your last post. ... View more

Just for the record, a single forward slash ("/") works fine, it's the backslash ("\") that's illegal. The following techniques will all work in a path: 1.) forward slashes = / 2.) double backslashes = \\ 3.) raw string with backslashes = r"H:\InfoRequest" Thanks for the clarification.  Python is not my language of choice, and the escape character and path string handling is something that trips me up and many other posts in this forum.  So I figured it could be related to his problem (even though my answer made the problem worse on that issue).  One of the reasons I use Model Builder instead of typing in Python directly when I get errors about paths. ... View more

Thank you for the help. The AddJoin code below worked well. As you said, I want to add a loop to the AddJoin of a grid and multiple bird range. Please kindly advise how to code it. Thank you. ################################################## ######################## ##AddJoin feature layers to a feature layer ##Elaine Kuo ##30 June 2013 ################################################## ####################### #Import standard library modules import arcgisscripting import os #Create the Geoprocessor object gp = arcgisscripting.create(9.3) gp.QualifiedFieldNames = "UNQUALIFIED" #Get a list of the featureclasses in the input folder source_fc = r"H:/temp_D/testt/A_grid.shp" Entity = r"H:/temp_D/test/geoc0283.shp" output_fc = r"H:/temp_D/test/grid_rng.shp" gp.Toolbox = "Data Management"     # convert a featureclass to a layer gp.MakeFeatureLayer_management (source_fc, "source_lyr") # have Layers for AddJoin gp.AddJoin_management("source_lyr", "GID", Entity, "GID", "KEEP_ALL") # convert a layer to a featureclass gp.CopyFeatures_management ("source_lyr", output_fc) # delete Field gp.deletefield (output_fc, "FID_1; GID_1") # Remove the join gp.RemoveJoin("source_lyr", "geoc0283")     # clear memory of layers gp.Delete("source_lyr")     gp.AddMessage(gp.GetMessages()) print gp.GetMessages() Great.  So this is the core of any loop you would build if you needed to process multiple bird range shape files against the grid. In another post you mentioned you have one grid shape file and 50 bird range shape files.  Do you need one final shape file that has 50 fields for all of those bird ranges or do you want 50 separate shape files that match each one of the bird ranges to the grid separately? ... View more