Re: [mkgmap-dev] mergeroads sometimes breaks routing

Hi, thanks for reporting! Without having had a detailed look at your test case it sounds like the same problem reported by Gerd: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q4/019532.html I will have a closer look to your testcase later on to ensure that it has nothing to do with merg

Re: [mkgmap-dev] mergeroads sometimes breaks routing

Hi, just to let you know: I am able to reproduce the results with your data. Not sure what happens with the mergeroad map. MapSource finds the shorter route when you select to minimize the distance, and (depending on the speed settings), it even may calculated the shorter time for the shorter rout

[mkgmap-dev] invalid types in check-styles

Hi Interesting 'bug' when using check-styles. It had me foxed as it actually by chance highlighted lines I didn't use in my TYP file. invalid type 0x11f for POLYLINE It transpires that when replacing 11f with 11f00 the type number is correctly identified as valid. I checked it with several line

Re: [mkgmap-dev] routing seems to depend on order of ways

Hi all, really confusing... The strange bug disappears in MapSource (6.16.3) when I (re-)activate option "Try to avoid.." "U-turns" In Basecamp (4.25) , the bug appears as well when I deactivate "Feature type avoidance" "U-Turns". Regarding the order of the ways in the OSM file: It seems that th

Re: [mkgmap-dev] invalid types in check-styles

Hi, yes, 0x11f00 is recognized as an extended type. What bug do you mean? Should mkgmap interpret 0x11f as 0x11f00 when used in the lines or polygons file? Gerd > Date: Mon, 30 Dec 2013 02:07:24 -0800 > From: o...@pinns.co.uk > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] invalid

Re: [mkgmap-dev] invalid types in check-styles

Hi Gerd 0x11f is the same as 0x11f00 - both have been valid expressions in the past. However, the style checker tells me that 11f is invalid. This applies to I think all extended types , ie it tells me 10A (without the 00) is invalid. It accepts 10A00 but not 10A It accepts 11F00 but not 11F I a

Re: [mkgmap-dev] invalid types in check-styles

Hi Nick, well, 0x11f00 is 256 * 0x11f, so it is not the same, but if I get you right you want mkgmap to interpret all values >= 0x100 and x as if they were written with a 00 at the end. What is the upper bound (x) ? See also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017797.html Ger

Re: [mkgmap-dev] invalid types in check-styles

Hi Gerd No , its only the style checker that throws up the anomaly. I might have missed something about mkgmap requiring 00 subtypes ? although I have not encountered any problems leaving them out for extended types The highest subtype is 1F and the highest type for lines/polylines, I think, &

Re: [mkgmap-dev] invalid types in check-styles

Hi Nick, nwillink wrote > Hi Gerd > > No , its only the style checker that throws up the anomaly. I can't confirm that. A line with type 0x11f is written as type 0x1f, so the test is right to complain. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/invalid-types-in-c

[mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

There are some dead-end highway=service,oneway=yes that trigger dead-end-check warnings in mkgmap RouteNode.java. To allow suppressing most of the warnings, years ago I added a check that suppresses the warning if either end node of the way is tagged with fixme=* or FIXME=*, such as fixme=cont

Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

Hi Marko, I think the dead-end test can be done in StyledConverter. The test is quite similar to the one that is done in findUnconnectedRoads(). Gerd Marko Mäkelä wrote > There are some dead-end highway=service,oneway=yes that trigger > dead-end-check warnings in mkgmap RouteNode.java. > > To

Re: [mkgmap-dev] Address search: city sometimes missing

Hi For example, look here: http://www.openstreetmap.org/#map=17/49.44674/11.03418 There are two buildings from Siemens, Von-der-Tann-Strasse 30 and 31 in 90439 Nuernberg. As you could see in the attached screenshot, only the housenumber 31 has a city assigned, the number 30 has not. I downl

Re: [mkgmap-dev] SEVERE (MapSplitter) Errors - "Area too small to split at..."

Hi Gerd, Tried lowering max-nodes value from 15 to 6500 which reduced but didn't stop the errors. I think that the cause is that within the 1685341 codes in the Ordnance Survey CodePoint data sometimes many different Postcodes are at the same coordinates. On analyzing can see a max of 1327 p

Re: [mkgmap-dev] Commit: r2906: Merge the mergeroads branch.

Hi WanMil the new mkgmap version now appears at other builds but the main download still links to r2889. Can you please have a look on it if you are back again? OK I have now set it so that it should be updated tonight. And thanks for posting the news item about it. I was going to suggest th