Ok, now i've gotten a chance to play with this software a bit, and its pretty nice!

A couple of small things, other people have probably reported before, but I’m not sure.

1. When you hit the top button to hide GPSapp, so you can adjust the player (volume or track) When adjusting the volume, my volume popup hides extremly fast, only while gpsapp is running in the background.

2. Usually after the second time I hide GPSapp, to adjust the mp3 playing, it will freeze. When holding the knob to bring up the hijack menu, it goes straight into the last GPSapp screen, then after a few seconds, back to the player. I have to remove the empeg from the cage, and reboot.

Otherwise, this app looks pretty solid, besides the minor bugs in the map data.

2. Usually after the second time I hide GPSapp, to adjust the mp3 playing, it will freeze. When holding the knob to bring up the hijack menu, it goes straight into the last GPSapp screen, then after a few seconds, back to the player. I have to remove the empeg from the cage, and reboot.

This is a known bug which seems to affect all of the third-party programs that bind to the hijack menu. We have long suspected a bug in Hijack. I'd love to see it solved, regardless of where the bug lies.

I've finally found a few minutes to install this, and...Wow, it really does show great potential. Going forward from here;

1) Jan, are you looking to integrating this into gpsapp more tightly (possible non-US ramifications), or perhaps reworking gpsapp to allow a 'modular' moving map 'plug-in' (allowing other potential data sources to be used if they come along). Or are you intending for roadmapgpsapp to remain a derivative of gpsapp?

2) Assuming for the moment that the zoom scales can be unified, we still have some UI hurdles to jump;
a) gpsapp currently displays a dim route with bright waypoints. The roadmap lines are always bright. This is almost the inverse of what is ideal. Obviously with only 3 shades and black available we are very limited in how to resolve this. Ideally major highways would be brighter than back roads. But how do we then indicate the route over the top? Perhaps a dotted line that inverts itself a few times/second? Perhaps an animated line that color-cycles through the 4 shades...Hmm. picture/thousand words;


b) It would be nice if we could have a larger virtual screen, and then a pan mode. This way we could look around at a higher resolution.
c) It'd be cool to pop up the nearest road name. Chances are that we should be on it.
d) Labelling major highways at an appropriate resolution.
e) De-cluttering some of the big-scale zooms. It appears as if we still get dots where some of the roads were. Ideally if I go to a 5mile+ scale, all I want to see are major roads. (Interstates, turnpikes etc)
f) It'd be nice to shade-fill water. It appears as though it is displaying line data for shorelines already. I'm not sure how feasible this is.
g) Remove transparency from gpsapp popup route directions.

3) It would be cool to implement a road name search. My brief source code excusion suggests that the underlying data should be there in a searchable form. I don't know if it would be possible to implement a fuzzy search similar to the empeg's song search feature, but that would be ideal. I'm guessing that the database would be too large to keep in memory, and the fuzzy search would require looking in multiple parts of the database simultaneously until the search gets narrowed down. But I can dream
...and then highlight/mark the resulting road whenever it appears in our viewport. (and ensure that it appears in large scale zoom modes too)

Lots of other exciting potential...

The NMEA output is really gay.

Unless you happen to be gay, in which case it's really straight.

Is WAAS any good? will it work with the empeg?

WAAS is used by the receiver and no data is output, so it will improve your accuracy with no impact to users of the data.

c) It'd be cool to pop up the nearest road name. Chances are that we should be on it.

Roadmap v1.0rc3 has this ability, along with the ability to display road names, at approaching intersections and even use Flite to text-to-speech them. I'm planning to re-work the "bridge" between GPSApp and Roadmap and integrate version v1.0rc3 of Roadmap sometime reasonably soon. If Jan wants to give me some guidelines for making a "bridge" that would be welcome..

d) Labelling major highways at an appropriate resolution.

Map Labeling would be nice but Roadmap doesn't appear to even do this, maybe the latest version does.. haven't installed it yet.

e) De-cluttering some of the big-scale zooms. It appears as if we still get dots where some of the roads were. Ideally if I go to a 5mile+ scale, all I want to see are major roads.
(Interstates, turnpikes etc)

I think what your seeing mainly here are bodies of water which aren't decluttered by default- you can mess with this in the schema and/or preferences file I believe. Real large scale zoom outs are dangerous anyways because they require so much disk reads that the empeg can easily get cloberred.

