Open ethanplunkett opened 9 months ago
BirdFlowRoute
objectsplot_routes()
. Unclear whether it's OK to start and end on the same timestep (OK with current synthetic routes, maybe not with @slager's working specification)When calculating track stats we shouldn't be limiting the track to locations the model thinks is valid. Therefore this function and snap_to_birdflow()
need an argument - maybe valid_only
- that controls whether the output should be limited to valid locations.
plot_routes()
is now used for real data and for synthetic routes generated in python, as well as for the output of route()
. It needs to be more robust and make fewer assumptions about the data. Switching from cyclical to monotonic dates will help a lot. Dropping any use of timesteps in the plotting code would also be good.
as_route()
Alternate name possibilities:
convert_to_route()
as.BirdFlowRoutes()
(method of genericas
),Most of the work is already done by
snap_to_birdflow()
, issue #155, pr #157This would be a wrapper to
snap_to_birdflow()
that makes the output a formal BirdFlowRoutes object.At a minimum it needs to:
snap_to_birdflow()
id_cols
bf
to the attributes.metadata$route_type
to something possibly set by an additional argument. Output ofroute()
uses "synthetic" we need to figure out what types we allow for real data. I suspect it might be good to keep track of sensor type something like: "gps", "light" "modis", "banding". The MigConnectivity package has names it uses for different sensor types, be consistent with their terms if reasonable.A few other related cleanup items:
snap_to_birdflow()
frominterval_log_likelihood()
to eliminate redundant code.interval_log_likelihood()
are slightly different thansnap_to_birdflow()
standardize them.BirdFlowRoutes
produced byroute()
have a different column order thansnap_to_birdflow()
. Standardize.