[FOSS-GPS] FoxtrotGPS Mapping Library

Post by John Stowers
I was interested to see the announcement of foxtrotgps.
I am the author of the mapping library osm-gps-map (
http://nzjrs.github.com/osm-gps-map/) which I originally developed
from the tangoGPS codebase when I forked it a few years ago (for many of the
same reasons I suspect you did).
Anyway, I would be interested in hearing your thoughts.

Well, my first thought is that github says that's an invalid link. :-)

Do you have an API declaration or a functional definition laying around
somewhere I can look at? I'm all for factoring things out into separate
components when practical, philosophically (though, since I'm a designer, not
a coder, and this is a FOSS project, all I can finally do is suggest. :-)

Cheers,
-- jra

--
Jay R. Ashworth Baylink ***@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Start a man a fire, and he'll be warm all night.
Set a man on fire, and he'll be warm for the rest of his life.

Jay R. Ashworth

2010-04-19 03:11:13 UTC

Post by John Stowers
Anyway, I would be interested in hearing your thoughts.

My thought is that Zimbra sucks.

Accidentally left the closing paren on your link; sorry. Looking now.
-- jra

Joshua Judson Rosen

2010-04-21 04:51:32 UTC

Post by John Stowers
I was interested to see the announcement of foxtrotgps.
I am the author of the mapping library osm-gps-map
( http://nzjrs.github.com/osm-gps-map/) which I originally developed
from the tangoGPS codebase when I forked it a few years ago
(for many of the same reasons I suspect you did).

[...]

Post by John Stowers
I suspect you could recreate the whole of tangoGPS UI/app in less than a few
thousand lines of C, or a few hundred of python. Additionally v0.5.0 is
available in the lucid repositories.

John,

Thanks for letting us know about osm-gps-map.

At a glance, it looks like osm-gps-map did in fact retain a *huge*
portion of the functionality of tangoGPS--much of which it'd be
appropriate to call `core competency', and much of which does in fact
overlap overlaps with what foxtrotGPS does; and I wouldn't be
surprised if there are even similarities in *ways* that we're doing
things, right now (especially given our common lineage...). Though,
some things *did* certainly change (or get added) in tangoGPS between
when you forked-off and our 0.99.3 base, so I'll have to allocate some
time to give osm-gps-map a fair look.

There are some changes in the works for foxtrotGPS to open things up
architecturally, generalise some things, and probably integrate some
of the new newer features (like `friend'-tracking) with some of the
older features (like self-tracking); we've also been talking about
pursuing things like different autocentre modes, and smarter
tile-downloading strategies (like downloading all of the tiles along a
path). So, I'm curious about how those plans interact with the idea of
switching to osm-gps-map--how much stuff osm-gps-map would want to
manage itself, and basically to what extent the library is
parameterised.

Also at issue, of course, is that I'd rather not run the other direction
from what Marcus Bauer is doing in tangoGPS `just for the sake of it',
right now--there's enough higher-priority work right now that doing
a mapper-engine transplant might not likely be an immediate task anyway.

I'm planning on spending most of my free time this week doing
`reverse engineering' work on our GUI module to turn the autogenerated
C code back into an actual GladeXML file, but I'm going to try
to find some time between now and next week to look at the osm-gps-map
API and internals.

Thanks,

-rozzin.

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

John Stowers

2010-04-26 01:34:35 UTC

On Wed, Apr 21, 2010 at 3:51 PM, Joshua Judson Rosen

Post by John Stowers
I was interested to see the announcement of foxtrotgps.
I am the author of the mapping library osm-gps-map
( http://nzjrs.github.com/osm-gps-map/) which I originally developed
from the tangoGPS codebase when I forked it a few years ago
(for many of the same reasons I suspect you did).

[...]

Post by John Stowers
I suspect you could recreate the whole of tangoGPS UI/app in less than a

few

Post by John Stowers
thousand lines of C, or a few hundred of python. Additionally v0.5.0 is
available in the lucid repositories.

John,
Thanks for letting us know about osm-gps-map.
At a glance, it looks like osm-gps-map did in fact retain a *huge*
portion of the functionality of tangoGPS--much of which it'd be
appropriate to call `core competency', and much of which does in fact
overlap overlaps with what foxtrotGPS does; and I wouldn't be
surprised if there are even similarities in *ways* that we're doing
things, right now (especially given our common lineage...). Though,
some things *did* certainly change (or get added) in tangoGPS between
when you forked-off and our 0.99.3 base, so I'll have to allocate some
time to give osm-gps-map a fair look.
There are some changes in the works for foxtrotGPS to open things up
architecturally, generalise some things, and probably integrate some
of the new newer features (like `friend'-tracking) with some of the
older features (like self-tracking); we've also been talking about
pursuing things like different autocentre modes, and smarter
tile-downloading strategies (like downloading all of the tiles along a
path). So, I'm curious about how those plans interact with the idea of
switching to osm-gps-map--how much stuff osm-gps-map would want to
manage itself, and basically to what extent the library is
parameterised.
Also at issue, of course, is that I'd rather not run the other direction
from what Marcus Bauer is doing in tangoGPS `just for the sake of it',
right now--there's enough higher-priority work right now that doing
a mapper-engine transplant might not likely be an immediate task anyway.
I'm planning on spending most of my free time this week doing
`reverse engineering' work on our GUI module to turn the autogenerated
C code back into an actual GladeXML file, but I'm going to try
to find some time between now and next week to look at the osm-gps-map
API and internals.

Sure, let me know when you have taken a look. I am happy to answer any
questions about osm-gps-map and help you integrate it if you wish.

John

Post by Joshua Judson Rosen
Thanks,
-rozzin.
--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."
_______________________________________________
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/foss-gps/attachments/20100426/612cd5be/attachment.html

John Gill

2010-04-26 14:14:38 UTC

Post by John Stowers
I was interested to see the announcement of foxtrotgps.
I am the author of the mapping library osm-gps-map
( http://nzjrs.github.com/osm-gps-map/) which I originally developed
from the tangoGPS codebase when I forked it a few years ago
(for many of the same reasons I suspect you did).

[...]

Post by John Stowers
I suspect you could recreate the whole of tangoGPS UI/app in less than a

few

Post by John Stowers
thousand lines of C, or a few hundred of python. Additionally v0.5.0 is
available in the lucid repositories.

Re: python version of this.

I wrote johnjohn: https://launchpad.net/johnjohn to run on series60 phones
-- it was inspired by maemo-mapper.

I wrote a little series60 emulation layer so it will run on linux with gtk
-- though that needs a little work.

You are correct though, that it isn't much code to write a good mapping app
in python. Performance is not really an issue -- even on an old nokia 6600
it was ok.

I just got an android, so fear I have to write java now :(

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/foss-gps/attachments/20100426/e8455b77/attachment.html

Joshua Judson Rosen

2010-04-28 21:15:03 UTC

Post by Joshua Judson Rosen
I'm planning on spending most of my free time this week doing
`reverse engineering' work on our GUI module to turn the autogenerated
C code back into an actual GladeXML file...

On that note: I pushed up some initial `gladifications' of the GUI, today.
This required some updates to the autoconf/automake infrastructure,
so you'll need to run ./autogen.sh even if you've done it before.

The main window (which looks like it makes up the bulk of the GUI work)
is done, including the popup menu. I still need to go through and
give many of the widgets more meaningful names (along with converting
the rest of the GUI), but at least it's more straightforward to edit
or add things now than it was.

So, the main GUI elements are now loaded from the GladeXML file that's
in the source tree as data/foxtrotgps.glade, and that gets installed
by way of `make install'; and we're moving toward conversion of the
rest of the GUI.

NOTE: an implication of this restructuring is that, while the program
used to `mostly work' when run from the build directory, it will
really fail quite badly now if you try to do that without taking some
(minorly) special steps to ensure that it can find the GladeXML file.
If you do a `make install' before running, though, it should work
perfectly well. There are various things that can be done to make it
easier to run with a GladeXML file in a different location
(adding a command-line option, using environment-variables...),
but nothing's been done on that yet.

Also, I've reconstructed the toolbars in the main window in a more
standard (and more straightforward) way than was used in tangoGPS,
so you may notice that they look a little different--more like
the toolbars in other GTK+ & GNOME applications.

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

Guilhem Bonnefille

2010-04-29 09:09:01 UTC

Please, note that libGlade is deprecated. GtkBuilder must be used (if possible).
http://developer.gimp.org/api/2.0/gtk/gtk-migrating-GtkBuilder.html

On that note: I pushed up some initial `gladifications' of the GUI, today.
This required some updates to the autoconf/automake infrastructure,
so you'll need to run ./autogen.sh even if you've done it before.
The main window (which looks like it makes up the bulk of the GUI work)
is done, including the popup menu. I still need to go through and
give many of the widgets more meaningful names (along with converting
the rest of the GUI), but at least it's more straightforward to edit
or add things now than it was.
So, the main GUI elements are now loaded from the GladeXML file that's
in the source tree as data/foxtrotgps.glade, and that gets installed
by way of `make install'; and we're moving toward conversion of the
rest of the GUI.
NOTE: an implication of this restructuring is that, while the program
used to `mostly work' when run from the build directory, it will
really fail quite badly now if you try to do that without taking some
(minorly) special steps to ensure that it can find the GladeXML file.
If you do a `make install' before running, though, it should work
perfectly well. There are various things that can be done to make it
easier to run with a GladeXML file in a different location
(adding a command-line option, using environment-variables...),
but nothing's been done on that yet.
Also, I've reconstructed the toolbars in the main window in a more
standard (and more straightforward) way than was used in tangoGPS,
so you may notice that they look a little different--more like
the toolbars in other GTK+ & GNOME applications.
--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."
_______________________________________________
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS

--
Guilhem BONNEFILLE
-=- JID: ***@im.apinc.org MSN: ***@hotmail.com
-=- mailto:***@gmail.com
-=- http://nathguil.free.fr/

Joshua Judson Rosen

2010-04-30 01:04:32 UTC

Post by Guilhem Bonnefille
Please, note that libGlade is deprecated. GtkBuilder must be used (if possible).
http://developer.gimp.org/api/2.0/gtk/gtk-migrating-GtkBuilder.html

Indeed. I was aware of GtkBuilder and the plan for it to overtake
libglade, but I somehow missed seeing the migration-guide and learning
about the existence of gtk-builder-convert.

So, I *was* going to hold off on using GtkBuilder until compatible
versions of Glade became more widespread..., but now it looks like I
can probably just add a `.glade.ui' rule to data/Makefile.am to make
GtkBuilder workable *right now*. So, I'll take a look at that.

Thanks!

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

Timo Juhani Lindfors

2010-04-29 10:57:38 UTC

Post by Joshua Judson Rosen
On that note: I pushed up some initial `gladifications' of the GUI, today.
This required some updates to the autoconf/automake infrastructure,

Good work! I can confirm that

sudo apt-get install bzr autotools-dev libexif-dev libcurl4-gnutls-dev libgconf2-dev libgtk2.0-dev libsqlite3-dev, libxml2-dev libglade2-dev
bzr branch http://www.foxtrotgps.org/branches/foxtrotgps-dev/
cd foxtrotgps-dev
./autogen.sh
./configure --prefix=/tmp/ftgps
make
make install
/tmp/ftgps/bin/foxtrotgps

is a working way to test without root privileges as of revision 32 on
debian unstable/amd64.

Joshua Judson Rosen

2010-05-19 03:51:34 UTC

Post by John Stowers
I was interested to see the announcement of foxtrotgps.
I am the author of the mapping library osm-gps-map
( http://nzjrs.github.com/osm-gps-map/) which I originally developed
from the tangoGPS codebase when I forked it a few years ago
(for many of the same reasons I suspect you did).

[...]

Post by John Stowers
I suspect you could recreate the whole of tangoGPS UI/app in less than
a few thousand lines of C, or a few hundred of python. Additionally
v0.5.0 is available in the lucid repositories.

[...]

Post by Joshua Judson Rosen
At a glance, it looks like osm-gps-map did in fact retain a *huge*
portion of the functionality of tangoGPS--much of which it'd be
appropriate to call `core competency', and much of which does in fact
overlap overlaps with what foxtrotGPS does; and I wouldn't be
surprised if there are even similarities in *ways* that we're doing
things, right now (especially given our common lineage...). Though,
some things *did* certainly change (or get added) in tangoGPS between
when you forked-off and our 0.99.3 base, so I'll have to allocate some
time to give osm-gps-map a fair look.
There are some changes in the works for foxtrotGPS to open things up
architecturally, generalise some things, and probably integrate some
of the new newer features (like `friend'-tracking) with some of the
older features (like self-tracking); we've also been talking about
pursuing things like different autocentre modes, and smarter
tile-downloading strategies (like downloading all of the tiles along a
path). So, I'm curious about how those plans interact with the idea of
switching to osm-gps-map--how much stuff osm-gps-map would want to
manage itself, and basically to what extent the library is
parameterised.

So, it looks like osm-gps-map would mostly be a pretty good fit to FoxtrotGPS.

There are a few things that initially scared me but have turned out to
be non-issues and a few minor nits for which I'm preparing some patches
foryour review, but also a couple of other items that are still bothering me
and for which I don't have a solution on-hand. Critique and questions follow.

The things that initially scared me were some of the points on the website,
like:

* Recording of points of interest on the map (and the ability to
add arbitary pixmaps at those points
* Automatically draws a GPS track (a line showing the history of
past added points)
* Automatic centering on new GPS points

The `POI management' scared be because I was expecting osm-gps-map to do
more than it does--I was pleased to find that it just manages a set of
pixmaps and their positions on the map-buffer :)

I see that "automatically draws a GPS track" is something that can be
toggled, so that's OK. That you have things like `tracks are drawn in red'
hard-coded in osm_gps_map_print_track() makes the whole track-management
API basically useless to me, so I'd want to do something about that.
It's not necessarily a deal-breaker, though--we could presumably use your
`layer' API to just do the track-rendering ourselves.

Since one of the things that we had been discussing for FoxtrotGPS was
providing different (more intelligent) autocentre modes, and
osm-gps-map does provide something for autocenter, it'd be nice if we
could make use of your autocenter feature somehow; but you have only a
boolean `do it or don't' option right now. Would you be open to
expanding that a little?

Looking deeper...:

The map-repository properties are usable, but seem awkward: several
properties that would seem to be more appropriate on an `OsmGpsMapSource'
class ("repo-uri", "tile-cache", "image-format") are instead on the
OsmGpsMap class, which means managing all of these properties individually
in order to support custom map-repositories like we currently do in
FoxtrotGPS. I may just be allocating rope to hang myself here, but would
you be open to expanding the API to include a GObject type for map-sources?

As Sander pointed out, the high-level osm_gps_map_draw_gps() may be either
too high-level or just not quite the right fit: at the very least, we need
to be able to provide a second directional indicator that points to a
destination; if Sander's concerns about slowness of the alpha-blended icon
are correct, then we'd also want to find another way of indicating HDOP.
I suppose we may want to be able to augment or change the icon in other
ways in the future, but I don't have anything specific in mind right now.
Actually, we could just skip using osm_gps_map_draw_gps() altogether and
use a layer or `poi' image instead instead of trying to re-parameterise
osm_gps_map_draw_gps(). That would probably be a better idea, anyway.

The only issues that I see right now that don't even have work-arounds
are that there's no way for to communicate `overzoom bounds' down to
osm_gps_map_render_missing_tile() or any of the logic underneath it,
and that there actually is no tile-scaling functionality except in the
handler for *missing* tiles; if we're to replace FoxtrotGPS' map-drawing
code with osm-gps-map, I'd need some sort of `tile zoom' knob to replace
the one that we have integrated into our current tile-loader/-renderer.

The fact that there's nothing in your `POI' (image) API to remove a single
POI from the display rather than removing all of the POIs that (happen to)
have the same pixbuf associated with them also bothers me, though we don't
currently have anything better in our codebase.... I might be keen on
getting an opaque pointer back from osm_gps_map_add_image() that I could
later pass to some `remove...()' function (which would be the same as
osm_gps_map_remove_image(), except would have an additional argument to
specify which specific POI to remove or NULL for `all of them').
Would you take a patch for that?

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

Joshua Judson Rosen

2010-05-19 05:00:22 UTC

Post by Joshua Judson Rosen
So, it looks like osm-gps-map would mostly be a pretty good fit to FoxtrotGPS.
There are a few things that initially scared me but have turned out to
be non-issues and a few minor nits for which I'm preparing some patches
foryour review, but also a couple of other items that are still bothering me
and for which I don't have a solution on-hand.

... and the nits are, which patches attached at the end...:

* The pkg-config probes for GLib and Cairo appear to demand
unnecessarily-high revisions of both packages; the versions in
Debian's current stable release seem to work fine (the `mapviewer'
demo app seems to build and work fine on my laptop).

* The way that the pkg-config probes are combined & labelled makes
the output from ./configure confusing (as well as the error
when the list of prerequisites is unsatisfied, which made me go
`What do you mean it failed when looking for OPENSTREETMAP_GPS_MAP!?
Isn't that what I'm building? Oh...').

* `./configure && make install' doesn't work in a dedicated build-tree
(outside of the source-tree).

* The using a funky trick with the linker where you `backdoor'
in past libtool, which I *think* is unnecessary and may lead
to problems (or at least confusion) for someone some day.
--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-It-looks-like-GLib-2.16-and-Cairo-1.6-are-actually-s.patch
Type: text/x-diff
Size: 764 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/foss-gps/attachments/20100519/0358e1c6/0002-It-looks-like-GLib-2.16-and-Cairo-1.6-are-actually-s.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Simplified-build-relationship-between-mapviewer-and.patch
Type: text/x-diff
Size: 758 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/foss-gps/attachments/20100519/0358e1c6/0003-Simplified-build-relationship-between-mapviewer-and.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Don-t-backdoor-in-through-.libs-just-let-libtool-do.patch
Type: text/x-diff
Size: 796 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/foss-gps/attachments/20100519/0358e1c6/0004-Don-t-backdoor-in-through-.libs-just-let-libtool-do.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Support-building-outside-the-source-tree.patch
Type: text/x-diff
Size: 907 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/foss-gps/attachments/20100519/0358e1c6/0005-Support-building-outside-the-source-tree.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Split-pkg-config-probes-for-less-confusing-.-configu.patch
Type: text/x-diff
Size: 4049 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/foss-gps/attachments/20100519/0358e1c6/0006-Split-pkg-config-probes-for-less-confusing-.-configu.bin

John Stowers

2010-05-19 06:12:04 UTC

On Wed, May 19, 2010 at 4:00 PM, Joshua Judson Rosen

Post by Joshua Judson Rosen
and for which I don't have a solution on-hand.

* The pkg-config probes for GLib and Cairo appear to demand
unnecessarily-high revisions of both packages; the versions in
Debian's current stable release seem to work fine (the `mapviewer'
demo app seems to build and work fine on my laptop).
* The way that the pkg-config probes are combined & labelled makes
the output from ./configure confusing (as well as the error
when the list of prerequisites is unsatisfied, which made me go
`What do you mean it failed when looking for OPENSTREETMAP_GPS_MAP!?
Isn't that what I'm building? Oh...').
* `./configure && make install' doesn't work in a dedicated build-tree
(outside of the source-tree).
* The using a funky trick with the linker where you `backdoor'
in past libtool, which I *think* is unnecessary and may lead
to problems (or at least confusion) for someone some day.

Excellent, I am away from my development computer for a few days, but I will
apply them when I get back.

Thanks for your work,

John

Post by Joshua Judson Rosen
--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."
_______________________________________________
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/foss-gps/attachments/20100519/7a903f9a/attachment-0001.html

John Stowers

2010-05-24 12:52:32 UTC

These have all been applied. Thanks.

John

John Stowers

2010-05-19 08:40:06 UTC

Yeah, as I said on previous mail, they look good. I will apply them
when I get back at my development PC.

Post by Joshua Judson Rosen
but also a couple of other items that are still bothering me
and for which I don't have a solution on-hand. Critique and questions follow.
I see that "automatically draws a GPS track" is something that can be
toggled, so that's OK. That you have things like `tracks are drawn in red'
hard-coded in osm_gps_map_print_track() makes the whole track-management
API basically useless to me, so I'd want to do something about that.
It's not necessarily a deal-breaker, though--we could presumably use your
`layer' API to just do the track-rendering ourselves.

I am currently cleaning up the track API at the moment (see my
previous reply to Sander) and the track-api-rework branch
(http://github.com/nzjrs/osm-gps-map/tree/track-api-rework).

Your comments would be appreciated.

Post by Joshua Judson Rosen
Since one of the things that we had been discussing for FoxtrotGPS was
providing different (more intelligent) autocentre modes, and
osm-gps-map does provide something for autocenter, it'd be nice if we
could make use of your autocenter feature somehow; but you have only a
boolean `do it or don't' option right now. Would you be open to
expanding that a little?

Yes, I guess there are a few ways this could be done without too much pain.
* add an autocenter-mode property and switch-case on that inside the lib
* do the existing autozoom calculation in an internal signal handler
that derived classes could intercept/connect before (and hence add
their own autozoom behaviour)
* expose the autozoom as a vfunc that derived types could override
* mystery option 4

What do you think of these approaches considering
* the implementation should be future proof to some degree, so that
new autozoom modes could be added
* existing users of the library will not be impacted too much
* the library retains a good default level of functionality

Post by Joshua Judson Rosen
The map-repository properties are usable, but seem awkward: several
properties that would seem to be more appropriate on an `OsmGpsMapSource'
class ("repo-uri", "tile-cache", "image-format") are instead on the
OsmGpsMap class, which means managing all of these properties individually
in order to support custom map-repositories like we currently do in
FoxtrotGPS. I may just be allocating rope to hang myself here, but would
you be open to expanding the API to include a GObject type for map-sources?

Perhaps, although the GObject per map source seems a little complex
considering almost all the code in the different sources will be
identical. Is there an intermediate option perhaps?

* add OsmGpsMapSource and OsmGpsMapSourceSlippy
* add map-source-object property
* by default map-source-object gets assigned a OsmGpsMapSourceSlippy
object with the values pulled from the current MapSource_t machinery

While this could be almost a way draw an interface between tile
fetching and rendering, as far as your use is concerned it almost
seems as the worst of both worlds and the better of none.

More thought and your comments would be appreciated on this.

Post by Joshua Judson Rosen
As Sander pointed out, the high-level osm_gps_map_draw_gps() may be either
too high-level or just not quite the right fit: at the very least, we need
to be able to provide a second directional indicator that points to a
destination; if Sander's concerns about slowness of the alpha-blended icon
are correct, then we'd also want to find another way of indicating HDOP.
I suppose we may want to be able to augment or change the icon in other
ways in the future, but I don't have anything specific in mind right now.

I have also had other people suggest that they wanted other ways to
draw the current GPS point/HDOP/etc. I think this definately qualifies
(i.e. patches welcome) as the kind of thing that would be suitable for
a vfunc (draw_gps_point) that derived classes could then override.

Post by Joshua Judson Rosen
Actually, we could just skip using osm_gps_map_draw_gps() altogether and
use a layer or `poi' image instead instead of trying to re-parameterise
osm_gps_map_draw_gps(). That would probably be a better idea, anyway.

I think this need to be considered in light of the tracks-api-rework
branch, so I will need to think about this too.

Post by Joshua Judson Rosen
The only issues that I see right now that don't even have work-arounds
are that there's no way for to communicate `overzoom bounds' down to
osm_gps_map_render_missing_tile() or any of the logic underneath it,
and that there actually is no tile-scaling functionality except in the
handler for *missing* tiles; if we're to replace FoxtrotGPS' map-drawing
code with osm-gps-map, I'd need some sort of `tile zoom' knob to replace
the one that we have integrated into our current tile-loader/-renderer.

Im not sure I understand you here. Could you please explain furthur.

Are you referring to how osm-gps-map first upscales the low res tile
while it waits for the high res one to arrive?

Post by Joshua Judson Rosen
The fact that there's nothing in your `POI' (image) API to remove a single
POI from the display rather than removing all of the POIs that (happen to)
have the same pixbuf associated with them also bothers me, though we don't
currently have anything better in our codebase.... I might be keen on
getting an opaque pointer back from osm_gps_map_add_image() that I could
later pass to some `remove...()' function (which would be the same as
osm_gps_map_remove_image(), except would have an additional argument to
specify which specific POI to remove or NULL for `all of them').
Would you take a patch for that?

Yes, a patch for this would be great. It would also be worthwhile to
rename the functions to osm_gps_map_poi_{add,remove} to match the work
going on in the tracks-rework / gtk-3.0 branch.

Regards,

John

Post by Joshua Judson Rosen
--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."
_______________________________________________
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS

Sander van Grieken

2010-05-19 14:54:30 UTC

See my previous mail. A sane default implementation is enough, other modes can be
implemented in the app quite easily by using set_mapcenter.

Slippy? Isn't that a view mode? IMO has nothing to do with map sources.

Anyway, I think I can set both foxtrotgps and internal map sources with the current osm-
gps-map without too much hassle, so if you really want to change this, please wait until
osm-gps-map integration is done.

Post by John Stowers
Yes, a patch for this would be great. It would also be worthwhile to
rename the functions to osm_gps_map_poi_{add,remove} to match the work
going on in the tracks-rework / gtk-3.0 branch.

Please no, keep it generic! I think the _image interface is more then enough (once it uses
opaque pointers) to handle POIs and anything else that might be rendered this way. So
don't make it POI specific please!

John, I also found another bug in osm-gps-map:

- map scale indicator is incorrect. It is location/center-map specific and changes with
the latitude.

And on the wishlist:
- I would like to have a zoom-changed signal, so I can update the zoom slider when zooming
in and out with the keybindings or mouse-scrollwheel.
- tangogps zoomed in and out on the mouse cursor when using the scrollwheel. I'd love to
see that also working with osm-gps-map.

Updates in my branch:
- osm-gps-map mapsources now integrated.
- track loading and display works, if loaded from file.
- all keybindings restored (and slightly changed, removed need for modifier keys)
- friends now shown on map

Still to do:
- show POIs and Photos, once the _image functions are usable (and refactor friends then
too)
- support foxtrotgps map sources, boilerplate already there, need only to set the correct
properties
- draw line when in distance mode (using _track functions probably)
- cleanup code, remove all unused paint code
- merge to trunk ;-)

grtz,
Sander

Guilhem Bonnefille

2010-05-19 17:36:42 UTC

Hi,

I read with high interest all your debates.

?* add OsmGpsMapSource and OsmGpsMapSourceSlippy
?* add map-source-object property
?* by default map-source-object gets assigned a OsmGpsMapSourceSlippy
object with the values pulled from the current MapSource_t machinery

Slippy? Isn't that a view mode? IMO has nothing to do with map sources.

In a recent refactoring of Viking, due to a lack of vocabulary, I
introduced something in the spirit of OsmGpsMapSourceSlippy. Now, like
Sander, I think its really not the right vocable as "slippy" refers to
the UI, not the model. Perhaps could you pick better idea in the
OpenLayers class hierarchy.

http://trac.openlayers.org/wiki/UML

--
Guilhem BONNEFILLE
-=- JID: ***@im.apinc.org MSN: ***@hotmail.com
-=- mailto:***@gmail.com
-=- http://nathguil.free.fr/

John Stowers

2010-05-19 23:44:40 UTC

Post by John Stowers
Yes, I guess there are a few ways this could be done without too much pain.
?* add an autocenter-mode property and switch-case on that inside the lib
?* do the existing autozoom calculation in an internal signal handler
that derived classes could intercept/connect before (and hence add
their own autozoom behaviour)
?* expose the autozoom as a vfunc that derived types could override
?* mystery option 4

See my previous mail. A sane default implementation is enough, other modes can be
implemented in the app quite easily by using set_mapcenter.

Fair enough. Is the current autocenter mode sane enough for foxtrotgps?

Slippy? Isn't that a view mode? IMO has nothing to do with map sources.

I was using Slippy as the term to describe the format of all these map
sources, i.e. mercator projection and derivation of tile_x and tile_y
from lat/lon/zoom
(http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames). What would
be an adequate term for this?

Post by Sander van Grieken
Anyway, I think I can set both foxtrotgps and internal map sources with the current osm-
gps-map without too much hassle, so if you really want to change this, please wait until
osm-gps-map integration is done.

This is not planned to be done anytime soon, the track clean up, the
image/poi stuff is more important IMIO.

Good point. I had overlooked this. The image/poi stuff should be the
same API (excepting for the opaque pointer change)

Post by Sander van Grieken
- map scale indicator is incorrect. It is location/center-map specific and changes with
the latitude.

The current implementation osm_gps_map_get_scale takes the scale at
the center. Do you want me to expose
osm_gps_map_get_scale_at_point (which is currently private)?

Post by Sander van Grieken
- I would like to have a zoom-changed signal, so I can update the zoom slider when zooming
in and out with the keybindings or mouse-scrollwheel.

You should be able to connect to "changed" which is called anytime the
bounding box is changed, i.e. zoom or scroll. I should probably also
emit notify::zoom signal here (i.e. patch welcome)

Post by Sander van Grieken
- tangogps zoomed in and out on the mouse cursor when using the scrollwheel. I'd love to
see that also working with osm-gps-map.

Umm this is already supported and works in the test app AFAIR (I am
not at my development PC)

Post by Sander van Grieken
- osm-gps-map mapsources now integrated.
- track loading and display works, if loaded from file.
- all keybindings restored (and slightly changed, removed need for modifier keys)
- friends now shown on map
- show POIs and Photos, once the _image functions are usable (and refactor friends then
too)
- support foxtrotgps map sources, boilerplate already there, need only to set the correct
properties
- draw line when in distance mode (using _track functions probably)
- cleanup code, remove all unused paint code
- merge to trunk ;-)

Excellent to hear.

I am filing all the bugs you mention as issues on github
(http://github.com/nzjrs/osm-gps-map/issues). It would be great if you
can take a quick look there to see if I have forgotten any of the
things mentioned in your mail.

Regards,

John

Joshua Judson Rosen

2010-05-20 06:14:41 UTC

Good point. I had overlooked this. The image/poi stuff should be the
same API (excepting for the opaque pointer change)

Indeed--not just the interface, but the implementation would also be
identical. Ideally, I'd suggest just adding the extra argument to
osm_gps_map_image_remove(), and changing the osm_gps_image_add() so
that it returns its image_t pointer as the opaque identifier
(cf. attached patch).

The only reasons that I suggested a new function with "poi"
in the name were that I wasn't sure you were ready to break
backward-compatibility, and I couldn't think of a better term for
a `specific instance of an image associated with a distinct point'
(or `specific image-bearing point in which client code is interested')
than "POI" :)

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Include-instance-identifiers-in-the-image-API.patch
Type: text/x-diff
Size: 5026 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/foss-gps/attachments/20100520/ceb45407/0001-Include-instance-identifiers-in-the-image-API.bin

John Stowers

2010-05-21 04:31:41 UTC

On Thu, May 20, 2010 at 5:14 PM, Joshua Judson Rosen

?Please no, keep it generic! I think the _image interface is more
?then enough (once it uses opaque pointers) to handle POIs and
?anything else that might be rendered this way. So don't make it
?POI specific please!

Good point. I had overlooked this. The image/poi stuff should be the
same API (excepting for the opaque pointer change)

Indeed--not just the interface, but the implementation would also be
identical. Ideally, I'd suggest just adding the extra argument to
osm_gps_map_image_remove(), and changing the osm_gps_image_add() so
that it returns its image_t pointer as the opaque identifier
(cf. attached patch).
The only reasons that I suggested a new function with "poi"
in the name were that I wasn't sure you were ready to break
backward-compatibility, and I couldn't think of a better term for
a `specific instance of an image associated with a distinct point'
(or `specific image-bearing point in which client code is interested')
than "POI" :)

Looking over the patch, I wonder if this implementation is flexible
enough, while not making the API too confusing, for the behavior you
are trying to enable (removing either a single poi/image, or a whole
group of pois/images).

The limitation appears to be the assumption that the same pixbuf be
used as a handle for a group of pois/images. Is this something that is
useful/true in practice or will the app still need to keep around the
pointer to each added poi/image anyway (in which case we might as well
keep the implementation simple, and thus remove() only accepts the
opaque pointer)

What do you think?

John

Post by Joshua Judson Rosen
--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."
_______________________________________________
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS

Joshua Judson Rosen

2010-05-21 14:44:05 UTC

Post by Joshua Judson Rosen
Indeed--not just the interface, but the implementation would also be
identical. Ideally, I'd suggest just adding the extra argument to
osm_gps_map_image_remove(), and changing the osm_gps_image_add() so
that it returns its image_t pointer as the opaque identifier
(cf. attached patch).

[...]

Post by John Stowers
Looking over the patch, I wonder if this implementation is flexible
enough, while not making the API too confusing, for the behavior you
are trying to enable (removing either a single poi/image, or a whole
group of pois/images).
The limitation appears to be the assumption that the same pixbuf be
used as a handle for a group of pois/images. Is this something that is
useful/true in practice or will the app still need to keep around the
pointer to each added poi/image anyway (in which case we might as well
keep the implementation simple, and thus remove() only accepts the
opaque pointer)
What do you think?

Speaking only for FoxtrotGPS, I have a patch that I'm going to want to
integrate at some point that enables distinct items in the same general class
(e.g.: different POIs) to have have different icons; so we're ultimately
not going to find much use in osm-gps-map's current remove_image() behaviour.

For maximal flexibility, I'd probably also add a `user_data' member
to image_t, add an add_image_with_data() function that associates
its `data' argument with the newly_created image_t, make add_image()
associate the newly-created image_t with *itself* and return the same
pointer; then you can drop the old GdkPixbuf argument from remove_image().
It'd also be good to add a foreach_image() function that can be used to
to iterate over all of the images with at least a 2-argument (key, userparm)
callback like they have in various places in GLib and GTK+.

A patch would, of course be a better illustration of what I'm talking about,
but I'm on my way out to work right now; I can put one together tonight,
though.

I don't know about osm_gps_map_add_image_with_alignment(); maybe
it's complicated enough already that nobody would even notice
another argument?

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

Sander van Grieken

2010-05-20 10:09:56 UTC

Post by John Stowers
Fair enough. Is the current autocenter mode sane enough for foxtrotgps?

It is exactly the same as the autocenter code in tango/foxtrot, so should give nobody
reason to complain :) It has a hardcoded dead-zone of 25% of the view though, which might
be good to expose as property, so we can set it to 0 to always follow GPS exactly, or to
1.0 to only re-center when GPS goes outside the view.

Slippy? Isn't that a view mode? IMO has nothing to do with map sources.

Good question. There's many aspects to it (mercator, power-of-two zoom levels, 256px
tiles, underlying directory structure) but it seems to be the standard way of serving up
tiles, so maybe call this way the 'standard' or 'MercatorStandard' or 'OSM' way or
something.

Is there anything out there that works with tiles, but in a totally different way?

Post by Sander van Grieken
- map scale indicator is incorrect. It is location/center-map specific and changes with
the latitude.

The current implementation osm_gps_map_get_scale takes the scale at
the center. Do you want me to expose
osm_gps_map_get_scale_at_point (which is currently private)?

No, the center is fine, but if that take_scale function is working correctly, then it's
probably another bug. My observation is that the OSD scale indicator doesn't get updated
when staying in the same zoom level but dragging the map to another latitude.

Post by Sander van Grieken
- I would like to have a zoom-changed signal, so I can update the zoom slider when zooming
in and out with the keybindings or mouse-scrollwheel.

You should be able to connect to "changed" which is called anytime the
bounding box is changed, i.e. zoom or scroll. I should probably also
emit notify::zoom signal here (i.e. patch welcome)

"changed" will do, thanks :)

Post by Sander van Grieken
- tangogps zoomed in and out on the mouse cursor when using the scrollwheel. I'd love to
see that also working with osm-gps-map.

Umm this is already supported and works in the test app AFAIR (I am
not at my development PC)

Strange.. The scrollwheel events go directly to osm-gps-map but it always zooms on
mapcenter. Will take another look.

Post by John Stowers
I am filing all the bugs you mention as issues on github
(http://github.com/nzjrs/osm-gps-map/issues). It would be great if you
can take a quick look there to see if I have forgotten any of the
things mentioned in your mail.

Something to add to issue #3:
- keypresses that have bindings also do not get propagated, so not propagating mouse
button events on OSD elements would make it consistent.
- Possible caveat: button_press and button_release should be symmetrical, so if a
button_press is propagated, so should the button_release, even if it's on top of an OSD
layer element.

And issue #7 is not a bug and not on my wishlist anymore, since "changed" will suffice.
But maybe "changed" is a too generic term, and might be better named "bbox-changed" or
something.

Anyway, thanks for your quick responses, it really helps keeping the pace.

grtz,
Sander

John Stowers

2010-05-21 04:22:29 UTC

Post by John Stowers
Fair enough. Is the current autocenter mode sane enough for foxtrotgps?

Good idea.

Post by John Stowers
I was using Slippy as the term to describe the format of all these map
sources, i.e. mercator projection and derivation of tile_x and tile_y
from lat/lon/zoom
(http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames). What would
be an adequate term for this?

According to another poster it is TMS or WorldWind.

Post by Sander van Grieken
Is there anything out there that works with tiles, but in a totally different way?

Not that I can think of.

Post by John Stowers
The current implementation osm_gps_map_get_scale takes the scale at
the center. Do you want me to expose
osm_gps_map_get_scale_at_point (which is currently private)?

OK, this sounds like a bug then. I will investigate

Post by Sander van Grieken
- keypresses that have bindings also do not get propagated, so not propagating mouse
button events on OSD elements would make it consistent.
- Possible caveat: button_press and button_release should be symmetrical, so if a
button_press is propagated, so should the button_release, even if it's on top of an OSD
layer element.

Thanks.

Post by Sander van Grieken
And issue #7 is not a bug and not on my wishlist anymore, since "changed" will suffice.
But maybe "changed" is a too generic term, and might be better named "bbox-changed" or
something.

To keep compatibility I will leave (but deprecate) the changed signal
and start to recommend people use the appropriate notify::foo signal.

Post by Sander van Grieken
Anyway, thanks for your quick responses, it really helps keeping the pace.

No prob. Its a shame I wont be back at my development PC until Sunday

John

John Stowers

2010-05-24 12:51:02 UTC

Post by John Stowers
You should be able to connect to "changed" which is called anytime the
bounding box is changed, i.e. zoom or scroll. I should probably also
emit notify::zoom signal here (i.e. patch welcome)

"changed" will do, thanks :)

notify::zoom has been implemented in git HEAD

John

John Stowers

2010-05-25 05:41:08 UTC

Post by John Stowers
The current implementation osm_gps_map_get_scale takes the scale at
the center. Do you want me to expose
osm_gps_map_get_scale_at_point (which is currently private)?

This has been fixed in git HEAD

John

John Stowers

2010-05-25 05:42:01 UTC

Post by John Stowers
Fair enough. Is the current autocenter mode sane enough for foxtrotgps?

This has now been exposed as a auto-center-deadband property in git HEAD

John

Joshua Judson Rosen

2010-05-20 15:09:02 UTC

Im not sure I understand you here. Could you please explain furthur.
Are you referring to how osm-gps-map first upscales the low res tile
while it waits for the high res one to arrive?

Yes--there's no way for me to specify limits on the upscaling.
I'm not sure how much I should be concerned with the upper limit
(tangoGPS used a hard-coded limit of 3; Stefan Fr?be has raised it
to 5 in his geocaching patchset), but there are times when we want
to set a *lower* limit on upscaling--because we don't actually always
want to use higher-res tiles. In particular, the pixel-densities of
some of the phone/tablet screens are so much higher (3x!) than typical
desktop resolutions (which the map-renderers target) that we basically
need to upscale just to make a lot of the details (lines, text, icons)
scrutable by the naked eye at a reasonable distance.

The FreeRunner's screen is ~300 px/inch, so text and icons that are
perfectly legible at 96 px/inch can be extremely difficult to read
from more than about a foot (~30 cm) away, which is absolutely
necessary when driving--as is being to see things at a glance
rather than with intentful scrutiny. :)

Nokia's N-series tablets are somewhat lower-density (~200 px/inch?),
but presumably still high enough to cause issues.

The same issue actually still manifests with lower-density displays
like most laptops (though mine's still ~145 px/inch...), just at
greater distances.

Some other aspects were described on the openmoko community list
<http://article.gmane.org/gmane.comp.handhelds.openmoko.community/55877>:

So, when you select `fewer, bigger details', the code just decreases
*pixel-density* and a `zoom-level offset' adjusted accordingly.
The map remains at the same zoom-level; but the text and icons get
bigger, the streets and other lines get wider; the amount of
visual `clutter' decreases, and information-clarity goes up.

If you select `more, smaller details', the pixel-density is increased
and the zoom-offset adjusted in the other direction. Again, the map
remains at the same zoom-level; but the text and icons get smaller,
the streets and other lines become thinner; the amount of information
visible at a given zoom-level (the information-density) increases.

If you want to see what I mean, I merged the back-end code into FoxtrotGPS's
trunk at revid ***@geekspace.com-20100507055217-p98k7n2pk08fskk7, and the
UI was merged at ***@geekspace.com-20100507130010-ykfut9y4nwcw4dn5
(about 2 weeks ago).

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

John Stowers

2010-05-21 04:40:44 UTC

On Fri, May 21, 2010 at 2:09 AM, Joshua Judson Rosen

Im not sure I understand you here. Could you please explain furthur.
Are you referring to how osm-gps-map first upscales the low res tile
while it waits for the high res one to arrive?

Yes--there's no way for me to specify limits on the upscaling.
I'm not sure how much I should be concerned with the upper limit
(tangoGPS used a hard-coded limit of 3; Stefan Fr?be has raised it
to 5 in his geocaching patchset), but there are times when we want
to set a *lower* limit on upscaling--because we don't actually always
want to use higher-res tiles. In particular, the pixel-densities of
some of the phone/tablet screens are so much higher (3x!) than typical
desktop resolutions (which the map-renderers target) that we basically
need to upscale just to make a lot of the details (lines, text, icons)
scrutable by the naked eye at a reasonable distance.
The FreeRunner's screen is ~300 px/inch, so text and icons that are
perfectly legible at 96 px/inch can be extremely difficult to read
from more than about a foot (~30 cm) away, which is absolutely
necessary when driving--as is being to see things at a glance
rather than with intentful scrutiny. :)
Nokia's N-series tablets are somewhat lower-density (~200 px/inch?),
but presumably still high enough to cause issues.
The same issue actually still manifests with lower-density displays
like most laptops (though mine's still ~145 px/inch...), just at
greater distances.
Some other aspects were described on the openmoko community list
? ?So, when you select `fewer, bigger details', the code just decreases
? ?*pixel-density* and a `zoom-level offset' adjusted accordingly.
? ?The map remains at the same zoom-level; but the text and icons get
? ?bigger, the streets and other lines get wider; the amount of
? ?visual `clutter' decreases, and information-clarity goes up.
? ?If you select `more, smaller details', the pixel-density is increased
? ?and the zoom-offset adjusted in the other direction. Again, the map
? ?remains at the same zoom-level; but the text and icons get smaller,
? ?the streets and other lines become thinner; the amount of information
? ?visible at a given zoom-level (the information-density) increases.
If you want to see what I mean, I merged the back-end code into FoxtrotGPS's
(about 2 weeks ago).

Ahh OK, I see now, this (and in particular your previous mail on
openmoko list) has cleared things up. Very interesting, and I will be
sure to take a look next week.

John

Post by Joshua Judson Rosen
--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."
_______________________________________________
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS

John Stowers

2010-05-25 05:45:21 UTC

Yeah, as I said on previous mail, they look good. I will apply them
when I get back at my development PC.

Yes, I guess there are a few ways this could be done without too much pain.
?* add an autocenter-mode property and switch-case on that inside the lib
?* do the existing autozoom calculation in an internal signal handler
that derived classes could intercept/connect before (and hence add
their own autozoom behaviour)
?* expose the autozoom as a vfunc that derived types could override
?* mystery option 4
What do you think of these approaches considering
?* the implementation should be future proof to some degree, so that
new autozoom modes could be added
?* existing users of the library will not be impacted too much
?* the library retains a good default level of functionality

Perhaps, although the GObject per map source seems a little complex
considering almost all the code in the different sources will be
identical. Is there an intermediate option perhaps?
?* add OsmGpsMapSource and OsmGpsMapSourceSlippy
?* add map-source-object property
?* by default map-source-object gets assigned a OsmGpsMapSourceSlippy
object with the values pulled from the current MapSource_t machinery
While this could be almost a way draw an interface between tile
fetching and rendering, as far as your use is concerned it almost
seems as the worst of both worlds and the better of none.
More thought and your comments would be appreciated on this.

draw_gps_point has now been made a virtual function that subclasses
can override if they wish.

John

Sander van Grieken

2010-05-19 10:20:47 UTC

Post by Joshua Judson Rosen
So, it looks like osm-gps-map would mostly be a pretty good fit to FoxtrotGPS.

Yes I see no big problems finishing the migration.

Post by Joshua Judson Rosen
There are a few things that initially scared me but have turned out to
be non-issues and a few minor nits for which I'm preparing some patches
foryour review, but also a couple of other items that are still bothering me
and for which I don't have a solution on-hand. Critique and questions follow.
The things that initially scared me were some of the points on the website,
* Recording of points of interest on the map (and the ability to
add arbitary pixmaps at those points
* Automatically draws a GPS track (a line showing the history of
past added points)
* Automatic centering on new GPS points
The `POI management' scared be because I was expecting osm-gps-map to do
more than it does--I was pleased to find that it just manages a set of
pixmaps and their positions on the map-buffer :)
I see that "automatically draws a GPS track" is something that can be
toggled, so that's OK. That you have things like `tracks are drawn in red'
hard-coded in osm_gps_map_print_track() makes the whole track-management
API basically useless to me, so I'd want to do something about that.
It's not necessarily a deal-breaker, though--we could presumably use your
`layer' API to just do the track-rendering ourselves.

No I don't think the layer API is suitable for this. It solves a different problem and
would generate more overhead than is needed. I DO think the track API should be extended
though, as I already discussed with John, at least with the ability to specify a color per
track, but possibly expose the whole Cairo object used to draw the track.

Right now my branch uses foxtrot's autocenter function, but it could be using osm-gps-map
provided autocenter functionality.

However, while it's nice to have autocenter functionality on the widget, we should be
careful to put too much application level functionality into osm-gps-map.

Autocenter is a bit of a 50/50 case (app vs. widget), and it's nice to have a default
implementation in osm-gps-map, but IMO we shouldn't put a super-fancy autocenter module
inside the widget, but instead let the application define it that's most suitable to the
application's usecase.

For example, if some application does navigation, it might decide to center the map not on
where you are but instead some distance along the planned route, so you see most of the
map ahead of you. This kind of logic should not be integrated in osm-gps-map.

This function is OK, it's not the drawing primitive the function name suggested it was. I
can fire-and-forget GPS locations to it. Maybe the parameters could be replaced by some
struct that can contain also bearing, HDOP, speed, altitude and GPS time, so it could
render some of these components, or dispatch them to the OSD layer for displaying.

Post by Joshua Judson Rosen
if Sander's concerns about slowness of the alpha-blended icon
are correct, then we'd also want to find another way of indicating HDOP.

I haven't yet tested on the freerunner, which is probably the best slowness test :)
Anyway, foxtrotGPS displays HDOP in the status bar, so we can pass HDOP=0 to osm-gps-map
on freerunner if it's a problem.

Post by Joshua Judson Rosen
I suppose we may want to be able to augment or change the icon in other
ways in the future, but I don't have anything specific in mind right now.
Actually, we could just skip using osm_gps_map_draw_gps() altogether and
use a layer or `poi' image instead instead of trying to re-parameterise
osm_gps_map_draw_gps(). That would probably be a better idea, anyway.

No I don't agree. The current draw_gps does what it needs to do and is highly optimized
(i.e. only drawing last gps-track segment) and there are dynamic parts to it (heading,
HDOP, bearing) that are hard to do when you make it image based. Absolutely the widget's
responsibility.

Yes I agree here. I'm running into this problem right now with the friends and POIs. I'm
working around that at the moment by removing all friend images, and re-adding them, but
this might have a more than necessary impact on performance.

I'm eagerly waiting for this change, so I can implement friends and POIs the right way :)

grtz,
Sander

pcreso at pcreso.com ()

2010-04-21 05:48:51 UTC

My 02c :-)

