<div dir="ltr">Hi Sebastian,<br><div class="gmail_extra"><br><div class="gmail_quote">On 20 April 2016 at 09:49, Sebastian Messerschmidt <span dir="ltr"><<a href="mailto:sebastian.messerschmidt@gmx.de" target="_blank">sebastian.messerschmidt@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>Am 20.04.2016 um 10:05 schrieb Robert
Osfield:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Sebastian,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 20 April 2016 at 08:17, Sebastian
Messerschmidt <span dir="ltr"><<a href="mailto:sebastian.messerschmidt@gmx.de" target="_blank">sebastian.messerschmidt@gmx.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Openflight databases
seem to use this user-data at the root node to describe
the geographic base coordinates of UTM-databases.<br>
Unfortunately this class doesn't seem to have a serializer
for the osgXYZ file formats. What is the best way to add
such serialization capabilities?<br>
</blockquote>
<div><br>
</div>
<div>Been a very very long time since I heard mention of the
osgSim::GeoographicLocation class... just been sitting
there quietly minding it's own business.<br>
</div>
</div>
</div>
</div>
</blockquote></span>
The issue right now is, that I somehow have to distribute the
lat,lon origin in some OpenFlight centric workflow. I could totally
do this differently by transforming the information into my own
format. <br><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Looking at the implementation now the two parameters
that need to be serialized at the latitude and longitude
paramters. If these used the setName()/getName()
convention then it'd be easy to add serializers using the
standard ADD_DOUBLE_SERIALIZER( Name, 0.0); serializers
(for instance see the usage in
src/osgWrappers/serializers/osg/ ). <br>
<br>
As these don't follow the setName/getName() one will
either have to write a custom serializer for it or simply
change the naming across to the setName()/getName()
convention that the almost all of the OSG uses. I'd be
inclined to do the later. Then just add the
GeographicLocation serializers to the
src/osgWrappes/serializers/osgSim. This would mean that
the change could only be add to OSG master and no
backported to OSG-3.4 or OSG-3.2 as the ABI would change,
but personally I'd be happy with this.<br>
</div>
</div>
</div>
</div>
</blockquote></span>
I'll try to do this then and present the submission when I find the
time. <br></div></blockquote><div><br><br></div><div>The other route which would with recent OSG versions would be to copy the GeographicLocation data to the a Node's UserValue i.e.<br><br></div><div> node->setValue("latitude", geographicLocation->latitude());<br><div> node->setValue("longitude", geographicLocation->longitude));<br><br></div><div>The values then would be serialized automatically.<br><br></div><div>Robert.<br></div><div><br></div></div> </div></div></div>