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

[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=detail&aid=2121215&group_id=148048&atid=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