Since it looks like I'll be getting an empeg, be it from ebay or SB, let the fun begin. I know smu tried to get a nav project off the ground a bit ago, I don't know how that is coming along. Maybe we can make it a joint effort, and maybe kim could give us a hand seeing as his project it so far ahead. Anyway I'm going to start rambling off my thoughts. Firstly... the maps. I know nothing of map formats, but will look at other projects for linux that use them to figure something out. Some more thoughts on maps. I've got a Street Atlas USA CD that has maps on it. Would these be usable? (as long as your own the cd). Are they a standard format? There are a few linux GPS projects that can help get us started. One of particular interest to me is a perl module that provides an interface with various GPS units. The GPS unit I have at the moment is an Delorme Earthmate. The first thing I plan on attacking is getting the epmeg/GPS to talk. Probably just display the coordinates and any other info the GPS unit sends. I guess thats it for now... I'm headed to bed (I'll probly think of something more to say while im laying here). But until then... happy empeging.

-Dan

Hi Dan.

Getting the player to read the GPS is far from being the main task. (BTW: The Street Atlas CD should be usable once we get a converter written, the specs are available)
The main problems currently are:

1. installation of 3rd party apps on the player


2. a graphical API that works on the player (and is still portable enough to be ported to other Linux systems, from notebook to PDA)


3. an open map storage format that contains enough preprocessed data to make the actual route calculation use less CPU and RAM (both tight resources on the empeg, even tighter on PDAs)


4. the core route calculation algorithm (take a start point, take an end point, calculate shortest/fastest/preferred route).
   
5. the route tracking algorithm (take a route, and start a new route calculation if the driver leaves it, while he is on track: Give instructions to follow it)
   

I am currently working on 1 and 2 with the focus on 1, need help with 2,3,...

Getting real map data to play with is a task that we can tackle when the route calculation algo(s) is/are tested with constructed test sets of data.
If we want to get tricky, we could later implement TMS (traffic messages) into the route tracking and/or calculation, at least for those countries that support it.

cu,
sven

I probably shouldn't complain since I have not done anything to help this project :-) but I don't really see much reason to waste time on 1 and 2 at this point. An easy way to install the software is not an issue until the software exists. If it has to be zmodem'd over your early adopters will be able to figure it out. As far as 2, doesn't hijack provide a nice way to do overlays on the screen that would be ideal for a project like this? No reason to reinvent the wheel just to make it portable if there is already a perfectly good wheel on the platform you are most concerned with. If someone else really wants it to work on a PDA let them contribute the code to do it!

I still wish someone would write something simple that talked to a GPS and used basic screen overlays to display direction, speed, etc. At least that way there is a proof of concept, everything else can be built on top of that.

Just some idle thoughts...
-Mike

I think initially the only types of graphics you'll need are some basic arrows, and some text. You can record some mp3's that say "Turn Right at next street" "Turn Left" ..that sort of thing. Then you can macro some things to the player to bookmark its current position, play the appropriate mp3, then return to the preset bookmark.

Calvin

I don't know if anyone noticed, but with a lot of help, I got the GD graphics library working on the Empeg, at least well enough to get my Trivia game running. Basic font support, circles, rectangles, lines, etc...

Hey, I noticed you list algorithm used as a problem. I know this is kinda hackneyed, and a code cliche that everyone throws at this sort of problem, but what's wrong with Dijkstra's algorithm?

It may be cliched to death, but it *is* fairly flexible, allowing you to factor in "weightings" for the decision making process and stuff....

...you could possibly implement a linked list of function pointers or something as the "decision factor", so you can dynamically alter how it weighs the best route and stuff.

Just a thought. You have probably already thought about it and discarded it for some reason, but hey, there's my 2 cents from having no idea whatsoever where you are with the project and stuff...

And dont laugh at me, it was just a thought ;)

Hi.

Easier install doesn't only benefit the nav project, but many others as well, most notably: displayserver (at least as soon as Frank gets to adjusting it to beta7 and hijack). Also, it does make testing a bit more convenient.
As for the graphics (or general UI) API: hijack only provides a nice way to overlay the content of a buffer with the current player display, but no convenient way to fill that buffer or to generate and handle the menu structure of an application.
I intended to create (and started working on) an API that handles the menu structure, allows easy image display and basic drawing instructions like lines, circles, arcs and stuff like that.
Regarding PDA support: I do not intend to directly support it, but I want the API to be abstract enough to allow easy porting.

If you want basic GPS data display, just start and write such an app. Noone is gonna stop you (to the contrary, many will support you).

cu,
sven

Hi.

Yes, I noticed, but I didn't see any sources for that (the patched GD sources I mean). I would really like to see them, and probably use them as a starting point for a more optimized API ( I remember you had problems with the speed of GD).
Your problems with it were mainly caused by writing/drawing to one buffer (GD format), then converting to an empeg raw buffer and finally merging (overlaying) it with (/to) the player's display. If I could get GD to use the empeg's raw buffer format internally, it should get a bit faster (both by elliminating the conversion step and because drawing to the empeg raw buffer should be easier/faster than writing to a multi-color GD buffer).

cu,
sven

Any reason why you shouldn't use the Java KVM for Linux and the AWT with small footprint class set (a la JMC Edition) for points 1 and 2?

Hi.

Dijkstra is a really nice algorithm if you are looking for a perfect solution (as far as I remember, I would have to look up the specifics), but even though it is one of the fastest algorithms for that task, it is still quite a slower than the estimation algos that are typically used by nav systems. But the "problem" about the algo isn't that much in finding the right one but in implementing it for the empeg (with tight memory and tight CPU power).

