Re: [mkgmap-dev] continue statement and order of drawn ways?

[MarkS]

On 04/05/2011 16:11, Torsten Leistikow wrote:
 MarkS schrieb am 03.05.2011 22:58:
 Would something like this work?

 highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue]
 highway=motorway  oneway=yes   [0x10f01 level 6]
 highway=motorway  oneway!=yes   [0x10f02 level 6]

 Then style 0x01 with no style (so nothing is drawn) - 0x01 would be used
 for the routing information.

 Then style 0x10f02 as plain motorway and 0x10f01 as motorway with arrows.

 The problem is, that the oneway overlay is not only to motorways. So you would
 need two line styles for motorways, two linestyles for primaries, ...

 And if you want to add overlays for access restrictions, speed  limits or what
 ever, th enumber of line styles required is growing exponentially.

 Gruss
 Torsten
I have seen a map which goes for another approach. That version used a 
single line/style for the motorway itself.

They then added a second line/style for oneway roads. This second style 
looked a bit like an arrow but with a transparent bit down the middle so 
only the edges of the arrow head were visible. This reasulted in the 
arrow heads sitting outside the normal road and working whatever the the 
draw order.

The drawback on this approach was that the road lines all needed to be a 
similar width, and it wasn't as pretty as arrows in the middle of the road.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] continue statement and order of drawn ways?

[MarkS]

On 03/05/2011 21:13, Thorsten Kukuk wrote:
 On Tue, May 03, Torsten Leistikow wrote:

 Thorsten Kukuk schrieb am 03.05.2011 20:53:
 But with both statements, the arrow is always drawn below the street.
 Is it somehow possible to have the arrow on top of the street?

 The drawing order of the lines in a single map is not really understood and 
 can
 not be set via the style file.

 Ok, thanks. That was the impression I got meanwhile, too.

 For such tasks I use multiple map layers (base layer + overlay layer), the
 display order of the complete maps can be defined via mkgmap command line
 parameter (draw-priotrity)

 I'm working already with several overlay layers, too. I wanted to avoid
 to create yet another one, but looks like that's the way to go.

 Thorsten
Would something like this work?

highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue]
highway=motorway  oneway=yes   [0x10f01 level 6]
highway=motorway  oneway!=yes   [0x10f02 level 6]

Then style 0x01 with no style (so nothing is drawn) - 0x01 would be used 
for the routing information.

Then style 0x10f02 as plain motorway and 0x10f01 as motorway with arrows.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Running mkgmap in Eclipse

[MarkS]

On 23/03/2011 10:30, Walter Wright wrote:
 Hi, this is my first foray into looking at the mkgmap code so please
 bear with. I'm trying to run mkgmap in an Eclipse workspace and I've
 downloaded the r1899 source archive as a starting point. I'm getting a
 load of errors, mostly around a number of crosby* libraries missing. Is
 there somewhere I can look to find out what I need to do to pull
 together a working environment?
 Also, is Eclipse a suitable IDE for this? It's what I've been working
 with for the last couple of years so it is comfortably familiar at least.
 Any help appreciated.
 Walter


I don't tend to build my own version much but I have got it to work in 
Eclipse.

Last time I built mkgmap (a few months ago) I noted down the steps I had 
taken. I've taken a copy of those steps and put them into the wiki. They 
may help (either directly or as a starting point for somebody to expand 
into a fuller explanation).



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Running mkgmap in Eclipse

[MarkS]

That's the page.  (and I'll freely admit it isn't anything more than a 
starting point)

On 23/03/2011 14:15, Walter Wright wrote:
   Last time I built mkgmap (a few months ago) I noted down the steps I had
   taken. I've taken a copy of those steps and put them into the wiki.
 Do you mean this page http://wiki.openstreetmap.org/wiki/Mkgmap/dev?

 On 23 March 2011 11:53, MarkS o...@redcake.co.uk
 mailto:o...@redcake.co.uk wrote:

 On 23/03/2011 10:30, Walter Wright wrote:
   Hi, this is my first foray into looking at the mkgmap code so please
   bear with. I'm trying to run mkgmap in an Eclipse workspace and I've
   downloaded the r1899 source archive as a starting point. I'm
 getting a
   load of errors, mostly around a number of crosby* libraries
 missing. Is
   there somewhere I can look to find out what I need to do to pull
   together a working environment?
   Also, is Eclipse a suitable IDE for this? It's what I've been working
   with for the last couple of years so it is comfortably familiar
 at least.
   Any help appreciated.
   Walter
  

 I don't tend to build my own version much but I have got it to work in
 Eclipse.

 Last time I built mkgmap (a few months ago) I noted down the steps I had
 taken. I've taken a copy of those steps and put them into the wiki. They
 may help (either directly or as a starting point for somebody to expand
 into a fuller explanation).



 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Style File Problem

