396 question

[dlevy]

I use mapsource with my 396. Occasionally an address is incorrect. That
got me wondering what is the process by which Garmin (or whoever) builds the
database? Can I submit an error to get the database fixed?

[xyzzy]

dlevy wrote:
> I use mapsource with my 396. Occasionally an address is incorrect. That
> got me wondering what is the process by which Garmin (or whoever) builds the
> database? Can I submit an error to get the database fixed?

Garmin buys the database from a third party (I think Navteq, they also
supply google maps -- see if the same error shows up on google maps)

[dlevy]

It's wrong there too. Interesting.

"xyzzy" > wrote in message
ups.com...
>
> dlevy wrote:
>> I use mapsource with my 396. Occasionally an address is incorrect. That
>> got me wondering what is the process by which Garmin (or whoever) builds
>> the
>> database? Can I submit an error to get the database fixed?
>
> Garmin buys the database from a third party (I think Navteq, they also
> supply google maps -- see if the same error shows up on google maps)
>

[dlevy]

Wrong on Yahoo maps too.

"dlevy" > wrote in message news:XgBfh.13$Iz.11@bigfe9...
> It's wrong there too. Interesting.
>
> "xyzzy" > wrote in message
> ups.com...
>>
>> dlevy wrote:
>>> I use mapsource with my 396. Occasionally an address is incorrect.
>>> That
>>> got me wondering what is the process by which Garmin (or whoever) builds
>>> the
>>> database? Can I submit an error to get the database fixed?
>>
>> Garmin buys the database from a third party (I think Navteq, they also
>> supply google maps -- see if the same error shows up on google maps)
>>
>
>

[Gig 601XL Builder]

Are we talking a block off? A mile off? Or next town over?

I've noticed that Google maps, in some smaller towns especially on not main
roads seem to look like they are estimating based off of some more primary
street. My home address shows up one block away from where it really is and
I have a XX00 address and it shows on the corner a block East of where it
really is.


"dlevy" > wrote in message news:OhBfh.14$Iz.13@bigfe9...
> Wrong on Yahoo maps too.
>
> "dlevy" > wrote in message news:XgBfh.13$Iz.11@bigfe9...
>> It's wrong there too. Interesting.
>>
>> "xyzzy" > wrote in message
>> ups.com...
>>>
>>> dlevy wrote:
>>>> I use mapsource with my 396. Occasionally an address is incorrect.
>>>> That
>>>> got me wondering what is the process by which Garmin (or whoever)
>>>> builds the
>>>> database? Can I submit an error to get the database fixed?
>>>
>>> Garmin buys the database from a third party (I think Navteq, they also
>>> supply google maps -- see if the same error shows up on google maps)
>>>
>>
>>
>
>

[Gus Cabre]

Why don't you click on http://www.garmin.com/support/ and phone them, or
just send an e-mail


Gus
"dlevy" > wrote in message
...
>I use mapsource with my 396. Occasionally an address is incorrect. That
>got me wondering what is the process by which Garmin (or whoever) builds
>the database? Can I submit an error to get the database fixed?
>

[Gus Cabre]

Further to my e-mail I have found a Garmin one that might be helpful
. 'Hope it helps.

Gus

"Gus Cabre" > wrote in message
...
> Why don't you click on http://www.garmin.com/support/ and phone them, or
> just send an e-mail
>
>
> Gus
> "dlevy" > wrote in message
> ...
>>I use mapsource with my 396. Occasionally an address is incorrect. That
>>got me wondering what is the process by which Garmin (or whoever) builds
>>the database? Can I submit an error to get the database fixed?
>>
>
>

[Gus Cabre]

Or even better, http://www.garmin.com/cartography/mapSource/errorForm.html

Finally!

Gus
"Gus Cabre" > wrote in message
...
> Why don't you click on http://www.garmin.com/support/ and phone them, or
> just send an e-mail
>
>
> Gus
> "dlevy" > wrote in message
> ...
>>I use mapsource with my 396. Occasionally an address is incorrect. That
>>got me wondering what is the process by which Garmin (or whoever) builds
>>the database? Can I submit an error to get the database fixed?
>>
>
>

[Travis Marlatte]

I work for NAVTEQ - although I am not directly involved in the data
collection for our maps.

The location of addresses is derived in a couple of different ways and it
depends on the area as to how accurate it is. To save on space, the range of
addresses for a block is usually all that is present. The location of a
particular address, then, is merely an interpolation of where it is in the
range. This usually results in the location being off by a small error.

