Hi all,

starting a new thread for this so that the main thread is not cluttered up.

I got a reply from TeleAtlas but that was only a brochure of how cool they are, no prices. I wrote them back, will see what happens.

Anyway, a quick websearch revealed that map CDs in GMF format are publicly available. For example, http://www.fugawi.de sells the TeleAtlas CD in GMF format for Germany for 78 Euro. They have one version that seems to be feasible for car navigation.

They say that the maps are also available for other countries, I don't know about the states but if one can get GMF data in Europe, one should be able to get it in the states as well.

Till

Hi Till.

First: Congratulations, you got more of a responce from teleAtlas than I got.

You are right that GMF data discs seem to be easily available. BUT if I read the (german) discription of those maps that I found at http://www.poly-electronic.ch/cd-karten.htm correctly, those aren't intended for real navigation tasks in the way we want it, but rather those are for moving map applications (read: rasterized maps, not vector based). Also, the map format doesn't seem to be well documented.
GDF maps would be different though, they are really well documented. Rather hard (or expensive) to get, though.

cu,
sven (just started working his way through the GDF documentation)

Damn, then I was wrong about the formats and mixed them up. They say they are selling Shapefile and ARC formats too, is that importable?

Also, the one CD that I found in that shop above was explicitely made for car navigation, it has all the necessary street information, even including house numbers.

Till

I mixed it up again. http://www.fugawi.de/TeleAtlas-Karten-Deutschland.html states that the data is in GDF format, of which the format is available. Also, it says that it is usable for GIS, for which a specification seems to be available at www.opengis.org.

Well, I am doing research here without really knowing what is needed, but it seems that the data format on the CD is a stanrdard format.

Till

HI Till.

http://www.fugawi.de/TeleAtlas-Karten-Deutschland.html states that the data is in GDF format,...

Where? I only see them stating that they are in GMF format. Oh, wait, no...
The Germany map seems to be the TeleAtlas-multinet version (GDF format) while the European map CDs seem to be GMF.
Oh no, wait,...
Damn, those people at fugawi.de need to get this straight, the CD description says GMF, while the documents regarding the contained countries all say GDF. How is anyone going to understand what the CDs actually contain?
Oh well, they say those are TeleAtlas multinet, so according to TeleAtlas themselves, they should be in in both GDS-AS and GDS-AR formats.

Kim: Could you import those CDs into your system? Or actually write a conversion program that takes a user's CD and imports that?

cu,
sven

The Germany map seems to be the TeleAtlas-multinet version (GDF format) while the European map CDs seem to be GMF.
Oh no, wait,...
Damn, those people at fugawi.de need to get this straight, the CD description says GMF, while the documents regarding the contained countries all say GDF. How is anyone going to understand what the CDs actually contain?
Oh well, they say those are TeleAtlas multinet, so according to TeleAtlas themselves, they should be in in both GDS-AS and GDS-AR formats.

You mean GDF-AS and GDF-AR .

Kim: Could you import those CDs into your system? Or actually write a conversion program that takes a user's CD and imports that?

Should be possible. However, consider the following:

1) GDF format models intersections and junctions as own entities. At the moment, I don't have support for this, everything is based just on line segments which define roads.

2) GDF format supports multi layered data, my system doesn't. But it should be possible to only use the highest detail layer.

3) I have never tried much bigger than 80 square kilometer maps at once, and I don't know exactly how the data is organized, so some manual splitting might be needed.

As with the Tiger data, if someone can provide me a chunk of map data in GDF format and a GPS driving log around the same area, I can see what I could do.

Kim

In reply to:

---

As with the Tiger data, if someone can provide me a chunk of map data in GDF format and a GPS driving log around the same area, I can see what I could do.

---

There is a demo download at the TeleAtlas site that provides GDF-whatever data of a small area in South Germany, namely Schwabach.

Anybody reading this board who is from the area of Nürnberg / Stuttgart / Frankfurt / Regensburg? For me, it is an 8 hour drive one way...

Most other European countries have a demodownload as well, please check out www.teleatlas.com and choose "Database Products" -> Multinet -> Demo Download for your country.

Till

I have checked back again, now they added a paragraph to their CD description that it is a stripped-down version of the multinet CD that is only used for route planning, no street navigation. Well then, we have to find another dealer.

Till

Also, I found out that Map&Guide can export its maps to a vector format. Does anybody have experience with this feature? Namely, what can be exported exactly and what is the format?

Till

Hi.

I just had a talk with a TeleAtlas representative by phone. This is the information he gave me:

