qpegps-devel

Re: [Qpegps-devel] Developing Qpegps

[Ralf H. <ral...@gm...>]

Hi Graham,

I'm sorry for the late reply.

> I understand you will be adding ztep to the users with CVS a
> ccess - can I ask you to add me as well.
Yes, everyone is welcome.
(tomorrow I'll add you and Juan as developers)

> I am looking a new 
> versions of gpsd and some alterations to do with multiple ma
> p folders.
Please post your ideas and the "why, what and how" on
the qpegps-devel mailing list to avoid that several peaple are working
on the same issue.
And it would be nice, if you post your interests and skills as well
(like knowledge about C++, Qt, map projections, map datum, NMEA,
languages (translations), docu, ....).

> If you have any other comments about further development of
> qpegps I would be interested to hear.
"multiple map folders" why ? (can't it be done via the profiles ? Please check 
the latest CVS code)

> I am fairly new to the 
>  code so I don't want to tread on too many toes while doing
> this.
Therefore we have the qpegps-devel mailing list ;-)

I CCed several people which wrote me mails about qpegps...
Please respond to the mailing list if you are working on qpegps or if
you are going to do....


Best Regards,
Ralf

Re: [Qpegps-devel] Developing Qpegps

[jujovilla <juj...@ya...>]

Hello everyone,

I'm Juan J. Villacorta (ztep on oesf forums). I've been working on qpegps 
during the last weeks.
My first task is to add support for 'tiled' maps, that is maps compound of 
several images. Usualy a big area is covered with several images and at this 
moment qpegps switch from a image/map to another, but when your are near the 
border of a map qpegps show the area not covered by the map as black. The 
objetive is to avoid these black areas creating a virtual map compounds of 
several images. In other mail I will explain my ideas about how I'm planning 
to implement this task.

I have started my work creating a MapSelector class as sugested in Todo.txt 
file. I have use as base code the files included on qpegps_0.9.2.3.3_src.zip 
downloaded from sf  because I supossed that this file was the last version, 
but with these two mails I'm confused (for example, in 0.9.2.3.3 code there 
is no profiles).
So what is the latest version? what code sould I take to make my work?

Regards,
Juan J.

----- Original Message ----- 
From: "Yann Dirson" <yd...@al...>
To: "Ralf Haselmeier" <ral...@gm...>
Cc: <qpe...@li...>; "Graham" 
<gra...@us...>; <juj...@ya...>; 
<Dmi...@gm...>; <ash...@us...>; 
<si...@ru...>
Sent: Tuesday, October 31, 2006 11:03 PM
Subject: Re: Developing Qpegps


> Hi Ralf,
>
> On Tue, Oct 31, 2006 at 10:28:32PM +0100, Ralf Haselmeier wrote:
>> I'm sorry for the late reply.
>>
>> > I understand you will be adding ztep to the users with CVS a
>> > ccess - can I ask you to add me as well.
>> Yes, everyone is welcome.
>> (tomorrow I'll add you and Juan as developers)
>>
>> > I am looking a new
>> > versions of gpsd and some alterations to do with multiple ma
>> > p folders.
>> Please post your ideas and the "why, what and how" on
>> the qpegps-devel mailing list to avoid that several peaple are working
>> on the same issue.
>> And it would be nice, if you post your interests and skills as well
>> (like knowledge about C++, Qt, map projections, map datum, NMEA,
>> languages (translations), docu, ....).
>
> I was myself waiting for news on the svn migration front.  I had noticed
> some migration work in the new svn directory, but that looked like a
> work in progress that was left unfinished.  I was rather expecting
> ahikase to import his own svn repository, including the code from latest
> releases...  Is there any status on this ?
>
> If the current svn-migration plan is stall, I'd like to help to complete
> it, at least by properly moving cvs history, and importing the latest
> releases which were not committed into cvs (and then shutting down the
> cvs server).
>
>
>> I CCed several people which wrote me mails about qpegps...
>> Please respond to the mailing list if you are working on qpegps or if
>> you are going to do....
>
> There are many things I'd like to help to make better, including
> improving usability in keyboard-less units (ipaq), waypoints, vector-map
> support.  Time is however a limiting factor :)
>
> Best regards,
> -- 
> Yann. 


	
	
		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com

Re: [Qpegps-devel] Developing Qpegps

[Rev S. R. <si...@ru...>]

