Just for testing to make it much easier - here are the routes:
https://openmtbmap.org/Test_routes.gdb
On 20 March 2018 at 23:19, Felix Hartmann wrote:
> The new patch seems to work pretty well - most ways that are supposedly
> not routable (according to my understanding
The new patch seems to work pretty well - most ways that are supposedly not
routable (according to my understanding so far if there are 6 arcs or more
it will break) are actually broken.
Map (just unpack the lzma installer:
https://openmtbmap.org/mtbitaly_test.exe
All broken - in simulation
Yes it only happens on device. Simulating routing via:
http://www.openstreetmap.org/browse/way/310376420 will in this case not
switch off the device, but just get stuck. Map moving forward/backwards
slightly.
Here you could reproduce it by simply doubling the routable lines - one
routable line
At least in my country it's really important that every housenumber
have its own entry, and postfix is kept together with the number.
Numbers like 26, 26A (or 26/A) and 28 are on the same level. 26A is
created when a new address is needed between 26 and 28, because a new
house is built for
Hi Felix,
well, up to now I thought that you want to fix the problem in your style and
just need help to find out where it happens.
I still don't understand why your style adds so many routable lines, in my eyes
this is an errpr on your side.
But you may be right, mkgmap might be able to change
Hi Gerd,
I had similar effect, but also haven't investigated further. As it was
during my hike quite cold outside and the eneloops were for longer time
around 0°C so I thought this might be the reason. I hope on my April
hike, the temperatures are more warm. I will let you know about it.
Henning
well I think if ways are overlapping which have identical nodes it should
be possible to throw away according to say this prinicple:
a) identical tags (except name which is not important) - throw away the
copy/copies. I think here it is clear the copies are not needed.
b) identical tags (except
Hi Gerd,
Yes, more than likely. However, I do find that my Oregons tend to be
more thirsty then the gps64.
Nick
On 20/03/2018 09:53, Gerd Petermann wrote:
Hi Nick,
okay, so it probably was coincidence. I've got 2 2100 mAh accus and I typically
never have to think about them,
means, on my
Hi Nick,
okay, so it probably was coincidence. I've got 2 2100 mAh accus and I typically
never have to think about them,
means, on my long tours in the summer I load them in the night and can cycle
more than 100 km without seeing a battery low message.
In the rare cases where the message
Hi Gerd,
Personally , DEM has little, if any effect using 2 rechargeable 2400 mAh
s on gps64
Nick
On 20/03/2018 08:53, Gerd Petermann wrote:
Hi all,
okay, it was quite cold when this happened, but I think my Oregon emptied the
batteries (NI-MH accu) within less than 2.5 hours when I used
Hi all,
okay, it was quite cold when this happened, but I think my Oregon emptied the
batteries (NI-MH accu) within less than 2.5 hours when I used a gmapsupp with
DEM.
In the summer they easily allow > 6 hours, maybe > 10. It happened two or three
times so I tried again with an older gmapsupp
Hi Felix,
note that we are counting arcs here, not ways. An arc connects two routing
nodes. There will always be two arcs between two nodes A and B,
one from A to B and one from B to A. The node from A to B is the forward arc in
A and the backward arc in B (and vice versa).
Also, we have so
Hi Lorenzo,
yes, device shows two hits, and I think both are okay. The on-road-distance
between the two buildings is ~170m, so mkgmap cannot combine them to
one entry. Since it also cannot store the "a" in 26/a it has to create two
separate entries.
I have no idea why Basecamp shows only the
13 matches
Mail list logo