Felix Hartmann escribió:
Strange that it's working for you. I'm allways on SVN latest wit
hVista HCx, I even think that before the updates it worked better.
Some time ago (but after time recalculation was improved) I had the
same problem. Finally I solved it building mkgmap from a fresh svn
Nuvi 255 here. Route recalculation works very well now (25/30m). I remember a
month ago (+/-) it was much worse (say 100m).
Mark, do you have some advice about OSM tagging for address search?
Ciao.
--- Sab 13/6/09, Mark Burton ma...@ordern.com ha scritto:
Da: Mark Burton ma...@ordern.com
Hi Felix,
I found out the problem associated to route recalculation not working
(well working but only far too late). We currently set the TRE header at
1,3,17 IF we change this over to 1,4,23 route recalculation kicks in at
around 25-30m instead of 300-400 (as it happens with 1,3,17 we
With my vista hcx and using the current value of 0x110301, the route
recalculates if I go off course by no more than about 25m. I believe
other people are also getting similar results. Perhaps people could
confirm that?
Yes, I can confirm that.
On my etrex Legend before the patch I had
Mark Burton wrote:
Hi Felix,
Let's hear them. I got many many complaints that my maps don't
recalculate...
Speak up chaps, how's the recalculating working out?
With the current mkgmap I get recalculation between 25 and 50m. Prior to
the discussion [mkgmap-dev] [PATCH] route
Currently with mkgmap created maps (just like most other maps) Mapsource
tries 3x to find a route when using the autorouting tool. I have noticed
that using Netherlands Onroute Fietskaart Mapsource tries much harder to
find a route - sometimes it restarts 15 times until it has found a
route
I made some observations on my Edge 705 yesterday. The route recalculation
sensitivity varies in bicycle mode. Sometimes, I can ride a couple hundred
metres until getting a notice; other times, I get the notice within a couple
dozen metres.
This might have something to do with junctions
Let's hear them. I got many many complaints that my maps don't
recalculate...
How can I change 0x110301 so that it sets 1,4,23 instead of 1,3,17?
Mark Burton wrote:
Hi Felix,
I found out the problem associated to route recalculation not working
(well working but only far too late). We
.
The maps i found that it's not set are worldwide base maps - gmapbmap.img(s)
For the route recalculation, it's not clear which of the two bites
changed the recalculation
- first rule of re - always change only one thing .
Can someone write a patch to allow setting the poiDisplayFlag
first displayed as a straight line and then
>recalculated.
>Only with these map crossing ways I don't see a recalculation.
>Interesting is that I see recalculation when I select
>a different default route vehicle, but the results look bad.
>
>Anyway, I think the extra nodes ca
a straight line and then recalculated.
Only with these map crossing ways I don't see a recalculation. Interesting is
that I see recalculation when I select
a different default route vehicle, but the results look bad.
Anyway, I think the extra nodes can improve routing, so I'll add an option t
Hi Felix,
Let's hear them. I got many many complaints that my maps don't
recalculate...
Speak up chaps, how's the recalculating working out?
How can I change 0x110301 so that it sets 1,4,23 instead of 1,3,17?
Change line 170 of src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java
to output
Hi Marco,
Mark, do you have some advice about OSM tagging for address search?
If a road has a name or reference it will have an entry in the address
search data structure. It needs also to have a city associated with it
which can either be the nearest city (town, village, etc.) or the
road can
Felix Hartmann schrieb:
Strange that it's working for you. I'm allways on SVN latest wit
hVista HCx, I even think that before the updates it worked better.
Could it be that you use a modified style file?
Some changed settings in the bit resolution for the layers? As far as I
know, these
Version mkgmap-r3626 was committed by gerd on Sun, 02 Aug 2015
Don't ignore no_u_turn restriction that has a via node and equal 'from' and
'to' way.
This restriction has an effect when moving with the device with automatic route
recalculation
switch ON.
Thanks to Ben Konrath for pointing
. Even if I'm just a few feet to the side
of the road eg sidewalk, I'm unable to calculate a route to any
destination.
On Sat, Jul 4, 2009 at 2:05 PM, Marko Mäkelämarko.mak...@iki.fi wrote:
I made some observations on my Edge 705 yesterday. The route recalculation
sensitivity varies in bicycle
Mark Burton wrote:
With my vista hcx and using the current value of 0x110301, the route
recalculates if I go off course by no more than about 25m. I believe
other people are also getting similar results. Perhaps people could
confirm that?
My eTrex Legend HCx with a map generated by mkgmap
Hi Felix,
BTW - thanks to those who have responded re performance of the current
value.
Strange that it's working for you. I'm allways on SVN latest wit hVista
HCx, I even think that before the updates it worked better. Anyhow I now
use the different value and am happy. Could it be that
Felix,
O.k. so there must be another reason.
Maybe its as well related to road_speed or road_class?
(Garmin may think that the lower the road_speed the higher the chance
that there are buildings that obstruct GPS reception, or the lower the
accuracy of the maps, cause minor roads are
Change line 170 of src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java
to output 0x170401 instead of 0x110301.
I'm happy to try this but won't be able to report back for a few days
So I finally got chance to try this out and after a brief test I would
say that at best it's the same as
know if it may help you: If I search for a city (any city), it doesn't
find any city.
Ciao.
--- Sab 13/6/09, Mark Burton ma...@ordern.com ha scritto:
Da: Mark Burton ma...@ordern.com
Oggetto: Re: [mkgmap-dev] route recalculation senstivity bug found
A: mkgmap-dev@lists.mkgmap.org.uk
Data
The first bit in poiDisplayFlags have to do something with the basemaps.
In all detailed maps it's set.
The maps i found that it's not set are worldwide base maps - gmapbmap.img(s)
For the route recalculation, it's not clear which of the two bites
changed the recalculation
- first rule of re
On 31.05.2010 16:08, Johann Gail wrote:
The first bit in poiDisplayFlags have to do something with the
basemaps.
In all detailed maps it's set.
The maps i found that it's not set are worldwide base maps -
gmapbmap.img(s)
For the route recalculation, it's not clear which of the two
On 30.11.2009 13:59, Felix Hartmann wrote:
Currently with mkgmap created maps (just like most other maps)
Mapsource tries 3x to find a route when using the autorouting tool. I
have noticed that using Netherlands Onroute Fietskaart Mapsource tries
much harder to find a route - sometimes
caculation time (or even a failure).
I used that in my try to route bicycle better. Unfortunately the long
calcultion time was a huge problem with lots of cycleways on a long
route. My test route (about 17km in Helsinki) lead to calculation time
(and recalculation!) of about 2-3 minutes on my Oregon 550
that had a major impact. By raising all the cycleways to
high road_class the computation time for the route was very
unacceptable. Route calculation (and recalculation!) time for a 20km
test route in Helsinki was about 2-3 minutes with Oregon.
The end result was that raising the road_class
ransferred them to the
>Oregon.
>Next, I looked at them in the Route Manager. With other routes, when I
>select button "Map" in the Route Manager
>the route is also first displayed as a straight line and then
>recalculated.
>Only with these map crossing ways I don't see
), is setting
the distance for recalculation when off road. The lower the earlier the
GPS will recalculate. It is useful for cycling/hiking as recalculation
is happening later the slower you go (maybe because this is interpreted
as bad gps reception??).
02 sets the draw priority (overrules DP if set
O.k. so there must be another reason.
Maybe its as well related to road_speed or road_class?
(Garmin may think that the lower the road_speed the higher the chance
that there are buildings that obstruct GPS reception, or the lower the
accuracy of the maps, cause minor roads are not that well
Yeah getting that 3byte field to work would be splendid. There are so
many lines that one can't differentiate without it. Especially as
Maspource only displays half as many compared to the gps.
Mark Burton wrote:
Felix,
O.k. so there must be another reason.
Maybe its as well related to
n-routable lines with
address. This worked correctly until recent releases of BaseCamp, where
I get direct routes (straight lines) instead of routes following roads.
Problem appears only for "driving" activity (car). When I change
activity to "motorcycling" or "trucking"
at offset 43-46, esp. 43 and 44:
0x040 3 display priority
0x043 1 0x11; distance for start route recalculation
0x044 1 0x03; draw priority (overrules DP if set inside tdb)
Wouldn't it be better to have two distinct options for these values?
And what does "Draw Pri
v] [patch v1] don't route the highway=construction ways
Hi Gerd,
> I am not sure what you did and what "routing doesn't work" means
> in this case.
My map was similar to the experiments, that you have analyzed here:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2015q2/02
l+G two times to clear all
caches. Next I loaded your
problem.gdb and selected the routes for recalculation. Each of them changed,
typically my calculated time was longer,
and route 2 and 3 used the roundabout.
So I assume it is related to the routing settings in MapSource (they seem not
to go into
Hi Carlos,
please post your route settings. I used the three *.o5m files from problem.zip
as input.
Gerd
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Carlos
Dávila <cdavi...@orangecorreo.es>
Gesendet: Mittwoc
. But the route calculation and recalculation can be VERY long. When
I tried elevating cycleways to similar class with motorways, a 17km
route took on some earlier devices something like 20mins to
calculate/recalculate the route.
I've never tried toll roads. Petrhaps I could misuse that in my style
MapSource, pressed Ctrl+G two times to clear all
caches. Next I loaded your
problem.gdb and selected the routes for recalculation. Each of them changed,
typically my calculated time was longer,
and route 2 and 3 used the roundabout.
So I assume it is related to the routing settings in MapSource
ll
caches. Next I loaded your
problem.gdb and selected the routes for recalculation. Each of them changed,
typically my calculated time was longer,
and route 2 and 3 used the roundabout.
So I assume it is related to the routing settings in MapSource (they seem not
to go into the *.gdb format).
M
roblem
>
>
>
> The default map askes for recalculation every time and does not finish. It
> stays in loop.
>
> My own style recalculates automatically but still finishes at the end
>
> But when passing the demo route, it is thrown back to the beginning of the
> C
Hi Felix
I retested your example and have more or less the same results on my Oregon 650
Builded a map with both default style and with my own style.
Both maps have the confusing problem
The default map askes for recalculation every time and does not finish. It
stays in loop.
My own style
with yours, pressed Ctrl+G two times, and Mapsource
still calculates different (better) routes.
My Mapsource version is 6.16.3, and I've verified that I have no "Advanced Route
Avoidances".
No idea why I should get good results and you don't.
Gerd
__
senumbers --reduce-point-density=4
>>> --polygon-size-limits="24:12,18:10, 16:0" --add-pois-to-areas
>>> --link-pois-to-ways --location-autofill=is_in,nearest
>>> --drive-on=detect,right --check-roundabouts --check-roundabout-flares
>>> --nsis *.o
. Didn't try on devices yet.
El 04/01/17 a las 14:31, Gerd Petermann escribió:
> Really strange.
> I've replaced my files with yours, pressed Ctrl+G two times, and Mapsource
> still calculates different (better) routes.
> My Mapsource version is 6.16.3, and I've verified that I have no "
itself if its result should be put into a tag or not.
If you have two lines with the function call ::length.m the first call
will calculate the value and store it in a tag. The second function call
checks if the tag exists and returns its value without recalculation.
- Functions might require
t for mkgmap
Betreff: Re: [mkgmap-dev] Intertile/access related routing problem
Vehicle: Car/Motorcycle
Avoidance: U-turns
Faster time
Road selection: in the middle
Default driving speeds
El 04/01/17 a las 12:59, Gerd Petermann escribió:
> Hi Carlos,
>
> please post your route settings. I
ddle
Default driving speeds
El 04/01/17 a las 12:59, Gerd Petermann escribió:
Hi Carlos,
please post your route settings. I used the three *.o5m files from problem.zip
as input.
Gerd
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im
I found that I was wrong. The no_u_turn restriction
has an effect, the warning makes no sense.
This is what I tested:
Switch to car routing with shortest distance (shorter time seems to
avoid u-turns),
and enable automatic recalculation of routes.
Enter a target which just requires a left turn
),
and enable automatic recalculation of routes.
Enter a target which just requires a left turn after 100m. Ignore the left turn,
after a few seconds the device tells me to make a u-turn at the next crossing.
(tried this two or three times with the same result)
I've then used JOSM to add a no_u_turn
added the problematic point in the error message of the
MapBuilder in case a node is not a CoordNode. Just having the way id
might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the
merge procedure. This should
the recalculation of the highway counters after the
merge procedure. This should not change anything but it avoids a
problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able
to reproduce it, so
it's just a guess: In a special case, we
is not a CoordNode. Just having the way id
might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the
merge procedure. This should not change anything but it avoids a
problem with merging...
WanMil
Hi Felix, WanMil
information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the
merge procedure. This should not change anything but it avoids a
problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I
moved the recalculation of the highway counters after the
merge procedure. This should not change anything but it avoids a
problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not
able
to reproduce it, so
it's just a guess
the way id
might not be enough information and the way also might have been
merged.
3. I have moved the recalculation of the highway counters after the
merge procedure. This should not change anything but it avoids a
problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch
the problematic point in the error message of the
MapBuilder in case a node is not a CoordNode. Just having the way id
might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the
merge procedure. This should not change anything
not be enough information and the way also might have been
merged.
3. I have moved the recalculation of the highway counters after the
merge procedure. This should not change anything but it avoids a
problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve
56 matches
Mail list logo