As for the progress of the nav project: Due to some events that were not under my control, I didn't get on nearly as fast as I wanted, so basically, I am still in the research phase (but at the end of that). I am currently sorting through all the information I got and will proceed with the first two tasks mentioned above (actually, I already started, but there is nothing presentable yet).

So if anyone wants to help out, he (or she) should just choose a task and email me, so that I can keep track of who is doing what (and put those into contact with each other that are trying to help on the same task). I would be really glad for any help.

cu,
sven

Hi Rob.

How would the Java KVM and AWT help in task 1? They might help with task 2, but I don't think they really would help much, because even with a small footprint clas set, Java still uses a lot of memory for itself that should better be available to the application IMHO.

Like I said in a previous post, the GD library should be ok for the graphics stuff (at least after being optimized for the empeg).

The easy installation will probably incorporate the use of an ftp daemon on the empeg (be it a kernel ftpd like Mark Lord proposed, or a user space ftp daemon which I would prefer) and a custom init on the spare partition, installed using the original upgrade process. I will hopefully get a first working version of that ready by the end of this week(end).

cu,
sven

Hey Sven,

I just dropped you an email with what I have for the graphics library. Hopefully you can carry the torch! An Empeg-optimized graphics API would be a huge step.

I agree with what you said. Half of the code in my Trivia game is setting "colors" for the image objects and converting the image into an Empeg buffer... Probably very inefficient.

If anyone else is interested in the GD source let me know and I can try to host it somewhere. I don't want to attach it here because it's about 700k or so.

I don't know if Kim Salo reads the BBS much now, but it would be interesting to find out what algorithm he uses. His empeg nav software does routing (including one-ways etc) and I seem to recall it already does real time rerouting if you take a wrong turn.

I could be wrong though. I do have a copy of the software but I don't have a UK map for it. If we can find a suitable Netherlands map it would be a cool thing to demo at the next owner meet in Amersfoort.

Rob

If you want basic GPS data display, just start and write such an app.

I have actually started to do that more than once, but having to teach myself C first tends to get in the way. Maybe someday when I am feeling overly motivated (not often).

-Mike

In reply to:

---

I do have a copy of the software but I don't have a UK map for it.

---

Could you send me a copy of that software just so I can take a look at it? I find this really interesting. Its one of the main things I added on to my car mp3 player when I made on from scratch a few years ago.

-Greg

I don't know if Kim Salo reads the BBS much now, but it would be interesting to find out what algorithm he uses. His empeg nav software does routing (including one-ways etc) and I seem to recall it already does real time rerouting if you take a wrong turn.

I'm using A*, which is one of the most commonly used algorithms for path finding. The accuracy and complexity of the algorithm can be controlled with the heuristic function.

However, the biggest design step is to make it memory friendly. In my implementation, I have five different buffers for the path finding which I can freely scale up or down, depending how much memory I want to spend vs. how fast it will be. In other words, what doesn't fit into memory will be swapped to the disk, but in a smart and efficient way.

Kim

Could you send me a copy of that software just so I can take a look at it?

I'm afraid he may not be allowed to do that

Honestly, you couldn't even do anything with the software unless you would have a map in the right format and the right type of map projection in place.

Kim

Hi.

If anyone else is interested in the GD source let me know and I can try to host it somewhere. I don't want to attach it here because it's about 700k or so.

I just uploaded it to http://www.incase.de/files/empeg/programming/gd-2.0.1-empeg.tar.gz. It is not linked from my homepage though.

cu,
sven.

Any reason why you shouldn't use the Java KVM for Linux and the AWT with small footprint class set (a la JMC Edition)

Do you have links to this stuff? Sun's j2me appears to be linux/x86 and Solaris/Sparc only. A quick google search just turns up a lot of press releases about future Sun/Arm projects and related hype. Is there a linux/arm j2me somewhere that I am missing? Do you actually have this stuff running on your empeg?

-Mike

Actually, what's the problem with starting with something simple? At least to get moral and support up and flowing. Vaporware rarely brings out the masses in interest.

I envision the basics, as mentioned, speed, direction, coordinates. I also envision a very rudimentary single waypoint routing ... enter your coordinates for your target and the empeg will point you in the right direction (complete with little arrow), miles (kilometers) to target, time of arrival given current speed.

Most of this is in GPSd right?

Greg

I agree with Greg. Once something simple like that is layed down and working more features can be implemented. It would be great (as a start) to have the empeg tell speed, direction, and coordinates.

-Greg

