Hi
A possible way to find the flag:
With MapSource (at least with 6.13) it is possible to include or exclude
the routing data when transferring to the device. If you transfer the
same data twice, one time with, the ther time without the routing data,
A great idea!
Unfortunately my results
On 31.05.2010 15:05, Steve Ratcliffe wrote:
Hi
A possible way to find the flag:
With MapSource (at least with 6.13) it is possible to include or exclude
the routing data when transferring to the device. If you transfer the
same data twice, one time with, the ther time without the
On 28.05.2010 12:18, Alexander Atanasov wrote:
Hi,
On Thu, May 27, 2010 at 11:44 PM, Steve Ratcliffest...@parabola.me.uk
wrote:
In the TREHeader.java (like in the patch from steve) add a one more byte
in first position. If I understand it correctly, this will set the
A possible way to find the flag:
With MapSource (at least with 6.13) it is possible to include or exclude
the routing data when transferring to the device. If you transfer the
same data twice, one time with, the ther time without the routing data,
A great idea!
Unfortunately my
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 31.05.2010 15:56, Johann Gail wrote:
A possible way to find the flag:
With MapSource (at least with 6.13) it is possible to include or exclude
the routing data when transferring to the device. If you transfer the
same data twice, one time with, the ther time without the routing data,
I've now got a small example that shows the problem.
No luck so far in finding the flag, if indeed it is just a flag.
A possible way to find the flag:
With MapSource (at least with 6.13) it is possible to include or exclude
the routing data when transferring to the device. If you
I've now got a small example that shows the problem.
No luck so far in finding the flag, if indeed it is just a flag.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Only solution I think is to make --route default and
compulsory for the moment. Else people will create maps that havoc other
maps without realising.
I strongly advice against this. The problem has been around a very long time
and nobody noticed, so I don't think it is that
Felix Hartmann schrieb:
On 27.05.2010 13:12, Johann Gail wrote:
Setting the fourth via gmaptool breaks the routing for routable maps
even though it should be there for setting maps tranparent/opaque is
some obscure way different from the general transparent/opaque flag
Could
On 27.05.2010 13:34, Johann Gail wrote:
Felix Hartmann schrieb:
On 27.05.2010 13:12, Johann Gail wrote:
Setting the fourth via gmaptool breaks the routing for routable
maps even though it should be there for setting maps
tranparent/opaque is some obscure way different from the general
This is the point which confuses me at the moment. This bit does
influence routing in some way. But you say that there are nonroutable
maps with this bit set/unset. So what could the meaning of this bit be?
Noone really knows. Mkgmap sets it even. Garmin maps are actually
allways
In the TREHeader.java (like in the patch from steve) add a one more byte
in first position. If I understand it correctly, this will set the
ominous fourth byte to 01. (Not tested).
In fact the 4th byte that appears in the gmaptool dialog is actually
what mkgmap calls poiDisplayFlags and
You need to combine two different maps of the same area (so most often
one being contourlines) into the same mapset (meaning same tdb/overview
image/mdr/).
OK I have finally reproduced it with your map.
It seems that in fact you have two different map sets with different
family/tdb/etc.
On 28.05.2010 00:21, Steve Ratcliffe wrote:
You need to combine two different maps of the same area (so most often
one being contourlines) into the same mapset (meaning same tdb/overview
image/mdr/).
OK I have finally reproduced it with your map.
It seems that in fact you
No it's originally two different maps, but they are joined into the same
mapset so they become one map. So if joined, they have the same
How are they joined?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On 27/05/2010 23:43, Steve Ratcliffe wrote:
No it's originally two different maps, but they are joined into the same
mapset so they become one map. So if joined, they have the same
How are they joined?
OK never mind I see how. The srtm set includes the other one and is
not separate.
On 28.05.2010 00:43, Steve Ratcliffe wrote:
No it's originally two different maps, but they are joined into the same
mapset so they become one map. So if joined, they have the same
How are they joined?
using mkgmap parsing all img files to create new tdb/overview map,
etc...,
already inflicting Mapsource 6.16.1 and Basecamp 3.
OK so I upgraded to 6.16.1, had to upgrade twice to get there.
This means that also if you compile maps that are not routable, you have
to pass the --route parameter. Else the GPS / Mapsource looks into an
empty NOD table and may crash.
On 26.05.2010 23:40, Steve Ratcliffe wrote:
already inflicting Mapsource 6.16.1 and
Basecamp 3.
OK so I upgraded to 6.16.1, had to upgrade twice to get there.
This means that also if you compile maps that
are not routable, you have
to pass the --route parameter.
If the flag is in TRE, then my first guess would be within
the 3 bytes from 0x43.
We don't know exactly what they are for, but some of the bits
at least affect routing (see:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001473.html)
Please try the attached patch.
The first 3 TRE
On 25.05.2010 14:28, NopMap wrote:
Felix Hartmann wrote:
Routable maps are in no way bigger than non routable maps (if there is
no routable information inside, of course if you use the same style that
is routable and compile it without --route it gets smaller, if you
remove all
On 27.05.2010 00:28, Felix Hartmann wrote:
If the flag is in TRE, then my first guess would be within
the 3 bytes from 0x43.
We don't know exactly what they are for, but some of the bits
at least affect routing (see:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001473.html)
Felix Hartmann wrote:
Only solution I think is to make --route default and
compulsory for the moment. Else people will create maps that havoc other
maps without realising.
I strongly advice against this. The problem has been around a very long time
and nobody noticed, so I don't think
On 25.05.2010 11:58, NopMap wrote:
Felix Hartmann wrote:
Only solution I think is to make --route default and
compulsory for the moment. Else people will create maps that havoc other
maps without realising.
I strongly advice against this. The problem has been around a very
On 25.05.2010 11:53, Alexander Atanasov wrote:
Hi Felix,
On Tue, May 25, 2010 at 2:02 AM, Felix Hartmann
extremecar...@googlemail.com wrote:
Just got to test it. Good try but ain't work. Still crashing
Mapsource/Basecamp. Only solution I think is to make --route default and
Felix Hartmann wrote:
Routable maps are in no way bigger than non routable maps (if there is
no routable information inside, of course if you use the same style that
is routable and compile it without --route it gets smaller, if you
remove all road_class and road_speed from style, there
Hi
Okay, there is probably no need to search for the revision that
introduced this bug. I went as far back as rev 500, and there the NOD
flag is already set, which was before we got started with autorouting.
Hence I assume we don't know about its existence, and it has been wrong
from the
Maybe it's this bit in the TDB-Header (HeaderBlock.java):
os.write(1);// map is routable
At least it looks strange that this bit is set regardless of the --route
option, and there are similar flags related to DEM info in this block as
well ...
Best wishes
Christian
Felix
On 24.05.2010 18:01, Christian Gawron wrote:
Maybe it's this bit in the TDB-Header (HeaderBlock.java):
os.write(1);// map is routable
At least it looks strange that this bit is set regardless of the
--route option, and there are similar flags related to DEM info in
this
On 24.05.2010 18:01, Christian Gawron wrote:
Maybe it's this bit in the TDB-Header (HeaderBlock.java):
os.write(1);// map is routable
At least it looks strange that this bit is set regardless of the
--route option, and there are similar flags related to DEM info in
this
There is a serious bug that breaks routable maps when --route is NOT
given. This bug will in future break routing on most GPS devices and is
already inflicting Mapsource 6.16.1 and Basecamp 3.
This means that also if you compile maps that are not routable, you have
to pass the --route
On 23.05.2010 18:24, Felix Hartmann wrote:
There is a serious bug that breaks routable maps when --route is NOT
given. This bug will in future break routing on most GPS devices and
is already inflicting Mapsource 6.16.1 and Basecamp 3.
This means that also if you compile maps that are not
On 23.05.2010 20:22, Felix Hartmann wrote:
On 23.05.2010 18:24, Felix Hartmann wrote:
There is a serious bug that breaks routable maps when --route is NOT
given. This bug will in future break routing on most GPS devices and
is already inflicting Mapsource 6.16.1 and Basecamp 3.
This means
On 5/23/2010 2:54 PM, Felix Hartmann wrote:
There is a serious bug that breaks routable maps when --route is NOT
given. This bug will in future break routing on most GPS devices and
is already inflicting Mapsource 6.16.1 and Basecamp 3.
This means that also if you compile maps that are not
36 matches
Mail list logo
