OSGEarth Symbology Classes

classic Classic list List threaded Threaded
14 messages Options
chuckshaw chuckshaw
Reply | Threaded
Open this post in threaded view
|

OSGEarth Symbology Classes


I'm looking for some pointers on using the osgearth symbology helper classes.  Right now I have my own 2525b symbology lib, so I pass in a SIC and it returns a QImage.  From there I convert it into an osg::Image.  

Currently, I'm just creating an osg::Geode with an osg::Text label and a random osg::ShapeDrawable and place it on the earth with objectplacer.  Now that I am about to replace the random shape with the actual 2525b symbol,  I'm trying to decide if i need to create a custom node class that will hold the symbol, label, and all other drawables such as sensor fans / domes, track history, etc.

Is there a specific design pattern that ya'll have envisioned when using OSGEarth?  I'm looking through the osgearth_symbology example right now looking at how ya'll did similar things.  I'm going to have to support, entity selection, popup menus etc, for these guys.  Is it intended that the OSGEarth::Symbology classes will support the kind of things i'm trying to do?  Or do I need to stop looking for the easy way out and just build my own?

Thanks,
Chuck

Thanks,
Chuck Shaw
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Chuck,

The short answer is "yes", the symbology library is intended to support that type of thing. More specifically, the goals of Symbology are:

* Provide a framework for compiling OSG geometry from raw vector data + symbol information.
* Apply the separation of content and styling in an OSG context.
* Make it easy to style, re-style, and interact with vector data at run time.

That said, the library is a work in progress. We are expecting to re-enter major development hopefully in early 2011. We intend to review the architecture, refactor a number of things, and also focus energies on scalability.

In the meantime, use cases such as yours are valuable as we enter into this process -- capabilities like interactivity/selection, popups, etc are all on the radar.

Glenn
Glenn Waldron / Pelican Mapping
Mogu Mogu
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Hi

I see that in 2.1 there are more feature and symbol support. The featureeditor example shows how you runtime can create and edit features with the use of stylsheets.

Would you say that the feature/symbol system is now mature enough to be used for creating tracks (e.g. 2525b)?

Morten
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Mogu,
Maybe, what all does that entail?

Glenn
Glenn Waldron / Pelican Mapping
Mogu Mogu
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Well, I'm going to make a system that supports tracks, where I define a track to be e.g. one or more vector data that defines a symbol, one or more texts placed at fixed posistions around this symbol, dynamic velocitiy vector, maybe history objects as well.

So I was wondering if you reccomend to use osg functionality directly to create mye tracks, or if it is better to use the osgEarth feature/symbyology system with the new 2.1 functionality?

Morten
chuckshaw chuckshaw
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Well for my own effort I plan to eventually migrate over to use more of the osgEarthSymbology classes.  However I do not think they are currently mature enough to handle tracks like I think you want to do.  

Right now I use a mix of osgEarth specific api (ObjectLocatorNode, etc) and base osg api to handle the task.  My 2525b Symbology is setup using osg::Texture2d etc, heading lines, track history, sensor view sheds etc use base osg classes.  Eventually I want to use osgEarth's FeatureNodeGraph to handle some of the items that are associated with tracks (ttl, track age, history, heading, sensors, battle damage assessment, classifications, etc).  That effort is currently in work and i'll let you know how that eventually works out.  On top of that, my attempts to use MarkerSymbol to actually draw the 2525b symbology just hasn't worked for me yet.  So If i were you, I would start with doing it the osg way, and slowly migrate over to the osgEarthSymbology classes as those api's stabilize and become more mature.

Thanks,
Chuck Shaw
Mogu Mogu
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Thanks!

I have done some testing now to see if I am able to draw a track using the Feature/Symbology system.
Using the osgearth_featureeditor example I can create features with symbols for lines, polygons, texts etc.

But when I create the geoemtry that is set to the feature this has to be in geographic values, that is later converted to geocentric (looking at the result vertices in the FeatureModelGraph).

