[GRASS-dev] ps.map consolidation

[Hamish]

Jáchym Èepický wrote:
> I started to look into ps.map code and I found few issues, which
> should be IMHO solved, so the code looks a bit nicer and the usage is
> more consistent.
> 
> It would be great, if somebody more skilled would post some comments
> to this topic, I will be very much thankful.
> 
> 1) some instructions (raster, setcolor) do not need to end with "end"
> keyword, where others do. this should be IMHO consolidated, so that
> ALL instructions will need to end with "end" keyword. we should look
> into configuration file of mapserver for inspiration

Glynn answered:
> More precisely, instructions which have options need "end", those
> which don't have options don't need "end".

The subinstruction code is never called (it doesn't exist), so the
"end" is never considered. It wouldn't be too hard to have main.c skip
over any extra "end"s in the control file, but that blurs the (obscure)
logic.

Jachym:
> 2) I think, file session.c can be removed. I did not quite understand,
> what is this session management about, but it would make the code a
> bit simplier and short test showed, it is working also without it (and
> I found no other function, which wuold access functions from
> session.c)

input() [input.c] calls add_to_session() [session.c] if PostScript level
is >0 (???). the reject() fn in session.c is called in a few places.
Perhaps this is all for storing input in a tmp file when entering
commands in interactive mode or when input is piped from stdin??
It's a case where some comments in the code would have been nice.

Looking way back to the GRASS 4.3 source code I see "session" is a
KEYword in cmd/main.c (it's in 5.4 as well), but commented out. So it's
probably a hold-over from p.map (where it isn't commented out), and
safely removed. It's not mentioned in the inter/ versions or help pages,
so I'm not sure if my guess for its purpose is correct. Regardless, rip
away!


> 3) some units are map units by default, where some are percent, some
> inches. It would be IMHO great, if the user would have allways to
> specify, which units she would like to use (without enything, it would
> be map units), example:
..
> currently, only some instructions are supporting %

Yes, this can be annoying. This is wish # 3335
  https://intevation.de/rt/webrt?serial_num=3335

For general purpose commands like placing text on the page I have tried
to add placement by all three modes where I could. (or at least allow
one of the comments/labels/text commands to get the job done using the
reference system needed)

There is another inconsistency in that some instructions refer to
location on the page (usually in inches; eg legend, mapinfo), while
other instructions refer to location in and around the map box (usually
in percent or map coordinates; eg rectangle, text). Percentages greater
or less than 0-100 are usually ok for placing text elsewhere on the page
than in the map box (eg 115% height).

So it is not random which commands have inches, and which have {percent
or map coordinates}, it just seems like that. :)

Presumably any GUI WYSIWYG tool could do all the units conversion math
for you when creating the instructions file. (short pain for the GUI
programmer, but then invisible)


> 4) placenemnt should be allways specified with "where" keyword

Careful, "where" is used for vector SQL queries too.

> 5) text or other value should be allways specified with "value"
> keyword:
> 6) file (map) names should be allways specified with "name" keyword

These are something that should wait for a full rewrite.


Glynn:
> While this may be a reasonable idea, it will break existing ps.map
> scripts. The same goes for most of your other suggestions.
> 
> If you're going to abandon compatibility, you may as well go all the
> way, rather than merely tinkering with the syntax and leaving the
> semantics intact.

I agree. My plan was to have the new wxPython ps.map GUI worry about all
the oddities in the ps.map controls and leave ps.map as it is. It may
be odd, but it is fully functional and well tested and that is worth a
lot.

http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map

If you wish to reimplement ps.map, as Glynn says you are best to start
over from the beginning and call it ps/ps.something_else. It would be
a real pain to have to rewrite years of carefully constructed ps.map
templates. Straight GUI -> PostScript, skip C?

I understand that it is a pain for writing the GUI to have to deal with
the weird ways of ps.map, and I support adding missing % placement to
any instruction that currently only takes map coordinates (if any still
exist). I'm not so sure about mixing inches with percent (of page), even
though this is annonying. Then you mix percent of page vs percent of map
box, which is even more confusing.


Hamish

ps - I found a nice 10 minute Python tutorial [for programmers of other
languages] that covers the basics,
  http://grass.gdf-hannover.de/wiki/GRASS_and_Python#Programming