logo separator

[mkgmap-dev] gmapi reader?

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Jan 29 10:01:26 GMT 2018

Hi Steve,

the DEM header structures are quite special, the headers of the sections are written at the very end of the DEM file,
and they point to data that follows the main header. This is probably not mandantory but it's the way Garmin does it,
and also DemDisplay uses it to determine the length of the last bitstream.

So, to do the needed checks we have to read main header and the DEM Section headers at the end of the file.
Not sure where to place this if not in DEMFile. Where would you implement that?

reg. FileCopier: I don't see how I can use that class outside of GmapsuppBuilder. Maybe you can extract it?

I've already thought about using FileBackedImgWriter. I'll do some tests to find out how it influences performance.


Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve at parabola.me.uk>
Gesendet: Montag, 29. Januar 2018 10:27
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] gmapi reader?


Hi Gerd

> A new fs sounds good to me, would be great if you could do that,
> I am always unsure where to call close().
OK

> Reg. FileCopier:
> I have to read the DEM file to make sure that it matches, I just

If I didn't miss anything you just need to read the header to do the check.
I would do the check outside of DEMFile.

FileCopier acts like a placeholder to the existing DEM in another file
and when the IMG file is closed the data will be copied directly
to the output.

If you always want DEM files to be written to a temporary file
instead of to memory (like the .MDR file is) then you can
use FileBackedImgWriter instead of BufferedImgWriter in DEM file.

> think that it would be better to store a reference to the existing file
> instead of copying it into memory. The code that writes the new img file
> would somehow notice that the data is not in memory but on disk.
> No idea if this would really improve anything, maybe the partial reading
> of DEM already requires a full copy in memory.
> I'll have a closer look at this now.

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list