As a long time FOSS GIS user (who used to work with pre-satellite fixes, then transit data, & at last, real GPS data!!), one thing I miss with most GPS software is the ability to natively utilise standard GIS data formats.

Traditionally, GPS units have not been too concerned with background raster or vector data, just with their track, marker & waypoint data.

Obviously this has changed markedly in recent years, with land & marine navigation systems & chart plotters largely supplanting basic GPS.

I can gather free topo, depth & road data, build my own maps with FOSS tools like GRASS, R & GMT. Build my own shapefiles & geotiffs, manange my data in PostGIS or SpatialLite, etc. But having done all the hard GIS work, none of the products (such as geotiffs, or png/world file combinations) can easily be used with a GPS software tool.

At least not one I've looked at...

I'd love to see support for world file image tilesets, as used behind web mapping applications such as Mapserver; shapefiles, spatial databases like PostGIS & SpatialLite from a GPS application.

Generally just better integration/interoperability between the FOSS GIS & FOSS GPS arenas.

Cheers,

Brent Wood

Oliver Eichler

2010-04-21 07:50:17 UTC

Post by pcreso at pcreso.com ()
in PostGIS or SpatialLite, etc. But having done all the hard GIS work,
none of the products (such as geotiffs, or png/world file combinations) can
easily be used with a GPS software tool.
At least not one I've looked at...