That was exactly my thought. I was planning on playing around with gpsd once I get my 30 gig unit. (I got a 10 gig in hand off ebay just in case, don't want to goof around with that until i decide not to sell it)

Dan

I also had a question that I forget to add to that, which was my main reson for posting. I had a Rand McNally GPS but I havn't seen it around. I was just woundering what a good gps would be to play around with on my empeg. (I am in the US)

-Greg

Kim, any thoughts yet about where you may choose to take your project?

It's a shame to see all these guys duplicating what you've already done.

Rob

Kim, any thoughts yet about where you may choose to take your project?

I've been waiting to find someone who could provide map data and preferably the knowledge of the source data format, in order to test the software in other environments. It seems that reverse engineering the data format of existing navigation CD's is the only possible way to go, since there is no information available without huge $$$ or strict agreements. SDAL didn't seem to help the situation at all.

Heck, even the data that I use is for private test use and only covers about 80 square kilometer area. The official navigation CD for Finland is supposed to come out only late this year or in 2003.

So, shortly, the maps and the knowledge of the map format is the biggest showstopper at the moment.

Kim

So, shortly, the maps and the knowledge of the map format is the biggest showstopper at the moment.

Kim, I know this was brought up before and at the time it did not sound like you and smu where heading in the same direction with your respective projects. But, now that the empeg has been EOL'd would you reconsider releasing the work you have done so far for the rest of us to use? It really sounds like you have done 90% of the work already and have a pretty cool system working. If the biggest piece you are missing is the map data maybe somebody else can help with that. I know a lot of people here would be greatful for your help.

-Mike

Kim, I know this was brought up before and at the time it did not sound like you and smu where heading in the same direction with your respective projects. But, now that the empeg has been EOL'd would you reconsider releasing the work you have done so far for the rest of us to use?

As pointed out before, at this stage, it's more useful to find someone who could help with the map data and test the program in other environment to find out how it would work. Then it would already be one step closer to build a package that other people could try out.

Believe me, it's more than 500kb of source code, kernel modifications, custom partitions and other changes here and there, and it still needs work to have it in condition where other people could use or benefit from it -- and the maps are the first thing.

Releasing the code is an option too, but that would require a lot of preparation and time to make it suitable for that. And as far as there are no maps or format knowledge available, the source is not going to help getting it running. Surely, you could rip some code and hack a simple GPS coordinate viewer, but what's stopping doing it already? I've posted the kernel modifications for adding a screen and audio overlay with the player application, and for anyone who has intermediate programming skills, it does not take too long to write a simple app to read NMEA ascii strings from GPS receiver (thru serial port) and display those on the screen.

Kim

Hmm... Well It would make sence to me for everyone to work together to get something setup since it seams like there is a bunch of seperate projects all over the place. I dont have much of a clue on programming anymore as its been a long while since i've done in (im waiting for some of it to come back to me), but I surely am willing to test anything anyone has. I still havn't found my GPS so im probobly going to be buying a new one, just have to figure out what one.. any suggestions?

-Greg

Intresting you are looking at GPS nav stuff i am looking forward to the next OEM to pop out

This has probably been said somewhere else, but for us US users, the US Census Department puts out all the data you could ever want. You can download their database of addresses, streets, landmarks (i.e. airports, stadiums, etc.), and all that jazz. They also give you a nice little 309 page manual for how all the information is presented, etc.

You can check it all out at:

ftp://ftp.census.gov/pub/geo/www/tiger/tiger2k/

Just keep in mind that ALL the maps for the US are over 2 gigs.... you may want to play with this on a city by city basis...

This has probably been said somewhere else, but for us US users, the US Census Department puts out all the data you could ever want. You can download their database of addresses, streets, landmarks (i.e. airports, stadiums, etc.), and all that jazz. They also give you a nice little 309 page manual for how all the information is presented, etc.

This looks good... I recall visiting on some Tiger/Line pages but back then it didn't fascinate, but I bet it was before the Tiger 2000 data set was released.

I roughly read the tech spec yesterday, and it seems to have nice amount of information available. However, I was still wondering the following:

a) Does it provide valid one-way street information? I saw there is some kind of feature field which had N,S,E,W type of info, but can that be used reliably to determine which way you can drive the road?

b) There didn't seem to be any road specific speed limits. Could the road type (street, road, avenue, etc) be used as such? How well those reflect to the speed limits/average driving speeds?

I'll take a deeper look into the tech spec and the data as soon as I have time, but meanwhile, is there anybody in the US with a GPS receiver (which outputs ascii NMEA sentences) who could be able to gather some log (preferably from the streets, while driving) and sending it to me?

Kim

Hi Kim.

I looked at the Tiger2000 documentation as well. I stumbled about this (at page 5-6 and following):

Coordinates in the TIGER/Line® files are in decimal degrees and have six implied decimal places. The positional accuracy of these coordinates is not as great as the six decimal places suggest. The positional accuracy varies with the source materials used, but at best meets the established National Map Accuracy standards (approximately + ⁄– 167 feet) where 1:100,000- scale maps from the USGS are the source. The U.S. Census Bureau cannot specify the accuracy of feature updates added by its field staff or of features derived from the GBF/DIME-Files or other map or digital sources.

Thus, the level of positional accuracy in the TIGER/Line® files is not suitable for high-precision measurement applications such as engineering problems, property transfers, or other uses that might require highly accurate measurements of the earth’s surface.

Despite the fact that TIGER/Line® data positional accuracy is not as high as the coordinate values imply, the six-decimal place precision is useful when producing maps. This precision allows you to place features that are next to each other on the ground in the correct position, relative to each other, on the map without overlap.

Now I'm wondering: A +/- 167feet accuracy (about 51 meters) isn't even as good as GPS is. And around my house, 167feet is surely more than the space between two parallel streets.
I guess this could be corrected with the aid of the user (like the CityMaps and RoutePlanner apps from www.palmtop.nl are doing it), but how often would that be needed on long distance drives?
I am still trying to find out how much efford (money and contract wise) it would be to license the TeleAtlas data format. Those maps are far more accurate (within the 10meter range) and available for almost any country in the world (with differing detail levels though).
Anyway, let me drop a word on why I even investigate nav software development while you obviously have a pretty mature application done: You only released some teasers, but almost no specific until recently, and I didn't see that changing. Now that you seem to be willing to release your application (be it open source or not), I am doing all I can to assist you.
If I could collect some GPS positions of street interconnections, along with information about those streets (like direction, speed limit, name), would that be enough information for you to create a suitable map? If so, I would be willing to collect that information for the area of the next owners meet (about a square kilometere or two), so that your application could be demonstrated there.

cu,
sven

Now I'm wondering: A +/- 167feet accuracy (about 51 meters) isn't even as good as GPS is. And around my house, 167feet is surely more than the space between two parallel streets.

