Adding/removing map sources not reflected in SourceConfigList

classic Classic list List threaded Threaded
18 messages Options
Evan Andersen Evan Andersen
Reply | Threaded
Open this post in threaded view
|

Adding/removing map sources not reflected in SourceConfigList

I have noticed that when adding or removing a SourceConfig to a MapNode the change is not reflected in the MapConfig's SourceConfigList.  I'm working on an app that allows users to build up a map at run-time and then save the map configuration to a .earth file to be reloaded later, so this causes a problem with that use case.  I've put together a fix that implements the desired behavior and attached the modified file.

Evan

MapNode.cpp
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

Hi Evan,

I've merged your changes as well as a few others to make moveImageSource and moveHeightField source move the SourceConfigs so order is maintained.  Try the latest trunk and see how it works for you.

Thanks!

Jason

On Wed, Jul 22, 2009 at 4:05 PM, Evan Andersen (via Nabble) <[hidden email]> wrote:
I have noticed that when adding or removing a SourceConfig to a MapNode the change is not reflected in the MapConfig's SourceConfigList.  I'm working on an app that allows users to build up a map at run-time and then save the map configuration to a .earth file to be reloaded later, so this causes a problem with that use case.  I've put together a fix that implements the desired behavior and attached the modified file.

Evan

MapNode.cpp


View message @ http://n2.nabble.com/Adding-removing-map-sources-not-reflected-in-SourceConfigList-tp3305519p3305519.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.


Evan Andersen Evan Andersen
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

Jason

Thanks for getting that in so quickly.  I've tested it out and everything compiles fine, but I'm getting some strange errors when I try to iterate over the image and heightfield sourceConfig lists at runtime.  In our application we have a list of all the sources that can be added to the map and for convenience we store that list as a .earth file and load it into a MapConfig at run-time.  The problem occurs when I call readXml to load that earth file into a MapConfig.  After readXml returns, the vectors holding the source configs have a bunch of bad pointers in them after the first source config in each vector.  I've traced into the readXml function and everything seems fine with those vectors right up to the point where readXml returns.  After that the vectors have bad pointers in them and my program crashes when it tries to iterate over the source config lists.  I think the issue might have something to do with the SourceConfigList having been changed from a list to a vector, but I don't know what the problem is.  I reverted to the revision before the change and all the problems went away.  Then I implemented the fix to keep the map and the source configs in sync with SourceConfigList being a list instead of a vector and everything works.  I haven't tried to code up a small example of this and I'm under a pretty tight deadline at the moment, so I won't be able to get to it right away, but as soon as I get something I will send it.

Thanks,
Evan
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

Hi Evan,

Have you tried doing a full rebuild of osgEarth and your app?  It sounds like something isn't being built correctly.

Thanks,

Jason

On Fri, Jul 24, 2009 at 3:06 PM, Evan Andersen (via Nabble) <[hidden email]> wrote:
Jason

Thanks for getting that in so quickly.  I've tested it out and everything compiles fine, but I'm getting some strange errors when I try to iterate over the image and heightfield sourceConfig lists at runtime.  In our application we have a list of all the sources that can be added to the map and for convenience we store that list as a .earth file and load it into a MapConfig at run-time.  The problem occurs when I call readXml to load that earth file into a MapConfig.  After readXml returns, the vectors holding the source configs have a bunch of bad pointers in them after the first source config in each vector.  I've traced into the readXml function and everything seems fine with those vectors right up to the point where readXml returns.  After that the vectors have bad pointers in them and my program crashes when it tries to iterate over the source config lists.  I think the issue might have something to do with the SourceConfigList having been changed from a list to a vector, but I don't know what the problem is.  I reverted to the revision before the change and all the problems went away.  Then I implemented the fix to keep the map and the source configs in sync with SourceConfigList being a list instead of a vector and everything works.  I haven't tried to code up a small example of this and I'm under a pretty tight deadline at the moment, so I won't be able to get to it right away, but as soon as I get something I will send it.

Thanks,
Evan


View message @ http://n2.nabble.com/Adding-removing-map-sources-not-reflected-in-SourceConfigList-tp3305519p3322079.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.


Evan Andersen Evan Andersen
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

That's what I thought too, but after several rebuilds and checking to make sure includes, libs, and dlls are being used the problem remains.  I certainly can't say that the problem isn't with my app, but all I know is that when I implemented the fix with a list instead of a vector the problem went away.

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

Re: Adding/removing map sources not reflected in SourceConfigList

Is it just that one .earth file that causes a problem? If so, can you send it?

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

Re: Adding/removing map sources not reflected in SourceConfigList

I've tried several different files, with the same result.  Here's the main one I've been testing with though.

Evan

MapDataSources.earth
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

