Converting screen coordinates into lat/lon with a 2D plate-carre map and infinite scroll

[clinically-proven]

Hi, I'm using code similar to the example here to show a 2D map that wraps around as the user pans east and west.

https://github.com/gwaldron/osgearth/blob/master/src/applications/osgearth_infinitescroll/osgearth_infinitescroll.cpp

It's working very well, but I'm having trouble converting client screen coordinates in the view to lat/lon coordinates. This is an overview of my conversion code, and it works correctly when the map is shown in 3D mode. In 2D infinite scroll mode, screenToWorld is returning true, dLat is either far out of range or 0, and dLon is 0. I'm guessing that something about the clever way the infinite scroll uses three matrices requires a more complex conversion. Any suggestions would be greatly appreciated. If it makes a difference, I'm using osgearth 2.8 on Windows.

Viewer* m_viewer;
EarthManipulator* m_earthMan;
CPoint clientPoint;
double dLat = 0;
double dLon = 0;
...
// Convert MFC y value to OSG.
clientPoint.y = m_viewer->getCamera()->getViewport()->height() - clientPoint.y;

bool isValid = m_earthMan->screenToWorld(clientPoint.x, clientPoint.y, m_viewer, coord);	
if (isValid)
{
	// Convert the coord to a geopoint and get the lat/lon.				
	GeoPoint geoPoint;
	geoPoint.fromWorld(m_mapNode->getMapSRS(), coord);		
	dLat = geoPoint.y();
	dLon = geoPoint.x();		
} //if	

[gwaldron]

From what I can see, in version 2.8 the screenToWorld() computation ignores any transforms above the terrain. I am pretty sure this was addressed in later versions (specifically 3.4):
https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/Terrain.cpp#L185

Version 2.8 is really old so the amount of support we can give you is somewhat limited.

[clinically-proven]

Thanks for the quick response. Version 2.8 is definitely quite ancient, but that's the version integrated into a 3rd party mapping product that we use. I'll see if there's any way to upgrade it.

[gwaldron]

Upgrading to the 3.x series is non-trivial; if you decide to go that route there's a quick guide here:
https://docs.osgearth.org/en/latest/3.0_upgrade_guide.html

And of course, we are always here to answer questions :)

[clinically-proven]

Great, thank you. It turns out that the third party library we use will be getting a big upgrade soon, including a move to osgearth 3.5. After we upgrade I'll verify that the issue is resolved. Thanks again for your help.

[gwaldron]

Great. May I ask what 3rd party library you are using?

[clinically-proven]

https://www.envitia.com/for-developers/maplink-pro/