f) It'd be nice to shade-fill water. It appears as though it is displaying line data for shorelines already. I'm not sure how feasible this is.

The code for this is probably already in roadmap, I just need to write the function that draws it correctly. I tried to use the function in vfdlib.c that draws polygons filled and it seems like it didn't clip correctly and clobbered the whole screen. Hard for me to test this shoreline stuff though, only body of water I have here is the ole Mississippi..hehe

3) It would be cool to implement a road name search. My brief source code excusion suggests that the underlying data should be there in a searchable form. I don't know if it would be possible to implement a fuzzy search similar to the empeg's song search feature, but that would be ideal.

Roadmap has very nice search functionality.. if you try the actual Roadmap program it works pretty well. No idea how you could put in what address you wanted though on the empeg without the remote or something.

Jan, are you looking to integrating this into gpsapp more tightly

I downloaded it, but haven't had time to try, or even look at how source was integrated. I did look at the roadmap sources to see if it is using a nifty encoding scheme, but it is pretty simple. I'm probably just going to see how it is developing for now.

(2a) The way routes are drawn would have to be changed considerably to get the crawling ants effect. Because it depends on the scale and we can't treat each route segment independently.

(2g) Yeah, transparency never was a problem with the simple route display. But clearing the area underneath the popup is pretty trivial.

It definitely has potential.

If Jan wants to give me some guidelines for making a "bridge" that would be welcome.

Not sure what would be needed. But it is probably best to keep roadmap as unmodified as possible to be able to track new releases. Gpsapp is smaller and I might just grab some or all of your changes at some point.

Real large scale zoom outs are dangerous anyways because they require so much disk reads that the empeg can easily get cloberred.

That's one of my issues with the data format. I had already decided that the data should probably be stored in several 'layers' so that at a larger zoom we don't have to seek past the unused details. i.e. one file with interstates and possibly borders/large bodies of water for the whole of the US. Other highways and possibly mayor roads in per-state files, etc.

No idea how you could put in what address you wanted though on the empeg without the remote or something.

We can intercept remote button codes as well. Grab them after a knob longpress, or some menu selection. I typically use the remote to adjust the volume while gpsapp is running.

Not sure what would be needed. But it is probably best to keep roadmap as unmodified as possible to be able to track new releases. Gpsapp is smaller and I might just grab some or all of your changes at some point.

Sounds fine, not many changes to GPSApp are really needed for this anyways. Although I may have to look into getting the zoom scales to match, not sure what that would involve.

That's one of my issues with the data format. I had already decided that the data should probably be stored in several 'layers' so that at a larger zoom we don't have to seek past the unused details. i.e. one file with interstates and possibly borders/large bodies of water for the whole of the US. Other highways and possibly mayor roads in per-state files, etc.

The author has this in his TODO file as something that needs to be done so hopefully in the near future this will get fixed.

It might be a projection issue. GPSapp is currently using a transverse mercator projection in the WGS84 datum, but the difference with a real UTM projection is that I center around the middle of the rectangle that fits around the route instead of the using the actual UTM zone in which the route falls.

