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=moto
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
hem into the wiki.
> Do you mean this page http://wiki.openstreetmap.org/wiki/Mkgmap/dev?
>
> On 23 March 2011 11:53, MarkS <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 mkgm
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 o
maning sambale wrote:
> I am trying to create a nightmode styling for my osm-ph gps maps. A
> good inspiration are radarmaps:
> http://justin.everett-church.com/ymaps/radarMaps.html
>
> Please share some tips in creating this style.
>
> Another thing, this maybe far fetched, but is there any desk
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
> i
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 re
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
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
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
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
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 d
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.
Howeve
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 ea
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 e
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 pe
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
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 pickin
Mark Burton wrote:
> Hi Mark,
>
> Thanks for the contribution - it sounds like a good idea.
>
> One thought, how about using words and not numbers, words are easier to
> interpret when you come back to them 3 months (5 minutes?) later. So
> you could have something like:
>
> ignore-maxspeeds (sa
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
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
> sepa
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.
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 wa
I've just discovered the overlays file but eveytime I use it routing
breaks for any road where an overlay is used (mapsource either crashes
or it just draws a straight line). These are very short routes (a few
hundred meters) and work if I turn the overlay off.
I'm confident the overlay is work
maning sambale wrote:
> On Thu, Aug 6, 2009 at 10:28 PM, Steve Ratcliffe wrote:
>> and the only one missing is for aster
> Aww shucks! This is what I am after (geotiff aster)
>
>
This post:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/002703.html
seems to indicate the code is in there
Clinton Gladstone wrote:
> On Thu, Aug 6, 2009 at 5:47 AM, maning
> sambale 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 c
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
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
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
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 ag
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
garmi
31 matches
Mail list logo