Do the standard osgEarth examples work as usual?  Also, what are you doing with the .earth file after it is loaded that is causing the crash, simply iterating over the sources?  Can you give me a quick code snippit so I can try to reproduce?

Jason

On Fri, Jul 24, 2009 at 3:35 PM, Evan Andersen (via Nabble) <[hidden email]> wrote:
I've tried several different files, with the same result.  Here's the main one I've been testing with though.

Evan

MapDataSources.earth


View message @ http://n2.nabble.com/Adding-removing-map-sources-not-reflected-in-SourceConfigList-tp3305519p3322203.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.


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

Re: Adding/removing map sources not reflected in SourceConfigList

In reply to this post by Evan Andersen
Thanks Evan. Your file loads fine and I am able to iterate over all the sources without a problem. What platform are you on?

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

Re: Adding/removing map sources not reflected in SourceConfigList

In reply to this post by jasonbeverage
The examples do seem to work as usual.  When I load the .earth file I just iterator over the sources to get their names and fill out a tree view control in MFC.  Below is the code without the references to the tree view control.  Sometimes when I run the app m_dataSources looks ok after the call to readXml, but then when I iterate over the heightfields it becomes corrupted.  Other time it just looks corrupted after readXml returns.  This behavior will change without doing any recompiling.

Evan

        const char *pszEarthFile = "MapDataSources.earth";
        osgEarth::MapConfig m_dataSources;
        if(!osgEarth::MapConfigReaderWriter::readXml(std::string(pszEarthFile), m_dataSources))
                return;


        // Terrain
        const osgEarth::SourceConfigList &terrainLayers = m_dataSources.getHeightFieldSourceConfigs();
    osgEarth::SourceConfigList::const_iterator it;
    for(it = terrainLayers.begin(); it != terrainLayers.end(); it++)
    {
                std::string name(it->getName());
        }

        // Surface Images
        const osgEarth::SourceConfigList &imageLayers = m_dataSources.getImageSourceConfigs();
    for(it = imageLayers.begin(); it != imageLayers.end(); it++)
    {
                std::string name(it->getName());
        }
Evan Andersen Evan Andersen
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

In reply to this post by gwaldron
I'm using Windows XP sp 3 and I'm developing with Visual Studio 2005 sp1.

It's certainly possible that something else in my app is clobbering memory, but I haven't been able to find it yet.

Evan
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

Hey Evan,

I just took that exact same code you posted and tested it within the osgEarth plugin and all seems well.  Are you running in Debug?  Does it work well in release?  Also please make sure that you are linking against the right version (debug/release) of OSG and osgEarth.

Jason

On Fri, Jul 24, 2009 at 4:12 PM, Evan Andersen (via Nabble) <[hidden email]> wrote:
I'm using Windows XP sp 3 and I'm developing with Visual Studio 2005 sp1.

It's certainly possible that something else in my app is clobbering memory, but I haven't been able to find it yet.

Evan


View message @ http://n2.nabble.com/Adding-removing-map-sources-not-reflected-in-SourceConfigList-tp3305519p3322369.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.


Evan Andersen Evan Andersen
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

Jason,

I am running in Debug and I have verified that I am linking against the correct (debug) version.  I haven't tried running the app in release mode, but I'll give it a shot when I get a chance.  Even if it does work in release I still have to figure out what's going on with debug, but at least that might give some kind of clue.

Thank you and Glen for taking the time to check on this and run that test code.  It seems likely that something in our app is causing the problem.  The app is is kind of big with lots of parts and we still have plenty of debugging to do, so it wouldn't surprise me if that is the case.  I will keep at it and let you know when I get it figured out.

Thanks for your help and thanks also for all your work on osgEarth.  It's a great piece of software.

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

Re: Adding/removing map sources not reflected in SourceConfigList

Thanks Evan. BTW are you able to say which company/project you're with? It's always nice to know who's using the software.

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

Re: Adding/removing map sources not reflected in SourceConfigList

Sure, I work for Procerus Technologies.  We make avionics for small UAV's, including autopilots and ground control stations.  You can check us out at www.procerus.com.  For our next-gen ground station software we are using osgEarth as the mapping component for route planning and tracking the aircraft during flight.  Since we work with small (1-3m wingspan) UAV's that generally fly at fairly low altitudes it's great for our users to be able to view their flight path in relation to the terrain.  We really like how easy it is to use osgEarth to get data off the web and generate high-quality terrains.  I'll post some screen shots and links to info pages when we've got them.  Probably within the next couple of weeks.

Evan

On Mon, Jul 27, 2009 at 10:17 AM, gwaldron (via Nabble) <[hidden email]> wrote:
Thanks Evan. BTW are you able to say which company/project you're with? It's always nice to know who's using the software.

Glenn