Erm, I don't have an Ipaq anymore so can you drop me from the CC list?

-- 
Rev Simon Rumble <si...@ru...>
www.rumble.net

The Tourist Engineer
Geeks need vacations too.
http://engineer.openguides.org/

 "Why Windows NT Server 4.0 continues to exist in the enterprise
  would be a topic appropriate for an investigative report in the
  field of psychology or marketing, not an article on information
  technology."
- John Kirch

Re: [Qpegps-devel] Developing Qpegps

[Ralf H. <ral...@gm...>]

@ Juan,
> example, in 0.9.2.3.3 code there is no profiles).
http://qpegps.cvs.sourceforge.net/qpegps/qpegps/settings.cpp?revision=1.22&view=markup
It allows to select (and create) several config files which can have their own
gps, units and map path settings: the idea is to have an selection at startup,
where you can choose between profiles => select if you need a street, marine 
or aviation setup .. ( it is also handy if you have several gps units with 
different settings or ...).

> So what is the latest version? what code sould I take to make my work?
Top from CVS, you can browse it here
http://qpegps.cvs.sourceforge.net/qpegps/qpegps/
but fetch it logged in as a developer.

@Yann
I'd prefer to migrate to SVN.
Could you take over the coordination of doing this ?


Regards,
Ralf

[Qpegps-devel] My current changes to qpegps

[ztep <juj...@ya...>]

@ Ralf,
>> So what is the latest version? what code sould I take to make my work?
> Top from CVS, you can browse it here
> http://qpegps.cvs.sourceforge.net/qpegps/qpegps/
> but fetch it logged in as a developer.

I have downloaded that code (v0.9.3). I like this code: clean and ordered, 
not like the one included on v0.9.2.3.3pre.

First of all, two questions:
1 - Someone has compiled/run this code? I have found at least 2 error during 
the direct compilation (very easy to solve)
2 - In a first run after compilation, I have seen that the code to show the 
Places/Waypoints are missing but exist on v0.9.2.3.3pre, is there any reason 
or just an omission?

My next work is to transfer my previous work done over v0.9.2.3.3 to this 
version. Before, I want to tell you some of the chages I have incorporated 
in order to get your opinions/approval:
1 - Add MapSelector class as said on todo.txt: no comments (although I haven 
used QPixmapCache as explained later).

2 - Improve map detection: Now to search which maps to include on actMapList 
it calls calcxy(...), that is a quite complex function, so it only search a 
few maps each iteration. I have improved this search adding as members of 
each map (on MapBase) the limits of the map (nort, south, west and east). 
This limits are calculated on the map constructor and checked on a funciton 
isInside(latitude, longitude) that is used in the map search and also to 
draw traks and places. Using this operation searching on a list of about 
1000 maps it only takes 2-3 ms.

3 - Improve map drawing (specially when large tracks/places are shown). In 
my code when a map is detected to cover the current position, the image is 
loaded into a QPixmap and then MapDisp::createMap do a bitblt (throught a 
MapSelector::DrawMap function)that is faster than the current 
convertFromImage(...). Also I pre-draw the track and the places/waypoints 
into the Qpixmap during the map loading so MapDisp doesn't need to draw them 
on each createMap iteration.
The idea is: you call MapDisp::createMap 4 times on a second, but you detect 
a map afer several seconds (or minutes depending on your speed and the maps 
zoom and dimensions), so I have tried to aligerate MapDisp::createMap at the 
cost of more memory usage and more time to load a map when it is detected to 
be on the cover area.

Please tell me your opinions about my work and if you think that I should 
add this changes to the current qpegps.

In other mail I will explain my ideas for the tiled maps.

Regards,
ztep


		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com

Re: [Qpegps-devel] My current changes to qpegps

[Ralf H. <ral...@gm...>]

Hi Juan,

> First of all, two questions:
> 1 - Someone has compiled/run this code? I have found at least 2 error
> during the direct compilation (very easy to solve)
It should be compiled (at least), but the last changes have been quite 
uncoordinated... sorry

> 2 - In a first run after compilation, I have seen that the code to show the
> Places/Waypoints are missing but exist on v0.9.2.3.3pre, is there any
> reason or just an omission?
The reason is, that not all developers used CVS ... sorry again
But now it is mandatory (but it will probably change from cvs to svn).