Depends on what you want. On the PC side there are quite some tools like QGis, Viking or QLandkarte GT that handle raster maps very well.

On the mobile device side it's a bit harder. Most of the applications, just like tango/foxtrot gps, focus on tile servers. Or, as for road navigation, on vector maps.

I myself asked for geotiff support in FoxtrotGps on IRC, yesterday. My personal idea is to replace QLandkarte M by another application, as I am tired of maintaining it. The answer was: Only tile server / cache support. But: You can partition your large raster map into tiles and use them by that trick. Of course that approach has a few caveats if it comes to zooming.

But speaking of a free mapping library. GDAL does a good job at least on the PC. It's very easy to read raster data from a supported file format. It's not that optimal for mobile devices, because it's generality seems to be in the way for performance optimization. That is no issue on a strong cpu with big memory. But on a small processor with 64M it behaved a bit sluggish. You can try the GDAL approach with QLandarte M on a WinCE device. There are precompiled binaries.

Thus generally speaking an optimized FOSS library to read raster maps on mobile devices is kind of missing. It would even be ok if it's focus is just on one format and projection. If that helps to speed up things.

Oliver

Oliver Eichler

2010-04-21 07:50:17 UTC

Joseph Reeves

2010-04-21 11:03:49 UTC

Hi Brent,

