[Gdal-dev] User Question: creating a geotiff from pnm

[Michael Darweesh]

Thanks for the quick reply, Frank.

It sounds like I'm thinking about this the wrong way. Perhaps I should 
just try gdal_translate and see if that meets my needs before I go 
writing a specialized solution. Then, if it's too slow or not producing 
what I want, then we should talk further. Does that sound sane?


Also, the gdal_translate.c I was typing about was the one on 
http://www.remotesensing.org/gdal/gdal_translate.c.html, not the one in 
the tarball. just maybe a broken link on the website.

-Mike


Frank Warmerdam wrote:

> Michael Darweesh wrote:
>
>> I'm new to the gdal lib and mapping and trying to come up to speed as 
>> fast as I can, newbie help is appreciated.
>>
>> I'm trying to do this.
>>
>> I have an in-memory (pnm) raster projected in swiss oblique 
>> (EPSG:9814 I believe) and I have the data which would be put into a 
>> world file in memory too. What's the right way to package this image 
>> up into a geotiff? I'd like to do this all in mempory since I'll be 
>> outputting the geotiff as an http response. But, I could probably get 
>> away with dumping it to disk if necessary.
>
>
> Michael,
>
> OK, doing this in memory is pretty trick.
>
> On the output side, there is no application accessable support for output
> GeoTIFF "in memory".  If you want to do this - as things stands you would
> basically have to avoid using the GDAL GeoTIFF driver and call into the
> libtiff API yourself.
>
> There is some example code that does something like this in
> gdal/frmts/gtiff/gt_wkt_srs.cpp (see GTIFMemBufFromWkt()).  This code is
> used to produce degenerate GeoTIFFs with georeferencing info in them that
> can be embedded in JP2 files without having to write them temporarily 
> to disk.
>
> We could also look at changing the code driver to support in memory 
> output
> under some circumstances but that could be fairly involved.  I would 
> encourage
> you to just write to a temporary file and then spool it to stdout.  
> That is
> what I did in a similar situation in MapServer even though I would 
> really like
> to have avoided the extra trip to disk.
>
> On the input side, once again, the PNM driver has no support for reading
> from memory.  However, the PNM format is pretty simple, so you could 
> manage
> it yourself.
>
> At this point we should take a step back and review.  If you are going to
> write your own custom code to write to GeoTIFF using libtiff and 
> libgeotiff
> (so as to avoid writing to disk), then you don't really need to use 
> GDAL at
> all.
>
> However, if you are going to write to disk, then you could parse the PNM
> header "manually" and then create a "memory dataset" referencing the data
> portion of the PNM file in memory.  This is a bit involved too, so I 
> won't
> try and describe it till you decide how you want to go.  If you do 
> want to
> use it, try reviewing the "In Memory Format" (MEM) on the web site first.
>
> All in all, GDAL isn't not well organized to handle in-memory images of
> files.  If this was needed "in general", then I think the best 
> approach would
> be a custom reimplementation of the VSI file io layer used to access 
> files.
> With approriate implementation it could support reading and writing 
> memory
> or disk.  This might be of use for other purposes as well.  I would 
> certainly
> like it for MapServer.
>
> Also, a client is interested in making it possible to embed as the 
> required
> GDAL support files within the DLL and one approach to that would be to
> virtualize access at the VSI layer.
>
> However, if you just need a quick custom hack for this one situation, I
> would suggest writing custom PNM-in-memory to GeoTIFF-in-memory code and
> using the GTIFMemBufFromWKt() and related code as a bit of guide.
>
>> Thanks,
>> Mike
>> ps. Is the gdal_translate.c sample code intentionally not showing or 
>> am I browsing wrong?
>
>
> It is called gdal_translate.cpp, perhaps that is why your not finding it?
>
> Best regards,