[Xastir] geo files again

[Curt Mills, WE7U]

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.

-- 
Curt Mills, WE7U                    hacker_NO_SPAM_ at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math!"
"Windows:  Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"