Is there a way to specify the geometry with a kind of local coordinate system? I would like to move/transform the FeatureModelGraph object with either geographic or geocentric values, not change all vertices in my geometries to move my track.

Any help is appreciated.

Morten
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Morten,

This isn't supported explicity, but you can achieve the result like this:

Use GeometryNode to build geometry in a local cartesian coordinate system (XYZ). Use the constructor that does NOT take a MapNode.

Then, call GeometryNode::getOrCreateParent<osg::MatrixTransform>(). This will create and return a parent node transform that you use to position the GeometryNode on the globe, creating a kind of local tangent plane coordinate system for the geometry.

The last step is to assign the proper positioning matrix to the transform. You can do something like

osg::EllipsoidModel* e = map->getProfile()->getSRS()->getEllipsoid();
osg::Matrix local2world;
e->computeLocalToWorldTransformForLatLongHeight( lat, lon, h, local2world );
...

Then assign that local2world matrix to the geometry node's parent transform.

HTH, Glenn
Glenn Waldron / Pelican Mapping
Mogu Mogu
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

That worked perfectly!
I now have a symbol system that support polyarc, circle, uprightrectangle, polygon, and polyline.
I use osg::AutoTransform to keep the symbols device fixed.

I now have some difficulties creating a TextSymbol the same way. How can I give the text symbol my text data when it is not connected to a feature source like OGR? I'm not sure I understand how to use content and provider to do this.

Morten
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Morten,

I should also call attention to this CircleNode and EllipseNode types in the Annotation header, though it sounds like you have this covered.

In general, just set TextSymbol::content() to a string and the GeometryCompiler will render that text. Set the provider to "overlay" and you will get a screen-space label that participates in the overlap prevention algorithm.

You can also try the PlacemarkNode. It renders a text label along with an optional icon. (Note that we might change the name of this note in the future to avoid ambiguity.)

HTH, Glenn
Glenn Waldron / Pelican Mapping
Mogu Mogu
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Yes thanks I found the CircleNode and EllipseNode in the doxymentaion.

I have been debugging a bit and it seems that using GeometryNode with a style containing a TextSymbol is not supported. BuildGeometryFilter seems to be the code that creates the osg geometry, and this code does not check for TextSymbol.

I did test with PlacemarkNode, but this cannot be created without the mapnode. I would like to have control of the result text node because I would like to place it together with my other geometries created with GeoemtryNode. I now have a top parent node with my world transform, a child node that is a osg::AutoTransform,  then several GeometryNodes with an offset transform as childs to the AutoTransform. That structure now represents a "track", but without text.

I can of course create my own osg::Text objects if GeoemtryNode is not supposed to support text? Or maybe I just so not understand how the text is supposed to be created. You did mention the GeometryCompiler, maybe I should look more to what happens within that object.

Morten
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Morten,

Fact is, the annotation stuff is a work in progress, so I'm happy to solicit your input in terms of how things should be laid out. For example, should all "annotation" elements support labeling? Or should labeling always be a separate thing? Anyway, we're open to suggestions. The annotation classes are intended to be convenient wrappers for lower-level concepts.

For example, GeometryNode just renders a Geometry; that's it. It does not honor the TextSymbol. The FeatureNode, on the other hand, renders a whole feature and honors all style information (including labels). But it does not support the kind of "local tangent plane" approach that you're using.

Again-- these are convenience classes and we're open to exploring the best way to organize a library for annotation support.

Glenn
Glenn Waldron / Pelican Mapping
Mogu Mogu
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Well, I do like the simple GeometryNode. A input geometery and a style gives you a node that looks similar to something the Feature system creates. It would be nice if GeometryNode could support all Style's.

I could contribute support for TextSymbol with GeometryNode if you'd like?

Morten
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: OSGEarth Symbology Classes

Morten,

Thanks. Actually, based on some new requirements, we're going to be re-working the entire annotation subsystem. So let me do some initial work on that and then see where we are. But it's helpful to gather requirements. I'm going to post a new message calling for comments on the topic.

Glenn
Glenn Waldron / Pelican Mapping