As I interpret the specs ("This precision allows you to place features that are next to each other on the ground in the correct position, relative to each other, on the map without overlap.)" it is saying that the placement of the streets and other map objects will be accurate relative to each other; but that you couldn't use any single point as an absolute position. Thus the map itself would be correct, but the corner of Third Avenue and Elm Street might not actually be at the exact lattitude/longitude specified.

This shouldn't offer any hindrance to navigation.

tanstaafl.

Now I'm wondering: A +/- 167feet accuracy (about 51 meters) isn't even as good as GPS is. And around my house, 167feet is surely more than the space between two parallel streets.

True, this could be a problem. Though, it would be interesting to see whether this means more like a constant offset or a varying +/- 50m error in the coordinates. This is one reason why I was asking for a GPS log data so that this could be verified.

I guess this could be corrected with the aid of the user (like the CityMaps and RoutePlanner apps from www.palmtop.nl are doing it), but how often would that be needed on long distance drives?

I don't know how the software works that you refer, but I'd think that the error won't grow over distance. I mean, it's not relative to any particular source position.

I am still trying to find out how much efford (money and contract wise) it would be to license the TeleAtlas data format.

TeleAtlas has one internal data format (called MultiNet) from where they produce maps for different navigation hardware vendors. All navigation disks that they sell are in vendor specific format (i.e. Audi, Blaupunkt, Mercedes, Mannesman/VDO) and I believe that those are proprietary formats and maybe even TeleAtlas won't have the right to give out the specs. But, as far as I know, the MultiNet data is in GDF format for which the specs should be freely available. They are also selling the MultiNet data but the question is how expensive that is. Maybe you could figure it out? TeleAtlas has an office in Germany, also.

If I could collect some GPS positions of street interconnections, along with information about those streets (like direction, speed limit, name), would that be enough information for you to create a suitable map? If so, I would be willing to collect that information for the area of the next owners meet (about a square kilometere or two), so that your application could be demonstrated there.

The data that I now have includes street name, road class, street numbers, one-way/two-way info, city name, zip code and a list of coordinates per road. That suffices for quite long. But how were you thinking to gather the data, somehow manually?

Kim

in addition to the Tiger data set, the USGS also publishes vector maps in SDTS format at varying scales. These can be combined with the Tiger data to produce more accurate maps. The problem is that the SDTS maps don't have street name information (they do have highways though and other useful info, like number of lanes. I believe one-ways as well). But, each vector has an entity ID that could be cross referenced with the Tiger data, which a friend and I are currently attempting.

Do you have any idea if the inaccuracy appears only as a constant offset in the coordinates or whether it is more or less random +/- 50m error? I think this is the key point, because a constant offset can be handled with the software but a random error within the mention margin is harder to handle.

Kim

I don't know. Most other providers of mapping data hark on this point, though, that the Tiger data isn't accurate enough. Most I've seen give a resolution of 5-10 meters. For US data, the ADOL data is more accurate (8 meters). Plus pretty cheap too, $10 a zip code. License agreement doesn't seem too restrictive for the purposes here.

Here is a sample map for Concord, NH

Actually, now that I think about it, $10 a ZIP can add up unless you just want to focus on one area. For example, in the Bay Area I can easily see 40 ZIPs...

In reply to:

---

(BTW: The Street Atlas CD should be usable once we get a converter written, the specs are available)

---

Could you point to where the specs are available? I'm not having much luck on my own with Google and I'd be interested in moving this data into a format we can use.

Hi.

That 167ft tolerance should be a more or less constant offset for a large area (such as a minor city (by american standards) or at least a few square kilometers, and only little different for the next part of a map. They say that the position is in degres with 6 significant digits, so this would be about 11cm (4") of tolerance between neighbouring landmarks (like streets or buildings). This is pretty good. I am just wondering how fast the offset (that is up to 167ft) might change.
However: My major point was that it would be difficult to correctly locate the current position on the map if the software doesn't already know the current offset (at least almost correctly, like within 1m or 2m/3ft or 6ft). In my case, my home is in a street that is a dead end, but within 167ft there are two parallel streets that both aren't dead ends. So if the software was assuming the wrong street, it would give totally incorrect instructions. I was just saying that the software would need some interface that allows for easy adjustment of the current offset.
Citymaps and RoutePlanner are using a very simple approach: You tell the software that you want to adjust the offset now, and it displays the part of the map that contains the current position (without correction). You can then move that map around and/or search for a street and finally just click on the position that you think is correct. The software than simply applies the offset you thereby entered to any following operation.
IWBN if the software was automatically compensating changes in the offset by snapping to the street you are currently driving along.

cu,
sven

[Street Atlas format available?]

Hi.

First, I confused the name, I intended to say TeleAtlas, not Street Atlas. Second, the format specs are available, just not to the general public. In other words: One has to sign a contract to get those specs, and they might even charge some (unknown to me) amount for that.
However, here are some collected links about map data (mainly providers of such data, some info about different formats should also be in there):
AND International Publishers
Map Projection Overview
Map Projection Overview
MapQuest Partners
SDAL Format
Tele Atlas

cu,
sven

As far as I saw it, the GDF specification is available to the public. By googling I found something that appears to be a format documentation. I did not bother to read it yet as it is very large.

Anyway, I mailed TeleAtlas to ask them for a price quote on their CDs.

Till

The road type won't tell you what the speed limit is, but you can make reasonable guesses from it.

Residential Street - 35mph
Avenue - 45mph
County Road - 50mph (In Texas, bump this up to 120mph)
Highway - 60mph
Highway with improved shoulder - 70mph
Interstate - 70mph

greg

So has anyone been able to bring up anything such as speed direction up on thier empeg yet? Just curious.
I just thought of another thing... i wish my empeg had came with some good empeg stickers like somepeople have ; D

-Greg

So we have a facility to calibrate it when you need more detail. If you notice you're on Elm and 1st but the empeg says you're on Ross and 1st ... tell it where you really are (the corner of ...) and it'll smarten up for you.

g

Talk to Rob or David at support in the UK - they may still have some empeg stickers there!

Greg,

If I can remember where I put my EMPEG sticker it's yours.

Bob

Cool ; D My car install isn't complete without an empeg sticker next to my subs or something. hehe.

Im still looking for a gps unit to replace my old one, im woundering how well the Rand McNally gps works. Its fairly inexpensive and will also work with my laptop. I think I found it for like $99. No idea if it will work on the empeg once something is developed.

-Greg

Cool ; D My car install isn't complete without an empeg sticker next to my subs or something. hehe.

Maybe you could get a blinking neon sign for the top of the car that says, "Attention: Stereo Thieves -- Look Here!"



tanstaafl.

Since 99% of sterio theives know what an empeg is right...... Now that I think of it a neon sign would be cool, j/k.

-Greg

Slowly drifting back to the original topic...

Since nobody commented on gathering GPS data from the US for testing the maps suitability for the purpose, I start to wonder how many people out there would even be able to test the software if one would be available. Obviously, there are lot of people interested on the navigation but in order to try it out, it means that one must be able to connect a NMEA capable GPS receiver to empeg in car and have moderate knowledge of the Linux/empeg environment to get stuff running.

I could spend more time looking at the specs and see if I could come up with a proper converter for the Tiger data, but only if I know that some people out there might actually be able to try it out.

Kim

Since nobody commented on gathering GPS data from the US for testing the maps suitability for the purpose, I start to wonder how many people out there would even be able to test the software if one would be available.

What exactly do you need? Long and lat for a few intersections or something more detailed? I have a NMEA capable GPS, plenty of linux knowledge, two empegs, and I really want to see this project happen. I am not particularly familiar with mapping software and I can't really do much with C code beyond compiling it, other than that just let me know what you need.

-Mike

What exactly do you need? Long and lat for a few intersections or something more detailed? I have a NMEA capable GPS, plenty of linux knowledge, two empegs, and I really want to see this project happen. I am not particularly familiar with mapping software and I can't really do much with C code beyond compiling it, other than that just let me know what you need.

Okay, what I was looking for is a five minute long (or longer) ascii log of NMEA sentences which are "recorded" while you drive the car (and later can tell the city and some street names). The idea is that I could use the log file as an input to the navigation software so that it simulates the situation of driving in the US. That way I would have a chance to test something here without going to the US for gathering the GPS data .

If you have a laptop, it probably is easist to plug the GPS receiver to the laptop, open a terminal program and save the output to an ascii text file. It is also possible to do with empeg, but then it requires a software to do the logging and saving it into a disk and a way to launch the program in car.

Note: According to the Tiger tech spec, the data is in North American Datum of 1983 (NAD83), so the GPS receiver should be set to the same datum.

Kim

I've never seen any abilities of a GPS device to set the datum, is this usually a hidden option?

Greg

The only GPS device I have right now is for my Palm Vx ... I'm hoping to at least get a cheap one for tinkering within about six weeks.

Greg

I've never seen any abilities of a GPS device to set the datum, is this usually a hidden option?

It should be a visible option. Atleast my Garmin has a list of datums I could use, and I have seen instruction manuals of other GPS receivers which do the same. If the GPS receiver is supposed to work world-wide, it should have user replaceable datum because different countries usually use different datums due to different geographical location.

Kim

Every GPS has to be calibrated on startup, they have to be given a date and an initial position to find out where exactly they are. From that point on, given that you do not travel too far and not have the unit turned off for too long, the GPS will recalibrate itself after that.

GPS' where also a major issue back when Y2K struck as everybody was worried that the internal clocks of GPS navigated weapons would not be Y2K compliant and due to modified navigation navigate somewhere else than their wanted target.

GPS has its own timecode, much like the Unix timestamp, which "rolled over" last year, if I remember right. GPS units track their internal date and time from the initial date and time and the GPS timecode.

So actually, since Y2K, GPS units had to survive two roll-overs, but nobody really noticed I guess.

Till

of course the problems people were expecting were under the assumption that the software used to set target information for GPS guided weaponry would be updated and not the bombs/missiles themselves.

More likely than not, both ends of the issue are back in the 60's still. They proabably have some Air Farce guy doing date translations on the fly using an abacus, while whipping around Afghanastan at Mach 2.

Okay, what I was looking for is a five minute long (or longer) ascii log of NMEA sentences which are "recorded" while you drive the car (and later can tell the city and some street names). The idea is that I could use the log file as an input to the navigation software so that it simulates the situation of driving in the US. That way I would have a chance to test something here without going to the US for gathering the GPS data

Got it. I will get you something tonight. I am not sure if the datum on my GPS (Garmin eTrex) can be adjusted. I will have to check that.

-Mike

Got it. I will get you something tonight. I am not sure if the datum on my GPS (Garmin eTrex) can be adjusted. I will have to check that.

I just read that all Garmin receivers default to WGS84 which is very close to NAD83 and the difference is 2m maximum, so it should be no problem.

If you get something grabbed, you can send it to me via email (after removing the nospam from the address).

Kim

I have a garmin etrex also. The datum set options are under the "units" menu on the setup page.

.... pseudo gomer pyle voice.... Well gooolly, there sure are a lot of datums there....

PeterK

I found this today on my HD it was some gps soft. Im not exactly sure what it does cause I havn't gotten a change to look though it. *I did not write this* I had this from back in the day when i had a computer in my car for a mp3 player. I think this is the software i was messing around with to tell direction, etc...
Hope this helps. I can't test it cause I can't find my gps and im in the process of looking for a new one.

-Greg

I've been looking at the Tiger data and the precision. With mcomb's GPS log, I've been able to determine that the accuracy compared to coordinates given by GPS is anything between 0 to 40m.

I'll attach a rather big GIF file which contains a piece of map generated from the Tiger data combined with mcomb's GPS log. The green lines represent the roads and the red line represents the output of the GPS receiver.

To give you idea of the map scale, one pixel represents about four meters.

Kim

Hi Kim.

That looks promissing for me. It seems to be possible to automatically adjust the current offset between map and GPS positions, given that the staring point is corrected by hand.

cu,
sven

Well I've got the linux experience and a Garmin eMap.

Not sure what I can use for Maps in the Uk - I do have the Garmin Maps but not sure what format these are in!

Great project - let me know how I can help!

Regards

Paul

Hi,

If you need grabs from Denmark, I can gather several as I drive around a lot.

How's it coming guys?! I've got some $$ burning in my pocket for a GPS reciever and probably a few more $$ left over for the developers that write the software to use it.... =]

Just curious why it got quite all of a sudden on this thread... i was so eagerly following.

Hehe. I was JUST going to post then I saw that loren did. I bought a Garmin Etrex from BestBuy today after tons of trouble from Amazon.com and made a data cable with a credit card and some wire. I am interested as well on how the project is going. I am also willing to test ; D

-Greg

Just curious why it got quite all of a sudden on this thread... i was so eagerly following.

We've been running various experiments with mcomb to find out how the biggest problems could be overcome.

Initially, we started with the Tiger data (that is freely available for the whole US area). The problems with that data is that it's fairly inaccurate and it's missing one-way info/turning restrictions.

Recently, I've looked into the USGS DLG data (also freely available for the whole US area) which has better accuracy and has one-way info. But since the data lacks street names and numbers, it is essential to combine these two maps together. However, the map conflating seems to be quite problematic. I can get about 80% of the streets mapped correctly, but the rest gets mapped to incorrect streets.

This is a common problem in map conflating and without a relatively complex algorithms and manual tuning afterwards, it is hard to get good results.

Read more here and here.

Another problem with the one-way that can be extracted from the USGS data is that I haven't been able to figure out which way a road is one-way. If a road is marked as one-way, it's not necessarily always one-way towards the same direction as the data is digitized.

Kim

I guess it would be more worthwhile to find out what kind of agreement Smu could get with TeleAtlas, as most likely everyone will pay for a data CD.

Till

Hmm. Just an idea.... Would it be hard to get information from retail mapping software? I didn't want to say M$ streets and Trips but i have the licensing info here so I thought I'd just mention it. Anyways, licensing is really cheap if bought in volume. Im sure there are other mapping software out the that has better maps and M$ usually over charges so this could even be cheap... but I dont know if you can read from those map or not.... the m$ maps do have a feature to export to a win-ce or palm device.. so even those maps could be used. Here is the m$ info:

Microsoft Open License Pack (MOLP)
Microsoft® Streets & Trips 2002 Win32 English OPEN Level C OLP C

Version: 2002
Part Number: B17-00036
Environment: 32-Bit Win
Media: Non-specific
Pool: Applications
Level/Unit: Level C/1
Estimated Price: $28.00
Notes:

-Greg

We've been running various experiments with mcomb to find out how the biggest problems could be overcome.

My experiences so far is that the tiger data by itself is not accurate enough for route planning. It lacks information on one-way roads so it constantly does stuff like tell you to go up freeway offramps. I have also had problems with dead ends that the current system assumes go through. I have also been meaning to ask Kim if there is enough data present to allow for easiest vs fastest vs shortest route selection. I believe the current algorithm tries for shortest where I would generally prefer easiest (stay on freeways as much as possible, etc) or maybe fastest (quickest route assuming you are going the speed limit the whole way).

But, and this is a pretty big but, the tiger data and Kim's nav system is very helpful as a supplement to written instructions. It is great to know what street you are on, what address range you are in, what direction you are heading, and be able to use the moving map as a reference if you sort of know the area. It is enough to get you around with crappy directions or no directions in an area you are sort of familiar with.

Hopefully Kim will be able to pull some more info out of the USGS data or someone will be able to come up with another data source.

Anyway, after using Kim's software for a couple of weeks I am still very impressed. An accurate datasource still seems to be the biggest missing piece.

-Mike

Kim, Any chance of being able to try out what you have or a demo or something? I completely understand if not but I thought I'd ask. This "demo" would be tried without bugging you of couse (like asking how to install it, why something isn't working, etc) cause I know that would probobly be annoying.

:::Crosses Fingers ;D
-Greg

the tiger data and Kim's nav system is very helpful as a supplement to written instructions. It is great to know what street you are on, what address range you are in, what direction you are heading, and be able to use the moving map as a reference if you sort of know the area.

You know what? This statement got me thinking...

I would still pay for that functionality alone. I mean, even if it didn't even attempt to route-plan for me... If I simply had a moving map on one part of the screen, and a arrow with range/bearing to my destination on the other part of the screen, I would love to have that on the empeg display. I could still get anywhere I wanted to go with that kind of data.

I know that there are more sophisticated nav systems already available which can do proper on-the-fly route planning. But those require room in my dash for the large screen, something I no longer have now that I've got the empeg. So until I can buy an integrated 1.75-din NAV+MP3 device, I'm going to be content with whatever I can get on the empeg.

Now here's something else that just occurred to me. The Tiger data doesn't have enough detail to do proper route-planning. But if I log into MapQuest.com, it will route-plan and will give me proper directions (well, most of the time. I've seen it glitch before).

Of course, we can't get our hands on the dataset that MapQuest.com uses, so it's no good to us.

Or is it...

Let's think for a second. Before we leave on a trip, we usually know our destination, correct? Well, what if we punched it in to MapQuest, have our (hypothetical) Windows client software screen-scrape the HTML that MapQuest spits at us and extract the route-planning instructions. Click a button on this client software and it automatically squirts the route into our empeg. That route is fed to Kim's software which simply parrots the MapQuest instructions while using its internal Tiger data to verify we're on the right road and display our progress.

The only thing we'd lose is the ability to accurately route-plan "on-the-fly". But if we can punch in an address and we've still got the moving map and the range/bearing data, that's still useful for on-the-fly calculations.

Of course, where the Tiger data and MapQuest data differ, there will be glitches. Okay. And it's a bit of a rube-goldberg solution for something which should be much slicker. But until we get our hands on better map data, it's at least something, right?

Hell, I'll even volunteer to write the screen-scraper, that's pretty simple. I've already got software in VB that does this sort of thing.

Surely I can't be the first person to have thought of this?

Good call Tony. I was thinking the same thing but was trying to thing of the best way it would work before I posted. There are many sites that tell how to program simple apps like your talking about. I was looking around and even saw a scaled down version that gets your destination maps from mapquest then puts waypoint on your etrex. The same thing could be done on the empeg. A sort of waypoint database. The cool part is that once those waypoints are in you empeg you could have the program make a list of them so you could use them in the future again.

-Greg

I was looking around and even saw a scaled down version that gets your destination maps from mapquest then puts waypoint on your etrex.
>

Wow, so where do I drop off my firstborn for a port of that to the empeg :P

I'll pay for shipping and everything!

You know what we should really do? We should each get a GPS and toodle around our own town gathering data and then transcribe it. Then release it ``open source'' and let everyone who needs street data use it instead of having to deal with all this data. There's bound to be a freely available analog street map from the US Govt. (maybe the USPS?) that we could compare against. I realize that it would be a big pain, but it would be a boon to the community at large. I'd start doing it myself if I had a GPS or some money with which to buy one.

I'd be willing to do it. There is also a bunch of small apps out there with maps. Im not sure how accuarate they are though.

btw: The Garmin Etrex comes out to $100 with standard shipping if you search for a amazon.com $5 of any puchase coupon. Then all you need is to make/buy a datacable and your set. Amazon screwed me twice though so I was forced to buy it at Best Buy for $30 more.

-Greg

Unfortunately, I don't have a job right now, so just paying my rent is hard. Frivolous purchases have gone by the wayside. Otherwise, my response to the recent poll elsewhere would have been ``I'm buying many more CDs now''.

There are some maps available at Mapopolis.com ... they've got maps for palm pilot software ... their platinum plus gps maps are $10, and they're from NavTech ... accurate enough to do door-to-door directions, streets and addresses, water, landmarks, etc...

Do you think you can reverse engineer one of these into something usable? I've got one of their older free maps of dallas, I could send it to you if you like.

The maps are of US and Canada only right now ...

Also, I've got Microsoft Streets as well as Rand McNally's Streetfinder maps. Both of these have GPS support and driving directions. They also know about one way streets.

If you like I can send you some of this data, or a whole ISO image if you prefer.

Greg

While reading Beowulf and watching Lord of the Rings I thought of something. Does anyone know how hard it would be to read from the maps that are used on a palm? I was thinking something could be made just how the palm works. Most people who use GPS on the palm dont have a huge ram card with every map on it, instead they just have use their desktop computer to choose the map they want and then sync it. The same thing could be done with the empeg. I've seen this software VERY cheap. Even some around $10-$30. M$ Streets and Trips (which is a bit more expensive) has that same option to export maps for a palm. Here is the info from Streets and Trips 2002:

Microsoft Pocket Streets 2002: Easily create and download maps to your Windows CE 2.0 or later palm-sized or hand-held PC to take on the road with you.

-Greg

I haven't upgraded to Streets & Trips 2002 yet, but I got Streets and Trips 2000 for like $10 after rebate or something. Pocket Streets was (is?) a free download. Pocket Streets 2000 is on my Pocket PC now and it works pretty well. I don't think the pocket version does routing though , just map viewing and finding locations and stuff AFAIK. I think you need the desktop version to do routing.

Yeah, what I was thinking was to take those exported maps that were meant for the palm and put them on the empeg and have the gps software on the empeg read them. The empeg gps software would do the routing according to the map.

-Greg

Here is the map file that comes out when you "Export map for pocket streets " if anyone wants to try to read it. It should just be a map of some streets in my neighborhood. The file is zipped to be able to attach it in here.

-Greg

I guess you can get the maps for free. My whole state is a 200k file.

http://www.microsoft.com/pocketstreets/mapdownload/MapDownload_EN.html

-Greg

These are all good ideas, but I think that the problem with all these maps is that they are proprietary and their format is not freely available. Thus, kim's software won't be able to make use of them.

Sean

...and if you did manage to reverse-engineer them, Gates' minions would be at your door within minutes.

Not really.. They can't do anything about Star Office reverse-engineering the Word .doc format... This would be the same thing.

I looked at the free map file for my area, and with a little data processing some of the information could be figured out. Unfortunately, there's a lot of unknowns that have to be figured out for any of the data to be useful. Probably a comparison between two different maps would be needed as well as a lot of guesswork..

They can't do anything about Star Office reverse-engineering the Word .doc format... This would be the same thing.

Eh... Not so fast, my friend. DOC, XLS, PPT are just file formats. What we're talking about with Streets & Trips is *data* in a file format. That data itself likely has some kind of copyright attached to it, and, I'd bet, was purchased by Microsoft from some other company. That company would likely be the people who would sue you, not Microsoft.

It seems that reverse-engineering file formats doesn't raise many eyebrows at Microsoft, and the law gets really grey when stuff like that happens... But taking proprietary *data* and reverse-engineering that, I think that's a little different. We'd need a team of lawyers to sift through the Streets & Trips EULA, but I'd imagine there's a clause in there prohibiting using the data for anything other than their software... Whether it would hold up in court is questionable since EULA's always have at least one ridiculous non-enforcable and downright illegal clause in them, but I would bet the map data is protected more strongly than the DOC format, which is just a format.

You're right.. reverse engineering the data format isn't illegal, using their data would be.. Knowing what's in the data isn't really useful though, if you can't use the data you figure out.

Looking at the data in the Pocket Streets downloadable map files, I wouldn't even attempt to reverse engineer the files. The stuff from mapopolis are easy to figure out.. looks like[coordinates, other info, street name] chunks, where the Pocket Streets info is stored much differently..

What about this, a gps app with moving maps that was written for an ipac handheld running linux. http://cvs.handhelds.org/cgi-bin/viewcvs.cgi/apps/pygps/
; D

-Greg

Need to get python running on the empeg.. or someone to port it. (I've done some python hacking in the past, but am not an expert..)

Looking at the code, it seems to be simply a program that takes a map image and selects a screenful depending on where the GPS says you are.

Edit: I suppose you could do the same thing on the empeg, though the resolution doesn't help. You really need a map-render as you want to show what's in front of you, not just a a section of the map around you. You'd have to limit it to a 32x32 square to get equal coverage.. If you render, you can do a 64x32 square of the road infront, with compas/location information on the right half..

Hmm.. this is the final thing i've seen that comes close to what were trying to do. http://fritz.ganter.at/software/
, GpsDrive.

-Greg

Well, this does the same thing.. It takes an image and displays the GPS data over it.

If you want to start with something simple then have a look at this software http://freespace.virgin.net/patrick.fox/codriver/ , note that it is designed to run on Psion 5MX but I thought the concept was quite good.
It worked by taking a file or files containing a list of directions with distances from the start point and as these distances were reached the display would change. The data was taken from MS Autoroute or the Psion Streetplanner and Routeplanner software but I guess it would work with any text file containing the data in the correct format.
Obviously it can't recaculate on the fly so if you take a wrong turning it doesn't work until you can tell it where you are on the original route, but for something basic I thought it was quite good.
Ray

Interestingly the empeg interface was originally going to be scripted in Python, but they had to give up on that idea when they had problems getting it to run reliably. If I remember rightly it had problems with the realtime scheduling that the empeg uses.

There were issues with priorities, multi-threading, and memory footprint/mlock() issues.

Hugo

That depends. If the EULA indicates reverse engineering is illegal, and you agreed to it at time of use, then it is illegal.

Calvin

Unless the EULA is illegal, and there's been more than a handful of instances where that's occurred recently. EULA's have all sorts of crap in them.

None of the map files I downloaded had EULA's attached to them. The only document I found was on microsoft's website, but that was about the site itself. There was no requirement that I had to agree to it to download the maps. So even if the EULA said I couldn't, I wasn't bound by it.

Hi.

I wanted to post this earlier today, but the PC I was working on wasn't fitting the BBS's requirements (probably the missing reverse DNS resolution).

I didn't get any valuable feedback from TeleAtlas yet. I think they won't come up with a deal that was in our range (below 250$/CD), so I think the only way left would be to contact BlauPunkt (the copyright holder on the navigation-CD format specs) and to get a license to use their navigation CDs (which are sold in different formats for the US and Europe at least, like Rob found out the hard way). However, I will be honest: I don't have the time to find the right contact at Blaupunkt and I certainly don't have the time to negotiate a deal with them. So if there is any volunteer: Please, please go ahead.
I will stand by my promise to try and negotiate a deal with TeleAtlas however, I will find the time to do that. But like I said before, I don't think this will turn out well. As it seems, the cost will be so high that the rather few people who expressed interest in this project will not be interested in it. It seems as if the costs would be at about 500$/CD, which is certainly to high for me.

cu,
sven

Hmm, I can't seem to find anything else. For 500 i'd almost rather get a built in gps with a screen ; / Hopefully we can find something cheap.

-Greg

Hi.

I really think the best bet is to get a license to use the BlauPunkt CDs. They are sold worldwide (though using different formats, but still in a format defined and copyrighted by BlauPunkt), they can easily be bought by the end user, they have (rather) complete and exact data. Also, we certainly aren't any kind of competitor to them. I guess if we would throw some money together and signed a NDA, we _could_ _possibly_ get a license to do this.

cu,
sven

Kim.. anyway I could get you to send me over a copy of something that just shows simple stuff like direction, etc on the empeg? I just wanna get everything configured in my car '; )

-Greg

What are you guys using to open and view tiger data? I need to open it and combine it with other data.

Thanks,

Sean

I've always just used their web site for viewing the maps ... I'm totally unfamiliar with how to examine the file directly.

My guess on combining it would be to have an application savvy enough to change directories/files to the new map once it reaches the end of the previous.

g

Ive found some companies that sell the data in usuable form already. I can view some road data here: http://edcnts14.cr.usgs.gov/Website/store/viewer.htm , but I can only download the national land cover info and elevation data.

Sean