On 28/01/10 13:25, svn commit wrote:
Version 1524 was commited by markb on 2010-01-28 13:25:35 + (Thu, 28 Jan
2010)
Let the background polygon (type 0x4b) cover the whole map area.
I forgot to say when this patch came out: what if the polygon really
is too big?
Garmin maps may only
Hello
What I was suggesting is that when mkgmap finds a line it looks in the
line style no other, when it finds a polygon it looks in polygon
no other. There would be no order or priority, mkgmap would look
This is not so easy, because you don't know if something is a line or
a polygon
On 30/01/10 13:58, Felix Hartmann wrote:
Continue works. But not without actions (ie it is as if without_actions is
always given).
a) Sorry, are you implementing now without_actions? In the trunk
with_actions means, actions get carried forward, else no actions get
carried forward. I did
That is exactly how it does work on the branch and how it is meant to
work on trunk although as usual the random ordering of actions will
make it unreliable.
It is worth pointing out that the name command works like 'add' and
not like 'set', so the correct result of:
highway=path { name 'A'
On 01/02/10 15:03, Felix Hartmann wrote:
So
highway=path {set name=a}
highway=path {set name='${name} path'}
Should result in a path named: /a path/ whereas not using set the result
would be a simple /a/
Yes exactly
WAY 1
highway=path
WAY 2
highway=footway
lines
highway=path {set name=a}
On 02/02/10 21:08, Felix Hartmann wrote:
Is this branch meant to be faster?
Not yet! I will be trying a few things out on the branch.
I'll announce or make an obvious comment when things are faster.
..Steve
___
mkgmap-dev mailing list
Hi
*trunk:* start: compilation 14:44:17 austria end compilation 14:49:50
austria = 5:33
*style-speed: *start compilation 14:50:15 austria end compilation
14:54:11 austria = 3:56
--- A style-file optimised for the old handling took more or less 3:10.
So a large part of the speed decrease
Hi
I ran the following against the Geofabrik Austria extract.
In all cases the only option other than style-file was --remove-short-arcs.
speed branch r1559, openmtbmap-r18: 2m41
trunk r1557, openmtbmap-r18: 3m16
pre-merge r1455 openmtbmap-r7 : 2m49
So as far as the style code
On 04/02/10 16:32, Felix Hartmann wrote:
Hi, I just discovered a bug (this is happening on both trunk as well as
style-speed).
Yes it sounds familiar.
I'll add the following test.
WAY
highway=road
mtb:scale=2
mtb:scale:uphill=yes
lines
( mtb:scale=* | mtb:scale:uphill=* )
{ set
Hi everyone,
After many tries from latest version 1560 to 1494, I cannot use sea
generation with multipolygon option after version 1512. Something seems
to be broken or you might forget to explain how to use it with latest
changes.
I have tracked down what is happening. It is due to the
for setting the name. BTW is the --name-tag-list
option still usefull. I think it can be better done directly from the
style-file (or is it faster to do via name-tag-list??).
I think it is useful. Obviously not so much for your style as it
sets a constructed name on most things itself.
But
On 10/02/10 21:11, Mark Burton wrote:
I just noticed that the recent changes to the style engine have broken
my map. I think it's possibly down to me using 'continue' in these
rules (that appear before the rules that generate the roads):
highway=* bridge=yes { delete 'ref'; delete 'int_ref';
Hello
On 12/02/10 10:24, Minko wrote:
Simplification looks like this, where the two
vertical border lines are not supposed to be there:
http://img63.imageshack.us/img63/1002/bordersnl5.jpg
Thanks for that image as it shows the problem clearly.
If the boundaries were being drawn as areas,
On 12/02/10 18:18, Chris-Hein Lunkhusen wrote:
I created a test map of Tokyo and want to use the name:en
tag for the names.
But I found that changing the name_tag = name:en in the
options file is not working.
The option is name-tag-list and not name_tag, if that wasn't just a
typo.
I had
The default style gives an example with name_tag. So this should be
corrected.
So it does :( That must have been from when you could just give one
name and not a list. I'll change it now.
..Steve
___
mkgmap-dev mailing list
I checked with git-bisect and found that this bug was introduced in r1562.
Your email crossed with the fix for the exception going in. However
it appears to now just not work - I see an empty map.
Bear with me a few more minutes.
..Steve
___
On 16/02/10 20:20, Ævar Arnfjörð Bjarmason wrote:
After upgrading from r1441 to r1572 using --map-features broke for me:
OK that should be fixed now. Let me know if there are any further problems.
Regards,
..Steve
___
mkgmap-dev mailing list
On 16/02/10 15:11, Martin Simon wrote:
I don't know if this helps, but I have to specify the *full* path of
my typ files to get them included. they are in another directory.
It might well help, as it is a possible clue to what is happening.
If mkgmap is run in a script and it changes directory
Hi
I think the answer is not so easy. From my point of view: use the latest
one (r1575).
Question to all: Which issues must be fixed before releasing another
stable version?
I think we should update the stable version fairly frequently, every
month or so, but avoiding just after a major
Hi, I'm forwarding this mail that ended up at the bounce address rather
than going to the list.
Original Message
Subject: resolution and zoom levels in style files
Date: Thu, 25 Feb 2010 03:43:52 +0100
From: Daniela Duerbeck daniela.duerb...@gmx.de
Reply-To:
On 27/02/10 13:23, WanMil wrote:
/**
* Copy the tags of the other element. Only to be used internally
* by subclasses.
* @param other The other element. All its tags will be copied to this
* element.
*/
public void copyTags(Element other) {
if (other.tags != null)
Hi
is there already a new host for the source code?
Or could someone point me to the python file?
Sorry I received the file ages ago, but didn't add it at the time. I
have now done this and it can be accessed at:
http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py
Regards,
Hi
/
| $(MKGMAP) --gmapsupp \
|--family-id=1672 --product-id=1672 1672*.img 1672.TYP \
|--family-id=6324 --product-id=6324 6324*.img 6324.TYP
\
That is supposed to work just as you have it.
I thought there was even a test for it!
I'll investigate.
..Steve
Steve's been handling the MP patches, hopefully he will look at
incorporating that patch.
All of that patch (as far as I can see) was included in the r1607 patch.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi
key=value {name 'alpha'} [0x6005 resolution 20 continue with_actions]
key=value {name 'bravo'} [0x5001 resolution 20 continue with_actions]
key=value {set name=alpha} [0x6005 resolution 20 continue with_actions]
key=value {set name=bravo} [0x5001 resolution 20 continue
Hi
Actually where is the best description/user guide for the different commands
of
the style files? The help for the command line parameters is maintained within
the help parameter of mkgmap, but details of the style-commands are hard to
find. I don't even know a single list on the net
On 31/03/10 08:17, Chris-Hein Lunkhusen wrote:
Hi,
I don't see the --keep-going option working in the recent versions
of mkgmap.
When there is a .NET1 overflow mkgmap stops complete
It only keeps going if there is an unexpected error. For anticipated
errors it stops straight away.
I
On 31/03/10 14:56, Scott A Crosby wrote:
I noticed that mkgmap does not intern any strings. In particular, this
This is true. There is a pending patch that deals with excessive
memory use in a slightly different way which is on the style-speed
branch, with a pre-built one available at the
On 05/04/10 18:35, WanMil wrote:
I started to make very basic checks to get the source of the tile bounds
problems.
I created the attached bbox1.osm and bbox2.osm. Both contain one
rectangular polygon identical to the bounds. After compiling it with the
default style I see in MapSource that
Hello Dani
In the default style, I find in the options:
levels = 0:24, 1:22, 2:20, 3:18, 4:16
But in the files (polygons, lines, points) the following resolutions are
used:
10, 12, 14, 16, 17, 18, 19, 20, 21, 22, 23, 24
I think I have read somewhere that just these from the options may be
On 12/04/10 11:21, Felix Hartmann wrote:
On 12.04.2010 12:10, Steve Ratcliffe wrote:
Great. I really do wonder if all the people that compile worldwide maps,
use --keep-going and therefore don't encounter such problems.
They may not get the actual crash - I don't on the small extract. I
On 12/04/10 11:44, Steve Ratcliffe wrote:
In this area there is definitely a data problem.
Eg: The way: http://www.openstreetmap.org/browse/way/27294429
has lots of repeated nodes.
So the other one was 27294458 and I have now fixed them both and
there are no more errors in the small area I
On 18/04/10 08:37, maning sambale wrote
1. Even though the points style includes only places=*, osb and
keepright code assignment, I still get other POIs in the map (hotels,
shops, etc). Why is this so?
Your info file includes the lines:
# This uses the default style as a base
On 29/04/10 11:25, Valentijn Sessink wrote:
I was wondering what is the difference between --remove-short-arcs and
--reduce-point-density. Their description differs (short-arcs says it
removes things that cause routing problems, while point-density seems
some sort of general simplification),
On 01/05/10 10:52, Felix Hartmann wrote:
Where is TRE4 set in mkgmap?
It is in the LocatorConfig.xml file as poiDispFlag if that is what you
mean. I didn't know that and I have no idea why it should vary by
country, but presumably Bernhard knows or at least has an inkling of why
it might
No I don't think you know what I want. Right now mkgmap sets the value
to 0xc, but I think it has to be 0xd. It is definitely fixed somewhere
and has implications on routing. However it seems to me that the actual
number does not matter, however it matters whether the number is even or
Hi
So do you mean:
rule is given. Quick example
lanes=2 oneway=yes { add mkgmap:road-speed = '+1'; add
mkgmap:road-class = '+1'; set rule=1 }
highway=primary maxspeed=100 {road_class=3 road_speed=4 0x02]
If the tags are: highway=primary, maxspeed=100
then you get road_class=3
and with
If I remember it was you or someone else who insisted that this
information were usable, hence the patch was not applied to trunk. The
list of POI where address info is used, can be found in the older topic.
No other POI are usable for additional info. The patch also removes the
fix my
The string to encode is ½ (1/2 as single character). This is used as
housenumber in Wuerzburg:
http://www.openstreetmap.org/?lat=49.801248lon=9.927579zoom=18
To solve this I increased the byte buffer provided in encodeText by 1.
But I'm not sure if this is the right solution.
The maximum
On 17/05/10 11:50, Claudius Henrichs wrote:
Currently if the name-tag is written in persian or arabic script on a garmin
device it ends up transliterated into latin script. I am not sure if garmin
is doing this internally or mkgmap. Can any developer clear this up?
I am asking because this
There is also something strange about the Russian encoding. The letter
я is translated into â, while I believe the correct transliteration
would be ya or ja, at least at the end of a word. But I can live
with the â, at least it looks like a and is easy to recognize.
You can transliterate
Hi
Okay, there is probably no need to search for the revision that
introduced this bug. I went as far back as rev 500, and there the NOD
flag is already set, which was before we got started with autorouting.
Hence I assume we don't know about its existence, and it has been wrong
from the
already inflicting Mapsource 6.16.1 and Basecamp 3.
OK so I upgraded to 6.16.1, had to upgrade twice to get there.
This means that also if you compile maps that are not routable, you have
to pass the --route parameter. Else the GPS / Mapsource looks into an
empty NOD table and may crash.
In the TREHeader.java (like in the patch from steve) add a one more byte
in first position. If I understand it correctly, this will set the
ominous fourth byte to 01. (Not tested).
In fact the 4th byte that appears in the gmaptool dialog is actually
what mkgmap calls poiDisplayFlags and
You need to combine two different maps of the same area (so most often
one being contourlines) into the same mapset (meaning same tdb/overview
image/mdr/).
OK I have finally reproduced it with your map.
It seems that in fact you have two different map sets with different
family/tdb/etc.
No it's originally two different maps, but they are joined into the same
mapset so they become one map. So if joined, they have the same
How are they joined?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On 27/05/2010 23:43, Steve Ratcliffe wrote:
No it's originally two different maps, but they are joined into the same
mapset so they become one map. So if joined, they have the same
How are they joined?
OK never mind I see how. The srtm set includes the other one and is
not separate
shop=Bäckerei [0x2A05 resolution 24]
will produce an error
Error in style: Error: (points:50): Stack size is 3
It doesn't give an error for me. I suspect that it is causing
a problem in combination with something else.
Could you send me the whole file?
..Steve
I've now got a small example that shows the problem.
No luck so far in finding the flag, if indeed it is just a flag.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Could someone who understands these things please look at the
linesCutEachOther() routine in MultiPolygonRelation.java and
let me know what needs to be done to it. Currently it never returns
true.
..Steve
___
mkgmap-dev mailing list
Hi
A possible way to find the flag:
With MapSource (at least with 6.13) it is possible to include or exclude
the routing data when transferring to the device. If you transfer the
same data twice, one time with, the ther time without the routing data,
A great idea!
Unfortunately my results
Hi Paul
I've got a bug to report for r1651 of mkgmap:
java.lang.ArrayIndexOutOfBoundsException: 3
at
uk.me.parabola.imgfmt.app.labelenc.Format6Encoder.put6(Format6Encoder.java:137)
Thanks for reporting this.
Can you try the latest version where it should be fixed.
..Steve
Hi
Anyway, I found a solution: Update the usedTags of the
RuleSet after merging in the base-RuleSet.
Yes the patch looks correct thanks!
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On 13/07/10 11:44, Markus wrote:
As already mentioned in a previous mail, I'd deem it a useful extension to
make splitter.jar and mkgmap.jar aware of source and target (output)
directories.
Right now I'm thinking about how the source directory can be implemented
for mkgmap.jar in a
Hi
The info for the Restaurant Mitani is:
Mitani
Rablstrasse 45
81669 G 18 85560 Ebersberg
So there seem to be some problems with strings.
I downloaded the area. I see:
Mitani
Rablstrasse 45
81669
which is all fine. I've no idea where the rest of it comes from, were
you using
On 15/07/10 16:46, Markus wrote:
It seems you agree with the general rationale; would you be willing to
integrate this in the next build of mkgmap?
Yes, except that I will modify to take account of absolute paths and
check for the key 'input-file' instead of checking to see if the value
looks
which is all fine. I've no idea where the rest of it comes from, were
you using some option that attempts to fill in town/state information?
No, there should be the city added: München.
81669 München would be correct. But to add the city was a former normal
behaviour of mkgmap.
This
I do not think so. It is a very strange bug. It changes for example
even, if the osm file, the styles, the mkgmap etc. remain the same and
just the typ file is changed.
That kind of points to the problem being in the TYP file - mkgmap
doesn't really do anything to modify
the TYP file, or
Hi
Thanks this option would be useful.
However, the diff is rather ugly, since file write operations are
scattered over a number of classes. Thus the code prepending the pathname
is equally scattered.
I think it would be better to define a method on CommandArgs called
getOutputPath(String
Hello
I dont know if this has been raised before but even mkgmap-1655 could
not produce an .IMG with proper Japanese character encoding.
Do you have a Garmin unit that displays Japanese characters? It would
be great to get this working, but I've never had any way of testing it.
I see the
Hi
Ok I have just understood the problem : I first have to create the img
file, and then to use the --gmapsupp option with the TYP file. This is
:
* java -jar mkgmap.jar --family-id=4242
--style-file=resources/styles/watsan --tdbfile bilbao.osm
* java -jar mkgmap.jar --family-id=4242
On 20/07/10 02:53, Tan, Eng Ten wrote:
Sorry I don't have a Japanese Garmin to test with. I was just using
GPSMapEdit on English Windows with Japanese fonts installed.
Maybe we shouldn't check the code in until it's verified to work on
Garmin devices.
Or if it worked with MapSource that
On 19/07/10 23:04, Daniela Duerbeck wrote:
Steve Ratcliffe wrote:
I do not think so. It is a very strange bug. It changes for example
even, if the osm file, the styles, the mkgmap etc. remain the same and
just the typ file is changed.
That kind of points to the problem being in the TYP
Hi
I have started to implement adding features into the overview
map. You can find ready built jar files on the download page
and in the 'overview' branch in subversion.
It creates the overview map from the .img (as before) and so it
is very quick to try out even on a set of tiles covering a
On 25/07/10 20:41, Felix Hartmann wrote:
okay, creating the overview map from existing .img does not seem to
work. Or I am missing something.
Not sure, it works just like before, except that there is more in the
overview map. If there is only one file on the command line you need
--tdbfile
Hi
Sounds intriguing. What precisely is the overview map for?
It shows the whole area covered by a set of detailed maps. It is
needed by mapsource.
We have always produced an overview map (its called osmmap.img by
default), but it has been empty. It should contain the sea polygons
and main
--area-name=switzerland_26.07.2010_openmtbmap.org 6327*.img
Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 62
at uk.me.parabola.imgfmt.app.BitReader.get(BitReader.java:46)
at uk.me.parabola.imgfmt.app.BitReader.sget2(BitReader.java:70)
(against both
Thanks Felix, I am able to reproduce now. Only seems to happen with
routa
ble maps.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 10/08/10 21:11, Nakor wrote:
I have always wondered what was the osmmap.img for. BTW I do not think
it is packaged if you use the --nsis option.
It is, it wouldn't work otherwise.
you call it baseFilename and then you assign it to MAPNAME and then
the overview map and tdb file are included
On 10/08/10 23:08, Nakor wrote:
On 8/10/2010 6:03 PM, Steve Ratcliffe wrote:
On 10/08/10 21:11, Nakor wrote:
I have always wondered what was the osmmap.img for. BTW I do not think
it is packaged if you use the --nsis option.
It is, it wouldn't work otherwise.
you call it baseFilename
Hi
Exception in thread main java.lang.IllegalAccessError: tried to
access method uk.me.parabola.imgfmt.app.ImgReader.position()J from
class uk.me.parabola.imgfmt.app.trergn.RGNFileReader$RgnOffsets
Any ideas?
I believe that you need to recompile mkgmap from scratch, do 'ant rebuild'.
On 01/09/10 21:17, Ralf Kleineisel wrote:
On 08/31/2010 07:35 PM, Josef Latt wrote:
Am 31.08.2010 18:37, schrieb Johann Gail:
Thats a interesting pattern. Do you create the maps on a multicore
machine (e.g. 8core or 4core with hyperthreading)?
I create the maps on a machine with an AMD
Version 1671 was commited by steve on 2010-09-02 20:58:10 +0100 (Thu, 02 Sep
2010)
output dir
This was the output dir patch by Markus which adds an --output-dir
option. All output files will be created in the given directory.
As always in mkgmap the option will affect the files following
If not, you could upload it to http://files.mkgmap.org.uk/
I uploaded my self created map (OSM-Karte.zip).
Thanks, my internet connection is on a go-slow at the moment and it is
going to take hours to download, so I can't take a look at it just yet.
Sorry
..Steve
On 02/09/10 21:13, Felix Hartmann wrote:
As far as I understand, as soon as I offer mkgmap.jar to download
somewhere, or include it somewhere, I have to host/supply the sourcecode
too (forever - or whatever forever means), or am I wrong?
You certainly don't have to host it forever. You only
Hi
Well linking is not practical, because as said, mkgmap-latest.tar.gz
includes much stuff different from the plain mkgmap.jar. So unpacking
via bash/batch is more complicated (subfolder and other stuff).
Well yes, but I'm not really sure what is being asked then.
It fine to host the plain
Hi
I uploaded my self created map (OSM-Karte.zip).
My internet connection is back to normal now and I downloaded it
and I can see the problem in qlandkartegt - that it is not possible
to select the map '0064 for download.
That doesn't happen in mapsource, and I don't see anything strange
in
some huge benefits to be had from going that route. Perhaps Scott, Steve
and co can chime in with their thoughts on the topic and where they see things
heading from here?
I am entirely in favour of supporting the format. Most importantly, it
seems to me, in splitter, but in mkgmap too.
I'll
Hi
I think that the cycleway=opposite handling would better be implemented
in a style definition. If I remember correctly, the special code in
Osm5XmlHandler was added before continue or continue_with_actions
were implemented in the style processor. Doing it in the style file
should take
On 12/09/10 21:08, WanMil wrote:
Hi,
I have rather finished the changes for the new multipolygon line/polygon
tag handling (see
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q3/008977.html). But I
need some quick help from someone who known the Java internals of the
style processing.
Hi Scott
I am adding support for your binary format to mkgmap itself (not the
splitter).
Now I've done enough refactoring of the XML reader to allow me to
start I have a few questions.
1. Is there an final name for the format and the jar file?
2. Is there an 'offical' download location for a
On 13/09/10 17:55, Scott Crosby wrote:
Not yet. There are too many 'osm binary formats'. I asked for
suggestions on osm-dev yesterday and got 'protobuf binary format'. Do
you have any ideas?
Not really, I'm calling it osmprotobuf at the moment...
I have not thought about how one might
Hi
I still have the same problem with r1671 or later. The problem is caused
by the --index option. Maps generated without --index work fine on
MapSource. Nobody else has this problem?
OK Thanks for the information. I assume you are not using --output-dir?
I'll try building an index before
OK Thanks for the information. I assume you are not using --output-dir?
I'll try building an index before and after r1671 there should be
no difference. Perhaps the file is being created in the wrong
place/wrong name.
Thanks again. I have now found the probable problem and will
get a
Hi
I've just committed a fix for a problem building valid index files
that was introduced in version r1671.
Everyone having problems with the index should upgrade to r1691
(or downgrade to r1670 or lower!)
..Steve
___
mkgmap-dev mailing list
On 15/09/10 12:05, maning sambale wrote:
using 1671, I get these errors:
ava.lang.IllegalArgumentException: InputStream cannot be null
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:117)
Sorry that is a bug that I introduced yesterday in the construction of
the jar
On 16/09/10 01:46, Dmitry Marakasov wrote:
Hi!
I've been using r1625 for some time and it worked pretty well. Recenly,
however, I've found out r1688 was released and tried it out - it died on
the same data r1625 worked fine with.
Sorry about that - it was a bad build as Maning has already
Hi
The changes to read Scott Crosby's binary format are complete (for
mkgmap itself) and I will merge them back soon.
Before that it would be good for as many people as possible to try
it out on their existing XML files, with the options that they
normally use, since the code has been completely
Hi
I haven't tried so far the new binary format. I haven't found a download
for the osmprotobuf.jar. Is there any? Download links should be added to
the documentation and the website if the changes are merged back.
Merging back can happen when I am sure that there is no harm to the XML
mkgmap already works in parallel if you specifiy multiple osm files
which are usually generated by the tile splitter (see parameter
--max-jobs). The advantage of my idea would be to skip the tile splitter
step.
Are you sure?
It is only reading the files that is serialised, the rest runs
On 09/20/2010 07:35 PM, Marko Mäkelä wrote:
On Mon, Sep 20, 2010 at 10:15:58PM +0400, Maks Vasilev wrote:
OMG! sorry :(
But you could rightfully complain that mkgmap silently ignores unknown
command line switches. As far as I understand, the problem is that there
I made a patch to check
On 25/09/10 05:59, Markus_g wrote:
It appears that --generate-sea=polygons no longer works as I get the
following error.
Thanks for reporting this. It should now be fixed in r1706. The fix
relates to --generate-sea=polygons in spite of the commit message.
..Steve
Hi
I have a script that runs the creation of my map every sunday morning.
Today, I got the following error on exactly the same osm data than last
week.
java.lang.NullPointerException
at
uk.me.parabola.mkgmap.osmstyle.StyledConverter.setBoundingBox(StyledConverter.java:399)
Thanks
On 26/09/10 22:58, Greg Troxel wrote:
I'm seeing comits to what I think is the same mkgmap svn with different
version numbers. So am I just missing something obvious, or is there
something unusual going on, or ??
Version 1707 was commited by steve on 2010-09-26 21:23:54 +0100 (Sun, 26
Hi
On 21/04/10 14:12 (yes that long ago...), Jeffrey Ollie wrote:
Has anyone had a chance to try this out? It would be nice to get this
committed if there aren't any issues with it...
Thanks for the patch which is now applied. Better late than never, I
always say...
Cheers,
..Steve
On
Hi Ralf
according to http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules
it should be possible to use the operator = for tag value comparison
in mkgmap style files. But whenever I try this I get an error:
Error in style: Error: (polygons:2): Stack size is 3
Could not open style null
On 05/10/10 12:21, Valentijn Sessink wrote:
smoothness ~ '.*(bad|horrible|impassable)' |
sac_scale ~ '.*(mountain|alpine)_hiking'
You are right, yesterdays fix was a bit rubbish, strange that
none of the tests caught it.
I'll have another attempt at fixing it.
..Steve
On 03/10/10 17:43, aighes wrote:
I have also a problem with coastline. I use
--generate-sea=extend-sea-sectors. Til now, everything was fine (last
rendering 2 weeks ago). Today th hole coastline was flooded. I used mkgmap
version 1708 and Geofabrik-Extract of friday.
Any guesses where I
Hi
is there a place, where I can download r1703? Also I checked the coastlines
of the extract, I split with osmosis. They seems to be ok.
Its now on the download page, and at
http://files.mkgmap.org.uk/download/5/mkgmap-r1703.jar
Thanks
..Steve
Hello aighes
thanks a lot for the old version. r1703 works fine. Everything is correct.
Well that is good as it shows where the problem is, but I need to
track down what the difference is.
Could you upload a tile that doesn't work (the .osm file not
the .img). You can use files.mkgmap.org.uk.
201 - 300 of 1614 matches
Mail list logo