• The TeleAtlas CDs that get sold for navigation systems are usually in Blaupunkt format, and TeleAtlas is not allowed to give those specs away, we would have to get in contact with the appropriate people at Blaupunkt and try ánd make a deal with them.
  
• The MultiNet CDs that TeleAtlas sells are available, but they are under restrictive copyrights. Basically, you have to sign a contract that will cost a certain (to be negotiated) amount. I told him we were talking about a maximum of 1000 copies, and he said he would check that with his colleagues and come back to me via email by the end of the week.
  
• For the MultiNet CDs, there is a developers license available, BUT it is very restricted: It only provides the data for a part of a larger country (like US, Germany, etc.) or a single country like the Netherlands, and only a license to use that for 3 month. This developer license is about 550EUR, which will be refunded if a contract for the use of multinet CDs is signed.
  

Ok, this much information for now, I will keep you posted.

A question to thos who would need to buy the data CDs, how much would you be willing to spend for them? And how many of you people really want to get a navigation system for the empeg.
The MultiNet data approach certainly won't be of much use if there are only a handful of people who actually want to buy these CDs.

cu,
sven

I would be interested in paying some amount for US maps (if I can figure out how to connect my Onstar GPS to the empeg). I'm working on that now.

Hi.

Oh well, nice to hear, but how much would you be willing to pay. As far as I can tell (and the sales representative is trying to get a better deal for us), we would have to pay at least 20.000EUR total with a minimum of 40EUR per dics.
So we would be at:
40EUR (approx the same amount in US$) per disc with 500+ users
100EUR per disc at 200+ users
200EUR per disc at 100+ users
400EUR per disc at 50+ users
plus taxes, of course. And there is a one-time fee of about 400EUR per different disc (but he is trying to eliminate this). These fees include a single update of the data after approx. 6month. If we wanted more, we would have to get a different deal (which is probably even more expensive).
Ok, more details when I get the next email from him.
Oh, BTW: We would have to make sure that each disc is tied to a specific player (serial number), he just left it to our judgement in which way, and how strong this restriction is enforced.
The reason that the Blaupunkt CDs are cheap compared to this (and with next to no restrictions regarding the machine they are used with) is that it was a huge deal and Blaupunkt (and its licensees) are paying on a per machine base rather than a per disc base.

cu,
sven

I don't have a set amount in mind. Realistically I think around $100 US would be practical but I'm flexible. I guess it might be worth trying to see how many people are interested first to get a better idea of cost. It seems from the new threads that more people are gaining an interest. And with the amount of new units sold recently there might be enought people to get a reasonable price. (Waiver of the one time fee would make it easier to justify).

$100US seems reasonable to me as well. A complete integrated NAV system like this for under $250 with hardware seems a steal to me (not factoring empeg cost of course =).

I agree. Under $250 would be a steal.

Yeah. $250.

I would pay 100 Euro for the Germany CD, eventually 150. Really depends on everything, if Kim decides to open the source to his program and we can all work on it, I might even pay more if we need just a few bucks additionally to get the TeleAtlas deal.

Till

Hello!

On freshmeat I just found this project: http://www.kraftvoll.at/software/

Perhaps, this will help you with your data-problem...

Have a look,

Falk

gpsdrive is interesting but really more focuses on raster maps, not well-suited for tracking on the empeg unless you come up with an external screen to drive. I assume the aforementioned discs in this thread are vector format maps, far more useful for an application where you essentially want to give spoken or textual directions.

Hi,

i think 200 - 300 € including the Hardware (GPS-receiver etc.) would be OK for me, since i do not really need a Nav but it would be very nice, if my empeg could show me the right way just for fun... ;-)
(would need a Germany map or perhaps a less detailed Europe...)

Keep on trying...

Hi!
I would pay up to 400EUR for the whole package (gps-hardware, software and map-data).

keep it goin...

I want one.

Can someone explain how this nav system would basically work?

Haven't seen this one asked before... but does anyone know where Mapquest, Expedia, Yahoo Maps, and the like get their maps and routing info??

The GPS Drive project mentioned above seems to be drawing it's maps from MapBlast and Expedia... could we find out how they are doing it and use a similar method?

You know, it occurs to me that a properly written screen-scraper could start with existing PD map data, then feed random direction requests into Mapquest and parse its direction returns to determine things like street directions...

If you're lucky enough to be in the US, freely distributed data (can't remember if it's Census Tiger or USGS digital line graph, but I think it's the Tiger) has attributes for one-way-street-ness; They're just not always... correct.

My recollection is that the Tiger data is what Kim already tried with his software, and the lack of street directionality was a major problem.