Less frequently, the addressing does not follow a logical pattern. The only
solution is to identify the location of each and every address - which is
only cost effective (both in data collection and in database size) in high
volume markets. i.e. it's a balance of customer satisfaction and the cost of
the database.

Other possibilities are that we purchased data from a government entity and
it is wrong. We do validate such data but it takes time. Validating is
plain, old hitting the streets and comparing our data against reality.

And, of course, it could just be a mistake.

On the NAVTEQ website, there is a feedback section where you can report
errors. Trust me, we review each and every report. NAVTEQ's website is
www.NAVTEQ.com and the direct link to the feedback section is
www.navteq.com/updates/mapfeedback.html.

-------------------------------
Travis
Lake N3094P
PWK
"xyzzy" > wrote in message
ups.com...
>
> dlevy wrote:
>> I use mapsource with my 396. Occasionally an address is incorrect. That
>> got me wondering what is the process by which Garmin (or whoever) builds
>> the
>> database? Can I submit an error to get the database fixed?
>
> Garmin buys the database from a third party (I think Navteq, they also
> supply google maps -- see if the same error shows up on google maps)
>

[xyzzy]

Travis,

Just wanted to thank you for this information. Even if you're not
officially speaking for them, it reflects well on Navteq that you
responded here this way.


Travis Marlatte wrote:
> I work for NAVTEQ - although I am not directly involved in the data
> collection for our maps.
>
> The location of addresses is derived in a couple of different ways and it
> depends on the area as to how accurate it is. To save on space, the range of
> addresses for a block is usually all that is present. The location of a
> particular address, then, is merely an interpolation of where it is in the
> range. This usually results in the location being off by a small error.
>
> Less frequently, the addressing does not follow a logical pattern. The only
> solution is to identify the location of each and every address - which is
> only cost effective (both in data collection and in database size) in high
> volume markets. i.e. it's a balance of customer satisfaction and the cost of
> the database.
>
> Other possibilities are that we purchased data from a government entity and
> it is wrong. We do validate such data but it takes time. Validating is
> plain, old hitting the streets and comparing our data against reality.
>
> And, of course, it could just be a mistake.
>
> On the NAVTEQ website, there is a feedback section where you can report
> errors. Trust me, we review each and every report. NAVTEQ's website is
> www.NAVTEQ.com and the direct link to the feedback section is
> www.navteq.com/updates/mapfeedback.html.
>
> -------------------------------
> Travis
> Lake N3094P
> PWK
> "xyzzy" > wrote in message
> ups.com...
> >
> > dlevy wrote:
> >> I use mapsource with my 396. Occasionally an address is incorrect. That
> >> got me wondering what is the process by which Garmin (or whoever) builds
> >> the
> >> database? Can I submit an error to get the database fixed?
> >
> > Garmin buys the database from a third party (I think Navteq, they also
> > supply google maps -- see if the same error shows up on google maps)
> >

[dlevy]

Pretty kewl. Thanks for taking the time to explain.

"Travis Marlatte" > wrote in message
t...
>I work for NAVTEQ - although I am not directly involved in the data
>collection for our maps.
>
> The location of addresses is derived in a couple of different ways and it
> depends on the area as to how accurate it is. To save on space, the range
> of addresses for a block is usually all that is present. The location of a
> particular address, then, is merely an interpolation of where it is in the
> range. This usually results in the location being off by a small error.
>
> Less frequently, the addressing does not follow a logical pattern. The
> only solution is to identify the location of each and every address -
> which is only cost effective (both in data collection and in database
> size) in high volume markets. i.e. it's a balance of customer satisfaction
> and the cost of the database.
>
> Other possibilities are that we purchased data from a government entity
> and it is wrong. We do validate such data but it takes time. Validating is
> plain, old hitting the streets and comparing our data against reality.
>
> And, of course, it could just be a mistake.
>
> On the NAVTEQ website, there is a feedback section where you can report
> errors. Trust me, we review each and every report. NAVTEQ's website is
> www.NAVTEQ.com and the direct link to the feedback section is
> www.navteq.com/updates/mapfeedback.html.
>
> -------------------------------
> Travis
> Lake N3094P
> PWK

[Bill Watson]

Thanks alot for the background.

I haven't run into any significant errors so far (which is simply
amazing). I love being able to use an address to find out where I need
to go after I land.

