create linear events from arc attributes.



ARCEVENT <cover> {route_cover} <route_system> <event_source> {search_radius} {max_iterations} {high_measure} {ALL | aat_item...aat_item}




<cover> - the input arc coverage from which events are to be created.


Only arcs that are in the ARCPLOT selected set will be used.  If no arcs have been selected, then all arcs are used.


{route_cover} - the coverage to which the output events are linked.


If no coverage is specified, then the input <cover> is used.


Only route sections that are in the ARCPLOT selected set will be used.  If no route sections have been selected, then all routes are used.


<route_system> - the route system in the {route_cover} to which the output events are linked.


<event_source> - the EVENTSOURCE which identifies the output event table.


This table must not already exist.


{search_radius} - the maximum distance (in map units) that an arc in the input <cover> can be from a route(s) in the {route_cover} in order for an event to be created.


If no distance is specified, it defaults to the current SEARCHTOLERANCE.


The {search_radius} is only applied at the ends of each input arc.  Thus, if there is a bow in the middle of the arc that is not within the {search_radius} of any routes, then an event will still be created.


This argument is ignored if the input <cover> is also the {route_cover}.


{max_iterations} - the maximum number of times that an input <cover> arc is bisected if either end isn't within the {search_radius} of an route in the {route_cover}.


If no number is specified, it defaults to 3.


ARCEVENT creates events using an iterative process.  On the first pass it tries to create events from the input arcs.  However, when either end of an input arc does not fall within the {search_radius} of an route, then no event is created.  Instead what is done is such arcs are bisected (twice) into four parts (I guess you should call it quadrasecting ;-), and a second iteration of ARCEVENT is made.  After the second pass any remaining arcs are bisected again, and the process continues until the {max_iterations} are reached.


The input <cover> isn't actually edited.  The bisecting takes place in a copy of the input <cover>.


This argument is ignored if the input <cover> is also the {route_cover}.


{high_measure} - the TO measure assigned to each output event that extends to the high end of a route.


Enter 0 to accept the actual high measure of the route.  This is the default.


{ALL | aat_item...aat_item} - which items in the <cover> AAT are transferred to the output event table.


ALL - all items (starting with <cover>#) are transferred.


aat_item...aat_item - only the specified items are transferred.


The output events are dissolved based on this item(s).





ARCEVENT runs from the ARCPLOT module of ARC/INFO.


ARCEVENT uses many other AMLs and C programs.  The AMLs and C programs need to reside in a directory in your &AMLPATH and &MENUPATH.  For more information, see arcevent.readme.


The more similar the input <cover> and {route_cover} are, the better ARCEVENT works.  Where there are gaps in the routes in the {route_cover} that do not correspond to gaps between arcs in the input <cover>, the results will not be as good.





PROCESS - When the input <cover> and {route_cover} are different, ARCEVENT creates events by adding route measures to the end of each input arc, and then traversing the route system between the two end points.


1) COPY INPUT COVER - A working copy is made of the input <cover>, so that the input coverage is not actually modified.  Nodes are built, and RENODE is run.


2) ADD ROUTE MEASURE - Route measures are calculated for the nodes in the input <cover>.  {route_cover} nodes take precedence.  In other words, if there are any {route_cover} nodes within the {search_radius} of a input <cover> node, then the route measure from the nearest {route_cover} node is assigned to the input <cover> node.  Otherwise the route measure from the nearest location along a {route_cover} route is assigned to the input <cover> node.  If no routes are within the {search_radius}, then no route measure is assigned.


3) PATH EVENT - Events are created by traversing the {route_system} between the route measures at the ends of each input <cover> arc.  The shortest path is taken.  (Actually it's the path that requires the fewest route sections.)


There are two limitations to this approach.  A) There is no requirement that the path taken stays within the {search_radius} of the input <cover> arc.  B) The path must be continuous.  In other words, it can't jump across a break in the route system.  Both of these limitations can conspire to cause the wrong path to be taken.  ARCEVENT works better when the {route_cover} more closely matches the input <cover>.


4) BISECT REMAINING ARCS - In the previous step there are two things that will prevent events from being created.  A) One or both of the ends of an arc don't have route measures (i.e. the node was outside of the {search_radius} of a route.)  B) There is a gap in the route system between the two route measures.  Each arc for which no events are created gets bisected twice to form 4 new arcs.  And then the process starts again, and is repeated until the {max_iterations} have been run.


5) DISSOLVE EVENTS - In the end the events are sorted and dissolved on the items specified by the argument {ALL | aat_item...aat_item}.





1) To display usage:


Grid: &run arcevent usage

Usage: ARCEVENT <cover> {route_cover} <route_system> <event_source> {search_radius} {max_iterations} {high_measure}

{ALL | aat_item...aat_item}


2) In this example ARCEVENT is used to create a stream class event table.  Stream class is stored in the AAT of the route coverage:


Arcplot: &run arcevent stream_cover # streams class_eso # # 9999 class


CLASS is the name of the stream case item.


3) The following example is the same except that stream class is stored in a different coverage than the route coverage:


Arcplot: &run arcevent class_cover stream_cover streams class_eso 100 ~ Arcplot: # 9999 class