[MarkS]

Felix Hartmann wrote:
 Mapsource only uses even resolution. Only gps uses uneven. So as you did 
 not set 20, that might be the reason to go straight up to 22. Try with 
 even resolution only.
 

I've changed the second line to

highway=primary  mcssl=40 [0x04 resolution 20]

but it doesn't resolve the problem. I still get two idential roads 
(except that one has a name key) showing at different resolutions.

Even if resolution 19 isn't acceptable to mapsource shouldn't that 
affect both roads?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Style File Problem

[MarkS]

Steve Ratcliffe wrote:
 On 09/09/09 11:27, MarkS wrote:

 
 The problem is definitely in the generated img and not how mapsource
 displays it. I would expect that both roads would be at resolution 22
 which is probably not what you wanted but that is due to the usual
 issue of the action rules being run in an indeterminate order.
 
 If you need to work around the problem while I look at it try this:
 
(highway=* | highway=primary)  maxspeed=40mph {set mcssl=40}
 
 ..Steve

Both appear at the same resolution is wanted.

What I was trying to achive was roads in different colours according to 
speed limit. However, I wanted more important roads to show at lower 
resolutions so you could zoom in and out easily and have a workable map.

The problem lines were part of a much longer style file. Originally the 
file followed your work around, but this creates long style files 
because speed limits are defined in one of 5 ways on OSM data.

The newer style file comes up with a consistent speed limit defintion 
first (mcssl) and then later on uses mcssl and highway type - at this 
point resolution for all primary highways should be 20, trunks 18, 
motorways 16 and other roads 22. This gives a much short style file.

However, in testing I came across this curious bug that the highway key 
is lost for some roads if a name key exists.

I can work around to get what I want but I guess at some point we need 
to find out why these particular combinations gets odd results.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Style file not working

[MarkS]

Steve Ratcliffe wrote:
 
 The first term in a rule has to have an equals sign (or the rule
 can be rearranged so that is the case).
 
 So the following should work:
 
highway=*  maxspeed  78  maxspeed  82 {set mcssl=50}
 
 Sorry about the error message, it is clearly useless and I will change it.
 
 ..Steve
Thanks Steve, I'll have a look at the wiki (which is what I was working 
from) and update as needed.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Style File Problem

[MarkS]

I've battled trying to narrow this down for a couple of days.

I have a lines style file that contains:


highway=*  maxspeed=40mph {set mcssl=40}
highway=primary  mcssl=40 [0x04 resolution 19]
highway=*  mcssl=40 [0x04 resolution 22]


I'm then running a stripped down (in JSOM) set of OSM data against this. 
The data file contains two roads. The first road is the original, whilst 
the second is a copy (in JOSM) with a name added (and dragged a bit so 
it is visible). Both have primary=highway and maxspeed=40mph. To me it 
seems that as both ways have the same maxspeed and highway attributes 
they should both become visible at the same resolution (ie. 19). 
However, they don't. The one without the name becomes visible at 3mi 
(which I guess is 19), whilst the one with the name becomes visible at 
0.5mi (which I guess is 22).


It seems therefore that having a name key (or a given value for that 
key) affects the style file somehow.


I've tried to look at the code but have no idea where to start (as my 
Java knowledge is virtually zero and I don't know how data moves through 
the mkgmap).


Files are attached. Mkgmap version: 1180 (although I've tried a few 
other recent version other the past few days). mapsource: 6.13.7


Any ideas?