I'd love to see support for world file image tilesets, as used behind web mapping applications such as Mapserver; shapefiles, >spatial databases like PostGIS & SpatialLite from a GPS application.

I don't know if you've seen it, but there's an unofficial version of
gvSIG mobile that is getting close to this wish list:

http://gvsigmobileonopenmoko.wordpress.com/

Cheers, Joseph

My 02c :-)
As a long time FOSS GIS user (who used to work with pre-satellite fixes, then transit data, & at last, real GPS data!!), one thing I miss with most GPS software is the ability to natively utilise standard GIS data formats.
Traditionally, GPS units have not been too concerned with background raster or vector data, just with their track, marker & waypoint data.
Obviously this has changed markedly in recent years, with land & marine navigation systems & chart plotters largely supplanting basic GPS.
I can gather free topo, depth & road data, build my own maps with FOSS tools like GRASS, R & GMT. Build my own shapefiles & geotiffs, manange my data in PostGIS or SpatialLite, etc. But having done all the hard GIS work, none of the products (such as geotiffs, or png/world file combinations) can easily be used with a GPS software tool.
At least not one I've looked at...
I'd love to see support for world file image tilesets, as used behind web mapping applications such as Mapserver; shapefiles, spatial databases like PostGIS & SpatialLite from a GPS application.
Generally just better integration/interoperability between the FOSS GIS & FOSS GPS arenas.
Cheers,
?Brent Wood
_______________________________________________
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS

