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