In reply to:

---

My recollection is that the Tiger data is what Kim already tried with his software, and the lack of street directionality was a major problem.

---

I thought he said he had directionality turned off entirely at this point, but anyway...

DLGs can include fields for travel direction and speed limit. Standards for Street Centerlines explains how to use the data, however it appears to not be widely adopted. Interestingly Massachusetts seems to do something a little different and not as useful.

A few Xastir folks talked about trying to use this data to warn APRS users who were being tracked at higher than the speed limit. I'm still using Xastir in a mode where I don't broadcast, so how fast I'm going isn't being broadcast anyhow

I thought he said he had directionality turned off entirely at this point, but anyway...

Oh boy, this topic is getting old... To avoid repeating myself, read this thread. And especially the one I posted on 26/01/02.

Kim

In reply to:

---

To avoid repeating myself, read this thread. And especially the one I posted on 26/01/02.

---

Thanks; Of course now that you point to it I remember reading it (closer to) the time. Back when the first link still had its images intact

None of it seems to conflict with the comments I made on one-way-ness in DLGs.

But, ok, the comment on directionality being disabled was my misrecollection of
this

What can I say, it's not been my month.

And just in case other people come here later and don't follow Kim's links and read through that thread, his comments were:

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.

Soo.... no one commented on what i'd said... Where do those folks get their data... and how is the GPS Drive project mining it?

gpsdrive (at least around version 1.0) was just connecting to various of the web services and downloading chunks of map; The URLs can be constructed if you know where you want to look at.

So... question to Kim and smu... Could this same data be used/mined for the empeg nav project??

It would require a net connection, or knowing where you're going to be, and it'd still be wrong. You're missing what all the people who point at gpsdrive keep missing: it uses raster maps, and the empeg's display isn't suitable for that. Any empeg solution requires vector maps, or serious software to vectorize raster maps... and you won't be running that on the empeg.

Obviously the maps would have to be mined before putting on the empeg... i didn't mean to infer that it would grab the maps on the fly. So does anyone know where those companies get their source data from?

http://mapquest.com/about/partners.adp is probably about complete for MapQuest at least, and from it you can gather they start with USGS and Census data for the U.S., and who they use for their other data.

This would imply MapsOnUs uses *only* the Census and USGS data thus far, probably because it's free, potentially through a partner to get enhancements since the base data gets out of date and of course has errors.

Those folks get their data from NavTech. Almost *all* the commercial mapping routing software in the US uses NavTech data. If you scoop the data from those sites that would be illegal. I sent one of the NavTech reps in smu's direction months ago. In terms of cost, if the project split the licensing fees with a few other groups doing the same thing, then certainly it would be very affordable.

Calvin

My contact at NavTech tells me that the TIGER data is notoriously inaccurate. That is why they have an army of drivers that drive the roads and streets of the entire country verifying the accuracy of the data. They go in teams of two, with a driver and a mapper. They ensure that one way streets are real, that changes in the road system is reflected. The updated data is proprietary. In addition, they use satellite maps and other data to make sure everything is right. Because of this army of people, the NavTech data is the most accurate but also the most costly as you can imagine. They cover north america from canada all the way down to latin america and western europe.

Calvin

In reply to:

---

My contact at NavTech tells me that the TIGER data is notoriously inaccurate.

---

It's quite obvious if you spend any time at all browsing the Census Tiger mapping site for any area you might be familiar with. And ignoring the question of the data being out of date, some USGS maps weren't accurate when they were current, either. A highway ramp near me is missing, probably photorevised away by the looks of it, despite having existed continuously since about 1952.

NavTech isn't perfect, either, but they certainly are (demonstrably) better than raw Tiger.

They ensure that one way streets are real, that changes in the road system is reflected.

Well, they must have a base camp at the Big Dig then...the road layout seems to change daily.

In reply to:

---

Well, they must have a base camp at the Big Dig then...the road layout seems to change daily.

---

One week I was in Boston for a conference. I showed up at South Station, went out and got a cab. When I came back the next week, the area where the cab stand was the week before was gone. There was a big hole there

Oh man.. the big dig... Forget having GPS if you live in that area... it'd be worthless. I've visted there 3 times in the past year and it's completely different every time. The streets there are mangled as it is...

Maybe we can convince NavTech to let empeg owners 'volunteer' their GPS tracking info that could be used to validate their maps automatically. Users could even use the empeg to 'annotate' the map...

If still looking for the right person:
I live about 100km away from Schwabach

Have you seen this site on the GDF specification yet?

http://www.ertico.com/links/gdf/gdf.htm