Jay R. Ashworth

2010-04-21 14:17:35 UTC

Post by pcreso at pcreso.com ()
My 02c :-)

Marked down for inflation, of course. :-)

Post by pcreso at pcreso.com ()
As a long time FOSS GIS user (who used to work with pre-satellite
fixes, then transit data, & at last, real GPS data!!), one thing I
miss with most GPS software is the ability to natively utilise
standard GIS data formats.

Oh, yes.

Post by pcreso at pcreso.com ()
I can gather free topo, depth & road data, build my own maps with FOSS
tools like GRASS, R & GMT. Build my own shapefiles & geotiffs, manange
my data in PostGIS or SpatialLite, etc. But having done all the hard
GIS work, none of the products (such as geotiffs, or png/world file
combinations) can easily be used with a GPS software tool.

Well, not necessarily directly, no, but -- as another reply points out -- that
is as much as for any other reason because the target platform for programs
like FoxtrotGPS goes down the horsepower scale as far as it does; clearly, some
optimization, trading time and horsepower for space, is called for in those
environments.

That said...

Post by pcreso at pcreso.com ()
I'd love to see support for world file image tilesets, as used behind
web mapping applications such as Mapserver; shapefiles, spatial
databases like PostGIS & SpatialLite from a GPS application.
Generally just better integration/interoperability between the FOSS
GIS & FOSS GPS arenas.

You and me both, Brent, and it's one of the directions I'm investigating.

The current implementation of Foxtrot expects to retrieve tiles from an
internet map tile server, using NASA Worldwind URL protocol, or anything
that looks a lot like it, which includes TMS, and *I think*, WMS-C (It
was a couple days ago I was surfing through this stuff, and I'm on a
different computer just now).

Now, all those things said, FoxtrotGPS can likely be coerced (I have not
yet personally tried this) to accept a pre-built tile cache for a map layer
for which it does not have a valid URL to retrieve live tiles. Additionally,
I saw a script -- I think it was part of the GDAL distribution -- which would
split GeoTIFF files into Worldwind style map tile files; I assume it gets the
naming/addressing right, but again, I haven't gotten that far yet.

And finally, if what you have is vector data, I understand Mapnik can render
that out into raster files -- it's a fair bet that Foxtrot will remain a raster
map based program for at least the foreseeable future, unless Mapnik (for example)
is much more processor-efficient than I intuit.

But I am a cartography junkie, and a generalist, and I share your view that
Foxtrot might well be useful for audiences far removed from it's current primary
target audience: people with GPSs who just want to get around, and keep track of
it... and some of my work is aiming in that direction; I invite assistance on
that point.

I'd love to see Foxtrot ship with, or at least include pointers to, toolchains
for building maptile sets from data sources other than those we have now.

Down the road, I'd like to see it become a WMS client, but that, also, is a
question of horsepower vs space and network speed.

Cheers,
-- jra

pcreso at pcreso.com ()

2010-04-21 18:33:25 UTC

Hi,

Yep, I'm a QGIS user since v0.2 :-) I have even used it for a navigation app at sea on top of a PostGis DB (long before QGIS had any sort of GPS support). A perl script read, parsed & loaded GPS NMEA strings into a PostGis db. A view on the points table provided "current position" & a daily cron job built daily tracklines from the points. QGIS auto refreshed the screen every 30 seconds. Did well enough for it's purpose...

My interest is aquatic, and for my purposes, collecting depth/gps data to make my own charts for the areas I frequent, and displaying them on something like a Toughbook CF18 running Linux as my chart plotter would be perfect.

When it comes to GPS today, for boat/car use, 512Mb RAM & 1Ghz+ cpu devices for Linux or Windows are pretty basic specs, which is quite different to OpenMoko & other hand held devices, which used to be the main domain of GPS.

This trend is likely to continue, so GPS capable devices (like netbooks) have the memory & processing power of recent mid-range laptops. I use an eeePC 900 with eeeBuntu for some of this stuff with no problems.

For maritime use, I generally have no internet access (although cellular modem coverage in some parts of the world is also changing this restriction) so web based data supply is problematic, and also, web based providers are not providing useful charts, just maps.

I realise I'm somewhere out in the fringe as far as GPS use is concerned, so don't expect too much development focused on my area of interest, but figured it was worth tossing in to the discussion. If you don't ask ...