?xml version='1.0' encoding='UTF-8'?
osm version='0.6' generator='JOSM'
  node id='-1' action='modify' timestamp='2008-03-24T20:00:15Z' visible='true' version='5' lat='51.33620658881399' lon='-1.110167078238406' /
  node id='-2' action='modify' timestamp='2008-03-24T20:00:17Z' visible='true' version='3' lat='51.32968780130509' lon='-1.105419278238406' /
  node id='-3' action='modify' timestamp='2008-11-23T23:13:35Z' visible='true' version='4' lat='51.335710865812395' lon='-1.110190178238406' /
  node id='-4' action='modify' timestamp='2008-03-24T19:59:02Z' visible='true' version='1' lat='51.339031749984365' lon='-1.1094719782384062' /
  node id='-5' action='modify' timestamp='2009-02-08T20:23:09Z' visible='true' version='2' lat='51.32859527098673' lon='-1.104623978238406' /
  node id='-6' action='modify' timestamp='2008-03-06T23:56:13Z' visible='true' version='3' lat='51.33533862363075' lon='-1.110141078238406' /
  node id='-7' action='modify' timestamp='2008-03-24T20:00:18Z' visible='true' version='2' lat='51.33144882779343' lon='-1.106729778238406' /
  node id='-8' action='modify' timestamp='2008-03-24T20:00:15Z' visible='true' version='2' lat='51.33404452463371' lon='-1.109563078238406' /
  node id='-9' action='modify' timestamp='2008-03-24T20:00:18Z' visible='true' version='3' lat='51.33069724452549' lon='-1.106170578238406' /
  node id='-10' action='modify' timestamp='2008-03-24T20:00:16Z' visible='true' version='2' lat='51.33347901246945' lon='-1.1089783782384062' /
  node id='-11' action='modify' timestamp='2008-03-24T20:00:18Z' visible='true' version='2' lat='51.33283981174973' lon='-1.108210978238406' /
  node id='-12' action='modify' timestamp='2008-03-24T19:59:06Z' visible='true' version='1' lat='51.33458104130092' lon='-1.1098647782384061' /
  node id='-13' action='modify' timestamp='2008-03-24T20:00:18Z' visible='true' version='2' lat='51.33205493365529' lon='-1.107219678238406' /
  node id='-14' action='modify' timestamp='2008-03-24T19:59:06Z' visible='true' version='1' lat='51.3289742121334' lon='-1.1049147782384061' /
  node id='-15' action='modify' timestamp='2009-02-28T18:55:52Z' visible='true' version='1' lat='51.327892080198396' lon='-1.1038989782384063' /
  node id='-16' action='modify' timestamp='2009-02-08T20:28:07Z' visible='true' version='8' lat='51.34113032400358' lon='-1.1091698782384058' /
  node id='-17' action='modify' timestamp='2008-05-05T23:20:57Z' visible='true' version='5' lat='51.33474511581643' lon='-1.109966478238406' /
  node id='-18' action='modify' timestamp='2008-03-24T20:00:12Z' visible='true' version='2' lat='51.3288403329262' lon='-1.1048148782384062' /
  node id='-19' action='modify' timestamp='2008-05-05T23:20:58Z' visible='true' version='2' lat='51.328646563020584' lon='-1.1046696782384058' /
  node id='-20' action='modify' timestamp='2008-11-23T23:13:35Z' visible='true' version='6' lat='51.34202318530859' lon='-1.1092362782384058' /
  node id='-21' action='modify' timestamp='2006-12-03T20:59:29Z' visible='true' version='1' lat='51.327791595804385' lon='-1.103787178238406' /
  node id='-22' action='modify' timestamp='2009-02-28T18:55:55Z' visible='true' version='2' lat='51.32740085648906' lon='-1.103434678238406' /
  node id='-23' action='modify' timestamp='2008-03-24T19:59:09Z' visible='true' version='1' lat='51.33110558110489' lon='-1.106475878238406' /
  node id='-24' action='modify' timestamp='2008-03-24T19:59:03Z' visible='true' version='1' lat='51.33699086699455' lon='-1.109961478238406' /
  node id='-25' action='modify' timestamp='2008-03-07T00:06:14Z' visible='true' version='4' lat='51.3370644864' lon='-1.109942578238406' /
  node id='-26' action='modify' timestamp='2009-02-28T18:55:55Z' visible='true' version='5' 

[mkgmap-dev] Style file not working

[MarkS]

Does anybody know why the following lines style file doesn't work for me:

maxspeed  78  maxspeed  82 {set mcssl=50}
highway=*  mcssl=50 [0x03 resolution 22]

This is the whole file and I get the error:

Error in style: Error: (lines:2): Invalid rule file (expr )
Could not open style null

The problem seems to be the first line and seems to be related to having 
maxspeed twice.


I then tried the following in the lines file:

maxspeed  78 {set over78=true}
over78=true  maxspeed  82 {set mcssl=50}
highway=*  mcssl=50 [0x03 resolution 22]

which produced the following error:

Error in style: Error: (lines:2): Invalid operation 'g' at top level
Could not open style null

which seems a very odd error as the only place the file contains a 'g' 
is in highway.


I've tried to debug this using the source code but got nowhere. So if 
anybody can tell me where I'm going wrong or where to start debugging 
that would be great.


I'm using mkgmap r1165.



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Styles and Typs

[MarkS]

At the momment mkgmap comes with two buit in styles (default and 
noname). I'm ignoring test which seems to be empty.

Are we looking to expand the number of styles included in mkgmap itself 
(for example I have something that divides roads by the maxspeed tag). 
If not should we setup a wiki page with links to other user defined 
styles for people to download?

Secondly would it be possible to add TYP files into the style and then 
get mkgmap to write the TYP file to the output folder and include it in 
a GMAPSUPP file (I guess mkgmap would need to correct the Family ID as 
part of this process). Some styles are dependent on having a paticular 
TYP file to work properly (eg. maxspeed style) so if the style was 
distributed (by whatever method) then the TYP file needs to be 
distributed to.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Can you set background colour in a TYP file?