The Tiger data is probably in the NAD27 datum, although they might have switched to WGS84 in the recent versions. There is approximately 200 meter difference between the two. I'm also guessing that roadmap doesn't do a cartographic projection to a rectangular grid (i.e. 1 pixel in either direction == 1 meter), but is using something like 1 pixel == 1 degree (or 100th of a degree), I forgot the name of this projection, but it is commonly used for world maps (which is why many people think that europe and north america are larger than they really are.

Basically you can use a ruler on the gpsapp route display and the distance between two points in any direction is always correct for the scale. When there is no cartographic projection 100 meters north might be 10 pixels, but 100 meters east is only 7 pixels. The difference is even more near the polar regions where the latitudes are getting closer to each other while the longtitude lines always have the same distance.

I'm leaning towards dropping the transverse mercator projection. Typically people won't be able to tell the distortion, and it makes it easier to draw areas that span several UTM zones, like the whole US when we zoom out a lot.

My analysis of the projection function, roadmap_math_compute_scale in roadmap_math.c, suggests Roadmap does a WGS84 projection of some sort. I really haven't dwelved into the math any futher to say if it is doing cartographic projection or not.. although the comments suggests it does- he says the projection tries to compensate for curves around the poles. I'll trace the code more and see what it's doing and let you know if I figure anything else out.

Since I can't find it in the FAQ, and I don't feel like searching the BBS, can someone tell me which pins to hook my GPS up to on the serial port coming off the EMpeg? Namely, I need to know the 12V power source, and the Rx/Tx data lines. Also, does anyone know how much current the 12V line can support?

...I don't feel like searching the BBS

Ignore the wealth of information that already exists and get everyone to re-type it 'cause you're feeling lazy. Nice.

From memory, on the docking sled serial port port connector, the Amp Remote (12V) line is on pin 4, and can handle 3A. TxD and RxD are on pins 2 and 3. They are the opposite of whatever the empeg itself is, but can't remember which way around. If your GPS is TTL level (ie GPS module from somewhere like bgmicro) then you'll need to convert the voltages, but if you bought an off-the-shelf unit then you probably wont need to. Check the specs.

Of course, none of this information is guarranteed to be 100% correct. It is from memory. But it is all available for free on this BBS.

Non-obvious but useful search terms include Oncore, Trimble, SVee6, streetfinder.

Ok, so I decided to give this a go and am having trouble getting it to work. I followed the instructions and am pretty certain I didn't leave any part out. But roadmap is not showing up in the hijack menu. Here is the end of my boot log

hijack_exec("/drive0/var/gpsapp/gpsapp"), rc=0 (okay)
GPS app started
hijack_exec("/drive0/var/roadmap/roadmapgpsapp"), rc=0 (okay)
** roadmap_file.c, line 315: cannot open file usdir.rdm
** roadmap_dbread.c, line 377: cannot open database file usdir.rdm
## roadmap_locator.c, line 132: cannot open directory database (usdir)
player.cpp : 385:empeg-car 2.00 2003/04/01.
Prolux 4 empeg car - 2.1434 Mar 26 2003
Vcb: 0x4086d000

There are 3 lines there that say the usdir file can't be opened. I put that file on the empeg in the correct place and extracted it and everything. So why cant it open that file?

I can only think of 3 reasons for it not being able to open the file:

* looks in the wrong place (ie file put in the wrong place - which you say isn't the case)
* wrong permissions on the file (try chmod 777 usdir.rdm)
* corrupt file (but one would hope for a better error message in that case), maybe because uploading from Windows->Unix with a client that autotranslated linefeeds? (try re-uploading in binary mode) Or corrupted for some other reason.

/Michael

Another possibility... case sensitivity in a file or directory name?

I'd say it's permissions or ascii corruption more likely, too.

By the way, you said you "extracted them and everything"... If you used WinZip on the PC to extract them, it's very likely ascii corruption because WinZip has the "smart CR/LF conversion" feature...

Anyone else have any ideas. I just double checked and the file usdir.rdm is in the same directory as roadmapgpsapp. I tried the chmod 777 but that didn't work. And I deleted it and put it back on and it still doesn't work. It is still giving me the same error message in the boot log.

chmod 777 but that didn't work.

Hmmm, drive needs to mounted read/write for that operation. But waht does ls -l in that directory say about the file?

I deleted it and put it back on

Same method of extraction/upload, or did you do anything different?

/Michael

Hmmm. I don't have my empeg on the network at the moment so I can't check, but I'm fairly sure the database files don't go in the bin directory that the roadmap-gpsass binary goes in. Check and make sure you're either using the defaults given in the installation instructions, or specifying where they are in your config.ini.

GPSapp-Roadmap is a great program once you get it going, so keep trying. Not really usefull for navigating yet, but it's really cool to watch as your arrow traces out the upcoming turns.

Does anyone know how much of a shift would it be to always have the arrow pointing in one direction and have the map rotate as you drive? As I navigate, I always orient the map so that I'm going up the page, and it'd be neat if gpsapp could do it too.

Matthew

You MUST install the usdir files and other support files in /drive0/roadmap (not /drive0/var/roadmap) as the install document says. That is unless you change the preferences files which you must put in /usr/share/roadmap (did you do this also?). The preferences file has a line which tells the roadmap code where to look for map files. I would say try to Install again using the same directory structure I mention in my install document.. if that doesn't work it's probably your FTP program corrupting the file.

Yep, that fixed it. Thanks. All it took was moving the usdir and state map to drive0/roadmap instead of drive0/var/roadmap.