I agree that GDAL as a data access library for serious volumes of GIS data om a 64Mb handheld GPS is unrealistic, but a GDAL driver (or pyGDAL tool) to simplify the generation of raster tilesets for such devices may be a viable alternative. There are a few developments in that direction already.

As regards vector data on minimal hardware, some of the spatial data support now available in low overhead embedable databases like Spatial lite are changing the situation here as well.

Cheers,

Brent

Subject: Re: [FOSS-GPS] FoxtrotGPS Mapping Library
Date: Wednesday, April 21, 2010, 6:50 PM

Post by pcreso at pcreso.com ()
in PostGIS or SpatialLite, etc.

But having done all the hard GIS work,

Post by pcreso at pcreso.com ()
none of the products (such as geotiffs, or png/world

file combinations) can

Post by pcreso at pcreso.com ()
easily be used with a GPS software tool.
At least not one I've looked at...

Depends on what you want. On the PC side there are quite
some tools like QGis, Viking or QLandkarte GT that handle
raster maps very well.
On the mobile device side it's a bit harder. Most of the
applications, just like tango/foxtrot gps, focus on tile
servers. Or, as for road navigation, on vector maps.
I myself asked for geotiff support in FoxtrotGps on IRC,
yesterday. My personal idea is to replace QLandkarte M by
another application, as I am tired of maintaining it. The
answer was: Only tile server / cache support. But: You can
partition your large raster map into tiles and use them by
that trick. Of course that approach has a few caveats if it
comes to zooming.
But speaking of a free mapping library. GDAL does a good
job at least on the PC. It's very easy to read raster data
from a supported file format. It's not that optimal for
mobile devices, because it's generality seems to be in the
way for performance optimization. That is no issue on a
strong cpu with big memory. But on a small processor with
64M it behaved a bit sluggish. You can try the GDAL approach
with QLandarte M on a WinCE device. There are precompiled
binaries.
Thus generally speaking an optimized? FOSS library to
read raster maps on mobile devices is kind of missing. It
would even be ok if it's focus is just on one format and
projection. If that helps to speed up things.
Oliver

Oliver Eichler

2010-04-21 19:39:24 UTC

Post by pcreso at pcreso.com ()
My interest is aquatic, and for my purposes, collecting depth/gps
data to make my own charts for the areas I frequent, and displaying
them on something like a Toughbook CF18 running Linux as my chart
plotter would be perfect.

So, what's missing in the current available solutions?

Oliver

I took that off the original thread. Hope that's ok.

Jay R. Ashworth

2010-05-20 15:31:20 UTC

Post by John Stowers
Im not sure I understand you here. Could you please explain furthur.
Are you referring to how osm-gps-map first upscales the low res tile
while it waits for the high res one to arrive?

Yes--there's no way for me to specify limits on the upscaling.

[...]

Post by Joshua Judson Rosen
The FreeRunner's screen is ~300 px/inch, so text and icons that are
perfectly legible at 96 px/inch can be extremely difficult to read
from more than about a foot (~30 cm) away, which is absolutely
necessary when driving--as is being to see things at a glance
rather than with intentful scrutiny. :)
Nokia's N-series tablets are somewhat lower-density (~200 px/inch?),
but presumably still high enough to cause issues.
The same issue actually still manifests with lower-density displays
like most laptops (though mine's still ~145 px/inch...), just at
greater distances.

Indeed it does, as I leaned when driving around the east coast of Florida
last week with my 12" 1024x768 Thinkpad in the trunk next to me.

The issue is really uncoupling the size of the viewport from the zoom level.

At a given zoom, let's say 14, you get a certain number of square miles of
actual land visible in the viewport, let's say 400.

If you zoom in to 15, you get 1/4 that amount of land, 100 sq mi.

Generally, you do that by loading the zoom-15 tiles for that smaller area. But
if you do that, you get features that are also scaled for that size, and those can be
too small to read unless you're holding the device in your hand, or sitting at a desk
with it, which is the problem Josh is talking about.

His solution, which I like a lot, is to build in a scaling-factor offset, such that
you don't *use* the zoom-N tiles at zoom level N, you use the zoom-(N-X) tiles,
where X is the scaling factor in question; you might set it to 1, and use the zoom-14
at zoom level 15, but scale them up by 2:1, using the machinery that already exists.

You'd just only display the parts of those tiles that fit in the zoom-15 viewport;
that is, the center of the area; this might require clipping tiles, but that support's
clearly already in there.

My idea of the optimum user implementation of this is to put the offset manipulation
on another pair of keyboard keys (for those devices that have keyboards), probably
[ and ], and I would clip it at unity; I don't know that I see that X needs to be able
to go negative; do you, Josh?

To reply to another thread here overnight: the generic term for map tiles such as we
use and the protocols to retrieve them seems to be TMS, or, if you weld in the
tile-name-addressing protocol, Worldwind, after NASA's setup, which appears to have
been the first implementation widely used.

Cheers,
-- jra

Joshua Judson Rosen

2010-06-03 14:49:46 UTC

Post by Jay R. Ashworth

Post by John Stowers
Are you referring to how osm-gps-map first upscales the low res tile
while it waits for the high res one to arrive?

Yes--there's no way for me to specify limits on the upscaling.

[...]

Indeed it does, as I leaned when driving around the east coast of Florida
last week with my 12" 1024x768 Thinkpad in the trunk next to me.

[...]

Post by Jay R. Ashworth
His solution, which I like a lot, is to build in a scaling-factor
offset, such that you don't *use* the zoom-N tiles at zoom level N,
you use the zoom-(N-X) tiles, where X is the scaling factor in
question; you might set it to 1, and use the zoom-14 at zoom level
15, but scale them up by 2:1, using the machinery that already
exists.
You'd just only display the parts of those tiles that fit in the
zoom-15 viewport; that is, the center of the area; this might
require clipping tiles, but that support's clearly already in there.
My idea of the optimum user implementation of this is to put the
offset manipulation on another pair of keyboard keys (for those
devices that have keyboards), probably [ and ], and I would clip it
at unity; I don't know that I see that X needs to be able to go
negative; do you, Josh?

I don't know--as far as the UI goes, probably not with the current
set of map-sources (OpenStreetMap, Google, Yahoo!...), but maybe;
images almost never downscale as well as they upscale without special
attention, and some of the tile-providers actually provide a fairly
extreme case of this be using *single-pixel-wide* lines that may
(or may not, depending on the details of the downscaling-algorithm...)
disappear entirely. This is why I haven't bothered adding support to
FoxtrotGPS for negative zoom-offsets thus far.

But, regardless of whether we support it in the application, I don't
see any reason why the *back-end library* should impose a *hard* limit
at either end; after all, if someone does actually find a set of very
high-density tiles that they like, but they're using lower-density
display (say, tiles using 128-pixel map-icons, and a 96-px/inch VGA
display), then it may make sense to enable that. We'll see, I guess.
I don't intend to clutter-up our UI (or even the GConf interface)
with things like this unless their absense is causing someone pain.

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

Sander van Grieken

2010-05-22 11:18:52 UTC

[...]

Speaking only for FoxtrotGPS, I have a patch that I'm going to want to
integrate at some point that enables distinct items in the same general class
(e.g.: different POIs) to have have different icons; so we're ultimately
not going to find much use in osm-gps-map's current remove_image() behaviour.
For maximal flexibility, I'd probably also add a `user_data' member
to image_t, add an add_image_with_data() function that associates
its `data' argument with the newly_created image_t, make add_image()
associate the newly-created image_t with *itself* and return the same
pointer; then you can drop the old GdkPixbuf argument from remove_image().
It'd also be good to add a foreach_image() function that can be used to
to iterate over all of the images with at least a 2-argument (key, userparm)
callback like they have in various places in GLib and GTK+.

Why would you want to put so much image management functionality in osm-gps-map? We need
to manage these things in the application anyway, in order to know what to put in and take
out of the view, if it's being clicked on, etc.

If osm-gps-map simply provides the add/remove image functions that work with unique
image_t* pointers for each image instance, we can manage everything from the outside. The
code is already there. If you want many more different icons, that should be no problem
since we can already pass any pixbuf.

It was on my wishlist too BTW, these POI class specific icons, but I don't want to start
with new functionality before my branch gets merged to trunk. Can you please consider
merging my branch soon? Everything is now integrated (so also the friends, POI and photo
icons), quite a number of pre-existing bugs are fixed too, and the few things that are not
yet possible with the current osm-gps-map (like line-drawing in distance mode) are
annotated with TODOs in the code. The code has changed much, so any work based on trunk
now will be difficult to merge later.

grtz,
Sander

Joshua Judson Rosen

2010-05-25 14:46:09 UTC

Post by John Stowers
The limitation appears to be the assumption that the same pixbuf be
used as a handle for a group of pois/images. Is this something that is
useful/true in practice or will the app still need to keep around the
pointer to each added poi/image anyway (in which case we might as well
keep the implementation simple, and thus remove() only accepts the
opaque pointer)
What do you think?

... while (I meant to say) trying to preserve ease of use...

Post by Joshua Judson Rosen
I'd probably also add a `user_data' member to image_t, add an
add_image_with_data() function that associates its `data' argument
with the newly_created image_t, make add_image() associate the
newly-created image_t with *itself* and return the same pointer;
then you can drop the old GdkPixbuf argument from remove_image().
It'd also be good to add a foreach_image() function that can be
used to to iterate over all of the images with at least a
2-argument (key, userparm) callback like they have in various
places in GLib and GTK+.

... or something like that.

Post by Sander van Grieken
Why would you want to put so much image management functionality in
osm-gps-map? We need to manage these things in the application
anyway, in order to know what to put in and take out of the view, if
it's being clicked on, etc.

There are a few different answers (or parts to a single answer) for this.

One is, "Well, *we* do in foxtrot, but I don't know about everyone else
with other applications using osm-gps-map". My response was poorly-phrased,
and I should have more clearly delineated the "speaking only for foxtrot..."
paragraph vs. the rest of the response.

Another is that it's not image-management, it's collection-management;
and osm-gps-map has already taken on the responsibility of managing
the collection by hiding it behind a PIMPL. If it doesn't provide
a sufficient API to interact with the opaque collection(s), that can
cause problems even for applications that are willing to handle a lot
of details themselves.

Post by Sander van Grieken
If osm-gps-map simply provides the add/remove image functions that
work with unique image_t* pointers for each image instance, we can
manage everything from the outside. The code is already there. If
you want many more different icons, that should be no problem since
we can already pass any pixbuf.

It's easy to add them--that's not the problem; the issue is managing
the collection once it's populated; `remove or replace a subset of icons',
for example, currently cannot be implemented by client code in anything
better than O(n**2), because every call to remove_image() potentially
needs to traverse the entire GSList. Also, I'm not sure, but I wonder
if it might actually cause a lot of superfluous redraws.

Post by Sander van Grieken
It was on my wishlist too BTW, these POI class specific icons,

We already have 2 classes/groups of icons: POIs and people....

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

Joshua Judson Rosen

2010-05-25 14:49:17 UTC

Post by Sander van Grieken
It was on my wishlist too BTW, these POI class specific icons, but I
don't want to start with new functionality before my branch gets
merged to trunk. Can you please consider merging my branch soon?

At the very least, I'd like to work something out with John about the
zoom-decoupling before we convert to osm-gps-map; most of the other
issues that I have with osm-gps-map are things that could be worked
around if we needed to, and they're all things for which I think John
is willing to accept patches into osm-gps-map. We need to resolve
the zoom-decoupling issue, though--I expect that the related menu-items
have been renderered non-functional in your branch, though there are
a couple of other regressions that prevent me from actually seeing
(why is it trying to download maps to the root directory?).

Post by Sander van Grieken
Everything is now integrated (so also the friends, POI and photo
icons), quite a number of pre-existing bugs are fixed too, and the
few things that are not yet possible with the current osm-gps-map
(like line-drawing in distance mode) are annotated with TODOs in the
code. The code has changed much, so any work based on trunk now will
be difficult to merge later.

You actually have several orthogonal things going on in that branch,
which makes it difficult to merge: the biggest one is that you've
integrated osm-gps-map, but you've also done some redesign of the GUI,
renamed variables, renamed callbacks, moved functions to different
files, and made other stylistic changes to unrelated segments of code.
It looks like there was also an unnecessary merge-conflict created and
resolved unfavourably in at least main.c (there is a regression in the
"--gui=" command-line option, if I merge your branch).

Can you prepare a branch that has just the changes necessary to integrate
osm-gps-map, without superfluous changes like the ones listed above
(including not adding the osm-gps-map dpad & crosshair)?

Some of those changes may be interesting, but we'll approach them
separately.

A huge thank-you doing this work,

-rozzin.

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

Sander van Grieken

2010-05-25 17:27:01 UTC

Yes, since there's no original tile painting code anymore, it all went to osm-gps-map and
of course it doesn't have the zoom-decoupled functionality yet, so I can't hook it up.

Post by Joshua Judson Rosen
though there are
a couple of other regressions that prevent me from actually seeing
(why is it trying to download maps to the root directory?).

It's downloading maps to ~/.cache/osmgpsmap here..

No I haven't actually changed the GUI. I have replaced one toolbutton with a
tooltogglebutton though..

Post by Joshua Judson Rosen
renamed variables, renamed callbacks, moved functions to different
files,

Yes. Since the statements within those callbacks totally changed anyway I went ahead and
gave them more intuitive names, but AFAIR *only* on the callbacks that were impacted
anyway.

Maybe that makes the changes a bit harder to follow as an observer, but it's more easily
understandable by future contributors.

Post by Joshua Judson Rosen
and made other stylistic changes to unrelated segments of code.

Yes and 99% of it is empty lines. There was lots of that. Maybe Marcus uses a portrait
flatpanel? :)

