Report 1 (29/05/2009)

i start to wrote code .... my first time using svn (cool!)

i'll try to describe it here ...

what is done :

• code to use ossim TCP capabilities to set a position and a point of view based on (lon, lat, altitude, roll, pitch, gain) (finished)
• code for reading the gps data from dgps and display the nmeadata in the gui (include a map view using qtwebkit), it will use a fixed position (gps) and a modificable view setting (roll,pitch,gain) (finished)
• code to change the position using a joystic (needs some implementation yet, but is ready for test)

so the position message can be sended using gui, gps, joystick

• code to read the grass environment and retrieve a list for vector, raster and regions in the running mapset so it is possible to syncronize the posiotion in ossimplanet on the center of the active grass region or change the region to a speciphic layer or saved region

• code to export grass elevation data to ossimplanet (g.ossim) the code is usable from the pyqt gui or directly from grass (finished)
• code to read vector layer in grass and export it to kml (it is to have a custom kml settings, like color, label etc...) (needs testing, not finished)

what to do during the next week :

• finish the code i described first
• work on a table widjet (it will contain the avayable layer in the mapset and a checkbox for each layer i'll try to realize a "query system" connected to the gui )
• reorganize the code in a clean way, ranaming function give them a better position in the code and create comment

known problems that can block me :

using the gdal-ossim plug-in we can read grass raster layer but there are problems to reneder images with more than 255 entries in the colortable.

i had a chat with FrankW where we discuss a bit the problem, i stored the irc log here :

​http://trac.osgeo.org/ossim/attachment/wiki/GdalOssimPlugin/frankw_irclog.txt

tring to summarize it :

the code needs to be modified to handle three cases - 8bit, 16bit and 32bit integers and to error out gracefully if it isn't one of those cases... ... and "the s[sample] value it fetched from the input buffer this would need to be altered to fetch it based on the type of the buffer." in function loadIndexTo3BandTile

what i learn .. :

theSingleBandTile ---> point to a byte array (that isn't every true) theGdalBuffer.resize(theSingleBandTile->getSizePerBandInBytes()*2); ---> the band is readed correctly but is is "casted" to 8bit

i think gdal-grass should read correctly the grass data, so maybe the problem is in the colortable rendering in the GDAL OSSIM driver.

i'm tring to documenting myself reading :

​http://www.gdal.org/gdal_datamodel.html

and :

ossimGdalTileSource::loadIndexTo3BandTile()

... seems it accepts only raster files with 3band or with indexcolor , need i a function to port in rgb mode a grass color table ?

i'm reading the grass colortable structure to learn more

any suggestion, lines of code, examples ... that can help me to know how to work on the gdal-ossim code .. can make me happy ... i know it is not a simple task.