> My next work is to transfer my previous work done over v0.9.2.3.3 to this
> version. Before, I want to tell you some of the chages I have incorporated
> in order to get your opinions/approval:
> 1 - Add MapSelector class as said on todo.txt: no comments (although I
> haven used QPixmapCache as explained later).
The idea of the QPixmapCache was based on the later possibility to use
the code for vector maps (drawing this maps takes some time, so there was
the idea of caching). Caching makes sense for tiles as well, but it can be 
done a lot of different ways (e.g. manually select which tiles have to be 
loaded from disc and which are kept inside the memory...). It's just 
important that it is not necessary to load all tiles into the memory...

> 2 - Improve map detection: Now to search which maps to include on
> actMapList it calls calcxy(...), that is a quite complex function, so it
> only search a few maps each iteration. I have improved this search adding
> as members of each map (on MapBase) the limits of the map (nort, south,
> west and east). This limits are calculated on the map constructor and
> checked on a funciton isInside(latitude, longitude) that is used in the map
> search and also to draw traks and places. Using this operation searching on
> a list of about 1000 maps it only takes 2-3 ms.
Calcxy was needed, if several maps are partially inside the display.
How do you handle this situation now ? (do you check which map has the best 
coverage if 2 maps are "inside" but do not cover the whole display; ok, this
is less important if tiled maps are available).

> 3 - Improve map drawing (specially when large tracks/places are shown). In
> my code when a map is detected to cover the current position, the image is
> loaded into a QPixmap and then MapDisp::createMap do a bitblt (throught a
> MapSelector::DrawMap function)that is faster than the current
> convertFromImage(...).
> Also I pre-draw the track and the places/waypoints 
> into the Qpixmap during the map loading so MapDisp doesn't need to draw
> them on each createMap iteration.
yes, this parts needed some tuning

> The idea is: you call MapDisp::createMap 4 times on a second, but you
> detect a map afer several seconds (or minutes depending on your speed and
> the maps zoom and dimensions), so I have tried to aligerate
> MapDisp::createMap at the cost of more memory usage and more time to load a
> map when it is detected to be on the cover area.
Another idea was to calculate the distance between the current position and
the maps and then sort the maps by this distance: the closer a map is, the 
more frequently it is checked. But if you found a fast and working way to do 
it, the better it is.
Please be careful about memory usage, because some PDAs have only 32M.
Which device are you using (Zaurus, Ipaq,...) ?

> Please tell me your opinions about my work and if you think that I should
> add this changes to the current qpegps.
Great job, keep on going !

Thanks,

Ralf

Re: [Qpegps-devel] My current changes to qpegps

[ztep <juj...@ya...>]

>> My next work is to transfer my previous work done over v0.9.2.3.3 to this
>> version. Before, I want to tell you some of the chages I have 
>> incorporated
>> in order to get your opinions/approval:
>> 1 - Add MapSelector class as said on todo.txt: no comments (although I
>> haven used QPixmapCache as explained later).
> The idea of the QPixmapCache was based on the later possibility to use
> the code for vector maps (drawing this maps takes some time, so there was
> the idea of caching). Caching makes sense for tiles as well, but it can be
> done a lot of different ways (e.g. manually select which tiles have to be
> loaded from disc and which are kept inside the memory...). It's just
> important that it is not necessary to load all tiles into the memory...

Yes, I will plan to load only the maps involved in drawing the current map, 
that is the current position and an area around it.

>> 2 - Improve map detection: Now to search which maps to include on
>> actMapList it calls calcxy(...), that is a quite complex function, so it
>> only search a few maps each iteration. I have improved this search adding
>> as members of each map (on MapBase) the limits of the map (nort, south,
>> west and east). This limits are calculated on the map constructor and
>> checked on a funciton isInside(latitude, longitude) that is used in the 
>> map
>> search and also to draw traks and places. Using this operation searching 
>> on
>> a list of about 1000 maps it only takes 2-3 ms.
> Calcxy was needed, if several maps are partially inside the display.
> How do you handle this situation now ? (do you check which map has the 
> best
> coverage if 2 maps are "inside" but do not cover the whole display; ok, 
> this
> is less important if tiled maps are available).

I use isInside position tu test if the current position is inside the map 
and then the map is loaded and added to actMapList. Then the map to show is 
selected just as before, using calcxy and coverge funcions. But this time 
you only have to iterate in actMapList that usually has only a few maps.
Anyway when I implement tiled maps the main list of maps will be a lot sort 
and this problem will be less important, as you said.