Haven't actually tested it, but it should be possible to ignore the whitespace in the
diffs.

Post by Joshua Judson Rosen
It looks like there was also an unnecessary merge-conflict created and
resolved unfavourably in at least main.c (there is a regression in the
"--gui=" command-line option, if I merge your branch).

Oh? My branch was rebased to trunk right before I sent out the merge request last
saturday, and it should have been conflict free then. But yeah, the --gui option
regressed, and is fixed now.

Post by Joshua Judson Rosen
Can you prepare a branch that has just the changes necessary to integrate
osm-gps-map, without superfluous changes like the ones listed above

Nope. It means I have to spend a whole day to revert changes that are rejected on an
esthetics basis and will later probably change anyway. You're right that I should have
been more conservative in what to change, but being strict about this is mostly only
useful in projects with many contributors that work on the same files.

Of course I'll prepare my branch by keeping it merge-conflict free, so when/if you decide
to merge it will be easy (but invasive, yes)

Post by Joshua Judson Rosen
(including not adding the osm-gps-map dpad & crosshair)?

Fixed.

grtz,
Sander

Joshua Judson Rosen

2010-05-28 05:00:01 UTC

No I haven't actually changed the GUI. I have replaced one toolbutton with a
tooltogglebutton though..

Is this a zen koan? When is a change not a change? :)

Post by Joshua Judson Rosen
renamed variables, renamed callbacks, moved functions to different
files,

Yes. Since the statements within those callbacks totally changed
anyway I went ahead and gave them more intuitive names, but AFAIR
*only* on the callbacks that were impacted anyway.

What about the variables and struct-members? :)

Post by Sander van Grieken
Maybe that makes the changes a bit harder to follow as an observer,

Indeed, it makes it harder for me to review the changes, which means
that it's more difficult to merge them :\

I just can't bring myself to merge a branch that I can't review;
of course, yours isn't anywhere near *impossible* to review, but
it may take a little longer than either of us would like.

On the up side, however: before merging this into the trunk, I'd like
to finish up the more mundane & low-risk work (like converting the GUI
to GladeXML--which is *almost* done), and then get an initial *release*
out that includes the improvements accumulated so far since we diverged
from tangoGPS (support for different gpsd versions via libgps,
zoom-decoupling, updated translations, misc. bug-fixes, etc.) so that
others can have something that's straightforward to package and distribute...,
and I'm expecting to give that all about another week right now--hopefully
not much more than that. So, if anyone has a regression to report, or
another set of translation-updates to contribute, now would be a good time
to do that :)

The release-notes still need to be written, also; and, since I've been
unfortunately lax about creating ChangeLog entries to go along with
the changes themselves..., a ChangeLog needs to be produced.
I'm debating just adding a Makefile rule that creates a ChangeLog
from the `bzr log' output....

Post by Sander van Grieken
but it's more easily understandable by future contributors.

Oh I didn't mean to outright reject the *content* of any of your
changes; orthogonal issues just need to be handled separately--
you'll find that I'm a stickler for `one thing at a time',
one issue/feature per branch/merge.

Of course, that's not to say that I *never* screw it up myself....

Post by Joshua Judson Rosen
and made other stylistic changes to unrelated segments of code.

Yes and 99% of it is empty lines. There was lots of that. Maybe
Marcus uses a portrait flatpanel? :)

I have no idea. There are some weird things in there, indeed--like the
"vaild_fix" typo that's somehow absolutely consistent everywhere,
all over the place. That's one fix I'd like to incorporate :)

But it's really the other `1%' is that's more confounding:

Unrelated behavioural changes:

* `gconf store/restore show_pois and selected POI category'

* `don't reset input fields for routing! much nicer this way'

* `fix autocenter treshold and make autocenter a gconf setting'

* `make toolbar autocenter button a toggle button.'

Stylistic changes(?):

* `move parse_degrees to support.[ch]'

* `move string (un)escape functions to support.[ch]'

* Changing the datatype returned by parse_degrees().

* Renaming the variables and struct-members used to store angles
(dropping the "_deg" suffix from "lat_deg" and "lon_deg").

* Removing hard linebreaks in some places to make lines extremely
long (this I *am* actually going to just outright reject...),
adding hard linebreaks in other places. It's not immediately
obvious whether you actually made any functional changes
along with this....

... and probably some more, but a full review is going to take more time
that I have available tonight--and this list is getting to the point where
I might as well just do the cherry-picks. ;)

Post by Sander van Grieken
Haven't actually tested it, but it should be possible to ignore the
whitespace in the diffs.

Eh. I'm not a big fan of "just ignore that" or other hand-waving
exercises; if something is just noise, and serves no purpose other
than distraction, I'd rather just not include it in the first place.

Also, even if it's ignorable in diffs (and only some of your changes are),

Oh? My branch was rebased to trunk right before I sent out the merge
request last saturday, and it should have been conflict free
then.

I didn't mean that I experienced a conflict when trying to merge your
branch into the trunk, but rather that it looks like you must have
experienced a conflict when merging the trunk down into your branch--
and then you must have opted to keep the wrong half of the conflict.
I have no idea how you would have got one half of the option-parser
changes but not the other half, otherwise.

So, you're right that you're not causing any merge-conflicts on my end;
it's perhaps worse, though: I can just merge your branch into mine, and
have it `cleanly' apply the conflict-resolution choices that you made
(which break some things).

This would be where the `informatic environmentalism' pays off, of course:
if you limit the scope of your changes so as to minimise the likelihood of
creating the conflicts in the first place, the `wrong resolution'
issue doesn't even come up. :)

Post by Sander van Grieken
But yeah, the --gui option regressed, and is fixed now.

Thanks; it's not obvious whether anything else is similarly broken,
though--and it's going to take some review to basically determine it
the hard way, since I can't necessarily just read all of the individual
diffs and then compare them piecemeal to the whole. And, even where I can
do that, there's enough `noise' in the diffs that it's going to slow me
down a bit--putting issues of `cleanliness for its own sake' aside, it
might even be *quicker* to just cherry-pick all of the desirable bits
into a new branch.

I'll probably do that, if you don't get to it first. Just let me know
whether you want your name attached to the resulting commits (bzr provides
an `Author' field in commits that can be used via, "bzr commit --author",
to indicate the author of a change if it's someone other than the committer).
Really, if I can understand what's what, it should be fairly straightforward
to do cherrypicking with something like "bzr merge --pull --change=...".

Actually, I'm wondering now whether your expecation was that I'd just
do that anyway--since you're mainly experienced with other revision-control
systems?

Post by Joshua Judson Rosen
Can you prepare a branch that has just the changes necessary to integrate
osm-gps-map, without superfluous changes like the ones listed above

Nope. It means I have to spend a whole day to revert changes that
are rejected on an esthetics basis and will later probably change
anyway.

I guess I'm on the hook for that, then :)

Going that route, I'll of course publish my cherry-pick branch
*alongside* the trunk so that everyone can see what's coming.

Post by Sander van Grieken
You're right that I should have been more conservative in
what to change,

I guess we'll do better in the future.

Post by Sander van Grieken
but being strict about this is mostly only useful in projects with
many contributors that work on the same files.

Well, I'd hate for that to become a self-fulfilling prophecy.... :)

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

John Stowers

2010-05-28 07:51:38 UTC

On Fri, May 28, 2010 at 3:59 PM, Joshua Judson Rosen

No I haven't actually changed the GUI. I have replaced one toolbutton with a
tooltogglebutton though..

Is this a zen koan? When is a change not a change? :)

Post by Joshua Judson Rosen
renamed variables, renamed callbacks, moved functions to different
files,

Yes. Since the statements within those callbacks totally changed
anyway I went ahead and gave them more intuitive names, but AFAIR
*only* on the callbacks that were impacted anyway.

What about the variables and struct-members? :)

Post by Sander van Grieken
Maybe that makes the changes a bit harder to follow as an observer,

Indeed, it makes it harder for me to review the changes, which means
that it's more difficult to merge them :\
I just can't bring myself to merge a branch that I can't review;
of course, yours isn't anywhere near *impossible* to review, but
it may take a little longer than either of us would like.
On the up side, however: before merging this into the trunk, I'd like
to finish up the more mundane & low-risk work (like converting the GUI
to GladeXML--which is *almost* done), and then get an initial *release*
out that includes the improvements accumulated so far since we diverged
from tangoGPS (support for different gpsd versions via ?libgps,
zoom-decoupling, updated translations, misc. bug-fixes, etc.) so that
others can have something that's straightforward to package and distribute...,
and I'm expecting to give that all about another week right now--hopefully
not much more than that. So, if anyone has a regression to report, or
another set of translation-updates to contribute, now would be a good time
to do that :)
The release-notes still need to be written, also; and, since I've been
unfortunately lax about creating ChangeLog entries to go along with
the changes themselves..., a ChangeLog needs to be produced.
I'm debating just adding a Makefile rule that creates a ChangeLog
from the `bzr log' output....

Post by Sander van Grieken
but it's more easily understandable by future contributors.

Oh I didn't mean to outright reject the *content* of any of your
changes; orthogonal issues just need to be handled separately--
you'll find that I'm a stickler for `one thing at a time',
one issue/feature per branch/merge.
Of course, that's not to say that I *never* screw it up myself....

Post by Joshua Judson Rosen
and made other stylistic changes to unrelated segments of code.