View message @ http://n2.nabble.com/Adding-removing-map-sources-not-reflected-in-SourceConfigList-tp3305519p3334746.html
To unsubscribe from Re: Adding/removing map sources not reflected in SourceConfigList, click here.


Evan Andersen Evan Andersen
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

In reply to this post by gwaldron
It turns out the bug was on our end.  A few years ago someone wrote a couple of header files which aren't really used much anymore, but which still get included in our project.  Those headers declare a couple of structures which are byte-packed using #pragma pack(1).  Unfortunately the developer didn't reset the packing back to the default after his declarations.  The result was that although the osgEarth library was compiled with the default packing, when the osgEarth headers were processed as part of our project's compile, the byte packing was enabled which caused the compiler to allocate space and calculate offsets for any osgEarth classes or structures as though they were byte packed.  The end result was strange values showing up in the debugger, heap corruption and strange bugs popping up in random places.

So now that the packing is fixed I'm running with the latest revision of the osgEarth trunk and things are working great.  I just wish I could get back all the hours spent tracking this one down :-).

Evan


On Mon, Jul 27, 2009 at 10:43 AM, Evan Andersen <[hidden email]> wrote:
Sure, I work for Procerus Technologies.  We make avionics for small UAV's, including autopilots and ground control stations.  You can check us out at www.procerus.com.  For our next-gen ground station software we are using osgEarth as the mapping component for route planning and tracking the aircraft during flight.  Since we work with small (1-3m wingspan) UAV's that generally fly at fairly low altitudes it's great for our users to be able to view their flight path in relation to the terrain.  We really like how easy it is to use osgEarth to get data off the web and generate high-quality terrains.  I'll post some screen shots and links to info pages when we've got them.  Probably within the next couple of weeks.

Evan


On Mon, Jul 27, 2009 at 10:17 AM, gwaldron (via Nabble) <[hidden email]> wrote:
Thanks Evan. BTW are you able to say which company/project you're with? It's always nice to know who's using the software.

Glenn


View message @ http://n2.nabble.com/Adding-removing-map-sources-not-reflected-in-SourceConfigList-tp3305519p3334746.html
To unsubscribe from Re: Adding/removing map sources not reflected in SourceConfigList, click here.



jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: Adding/removing map sources not reflected in SourceConfigList

Hi Evan,

Great to hear you got it working!  Definitely sounds like a doozy to find :)

Looking forward to seeing some cool screenshots!

Take care,

Jason

On Tue, Jul 28, 2009 at 4:26 PM, Evan Andersen (via Nabble) <[hidden email]> wrote:
It turns out the bug was on our end.  A few years ago someone wrote a couple of header files which aren't really used much anymore, but which still get included in our project.  Those headers declare a couple of structures which are byte-packed using #pragma pack(1).  Unfortunately the developer didn't reset the packing back to the default after his declarations.  The result was that although the osgEarth library was compiled with the default packing, when the osgEarth headers were processed as part of our project's compile, the byte packing was enabled which caused the compiler to allocate space and calculate offsets for any osgEarth classes or structures as though they were byte packed.  The end result was strange values showing up in the debugger, heap corruption and strange bugs popping up in random places.

So now that the packing is fixed I'm running with the latest revision of the osgEarth trunk and things are working great.  I just wish I could get back all the hours spent tracking this one down :-).

Evan


On Mon, Jul 27, 2009 at 10:43 AM, Evan Andersen <andersen.evan@...> wrote:
Sure, I work for Procerus Technologies.  We make avionics for small UAV's, including autopilots and ground control stations.  You can check us out at www.procerus.com.  For our next-gen ground station software we are using osgEarth as the mapping component for route planning and tracking the aircraft during flight.  Since we work with small (1-3m wingspan) UAV's that generally fly at fairly low altitudes it's great for our users to be able to view their flight path in relation to the terrain.  We really like how easy it is to use osgEarth to get data off the web and generate high-quality terrains.  I'll post some screen shots and links to info pages when we've got them.  Probably within the next couple of weeks.

Evan


On Mon, Jul 27, 2009 at 10:17 AM, gwaldron (via Nabble) <ml-user%2B93432-1941045983@...> wrote:
Thanks Evan. BTW are you able to say which company/project you're with? It's always nice to know who's using the software.

Glenn





View message @ http://n2.nabble.com/Adding-removing-map-sources-not-reflected-in-SourceConfigList-tp3305519p3345777.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.


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

Re: Adding/removing map sources not reflected in SourceConfigList

In reply to this post by Evan Andersen
Evan, a heads-up for you:

I am about to check in a re-factoring of the whole map layer data model. This will introduce significant API changes to how you manage maps and map layers, and will require you to update your code. Just wanted to warn you before you do an update and get a big surprise.

If anything about the new API is unclear, just post and we'll help you out.

Glenn
Glenn Waldron / Pelican Mapping