Travis Marlatte wrote:
> I work for NAVTEQ - although I am not directly involved in the data
> collection for our maps.
>

[karl gruber[_1_]]

Why does the 396 in "Automotive" mode sometimes take me off an interstate
off ramp, and then right back on the on ramp?

Best,
Karl
ATP, CFI, ETC.
World's most hangar queeny Skywagon
http://temp.corvetteforum.net/c5/kgruber//cessnaafterwaxjob.jpg


"Travis Marlatte" > wrote in message
t...
>I work for NAVTEQ - although I am not directly involved in the data

[Mark Hansen]

On 12/13/06 10:32, karl gruber wrote:
> Why does the 396 in "Automotive" mode sometimes take me off an interstate
> off ramp, and then right back on the on ramp?

Maybe it thought the car needed gas?

;-)

[Jay Beckman]

"karl gruber" > wrote in message
...
> Why does the 396 in "Automotive" mode sometimes take me off an interstate
> off ramp, and then right back on the on ramp?
>
> Best,
> Karl
> ATP, CFI, ETC.
> World's most hangar queeny Skywagon
> http://temp.corvetteforum.net/c5/kgruber//cessnaafterwaxjob.jpg

To avoid the Cop lurking under the overpass?

<gg>

Jay B

[Bill Watson]

karl gruber wrote:
> Why does the 396 in "Automotive" mode sometimes take me off an interstate
> off ramp, and then right back on the on ramp?
>
Perhaps because there was construction of some sort when the data was
collected.

I was amazed when I was on I-85 in Durham NC. The road was in the
process of major overhauling - 2 lanes to 4, etc. It directed me off
and along a section of service road that had not been put in service
yet. The data reflected the way was going to be in a few weeks/months.

[Travis Marlatte]

"karl gruber" > wrote in message
...
> Why does the 396 in "Automotive" mode sometimes take me off an interstate
> off ramp, and then right back on the on ramp?
>
> Best,
> Karl
> ATP, CFI, ETC.
> World's most hangar queeny Skywagon
> http://temp.corvetteforum.net/c5/kgruber//cessnaafterwaxjob.jpg
>
>
> "Travis Marlatte" > wrote in message
> t...
>>I work for NAVTEQ - although I am not directly involved in the data
>
>

I can share some of the issues that I am familiar with.

Navigation systems are not running on the most powerful computing platform.
So, anything that they do is a tradeoff between response time and quality.
To find the truly optimal path between two points on the map is
computationally prohibitive.

The Route Calculation algorithm wants to find the least cost path from point
A to point B. Lease cost may be defined as quickest based on predicted
travel speed or smallest distance - combined with other possiblities like
avoid tollways, avoid highways, etc. Every road in the database has
attributes, a length and a speed. Even the intersections have tables to
indicate the "cost" to get from one branch to another through that
intersection.

Techniques are used to reduce the amount of searching that must be done but
these techniques sometimes result in far from optimal results. One of the
popular algorithms that is used searches from both the origin and from the
destination. During the search, branches are pruned off that don't seem to
be going in the right direction. This, of course, sometimes eliminates one
of the good routes. The other result is that sometimes the two searches meet
but because of the ordering of the search paths, the first meet is not the
best but somehow wins.

Of course, the other problem is personal preference. My sound-bite is "only
use a navigation system when you don't know where you are going and you will
be please with the result. Use it to get to the office and home every day
and you will soon conclude that it couldn't route itself out of a paper
bag." It's going to be a long time before navigation systems will cut down
that side street to avoid that typically long light.

To address your specific question of ramp jumping, fundamentally, the
algorithm believes that getting off and back on is shorter (or faster) than
staying on the highway. I have seen several causes: 1) the user has chosen
to avoid highways but there is no other way to get there. But, while
determining the path, the algorithm mistakenly is still trying to avoid
highways wherever it can; 2) for some reason, the cost of staying on the
highway is less than using the ramp. This certainly could be a mistake in
the data but it could also be a bug in the algorithm. 3) In pruning, the
algorithm eliminated the path that stayed on the highway but then was forced
to make a connection and the ramps were used instead.

Another problem is that ramps are typically posted at something like 45mph.
I know that, for a while, the algorithm we used presumed that people would
drive them faster than coded which basically made them as good as a highway.
Prune a few branches. Ignore some data. And, presto, the ramp is better than
the highway.

If you happen to remember the highway junction where that has occured, I can
check our data.
-------------------------------
Travis
Lake N3094P
PWK