[MarkS]

Ralf Kleineisel wrote:
 Mark Burton wrote:
 
 Has anyone managed to change the background colour on an etrex vista
 hcx?
 
 My TYP works on my eTrex Legend HCx which is very similar.
I've got it to work on a Legend HCx except it I zoom a very long way out 
when it reverts to yellow.

However, I seem to recall that when I first played around with this the 
background reverted to yellow quite early on as I zoomed out. In the end 
this problem went away when I reduced the number of levels in my style 
file - originally I was using the default style which seemed to create a 
lot of levels (if you combined what was in the options file and extra 
resolutions specified in the lines/points files). Whether this was 
connected in any way I don't know.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Can you set background colour in a TYP file?

[MarkS]

Mark Burton wrote:
 Hi Mark,
 
 However, I seem to recall that when I first played around with this the 
 background reverted to yellow quite early on as I zoomed out. In the end 
 this problem went away when I reduced the number of levels in my style 
 file - originally I was using the default style which seemed to create a 
 lot of levels (if you combined what was in the options file and extra 
 resolutions specified in the lines/points files). Whether this was 
 connected in any way I don't know.
 
 That's interesting, what levels are you using now?
 
 Cheers,
 
 Mark
This is what I have at the moment:

levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18, 6:16, 7:12

I also (try) to make sure that only these resolutions are used in the 
lines and points file. I seem to recall that the mkgmap default style at 
the time (about 3 months ago) used some resolutions that weren't defined 
in options file. I guessed that maybe extra levels were being created 
inside mkgmap, which caused the total number of levels to exceed the 
maximum a map file can cope with and that maybe this caused the 
background to disappear as I zoomed out.

This was about 3 months ago and I have no idea if the two issues were 
truely connected.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Possible maxspeed patch

[MarkS]

WessexMario wrote:
 With this maxspeed debate, aren't we confusing two different data items.?
 
 maxspeed is defined as the legal speed limit, but the speed we are 
 discussing here is an average transit speed for routing purposes.
 
 The 'real' maxspeed would be useful in applications like excessive speed 
 warning, or notification of changes to the limit while in transit, even 
 (on the future) as a physical limit for automated vehicles; as the 
 average transit speed is a different value and is what is needed for routing
 
 Shouldn't a separate data item (eg routingspeed) be used, leaving 
 maxspeed for what it is, the legal limit?
Agreed. I suggested early that perhaps this option would be better 
labelled speed rather than maxspeed. However, routingspeed is 
probably more specfic and might be even better.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Possible maxspeed patch

[MarkS]

Greg Troxel wrote:

 
 This all makes sense, but it seems that the real problem needs to be
 solved at the database semantics level.  Patching it up in mkgmap
 certainly is useful, but other routing engines should have a consistent
 view.  I think we're really talking about given a .osm file and a
 particular way, how do you decide what speed you should assume one can
 drive on that way. 
 

I agree with the principle. However, I guess a limitation on mkgmap 
routing is that mkgmap doesn't do the routing it supplies that data to 
garmin who do the routing. We can affect the data going in but not the 
routing algorithms. I was testing yesterday and road speed doesn't seem 
to make much difference to mapsource routes. Mapsource seems to follow 
the road class (set in preferences) and only allows speed to affect the 
route if it makes a major difference.

However, this patch doesn't really attempt to provide a calculation of 
the correct speed. All it tries to do is make it more flexible to choose 
what method mkgmap uses to set the road speed attribute. In its current 
form it provides four options (which compares with the two we have 
available at the moment). If this patch were added we could add extra 
methods in the future. For example last night I added an extra option 
for a new method to calculate the speed which took 90% of maxspeed, 
unless it was a single track road in which case it took 60%. I could 
easily try this alternative method by using maxspeed=MarkS. I don't 
pretend this new method is any good and I don't see much point in 
showing this extra code off. But what this method did show was that 
having maxpseed= allows extra methods to be added easily. If 
maxspeed patch is added then a future job is to come up with better 
speed algorithms.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Possible maxspeed patch

[MarkS]

Marco Certelli wrote:
 Hello,
 
 as I said some months ago, deciding the right speed to set in the garmin map 
 for each way shoud be a new mkgmap function.
 
 The function should take into consideration:
 
 the assigned OSM highway tag
 the assigned OSM maxspeed
 the number of crosses per km (maybe the number of routing nodes / lenght)
 the number of traffic_lights per km
 the curves ((for each node, add the angle) / lenght))
 
 
 All these info shoud be properly combined to tell how fast a vehicle can run 
 on that road. We should experiment a lot...
 
 But maybe this is too far away ;-)
 
 Ciao, Marco.
