I should have tested using the DEFAULT STYLE, the exit and destination
strings look correct using the DEFAULT STYLE.
Greg
On Thu, Mar 3, 2016 at 12:26 AM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Greg,
>
>
> I don't think that r3669 introduced the problem. You can check
Walter, I also have setup non-routable linetypes for roundabouts to show
different road types all on top of an INVISIBLE roundabout routable
linetype 0x0c. Gerd says I should leave 0x0c and 0x08 and 0x09 alone
because the GPS expects these *_links and roundabouts to use these specific
layers.
Hi Andrzej,
okay, I understand. If you can reproducde it with the large
file I'd still like to check that.
Gerd
Von: mkgmap-dev-boun...@lists.mkgmap.org.uk
im Auftrag von Andrzej Popowski
Hi Gerd,
I can't repeat the problem on smaller extracts. The problem is not so
important, I would leave it for now, unless it reappear on easier to
track dataset.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Greg,
why do you want to “free” some routeable line types?
If it is just for different display options, you can do another trick.
I am using 0x0c as an invisible line type just for routing purpose,
and non-routeable overlay linetypes to display roundabouts how they should look
like.
The previous file version contained a lot of such nonsense data.
Hope the rest is okay...
Gerd
Von: mkgmap-dev-boun...@lists.mkgmap.org.uk
im Auftrag von Minko
Gesendet: Donnerstag, 3.
Problem is corrupt data in the Vlaanderen set:
lon min: 2.3066895
lon max: 200.000
lat min: -120.4967296
lat max: 103.000
I have fixed it with osmconvert (bbox around Belgium)
https://github.com/ligfietser/mkgmap-style-sheets/commit/bd945183cdfc704d0ff6dc8190e463f31b9ee0ce
Hi Lambertus,
good to know. I still think that I should change the code to improve
the handling of wrong data. As you pointed out, the status messages
are misseading, on expects that the last message before a stack
trace is somehow related to the problem, but it wasn't here.
Gerd
Thanks, Gerd, for looking into this. The problem is now nailed down to
one of the other address files that are merged with the planet file. So
there is currently no need to change Splitter's code.
On 02/03/2016 07:09, Gerd Petermann wrote:
Hi Lambertus,
maybe the problem is related to the