>> The idea is: you call MapDisp::createMap 4 times on a second, but you
>> detect a map afer several seconds (or minutes depending on your speed and
>> the maps zoom and dimensions), so I have tried to aligerate
>> MapDisp::createMap at the cost of more memory usage and more time to load 
>> a
>> map when it is detected to be on the cover area.
> Another idea was to calculate the distance between the current position 
> and
> the maps and then sort the maps by this distance: the closer a map is, the
> more frequently it is checked. But if you found a fast and working way to 
> do
> it, the better it is.

The problem is that you must update the distance from the current position 
and then re-sort the map. I think that this can be as slow (or more) than 
the current implementation.

> Please be careful about memory usage, because some PDAs have only 32M.
> Which device are you using (Zaurus, Ipaq,...) ?

I use a Zaurus C3200, but I also has tested it on a C760, both with cacko 
rom.


		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com

Re: [Qpegps-devel] SVN transition

[Ralf H. <ral...@gm...>]

Hi Yann,

> > @Yann
> > I'd prefer to migrate to SVN.
> > Could you take over the coordination of doing this ?
>
> I can handle that.
Thanks

> Oh yes - I'm not yet a project member - my sf id is ydirson ;)
done.

Best Regards,
Ralf

Re: [Qpegps-devel] Developing Qpegps

[ztep <juj...@ya...>]

From: "Graham" <gr...@4o...>
> My main thoughts were to update to latest gpsd, using the lib interface,
> hopefully making the communication to gpsd cleaner. It also offloads the
> work of interpreting the gps info to the expert library so qpegps can get
> on with displaying it. There seems to be a number of extra pieces of
> information gpsd will report (such as position errors) so I am thinking
> about finding ways to display those without cluttering the interface.

Hi Graham,

Are you still interested in develop the compatibility with the latest gpsd?

I have uploaded to svn a version of my trial with gpsd 2.xx as a branch of
the head version I uploaded past weekend.