I agree with this. We have a level crossing near us where the barriers 
are down for around 2-3 minutes and are down around 10 times an hour. At 
the moment routing always goes across the crossing rather than using an 
alternative route (which takes about 30 seconds longer but which would 
be quicker on average).

I do have doubts how it work in practice. In practice the average speed 
of a road comes from a mix of fast sections (ie. plain road) and slow 
sections (junctions, lights...). Whilst we can count crossings/traffic 
lights along a road and get the overall speed for the road right, it 
doesn't work so well if you turn on/off along the road.

This patch allows you to switch the methods used to set the road speed 
in the IMG file. At the moment it simply switches between maxpseed and 
the style file setting. However, it would be easier to include an extra 
option (eg. MarcosMethod) to offer extra options if somebody wants to 
write it.  Maybe it would be better to change the option in the patch 
from maxspeed to speed.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Selectable maps on gps

[MarkS]

Clifford Nolan wrote:
 I can't seem to find the right options so that I can output more than 
 one map within a gmapsupp.img file and have those individual maps be 
 selectable with the ticks on the gps itself.
 
 For example, if I have file_A.osm and file_B.osm  how can make these two 
 separate maps show up separately on the gps so I can select them?
 
 Thanks in advance,
 Cliff
My approach is:
- Run splitter on a UK extract
- Run mkgmap with the GMAPSUPP option turned on to create a single UK 
file with (in my case) 11 sub-maps (one for each area). Make sure family 
name is defined in the options.
- Run mkgmap again using a different style (in this case a style file 
showing speed limits and nothing else) again with the GMAPSUPP option 
turned on so I get GMAPSUPP.IMG as an output. Make sure family name is 
defined.
- Run wgmaptool to combine these two GMAPSUPP.IMG files together. At the 
same time I also add in typ files and a couple of other GMAPSUPP.IMG 
files (one has contours and one is from OpenMTB). This creates a new 
GMAPSUPP.IMG file with all the individual files combined.
- Copy to an SD card and put it in the garmin
- In the garmin go to the list of the maps (which is very long in my 
case), press the menu button and it then lets you show/hide all the maps 
  with the same family name in one go (so for example I can turn OpenMTD 
on/off in one go).

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Possible maxspeed patch

[MarkS]

Here is a possible patch for maxspeed.

Around here lots of roads have been tagged with their speed limit (which 
is 60mph). However, these are unclassified roads and you are unlikely to 
get above 40mph. At the moment the default behaviour of mkgmap is set 
overide the style file for these roads and set the road class 
appropriate to 60mph, which is too fast.


I could turn on ignore-maxspeeds which would fix these roads but in turn 
that would result in the trunk roads in town getting too high a speed.


The patch attempts to overcome this by offerring an extra option for 
ignore-maxspeed, so the options become


[Default] - Use maxspeed if it exists, otherwise Road Class from the style

ignore-maxspeeds - Use road class from the style file
ignore-maxspeeds:0 - Use road class from the style file
ignore-maxspeeds:1 - Use maxspeed from the style file
ignore-maxspeeds:2 - Use the lower of road class and maxspeed

Effectively option 2 solves my problem. The other numbered options are 
there to reproduce existing behaviour using a number. The non-numbered 
option is to keep compatiblity with existing code.



Note:
- This is the first patch I've done so I might have gone about it 
completely the wrong way. If so I'm sorry and please give me some hints
- It is also the first Java code I've ever edited so I might have done 
something wrong! All I can say is that it worked for me !
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1145)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy)
@@ -100,7 +100,7 @@
private final Rule nodeRules;
private final Rule relationRules;
 
-   private boolean ignoreMaxspeeds;
+   private int ignoreMaxspeeds=1;
 
class AccessMapping {
private final String type;
@@ -141,8 +141,17 @@
wayRules = style.getWayRules();
nodeRules = style.getNodeRules();
relationRules = style.getRelationRules();
-   ignoreMaxspeeds = props.getProperty(ignore-maxspeeds) != null;
+   String ignoreMaxspeedsPar = 
props.getProperty(ignore-maxspeeds, null);
 
+   if(ignoreMaxspeedsPar != null){
+   try {
+   ignoreMaxspeeds = 
Integer.parseInt(ignoreMaxspeedsPar);
+   }
+   catch (Exception e) {
+   ignoreMaxspeeds = 0;
+   }
+   }
+
LineAdder overlayAdder = style.getOverlays(lineAdder);
if (overlayAdder != null)
lineAdder = overlayAdder;
@@ -903,17 +912,28 @@
}
 
