[Xastir] geo files again

[vic]

On Friday 02 May 2003 01:42 pm, you wrote:

Okay, thanks, I really appreciate the time necessary to answer all my
questions....

I understand better now....

Regards, Victor

P.S ImageMagick version works using the rpmfind latest mdk.src.rpm and
rebuilding.... ver 5.5.4  ...that is on Mandrake 9.0

> On Fri, 2 May 2003, vic wrote:
> > On Wednesday 30 April 2003 06:50 pm, you wrote:
> >
> > Where in the documentation of xastir does it say that the geo files HAVE
> > to look like this???
>
> The docs may not have caught up to the code in this instance.  I
> don't think IMAGESIZE was initially required, but it might well be
> now.  It was probably the work I did on keeping track of the map
> extents where IMAGESIZE became a requirement.  Without it, it's
> difficult to know when to load the maps, unless we make some queries
> through ImageMagick calls to compute the image size, which we don't
> currently do (something to implement for the future).
>
> > It says that :
> >
> > you'll probably want to add an IMAGESIZE line to each one to speed up
> >       loading when some radars are offscreen: (bash syntax, modify for
> > your shell...)
> >
> >   for a in srb_*; do echo "IMAGESIZE 620 620" >> $a; done  <[What is
> > this}
> >
> > what is negate 200??
>
> Looking at maps.c:draw_geo_image_map(), NEGATE is an ImageMagick
> option that can be passed.  Look in the ImageMagick docs to see what
> it's used for.  We allow quite a few options to be used, and they
> are described in the help-English.dat file.
>
> Here are the keywords that we parse out of .GEO files:
>
>     FILENAME
>     URL
>     TIEPOINT
>     IMAGESIZE
>     DATUM
>     PROJECTION
>     TERRASERVER
>     GAMMA
>     CONTRAST
>     NEGATE
>     EQUALIZE
>     NORMALIZE
>     LEVEL
>     MODULATE
>
> It looks like DATUM is not implemented in the code yet, and
> PROJECTION is only partially used.
>
> > What I have found, is that the image size is REQUIRED to make xastir even
> > read in the file to the maps_index.sys file on my system. So I open them,
> > add the imagesize and negate, save and restart OR re-index and they show
> > up and are usable.
> > REMOVE the geo files,, and the map_index.sys file and the
> > selected_maps.sys remain stuck... as in they will not reindex, the data
> > remains and can only be deleted by hand.  Upon which a new proper geo
> > file will show up again on re-indexing, but not go away on removal. Its
> > repeatable....
>
> If a recognized map format is deleted, it takes two restarts of
> Xastir to remove them.  It takes one restart or a re-index to add
> new ones.
>
> maps.c:map_indexer() adds an entry to the index file only if the map
> file entry is actually missing from the index.  If the .GEO file has
> merely been changed, the indexing code does nothing.  There's a note
> in there about checking timestamps on the files and re-indexing if
> they're newer than the index file, but that hasn't been implemented
> yet.  I'd consider this a bug.  Please add it to the bug list.  In
> order to fully re-index in this case, you have to kill Xastir,
> delete the map_index.sys file, then restart Xastir.
>
> > Is that the proper action of xastir or bugs??
> >
> > 1. not seeing a geo file without the display option.
>
> I'm assuming you mean the IMAGESIZE option.  Looking at the code,
> these appear to be required options now, as you stated.  I just
> changed the help-English file to match.
>
> > 2. not removing a geo file from the index file and the map
> > selection list, (when it is removed physically from the hard
> > drive), upon re-indexing.
>
> It should be removed after two restarts of Xastir.  I don't consider
> that to be a bug, as it's understood why it works that way in the
> code.  It's not the operation I would like, but it's livable.
> Someday we'll get back in there and rework it.