[GRASS-dev] WxPython front-end to ps.map

[Moritz Lennert]

On 08/02/07 10:52, Jáchym Čepický wrote:
> hi
> 
>> >> This is not meant replace a Print button for the current display
>> >> monitor, it's a stand alone hardcopy plot generator. That print button
>> >> could write to a ps.map file, but maybe it is very easy to write
>> >> directly to PostScript from the map canvas, like Michael has done for
>> >> gis.m?
>>
>> Yes, but currently what is written from the map canvas is the rasterized
>> PNG image, not the original vector information, which makes working on
>> the resulting ps file in a vector graphics program impossible...
>>
>> >
>> > As soon as new map display class will be defined in wxPython, I would
>> > like to build georectifing, ps.map and digitizing tool on top of it.
>> >
>>
>> Is there any possibility of changing the display system so that vector
>> data is displayed as such in the display or at least the content of the
>> display could be directly exported to ps or pdf as vector ?
>>
>> Just naive questions, but this might determine whether it is better to
>> concentrate on a ps.map frontend or on direct vector export of the 
>> display.
>>
>> Moritz
>>
> 
> well, this puts us back to discussion about basic GUI concept. The
> chosen one, Python+some graphical library (currently wxWidgets) stands
> for
> 
> * fast development
> * more people able to help with the development: it will be always
> easier to learn python, then C(++) and it's usage together with
> Qt/wxWdigets/Gtk+/...
> 
> but there are also some disadvantages:
> 
> * the gui will be never as fast as compiled one
> * since there is no properly working swig interface, it would be very
> difficult to access raster and vector data with help of Python. But it
> would be very difficult to rewrite whole d.vect module in any other
> language.
> 
> I would say, if we would need to rewrite Map Displays so they access
> raster and vector files directly, we would need to code this parts in
> C. It would take us too much time IMHO.
> 
> My imagination is, to use Map Display with pop-up tool bar(s) for
> specific tools -- if there is someone, who disagrees with this point,
> please raise your hand. ps.map is very good tool for creation of
> hard-copy maps. It should not be too big task to add tool, which would
> generate configuration file for ps.map based on map display content.
> 
> For the future, it would be good to improve d.vect to be able to
> display e.g. dashed lines and so on and to improve ps.map so it is
> possible to work with multiple raster tiles and so on.
> 

Glynn has mentioned reflections on rewriting the whole display 
architecture (see 
http://grass.itc.it/pipermail/grass5/2006-May/023325.html). But I agree 
that until this is done, advancing with the combination of PNG/PPM 
displayed in map canvas + ps.map for output is probably the best solution.

I also agree that ps.map needs a series of improvements[1] to make it 
really good for cartography...but I know that it's up to me to make them ;-)


Moritz


[1] one example: at this stage proportionate symbols are not drawn in 
descending order of size, thus potentially hiding smaller symbols. I 
corrected that in the new version of d.vect.chart I proposed, but it is 
still an issue in ps.map. This gets even more complicated when you want 
to add a color scheme to that as you have to use a separate vpoints 
command for each color and making sorting symbols by size almost 
impossible, but allowing the use of the RGB column in ps.map would solve 
that (I remember there being mails about this latter issue, but can't 
find them now).
Maybe not a fundamental issue for most, but a show stopper for adopting 
GRASS as the main GIS and cartography tool here in my department where a 
lot of proportionate symbol maps are drawn.