int speedIdx = -1;
-   if(!ignoreMaxspeeds) {
-   // maxspeed attribute overrides default for road type
-   String maxSpeed = way.getTag(maxspeed);
-   if(maxSpeed != null) {
-   speedIdx = getSpeedIdx(maxSpeed);
-   log.info(debugWayName +  maxspeed= + maxSpeed 
+ , speedIndex= + speedIdx);
-   }
+   String maxSpeed;
+   switch(ignoreMaxspeeds)
+   {
+   case 0:
+   // Use the style file and ignore the maxspeed tag
+   road.setSpeed(gt.getRoadSpeed());
+   break;
+   case 1:
+   // Use maxspeed tag, only use the style file if 
maxspeed is missing (the default if ignoreMaxspeeds is not defined)
+   maxSpeed = way.getTag(maxspeed);
+   if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed);
+   road.setSpeed(speedIdx = 0? speedIdx : 
gt.getRoadSpeed());
+   break;
+   
+   case 2:
+   // Use the lower of the maxspeed tag and the style file 
value
+   maxSpeed = way.getTag(maxspeed);
+   if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed);
+   road.setSpeed(speedIdx = 0? 
Math.min(gt.getRoadSpeed(),speedIdx ) : gt.getRoadSpeed());
+   break;
}
 
-   road.setSpeed(speedIdx = 0? speedIdx : gt.getRoadSpeed());
-
boolean[] noAccess = new boolean[RoadNetwork.NO_MAX];
String highwayType = way.getTag(highway);
if(highwayType == null) {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Possible maxspeed patch

[MarkS]

MarkS wrote:

Mark Burton wrote:

Hi Mark,



I'll change it. The original intention was to avoid creating another 
option (as I'd seen some comment about yet another option). But I'm 
happy to go down that route.


Here's a revised version of the patch picking up the suggestions Mark made.

This adds a new option maxspeed. This can be set to:

ignore - The maxspeed tag is ignored and road class from the style 
file is used.
heed - The maxspeed tag is used. If it doesn't exist then road class 
from the style file is used

lower - The lower of the maxspeed tag and the road class is used.
higher - The higher of the maxspeed tag and the road class is used.

If maxspeed isn't defined then the patch will look for ignore-maxspeed 
; if ignore-maxspeed is present then it will just use the road class 
from the style file. This will ensure current usage isn't broken.


If maxspeed and ignore-maxspeed are not defined then it will default 
to heed which reproduces current behaviour.


Mark
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1147)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy)
@@ -101,6 +101,7 @@
private final Rule relationRules;
 
private boolean ignoreMaxspeeds;
+   private String MaxspeedsPar;
 
class AccessMapping {
private final String type;
@@ -143,6 +144,18 @@
relationRules = style.getRelationRules();
ignoreMaxspeeds = props.getProperty(ignore-maxspeeds) != null;
 
+   MaxspeedsPar=props.getProperty(maxspeed,null);
+   if(MaxspeedsPar==null){
+   // If the maxspeeds parameter has not been defined then 
fall back to looking at the ignore-maxspeeds parameter
+   if(ignoreMaxspeeds){
+   MaxspeedsPar=ignore;
+   }
+   else{
+   MaxspeedsPar=heed;
+   }
+   }
+   MaxspeedsPar=MaxspeedsPar.toLowerCase();
+
LineAdder overlayAdder = style.getOverlays(lineAdder);
if (overlayAdder != null)
lineAdder = overlayAdder;
@@ -903,17 +916,30 @@
}
 
int speedIdx = -1;
-   if(!ignoreMaxspeeds) {
-   // maxspeed attribute overrides default for road type
-   String maxSpeed = way.getTag(maxspeed);
-   if(maxSpeed != null) {
-   speedIdx = getSpeedIdx(maxSpeed);
-   log.info(debugWayName +  maxspeed= + maxSpeed 
+ , speedIndex= + speedIdx);
-   }
+   String maxSpeed;
+   if(MaxspeedsPar.equals(ignore)){
+   // Use the style file and ignore the maxspeed tag
+   road.setSpeed(gt.getRoadSpeed());
}
+   else if(MaxspeedsPar.equals(heed)){
+   // Use maxspeed tag, only use the style file if 
maxspeed is missing
+   maxSpeed = way.getTag(maxspeed);
+   if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed);
+   road.setSpeed(speedIdx = 0? speedIdx : 
gt.getRoadSpeed());
+   }
+   else if(MaxspeedsPar.equals(lower)){
+   // Use the lower of the maxspeed tag and road class 
from the style file
+   maxSpeed = way.getTag(maxspeed);
+   if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed);
+   road.setSpeed(speedIdx = 0? 
Math.min(gt.getRoadSpeed(),speedIdx ) : gt.getRoadSpeed());
+   }
+   else if(MaxspeedsPar.equals(higher)){
+   // Use the higher of the maxspeed tag and the style 
file value
+   maxSpeed = way.getTag(maxspeed);
+   if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed);
+   road.setSpeed(speedIdx = 0? 
Math.max(gt.getRoadSpeed(),speedIdx ) : gt.getRoadSpeed());
+   }
 