This version works quite well if I poll gpsd with a timer every 500 ms, but
my goal is to use a QSocketNotifier to know when ther is new data form gpsd.
I have got problems with this because the activated() signal is never
called. Things that I notice:
- The socket descriptor given by gpsd is allwais 0. I know that this is a
valid value, but is it not reserved for standar input?
- When I start qpegps from the shell (./qpegps) in order to see the messages
from qDegug sentences, it starts to receive QSocketNotifier notifications
after I press return on the shell (qpegps is the running process of thar
shell, that is I don't run in in background with &). After pressing return,
all works ok.

If you (or someone else) can use my code as starting point it is on:
https://svn.sourceforge.net/svnroot/qpegps/branches/gpsd2xx/qpegps

This code is based on trunk revision 237 that I uploaded to svn on november
18, I'm going to continue adding track animation support from v0.9.2.3.3 to
this version, but as long as you only need to work on client.h/cpp and
gpsstatus.h/cpp files, we can work together.

Regrards,
ztep


		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com

Re: [Qpegps-devel] Developing Qpegps

[Graham <gr...@4o...>]

Hi,

Yes, I am still here, though I have been tied up with a number of other=20
things for the past couple of weeks or so.

I will grab a copy of your gpsd updates and take a look myself and see=20
if I can help.

I have also been thinking about profiles vs. nested map folders and I=20
think both can be useful. My nested folders addition doesn't affect=20
anything if the feature isn't used, so it shouldn't add confusion or=20
unnecessary complication if it is included. I will also look at how it=20
fits with the updates which are in progress.

I don't guarantee to work fast, especially as I am doing quite a bit of=20
travelling at the moment!

Graham

ztep wrote:
> From: "Graham" <gr...@4o...>
>  =20
>> My main thoughts were to update to latest gpsd, using the lib interfac=
e,
>> hopefully making the communication to gpsd cleaner. It also offloads t=
he
>> work of interpreting the gps info to the expert library so qpegps can =
get
>> on with displaying it. There seems to be a number of extra pieces of
>> information gpsd will report (such as position errors) so I am thinkin=
g
>> about finding ways to display those without cluttering the interface.
>>    =20
>
> Hi Graham,
>
> Are you still interested in develop the compatibility with the latest g=
psd?
>
> I have uploaded to svn a version of my trial with gpsd 2.xx as a branch=
 of
> the head version I uploaded past weekend.
>
> This version works quite well if I poll gpsd with a timer every 500 ms,=
 but
> my goal is to use a QSocketNotifier to know when ther is new data form =
gpsd.
> I have got problems with this because the activated() signal is never
> called. Things that I notice:
> - The socket descriptor given by gpsd is allwais 0. I know that this is=
 a
> valid value, but is it not reserved for standar input?
> - When I start qpegps from the shell (./qpegps) in order to see the mes=
sages
> from qDegug sentences, it starts to receive QSocketNotifier notificatio=
ns
> after I press return on the shell (qpegps is the running process of tha=
r
> shell, that is I don't run in in background with &). After pressing ret=
urn,
> all works ok.
>
> If you (or someone else) can use my code as starting point it is on:
> https://svn.sourceforge.net/svnroot/qpegps/branches/gpsd2xx/qpegps
>
> This code is based on trunk revision 237 that I uploaded to svn on nove=
mber
> 18, I'm going to continue adding track animation support from v0.9.2.3.=
3 to
> this version, but as long as you only need to work on client.h/cpp and
> gpsstatus.h/cpp files, we can work together.
>
> Regrards,
> ztep
>
>
> 	=09
> ______________________________________________=20
> LLama Gratis a cualquier PC del Mundo.=20
> Llamadas a fijos y m=F3viles desde 1 c=E9ntimo por minuto.=20
> http://es.voice.yahoo.com
>
>  =20

Re: [Qpegps-devel] Developing Qpegps

[Graham <gr...@4o...>]

Ralf Haselmeier wrote:
> Hi Graham,
>
> I'm sorry for the late reply.
>   
Hi Ralf, and everybody else on the list.
My name is Graham Jones - grahamj on oesf forums.
>> I am looking a new 
>> versions of gpsd and some alterations to do with multiple ma
>> p folders.
>>     
> Please post your ideas and the "why, what and how" on
> the qpegps-devel mailing list to avoid that several peaple are working
> on the same issue.
>   
My main thoughts were to update to latest gpsd, using the lib interface, 
hopefully making the communication to gpsd cleaner. It also offloads the 
work of interpreting the gps info to the expert library so qpegps can 
get on with displaying it. There seems to be a number of extra pieces of 
information gpsd will report (such as position errors) so I am thinking 
about finding ways to display those without cluttering the interface.

> And it would be nice, if you post your interests and skills as well
> (like knowledge about C++, Qt, map projections, map datum, NMEA,
> languages (translations), docu, ....).
>   
As for my skills and interest - I have been programming in C/C++ for a 
number of years now, and also use whatever other languages are 
useful/necessary at appropriate times. I have been using the Zaurus 
since the 5500 series and follow developments quite closely. I have done 
some programming in Qt, mostly for my own interests, but a few things 
which, when I have time to complete them, may see the light of day.
I have to admit I don't have a huge amount of knowledge in map 
projections, datum or NMEA, but I am learning. A little while ago I 
produced a way to get Google maps into qpegps (simple use of Google maps 
and investigation to find the best parameters).
I became interested in using a GPS unit to help me find my way around, 
naturally using the Zaurus, found and liked qpegps and would like to see 
it continue to evolve if possible.

>> If you have any other comments about further development of
>> qpegps I would be interested to hear.
>>     
> "multiple map folders" why ? (can't it be done via the profiles ? Please check 
> the latest CVS code)
>   
Interesting, I haven't seen a qpegps built/released with any of this 
code. Did any of the earlier releases include profiles? (and any of the 
other differences between CVS code and latest builds).

I keep an eye on the project regularly but until recently hadn't started 
to build the code for myself. I was probably, perhaps foolishly, 
assuming the ipk's contained all the latest code, especially since the 
CVS source was last altered over a year ago. Since the most recent files 
distributed on SourceForge are from Jan when 0.9.2.3.3 was posted I 
didn't compare against CVS since that had not been updated for sometime 
before.

I have checked it out and will see what the profiles do for me.

My original thought behind multiple map folders was to be easily able to 
swap in and out different sets of maps without editing a central copy of 
maps.txt. Profiles may be a slightly different thing, though until I 
have built the code and tried it I don't know whether I can achieve the 
same effect.

My observation on coming to this project with an interest in 
contributing is that the code in CVS does need to be unified with the 
"release" code so that there isn't confusion over the features in future.

Anyway, I now need to look at the different versions of the source and 
decide how and where to continue.

Graham