Latest Contributions by AZendel

The below is the ArcMap UI for setting impedance in a service area layer: Is there a way to set this in model builder? Our county's central GIS office set up our network dataset and I can't change it. It includes attributes (fields) such as FT_COST, FT_SPEED, FT_MINUTES. FT_COST and FT_MINUTES are the same for most street segment - they both represent time costs. I need service areas based on distance (feet or miles), but model builder seems to keep defaulting FT_COST or FT_MINUTES. If I change the impedance in Pro to "CostLength feet" in the above screenshot, I get the expected results. One way streets and overpasses (F_ZLEV, T_ZLEV) are respected as well. But I want to use model builder so we don't have to go through all of these steps manually. But I can't find a place to set the impedance to distance/length. Is this possible in model builder? I also tried exporting the model to python and then adding a travel mode: #new_travel_mode = arcpy.na.TravelMode(travel_modes["Driving Distance"]) new_travel_mode = arcpy.na.TravelMode() new_travel_mode.impedance = "Feet" # Process: Make Service Area Analysis Layer (Make Service Area Analysis Layer) (na) Service_Area2 = arcpy.na.MakeServiceAreaAnalysisLayer(network_data_source=TRANSROUTING_ND, layer_name="Service Area2", travel_mode=new_travel_mode, travel_direction="FROM_FACILITIES", cutoffs=[2], time_of_day="", time_zone="LOCAL_TIME_AT_LOCATIONS", output_type="LINES", polygon_detail="STANDARD", geometry_at_overlaps="OVERLAP", geometry_at_cutoffs="RINGS", polygon_trim_distance="100 Meters", exclude_sources_from_polygon_generation=[], accumulate_attributes=["CostLength"], ignore_invalid_locations="HALT")[0] But line 6 bugs out with this error: ERROR 030232: Invalid travel mode value: "The travel mode refers to an impedance attribute that does not exist.'' I am using Pro version 3.0.3. We can't upgrade due to incompatibilities with our county's ArcGIS Server Version. Thanks for any insight that you can provide! ... View more

Howdy folks. I'm not using the FGDB API at all. But I think is the best community/forum to ask because it's a question about low-level FGDB functionality and manipulation. I'm using 3rd party software that's built on top of Pro. It involves a number of tables in a file geodatabase. And it's critical that rows remain in their original order because re-ordering rows caused catastrophic results in their software. I think they're looping through multiple tables that they expect to be in a particular order rather than using proper database joins on identifier fields. I would like to add fields to their FGDB tables "behind the scenes" in the catalog pane in Pro. I'm aware that schema changes will cause many RDBM systems to fully re-write the table. Is that the case for FGDBs? If it does require a re-write, will the new table have the rows sorted in the same order? In a related matter, are there other operations on FGDBs that may alter the order of the rows? Thanks for any insight that you can provide. ... View more

I just ran across this help topic while researching a related issue: File geodatabases SQL reference. This has a lot of potential to be very handy. Where can you execute these statements that use concepts such as aggregations and joins? Is there somewhere in the Pro interface that I haven't noticed? In some geoprocessing tools? Or only in the FGDB API? ... View more

I've been using model builder for over 2 decades now -- back to the days of ArcMap 8.x.  A very common workflow is to join a 'standalone table' to a feature class and then use the Calculate Field tool to either transfer values from the table or perform actual numeric calculations across both tables. I've done that probably 100s of times over the years and it used to be easy in model builder. When you'd open up the Calculate Field tool, the list of fields where you could specified the target field would be listed as FeatureClass.Field or Table.Field. This appears to still happen most of the time, maybe all of the time (see blue highlight below). Then you could double click fields in the area circled in green to start building your calculation expression.  But now the fields from the joined table aren't even listed in the green list any more. But I remembered that with Python, the expression would be !tablename.fieldname!. When I type that by hand and click the verify button (green check mark circled in purple above) it doesn't report any errors or problems. But when I run the tool, it fails. OK, so let's try Arcade instead. Since the fields from the joined tables are listed in the fields list, we have to guess the correct syntax. Based on how it used to work with VB expressions and python expressions, I've tried: $feature.tablename.fieldname  (not accepted) To try to be in sync with the python expressions, I've tried $feature!tablename.fieldname!. That didn't work either -- and I didn't expect it to.  I'm still on Pro 3.0.3 due to some compatibility issues with our county's ArcGIS Server. Was this a bug in 3.0.x versions of Pro? Is it fixed in newer versions? If not, does anyone have suggestions? I'm aware of the "join field" tool and I'm using it as a work around for now. When you're just transferring values from one field from a joined table to the feature class, it only requires one step and therefore it's actually easier. But not necessarily if you're trying to repopulated a field that's already in the 'target' feature class or table.  And it's not easier when you're doing arithmetic across both tables such as (featureclass.field1 + jointable.fieldX) * jointable.fieldY. It's also not faster in my current need: I have a stand alone table that I need to populate with X, Y coordinates from several 2 feature classes, meaning I have to do 2 joins. And this is what I get when I do that with the Join Field tool:   So now I have to 1) Select by Attributes where X is Null 2) Calculate Field twice, one to transfer X_1 to X field, one to transfer the Y_1 to the Y field 3) Delete the unneeded X_1 and Y_1 fields.  ... View more