[ gpsdrive ] Patches

[Guenther Meyer]

Am Freitag 19 Dezember 2008 schrieb Paul Martin:
> On Fri, Dec 19, 2008 at 08:31:19AM +0100, Guenther Meyer wrote:
> > Am Donnerstag 18 Dezember 2008 schrieb Paul Martin:
> >
> > first, thanks for the splitting!
> >
> > > The flashing 3D fix correction is:
> > >
> > > -      current.gpsfix = 2;
> > > +      if (current.gpsfix<2) current.gpsfix = 2;
> >
> > it's not really a good idea to fix it that way.
> > gpsfix is the flag to store the current gps status, and we should not
> > falsify this state just for a gui fix. other functions may rely on
> > that...
>
> It's set elsewhere to three in another function. This function can only set
> it to two, never three. If it's been already set to three by another
> function, why are we resetting it down to two here?
>
> The GPS status is determined from two different NMEA sentences. One says "I
> have a GPS fix", which is used to set gpsfix=2 as above. The other says "I
> have a 2D fix" or "I have a 3D fix". If the first sentence has come in and
> the display is updated, you get a flash of "2D Fix" before the second
> NMEA sentence comes in.
>
the problem is the nmea parsing, and that we use different functions for the 
different sentences. as the nmea sentences are coming line for line, this 
switching happens.
but afaik the issue of flashing was already fixed some time ago by delaying 
the gpsfix display.

the best way to solve this, would be really to drop nmea parsing and switch to 
libgps, which is already planned. maybe I should do this now...


> > > > mapnik projection:
> > >
> > > That's this one:
> >
> > see hamish's statement...
>
> The reason is that without this fix, the osm.xml file disagrees with what
> gpsdrive requests, and all your roads are drawn about 50km closer to the
> equator than the correct position. The closer to the equator your location,
> the less the offset.
>
I agree that the projection used in the xml file has to be matched with the 
one in the mapnik initialization.

> This projection is also the default used by the current osm2pgsql "SVN
> version 0.55-20081217 $Rev: 10464 $".
>
but exactly this is the problem. it's the CURRENT projection used.
they already changed it some time ago, which led to the problems we have now.
what if they change it again? adapting a fixed projection to every change of 
osm2pgsql's projection seems to be senseless work.

> Agree on a projection, then use it consistently.
>
this is dependending on osm2pgsql.
we also could use our own copy of osm2pgsql with a fixed "gpsdrive" 
projection, but that seems also to be stuid.

the best way would be reading the used projection from the database, but that 
has to be done by someone who knows how to get this information out of the 
postgis database.


> There's also a bug in "draw line to route destination". If you're over a
> certain distance from the destination, the line may be drawn in a seemingly
> random direction. I suspect this may be an overflow, but I haven't found it
> yet.
>
ok.
which distance?
I didn't try this with really big distances, yet.

maybe you want to add this issue to our tracker at sf.net, so it won't get 
lost?


> Another problem is that gpsdrive hammers the X server. I suspect its
> method/frequency of updating the display is less than optimal. This
> severely affects battery life.
I know there should be done some optimization regarding all the timeout and 
expose callbacks. but as this works so far, and the risk of breaking gpsdrive 
is very high, there wasn't really a demand to analyze and optimize this; at 
least not for me...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.gpsdrivers.org/pipermail/gpsdrive/attachments/20081219/81e4dd91/attachment.bin>