Yes and 99% of it is empty lines. There was lots of that. Maybe
Marcus uses a portrait flatpanel? :)

I have no idea. There are some weird things in there, indeed--like the
"vaild_fix" typo that's somehow absolutely consistent everywhere,
all over the place. That's one fix I'd like to incorporate :)
? ? ? ?* `gconf store/restore show_pois and selected POI category'
? ? ? ?* `don't reset input fields for routing! much nicer this way'
? ? ? ?* `fix autocenter treshold and make autocenter a gconf setting'
? ? ? ?* `make toolbar autocenter button a toggle button.'
? ? ? ?* `move parse_degrees to support.[ch]'
? ? ? ?* `move string (un)escape functions to support.[ch]'
? ? ? ?* Changing the datatype returned by parse_degrees().
? ? ? ?* Renaming the variables and struct-members used to store angles
? ? ? ? ?(dropping the "_deg" suffix from "lat_deg" and "lon_deg").
? ? ? ?* Removing hard linebreaks in some places to make lines extremely
? ? ? ? ?long (this I *am* actually going to just outright reject...),
? ? ? ? ?adding hard linebreaks in other places. It's not immediately
? ? ? ? ?obvious whether you actually made any functional changes
? ? ? ? ?along with this....
... and probably some more, but a full review is going to take more time
that I have available tonight--and this list is getting to the point where
I might as well just do the cherry-picks. ;)

While this sounds like something you guys need to agree on amongst
yourselves, allow me to make a few observations, especially as they
relate to osm-gps-map, because AFAICT some of the directions you guys
have been working in have been a little orthogonal.

This is of course based on the assumption that your goal is to make
foxtrotGPS easier to maintain by removing the map drawing code, using
osm-gps-map and delegating that work to me.

Support for zoom decoupling does not exist in osm-gps-map-0.5/6.0, so
if the goal of supporting multiple libgps versions is making it easy
to package/build for all *currently released* distros then a
foxtrotGPS that uses osm-gps-map will lack this feature initially.
Note, when I say "not buildable on current distros" I mean "not
buildable against the version of library xyz shipped on current
distros".

What are the options
* Release from Joshua branch. This can be packaged against current
distros, difference to tangoGPS is the zoom decouple stuff, libgps
compat, translations and bug fixes. The release following this will
move to osm-gps-map 1.0.0 and so will not be buildable on current
distros (but the zoom decoupling will need to be implemented in
osm-gps-map first).
* Release/merge from Sander branch. This can be packaged against
current distros, difference to tangoGPS is libgps, translations, bug
fixes, and osm-gps-map. The release following this will move to
osm-gps-map 1.0.0 and not be buildable on current distros (but will
gain the zoom decoupling back once added to osm-gps-map).

AFAICT this gives three options, and you can only have 2 for the first release!

osm-gps-map <---> buildable on current distros <---> zoom decoupling

Post by Joshua Judson Rosen
From my experience, don't be too eager in restricting yourself to

"must build on currently released distro versions of software". Things
like PPAs solve this for users, and a developer who is not comfortable
building against uninstalled libraries is not a useful developer
anyway!

Also, don't forget one motivation for this fork was because Marcus was
unwilling to release his draconian grip on the project, accept new
features from contributors, and interact with the larger community in
a mature way. If foxtrotGPS can't be daring and open with its first
release then I suggest that is all ready getting started on the wrong
foot!

Regards,

John

Sander van Grieken

2010-05-28 12:23:33 UTC

Post by John Stowers
While this sounds like something you guys need to agree on amongst
yourselves, allow me to make a few observations, especially as they
relate to osm-gps-map, because AFAICT some of the directions you guys
have been working in have been a little orthogonal.
This is of course based on the assumption that your goal is to make
foxtrotGPS easier to maintain by removing the map drawing code, using
osm-gps-map and delegating that work to me.
Support for zoom decoupling does not exist in osm-gps-map-0.5/6.0, so
if the goal of supporting multiple libgps versions is making it easy
to package/build for all *currently released* distros then a
foxtrotGPS that uses osm-gps-map will lack this feature initially.
Note, when I say "not buildable on current distros" I mean "not
buildable against the version of library xyz shipped on current
distros".
What are the options
* Release from Joshua branch. This can be packaged against current
distros, difference to tangoGPS is the zoom decouple stuff, libgps
compat, translations and bug fixes. The release following this will
move to osm-gps-map 1.0.0 and so will not be buildable on current
distros (but the zoom decoupling will need to be implemented in
osm-gps-map first).
* Release/merge from Sander branch. This can be packaged against
current distros, difference to tangoGPS is libgps, translations, bug
fixes, and osm-gps-map. The release following this will move to
osm-gps-map 1.0.0 and not be buildable on current distros (but will
gain the zoom decoupling back once added to osm-gps-map).
AFAICT this gives three options, and you can only have 2 for the first release!
osm-gps-map <---> buildable on current distros <---> zoom decoupling

Post by Joshua Judson Rosen
From my experience, don't be too eager in restricting yourself to

"must build on currently released distro versions of software". Things
like PPAs solve this for users, and a developer who is not comfortable
building against uninstalled libraries is not a useful developer
anyway!
Also, don't forget one motivation for this fork was because Marcus was
unwilling to release his draconian grip on the project, accept new
features from contributors, and interact with the larger community in
a mature way. If foxtrotGPS can't be daring and open with its first
release then I suggest that is all ready getting started on the wrong
foot!

Ok I see your point. Maybe it's not so important to be compatible on an older osm-gps-map
release.

Since we are progressing so quickly, if we can hold off releasing for another week or two,
we might be able to have it all, and be sufficiently different from tangogps to really
stand apart.

It would also save time w.r.t. packaging, changelogs, etc.

grtz,
Sander

John Stowers

2010-06-03 04:27:30 UTC

Post by Joshua Judson Rosen
... and probably some more, but a full review is going to take more time
that I have available tonight--and this list is getting to the point where
I might as well just do the cherry-picks. ;)

Just a subtle ping, have you guys reached a consensus yet?

Cheers,

John

Joshua Judson Rosen

2010-06-03 15:15:29 UTC

Post by Joshua Judson Rosen
... and probably some more, but a full review is going to take
more time that I have available tonight--and this list is
getting to the point where I might as well just do the
cherry-picks. ;)

Just a subtle ping, have you guys reached a consensus yet?

Right on cue--I did say to give me `about another week, hopefully
not much more than'... exactly 1 week ago, didn't I? :)

I'm about half-way done reading through Sander's changes, mainly
because I've spent most of my available time so far finishing up my
own pre-release work (the GUI has now been fully converted to GladeXML,
there's a new application icon that should work on all backgrounds,
there were a few more inherited bugs that I found and had to fix
before I could finish testing my changes and comparing the updated
behaviour against the last version of tangoGPS, and I'm just finishing
a draft of the NEWS file right now).

I'm not very far into looking over your new API, but I like what I see
so far.

Have you had any thoughts on how we should get the zoom-decoupling
into osm-gps-map?

--
"Don't be afraid to ask (?f.((?x.xx) (?r.f(rr))))."

Sander van Grieken

2010-05-28 12:10:14 UTC

Post by Joshua Judson Rosen
integrated osm-gps-map, but you've also done some redesign of the GUI,

No I haven't actually changed the GUI. I have replaced one toolbutton with a
tooltogglebutton though..

Is this a zen koan? When is a change not a change? :)

Ok ok I have to choose my words carefully :) So it's a change, but not a redesign :)

No zen koan yet, but I suspect we might invent one along the way with these discussions :)

Post by Sander van Grieken
Maybe that makes the changes a bit harder to follow as an observer,

Post by Sander van Grieken
but it's more easily understandable by future contributors.

Yes :) And I see the advantages of that.

Post by Joshua Judson Rosen
Of course, that's not to say that I *never* screw it up myself....

Since I have been through all the code the last few weeks, it was sometimes just too
tempting to *not* go outside the branch scope. But yeah, I'll try to restrain myself in
the future, or branch mercilessly if I really cannot hold back :)

Post by Joshua Judson Rosen
* `gconf store/restore show_pois and selected POI category'
* `don't reset input fields for routing! much nicer this way'
* `fix autocenter treshold and make autocenter a gconf setting'
* `make toolbar autocenter button a toggle button.'

Ok I can revert these.

Post by Joshua Judson Rosen
* `move parse_degrees to support.[ch]'
* `move string (un)escape functions to support.[ch]'

Maybe these can stay in? They haven't changed internally.

Post by Joshua Judson Rosen
* Changing the datatype returned by parse_degrees().
* Renaming the variables and struct-members used to store angles
(dropping the "_deg" suffix from "lat_deg" and "lon_deg").

These two are for consistency among poi_t, photo_t and friend_t. It also avoids having to
use convertor macros everywhere. I think it's also in scope for the branch, since osm-gps-
map takes degrees in many cases, where tango used radians (although not consistently).

Post by Joshua Judson Rosen
* Removing hard linebreaks in some places to make lines extremely
long (this I *am* actually going to just outright reject...),
adding hard linebreaks in other places. It's not immediately
obvious whether you actually made any functional changes
along with this....

Yes you're right, these have to go.

Post by Sander van Grieken
Haven't actually tested it, but it should be possible to ignore the
whitespace in the diffs.

It's not meant as hand-waving. I know 'diff' can ignore most of the whitespace changes,
and it would be nice if bzr can merge this way. After merging, my branch dies anyway, and
any new branch will be (re)based on trunk.

Oh? My branch was rebased to trunk right before I sent out the merge
request last saturday, and it should have been conflict free
then.

I didn't mean that I experienced a conflict when trying to merge your
branch into the trunk, but rather that it looks like you must have
experienced a conflict when merging the trunk down into your branch--
and then you must have opted to keep the wrong half of the conflict.
I have no idea how you would have got one half of the option-parser
changes but not the other half, otherwise.
So, you're right that you're not causing any merge-conflicts on my end;
it's perhaps worse, though: I can just merge your branch into mine, and
have it `cleanly' apply the conflict-resolution choices that you made
(which break some things).

It's only worse if you merge blindly, which you already said you didn't do. Besides, any
merge has the potential to break things, I think I did pretty well so far, you found the
only regression I introduced (fingers crossed :) )

Post by Joshua Judson Rosen
if you limit the scope of your changes so as to minimise the likelihood of
creating the conflicts in the first place, the `wrong resolution'
issue doesn't even come up. :)

In this case I think it was unavoidable since integrating osm-gps-map touched that part of
the code anyway, regardless of the out-of-scope changes.

Post by Sander van Grieken
But yeah, the --gui option regressed, and is fixed now.

Maybe this is easier and/or faster:
- cherrypick the out-of-scope changes that you want in trunk from my branch (like the
seen_vaild typo, the move of support functions to support.[ch], xml parsing crash fix)
- I rebase my branch on trunk again, so those changes 'disappear'
- I revert the changes you *don't* want in trunk
- finally, merge

Post by Joshua Judson Rosen
I'll probably do that, if you don't get to it first. Just let me know
whether you want your name attached to the resulting commits

I'm surprised. For someone that's quite strict about the process to be loose about this.

Post by Joshua Judson Rosen
Can you prepare a branch that has just the changes necessary to integrate
osm-gps-map, without superfluous changes like the ones listed above

Nope. It means I have to spend a whole day to revert changes that
are rejected on an esthetics basis and will later probably change
anyway.

I guess I'm on the hook for that, then :)

Well there has been more out-of-scope stuff going into my branch than I initially thought,
so I won't burden you with that. Please consider my 'reverse' cherry-picking proposal
above.