[DebianGIS-dev] Bug#456569: Bug#456152: gpsdrive: Can't override window size

2008-12-16 Thread Hamish
Hi,

I have rewritten/updated the man page in gpsdrive SVN. This will be
included in the upcoming 2.10pre7 release.

But a --geometry bug remains:
  
http://sourceforge.net/tracker/index.php?func=detailaid=2121215group_id=148048atid=770280


the problem seems to be with the order of calling gtk_window_get_size()
and gtk-window-parse-geometry(), but I don't know enough about GTK to fix
it. [help welcome]


--end of content dealing with this bug report--



to address side concerns:
 Further, there are obvious map rendering errors using when using
 neither the no_dir nor expedia maps at wide zooms.

projected maps (map_*) should not be used at scales beyond 1:500,000 or
so. They are more useful for local street maps.

I've added the following to src/map_download.c:
/* wider scales than 1:500k should switch to top_ Plate Carrée
   projection. It would be more accurate to switch nearer to
   1:125k, but map_ is prettier so we hold on longer than we should.
   Distortion grows the further you get from lon_0; e.g. UTM
   is only valid in a 6deg wide band. Usage beyond half the
   next band is not recommended, and by the time you get to
   +/-90deg from lon_0 it completely breaks. */

expedia download is removed upstream due to their terms  conditions.
OpenStreet map tiles are added, but tiles are not projected well so the
problem propagates. The new NASA OnEarth LANDSAT mosaic tile download
does render exactly as it downloads from a real WMS server instead of
someone's fudge.

if a geodesist programmer from the PROJ.4 project wants to revisit
src/map_projection.c they are most welcome, otherwise our map_*
rendering will stay only locally valid.

 The scale bar at the bottom right of the image appears to be
 approximately an order of decimal magnitude out.

same wide map scale problem. Now in SVN the scalebar is disabled for top_*
maps, where scale differs in the lat an lon axes (changes with cos(lat)).
and you shouldn't be using map_* at global scales due to distortion.

 The map grabbing code seems buggy too.

since rewritten in SVN.. fixed with next release

 Menus to configure mysql and pgsql seem to have disappeared and that
 support which remains seems broken.

mysql support has been removed in upstream SVN (POI db replaced by SQLite),
and a lot of work has gone into improving the Postgre DB used with the
OSM PostGIS db lately.

 It's a shame that this very promising program seems to be becoming less
 functional with more development.

lost of cleanups since the last ** pre ** release.
IMO the pre7 will be a really good one.


Hamish



___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel


[DebianGIS-dev] Bug#456569: Bug#456152: gpsdrive: Can't override window size

2007-12-16 Thread Andreas Putzo
On Dec 14  12:40, Mark Robinson wrote:
 
 Sadly it's still quite badly broken, failing to correctly calculate the 
 sizes for the various panels leaving critical values (lat, long etc) 
 unreadable and failing to make the map the same size as the panel it's 
 assigned to.

Can you please elaborate on what exactly the problem is? I have no
problems neither with 800x600 nor 1024x768. All widgets are visible for
me, even if i force the resolution with the -g switch. There seems to be
a problem when resizing the window, though.

 Further, there are obvious map rendering errors using when using neither 
 the no_dir nor expedia maps at wide zooms.
 
 The scale bar at the bottom right of the image appears to be approximately 
 an order of decimal magnitude out.
 
 The map grabbing code seems buggy too.

Please open separate bugs for this problems. It's otherwise a bit hard
to track.

 Menus to configure mysql and pgsql seem to have disappeared and that 
 support which remains seems broken.

For all i know there never was a configuration menu for mysql (also i
agree that it would be nice to have one :) ). 
Please see Readme.Debian for instructions on how to set up the
database(s).

 It's a shame that this very promising program seems to be becoming less 
 functional with more development.
 
 Perhaps it is worth considering reverting distribution to an earlier 
 version which is less buggy.

Cheers,
Andreas




___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel