https://docs.nvidia.com/isaac/isaac/doc/doc/component_api.html#isaac-map-map states:
This component is used to mark a node as a map and gives convenient access to the various map layers and also some cross-layer functionality.
But it is not documented anywhere how to do that. In my case, I just want to know the defined waypoints in the WaypointMapLayer.
How do I do this specifically and in general? The documentation seems to be really missing a lot of such details or examples still.
After a long search, mostly through existing header files in the SDK, I found my way up through Codelet, Component::Node, to Application. The Application class has methods for finding arbitrary nodes in the application graph, specifically one can use:
getNodeByName(const std::string& name) const;
In my case, I was able to call this in my components start method:
// get the map node:
isaac::alice::Node* map = node()->app()->getNodeByName("map");
// within that node, get the WaypointMapLayer component:
isaac::map::WaypointMapLayer* comp = map->getComponent<isaac::map::WaypointMapLayer>();
// get the configuration parameter we want:
waypoints = comp->get_waypoints();
Related
Is it possible to have OSMnx (great tool BTW) include car ferries when building a graph? Failing that, what would be the most direct way to build such a graph? The problem isn't just that the ferry routes themselves aren't present but, without the ferries, islands that are in reality reachable by car aren't included in the road network.
I have tried using osmnx.settings.useful_tags_way to no avail. Using 'route'='ferry' in overpass-api returns what I would like to include in the graph so I have been editing the OSMnx downloads.py file trying to alter the overpass-api call directly.
Thanks!
First pass (hacky)
I've came up with fairly hacky partial solution by editing osmnx's downloads.py file and replacing the line (originally around line 350):
query_str = f"{overpass_settings};(way{osm_filter}(poly:'{polygon_coord_str}');>;);out;"
with:
osm_filter2 = f'["route"="ferry"]'
query_str = f"{overpass_settings};(way{osm_filter}(poly:'{polygon_coord_str}');>;way{osm_filter2}(poly:'{polygon_coord_str}');>;);out;"
The query string format took some trial and error. If this, or something like it, turns out to be the best approach, I'll try to make it more broadly applicable (add "ferry" to the predefined filter list rather than hardcoded, pass a list of filters, etc).
Much Better
I found that building separate graphs and unioning them using networkx.union or networkx.disjoint_union did not give usable results. So I have added a multiple filter capability to my version of the osmnx downloads.py file. I also added some additional network type options. So it's now possible to pass, for instance, "ferry" as a network_type for the osmnx.graph_from_* functions:
network_type = "ferry"
I can also now pass multiple network types using a pipe delimiter:
network_type = "drive|ferry"
to get a graph that is the union of the two. When doing this, I found that it's useful to create a second ferry-only graph and use that as a reference to update the tags in the combined network graph. It is also better to load non-simplified graphs at first and and simplify it/them yourself after this step.
Still experimenting
Still having some issues with non-connectedness - now in the ferry-only network. Car ferries at isolated crossings than don't share a harbor with a through-ferry are not included in the ferries-only graphs and therefore the tags of their counterparts in the combined network aren't getting updated as needed. The ferries in the combined network (network_type = "drive|ferry") are all present and connected correctly and therefore their respective islands are now on the road network - which is great. But, because their tags aren't being updated, these isolated ferries are getting default highway speeds (and I'm doing travel time analysis). I can use work around this using:
if not 'highway' in edge[3]:
but, for a robust solution, I think we want to be able to tag them explicitly.
I'd still love to hear what other think.
I'm writing MapBox vector tiles using geotrellis vectorpipe.
see here for the basic flow: https://geotrellis.github.io/vectorpipe/usage.html
Typically GeoJson Features can have an id field, so that Features can be rolled up into FeatureCollections. I need to make use of this field, but vectorpipe doesn't (natively) have this capability.
This is the Feature type used, and you can see it only has space for 1) a Geometry and 2) a data object D (which ends up populating properties in the output). There is no spot for an id.
https://geotrellis.github.io/scaladocs/latest/index.html#geotrellis.vector.Feature
Upstream there's a method called writeFeatureJsonWithID() that does let you inject an id field into a Feature when writing GeoJson.
https://github.com/locationtech/geotrellis/blob/master/vector/src/main/scala/geotrellis/vector/io/json/FeatureFormats.scala#L41-L49
My question is this:
I have worked through the vectorpipe code (https://github.com/geotrellis/vectorpipe), and I can't figure out if/where the data ever exists as GeoJson in a way where I can override and inject the id, maybe using the writeFeatureJsonWithID() or something I write explicitly. A lot of conversions are implicit, but it also may never explicitly sit as json.
Any ideas for how to get an id field in the final GeoJson written to vector tiles?
EDIT
Right now I think the trick is going to be finding a way to override .unfeature() method here:
https://github.com/locationtech/geotrellis/blob/master/vectortile/src/main/scala/geotrellis/vectortile/Layer.scala
The problem is that the internal.vector_tile.Tile is private, so I can construct it without forking the project.
Ended up having to fork geotrellis, hard-code a metadata => id function in Layer.unfeature() and compile locally to include in my project. Not ideal, but it works fine.
Also opened an issue here: https://github.com/locationtech/geotrellis/issues/2884
I recently upgraded my Free Radius code from 2.0 to 3.x build. I am looking for some of the APIs supported by older Free Radius versions. I am looking for APIs ldap_pairget(). Can you please let me know what APIs should be used in place of ldap_pairget. ALso these function include pairmake(), pairadd(), pairdelete() APIs which are not available in newe Free Radius Code.
Thanks
In v3.0.x theres a concept of "tmpls" (templates) and maps. Templates describe a data source or sink, and maps describe how to move data from one tmpl to another. There are still the low level pair move functions.
Pair allocation fr_pair_alloc.
Assigning value from string fr_pair_value_from_str.
Add a pair to a list fr_pair_add.
Replace an existing pair in a list fr_pair_replace.
Delete a pair by its protocol number fr_pair_delete_by_num.
The equivalent function to ldap_pairget in v3.0.x is fr_ldap_map_do, but it's not designed to be used by external callers. It'll work, but it's a lot of effort to feed it the structures it expects.
In general, if you have user configurable mappings you should call map_to_request, and pass it the callback it needs to get values for the pairs being created.
In Paper [A Software Product Line for Static Analyses(2014)], there is an illustration related constructing call graph(Listing7).
In this example, Line14 is related to construct call graph. while i check the src code and API, what i could find is DefaultCHACallGraphDomain.scala which has no implementation of construct call graph.
As my purpose is using OPAL to construct call graph. Is there any demo or documents help me understanding existing CallGraphDomain in OPAL? currently, i can only find some class declaration.
I'll be really appreciated if anyone can give me some suggestions related this topic.
Thanks in advance.
Jiang
The interface that was shown in the paper doesn't exist anymore, so you can totally forget about it.
The default interface to get a CallGraph class is provided by the Project object you retrieve when you load the bytecode a Java project.
A general code Example:
val project = ... // a java project
val computedCallGraph = project.get(/* Some call graph key */)
val callGraph = computedCallGraph.callGraph // the final call graph interface.
The computed call graph contains several things. It contains the entry points, unresolved method calls, exceptions when something went wrong at the construction time and the actual call graph.
OPAL provides you several call graph algorithms, you can retrieve each by passing the corresponding call graph key to the Project's get method.
Currently, the following two keys are available and can be passed to Project.get (more information is available in the documentation of this classes):
CHACallGraphKey
VTACallGraphKey
Analysis mode - Library vs Application
To construct a valid call graph for a software project it depends on the project kind which analysis mode to chose. While applications provide complete information (except incomplete projects, class loading and so on), software libraries are intended to be used by other projects. However, those two different scenarios have to be kept in mind, when construction call graphs. More details can be found here: org.opalj.AnalysisModes
OPAL offers the following analysis modes:
DesktopApplication (safe for application call graphs)
LibraryWithClosePackagesAssumption (safe for call graphs that are used for security-insensitive analyses)
LibraryWithOpenPackagesAssumption (very conservative/safe for security analyses)
The analysis mode can be either configured in OPAL's config file or set as project setting at runtime. You can find the config file in the Common project under /src/main/resources/reference.conf.
All of those analysis modes are supported by the the CHACallGraphKey while VTACallGraphKey only supports applications so far.
NOTE: The interface may change in upcoming versions again.
This is the problem:
Create a class and set the access to be private for some of the properties or methods.
Use the doc command for the created class. This will auto-generate documentation from your comments and show it in the built-in help browser.
doc classname
The problem is that documentation for the private properties and methods is not shown in the help browser. Is there any way to overcome this problem?
So I spent like 10 minutes using the debugger, jumping from one function to the next, tracing the execution path of a simple doc MyClass call.
Eventually it lead me to the following file:
fullfile(toolboxdir('matlab'),'helptools','+helpUtils','isAccessible.m')
This function is called during the process of generating documentation for a class to determine if the class elements (including methods, properties, and events) are publicly accessible and non-hidden. This information is used later on to "cull" the elements.
So if you are willing to modify MATLAB's internal functions, and you want the docs to always show all methods and properties regardless of their scope, just rewrite the function to say:
function b = isAccessible(classElement, elementKeyword)
b = true;
return
% ... some more code we'll never reach!
end
Of course, don't forget to make a backup of the file in case you changed your mind later :)
(on recent Windows, you'll need to perform this step with administrative privileges)
As a test, take the sample class defined in this page and run doc someClass. The result:
This behaviour is by design - the auto-generated documentation is intended for users of the class, who would only be able to access the public properties and methods.
There's no way that I'm aware of to change this behaviour.
You could try:
Use an alternative system of auto-generating documentation such as this from the MATLAB Central File Exchange (which I believe will document all properties, not just public).
Implement your own doc command. Your doc command should accept exactly the same inputs as the built-in doc command, detect if its inputs correspond to your class/methods/properties etc, and if so display their documentation, otherwise pass its inputs straight through to the built-in doc. Make sure your command is ahead of the built-in on the path.