-   road.setSpeed(speedIdx = 0? speedIdx : gt.getRoadSpeed());
-
boolean[] noAccess = new boolean[RoadNetwork.NO_MAX];
String highwayType = way.getTag(highway);
if(highwayType == null) {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Possible maxspeed patch

[MarkS]

Florian Lohoff wrote:

 
 Wouldnt it make sense to make it possible to apply factors based on road
 class to the maxspeed setting?
 
 e.g unclassified - maxspeed*0.6 
 tertiary - maxspeed*0.8
 
 OTOH this should all be the responsibility of the routing engine
 and at the moment as i understand we abuse the maxspeed (OSM) to set
 an average speed in the Garmin dataset - not something like a 
 speed limit which is obviously broken anyway and just some
 idea to make use of the maxspeed ...
 
I'd come across this whilst setting up the patch. The main road near me 
has maxspeed=50mph on it. This then gets converted to kilometers and 
just scrapes over the 80kph barrier and gets a road class of 5 which 
effectively assumes you will never drop below the speed limit.

My feeling was that there might be a case for another patch which 
reduces the maxspeed by a certain amount (eg. 5mph or by 20%) when 
deciding which road class to allocate. This probably needs (yet) another 
parameter.

My patch isn't really concerned with how the maxspeed tag is converted 
to a road class. It is aimed at deciding whether to use set the road 
class from the style file, the maxspeed tag (however that is translated 
to road class) or both.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Overlays and routing

[MarkS]

Thilo Hannemann wrote:
 There is a bug in the overlays handling that breaks routing. Please try 
 the attached patch. I don't know whether it works with the current 
 mkgmap, but revision 1136 should be fine.
 
Thanks for the confirmation that the default version of mkgmap doesn't 
handle this.

I tried the patch (and have to admit it is the first time I've compiled 
mkgmap myself - up to now I've only downloaded it so I could see what 
command line options there were). The patch worked fine on the tests 
I've run so far.

I presume I was running against the latest version of mkgmap because I 
updated my copy of the code subversion last night.

Thanks for your help on this.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Overlays and routing

[MarkS]

Felix Hartmann wrote:

 overlays file contains just this:

 0x123:   0x23, 0x02

 0x23 is a non-routable type. Try 0x03 and 0x02 for example and it should 
 work.

I'd hoped that 0x02 would make the way routable and that 0x23 would then 
be used for extra decoration (in this case one way arrows on the road 
were being added by a type file that defines arrows for 0x23).

If I enter: 0x123:  0x02, 0x03 in overlays won't this create two 
routable ways in exactly the same place?

If I enter: 0x123: 0x02, 0x02 this would seem to create two routable 
ways of exactly the same type. But I can't add one way arrows.

I feel like I'm missing something here.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] compiled mkgmap binary with contour option

[MarkS]

Clinton Gladstone wrote:
 On Thu, Aug 6, 2009 at 5:47 AM, maning
 sambaleemmanuel.samb...@gmail.com wrote:
 Any download link of mkgmap binary with the contour generation options?

 I can't find r1079 in the mkgmap download site
 
 Er... don't all the most recent binaries (after the contour commit)
 contain the contour options?
 
 Or was this removed when I wasn't paying attention?
 
 Cheers.

According to this post: 
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/002582.html

they seem to have been removed in r1080.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Routing across multiple tiles

[MarkS]

Ralf Kleineisel wrote:
 On 07/30/2009 11:25 PM, MarkS wrote:
 


Thanks for this. I've tried it but it doesn't seem to make much 
difference. A couple of routes did calculate different (in fact one was 
a bit odd as it took the M4 across the Severn Bridge and then the A48 up 
the side of the Severn before joining the M5, rather than just going up 
the M5).

However, whilst some longer distances (over a couple of tiles are 
working), shorter ones sometimes break (unless within a single tile).

Here is what I can tell:
- The route is more likely to calculate in mapsource if I prefer 
highways. Using a garmin map it mapsource will calculate regardless of 
prefernce.
- My Etrex has the same sort of issues (not exactly the same). Routing 
is more likely to work on quickest calculation than best route.
- It isn't distance related (some routes were much longer than others)
- It isn't purely crossing tiles (some crossing one tile, or going via 
another fail).
- Cornwall and Mid-Wales seem to have more problems with routing to/from 
(note: might just be where I placed a marker rather than the whole of 
the area).

It looks a bit as if a route that is more likely to involve minor roads 
(either because of the area or the preferences) the more likely a 
problem will occur.




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Routing across multiple tiles

[MarkS]

Ralf Kleineisel wrote:

On 07/28/2009 08:04 PM, MarkS wrote:

However, if I route across multiple tiles then it always fails. 
Mapsource just spends ages and then draws a straight line whilst my 
garmin counts to 100% and says their was a calculation error.


It does work for me. I routed successfully through half of Germany and the
Netherlands with a map made with r1065. Used Geofabrik Europe data and
mkgmap-splitter.

What are the command line options you used?


These are the command lines I just tried with.

java -Xmx1200m -enableassertions -jar ../splitter/splitter.jar
--max-nodes=150 ../great_britain.osm

java -Xmx1200m -jar ../mkgmap-r1099/mkgmap.jar --latin1
--remove-short-arcs --lower-case --preserve-element-order
--location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args

They seem to improve the situation slightly (it will sometimes route
across a whole tile). However, equally it fails to route sometimes even
when the start and end are within the same time. For example in the
attached gdb file it fails to route from Cornwall to Wales (same tile).

A number of other routes (eg. Bramley to Hol, Sherfield to Hol)
also fail to calculate, whereas M4 to A1 calculates fine and covers
the same sort of tiles.

All the routes have been tried in Mapsource (v.6.15.6), altough I've had
similar behaviour in 6.13.7.

I've also done a bit of experimenting:

- My routing preference has been set at the mid point. If I move the
slider two notches up towards prefering highways then I don't have a
problem. suggesting that it might be complexity of the route.
- In a test (on a separate machine) against a Garmin map, the gamin maps
had no problem with the routing.
- Using splitter with less max-nodes (and therefore more tiles) makes
the situation worse.

I wonder if it is something to do with minor roads (and inter-tile
connections). Maybe they get a higher class on mkgmap than on the garmin
maps. This allows more complex routes, which eventually overloads the
routing calculation and it fails.




TestRoutes.gdb
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Routing across multiple tiles

[MarkS]

I'm trying out maps with routing turned on. The routing seems to work 
fine within a single map tile, it also works fine when I route to a 
neighbouring tile.

However, if I route across multiple tiles then it always fails. 
Mapsource just spends ages and then draws a straight line whilst my 
garmin counts to 100% and says their was a calculation error.

Am I doing something wrong or is this something we are aware of?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Routing across multiple tiles

[MarkS]

Mark Burton wrote:
 Hi Mark,
 
 I'm trying out maps with routing turned on. The routing seems to work 
 fine within a single map tile, it also works fine when I route to a 
 neighbouring tile.

 However, if I route across multiple tiles then it always fails. 
 Mapsource just spends ages and then draws a straight line whilst my 
 garmin counts to 100% and says their was a calculation error.

 Am I doing something wrong or is this something we are aware of?
 
 I believe that routing across multiple tiles generally works OK.
 
 You don't say anything about how you produced your tiles. Are you using
 splitter.jar? What options are you using?
 
 Cheers,
 
 Mark

Sorry forgot to add that bit. I'm using splitter on the UK extracts from 
geofabrik.

The most recent trials have used r1099, but before that I was using 
r1067 and r1072 all with the same results.

As I say going from one tile to an adjacent one works; but anything with 
an intermediate tile fails. I've tried various routes so I believe the 
problem is general (for me at least!) rather than a specific road that 
is causing the problem.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Routing across multiple tiles

[MarkS]

Mark Burton wrote:
 Hi Mark,
 
 Sorry forgot to add that bit. I'm using splitter on the UK extracts from 
 geofabrik.
 
 OK.
  
 The most recent trials have used r1099, but before that I was using 
 r1067 and r1072 all with the same results.
 
 OK.
  
 As I say going from one tile to an adjacent one works; but anything with 
 an intermediate tile fails. I've tried various routes so I believe the 
 problem is general (for me at least!) rather than a specific road that 
 is causing the problem.
 
 Testing with mapsource on tiled maps of the UK and the Netherlands, I
 can route across multiple tiles (in one case, I counted 7 tiles).
 
 However, mapsource often gives up when trying to route long distances
 (especially with the UK map compared to the NL) so I wonder if there's
 some complexity contstraint that we're not adhering to.
 
 But to answer your original question, multiple tiles can be routed
 across.
 
 Cheers,
 
 Mark

Thanks for the feedback. I've just done a new map rerunning splitter and 
mkgmap r1099 again but I get the same problem. At least you've confirmed 
it should work so I'll try and do some more thorough testing to see if I 
can pin down what I'm going wrong.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev