Hi
> I can reproduce this problem with mkgmap when I rename a
> file from xyz.osm.pbf to xyz.pbf.
Yes files have to end in .osm.pbf ... thought we had fixed this already.
I will change this now, so that they only have to end with .pbf.
..Steve
___
mk
Hi
because in general creating several routable lines on top of each other
is perfectly okay. Are they maybe not correctly connected?
The 'continue' is making *more* lines on top of each other, its not
preventing lines being on top of each other.
I do not see the routing failure with my smal
Hi
A large polygon is split up into many smaller ones. For a tile with a
large area of sea there will therefore be many more polygons in the img
file than you would expect from the number of nodes on the coastline.
So that is one problem. The polygons fragments will be roughly the
same size and
Hi
> WARNING: input file ... has a different sort order (20007 rather than 0
> I have read the thread started Dec. 22nd but the error message doesn't
> disappear.
It doesn't work with the patch applied?
I will commit it now. I hesitated because, with the patch there
would be no warning if the
On 27/12/12 08:46, Henning Scholland wrote:
> Hi,
> is there a possibility to change template of nsis without compiling
> mkgmap by myself?
>
Yes, you can. It first looks for a file named
"resources/installer_template.nsi", so you just have
to create a file with that name.
You could also unzip t
Hi
> is this patch already committed?
No it isn't yet, and that patch doesn't make tdbfile a default
in a way that would affect its use with --index.
Still, you make a good point.
We shall have to think about how this should work. I don't really
like using tdbfile with index to mean create a "
On 25/12/12 22:03, WanMil wrote:
> Attached is a patch that removes the handling of the special tag
> mkgmap:gtype.
Yes get rid of it, thanks.
If we ever wanted to do somthing like this (and I do not) then it
should be implemented as a style rule, something like this:
tag_containing_type != *
On 24/12/12 08:50, Minko wrote:
> Thanks Steve,
> Ubfortunately I'm not familiar with patches so I can't test it.
I've uploaded the jar:
URL: http://files.mkgmap.org.uk/download/80/mkgmap.jar
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgm
Hi Minko
When I'm trying to combine two img tiles from different maps mkgmap gives this
warning:
input file ...img has a different sort order
The attached patch should now fix this.
As an aside, I also noticed that if you put the TYP file first, then
any following .osm files start with numb
Hi
> It would be very easy if it would be possible to stop style-processing
> of actual object, if it matches one rule. E.g.
>
> disused=yes { stop-processing() }
All we need is to put this
disused=yes [ ... ]
at the top of the file, and some way of saying that there is no type.
Could just
Hi
> Ah, yes I had put the typ file before *.img in the args file, see
> http://www.openfietsmap.nl/downloads/osm_combi
OK, that's fine, there is no need to change your script
I was just asking to make sure that I understood what was
happening in your case.
This would work in 2328 because I fix
Hi
OK I've an idea what it might be, since a typ file does not have a sort order.
But then I thought I had dealt with that case, do you put it before the img
files or after?
I should be able to look at it tomorrow
Steve
Minko wrote:
>Another observation:
>
>Including a typ file seems the re
Hi
I was sent a bug report about a NullPointerException which it was later
determined only occurred when --add-pois-to-lines was used.
I managed to reproduce this and have the attached patch as a possible
solution, but wondering if anyone else has seen such a problem.
The problem way I found
Hi Gerd
That works fine now on my test tile.
Thanks
..Steve
GerdP wrote:
>Steve Ratcliffe wrote
>>> Does that mean you see these differences with r2413 or newer?
>> Yes, it is with r2414
>
>Ok,
>Bad luck while testing : I just took tile 63240001 to compare, and a
> Does that mean you see these differences with r2413 or newer?
Yes, it is with r2414
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> I've verified now that the styled-converter "sees" the same data when using
> o5m,
> so output of mkgmap should be similar again.
I'm afraid I don't much, if any difference.
From o5m
http://files.mkgmap.org.uk/download/78/Selection_021.png
From pbf
http://files.mkgmap.org.uk/download/79
Hi
> resolve-optional:
> [ivy:retrieve] conflict on D:\mkgmap\lib\optional\license-1.1.3.txt in
> [optional]: 1.1.3 won
I think that is harmless and anyway I don't know how to get rid of it.
> and some missing gt-* jars
Right, according the final version of the patch:
http://lists.mkgmap.org
> The main difference seems to be polygons.
I used osmconvert to convert the .o5m and .pbf to .osm; they were
identical apart from a difference in the last decimal place of minlon
and maxlat in the elements.
So the problem would appear to be on the mkgmap side, not the splitter
side. Or perha
> Last night i tried o5m also for intermediary format to further speed up
> things:
> 3) data-o5m -> splitter -> tiles.o5m -> mkgmap -> gmapsupp.img
> (1.612.251.136 bytes)
> and a lot of detail is missing?
I see this problem too.
Looking into the differences, there are a few minor differences
i
Hi Gerd,
> OK. I found so many wrong and out-aged help files for splitter, let's see
> how long this one will be usable ;-)
Yes documentation is something that I also want to improve and I have
some ideas, but will finish the other things I've started first.
If there is anything on mkgmap.org.uk
Hi
The new website is ready to start publishing news again - just in
time for Gerd's splitter release.
It is important that we have a place where people can go to see a
summary of all the new feature and progress that has been made, so I
plan to write a story from now on for every significant new
Hi Nick
> Almost every street in Exeter has osm address numbers . I'm keen to
> translate them into a mp format so I can test your latest amazing efforts.
>
> Unfortunately I'm not too sure what to do with the jar .
Since numbers only work with .mp file, there is no need for anything
else and yo
Hi Gerd
> @Steve: Attached is an updated file to replace
> http://www.mkgmap.org.uk/page/tile-splitter
> Please check, I am a beginner with html and my editor complains about
> line 351, whereas html tidy complais about other lines as well.
Thanks Gerd, the web site is written mostly in mediawiki
> Felix Hartmann-2 wrote
>> Also I think most people will want --keep-complete by default, except if
>> overlap is >0
>
> I did not dare to make it the default, but I agree that most people will
> want it.
I'd support making it the default and even removing --overlap and
any of the overlap code.
> @Steve:
> Unfortunately, the scripts that build the snapshots are still not correctly
> filling the splitter-version.properties
Thats because it is built from a clean export of the code, and so there
is no svn information there. Your build file no longer checks for the
.svn directory and so o
On 14/12/12 18:21, WanMil wrote:
>> We have code to avoid placing all those names into the .img,
>> but this is not correct as I just found out... it breaks
>> searching for house numbers.
>
> What a pity... I don't think it's a very urgent task to solve. But maybe
> you can keep in mind that it wo
On 13/12/12 09:55, WanMil wrote:
> I remember that there was an idea to be able to prevent small ways etc.
> to be added to the index, e.g. by adding the tag mkgmap:noindex=true.
> This would not prevent a bench to get address information but it should
> prevent to be searchable via the index.
>
>
On 12/12/12 09:29, Thorsten Kukuk wrote:
> Hi,
>
> the --no-poi-address mkgmap option doesn't work anymore:
>
> Invalid option: 'poi-address'
>
> I assume this is the outcome of the changes in r2386.
Yes, I was wondering if anyone would notice!
So what does this option do? Nick's reason why --no
On 12/12/12 00:46, Richard Welty wrote:
> 6 Empire State Plaza
> Albany, NY 12228-0330
>
> this is the real mailing address for the motor vehicle department, and
> the Empire State Plaza is
> not a street, it's a (rather large) building complex.
Not every postal address is a street address, so if
Hi Felix
Thanks for your thoughts.
> --ignore-maxspeeds , Strong Objection. For a bicycle map it is really
> needed. I don't want mkgmap messing around with maxspeeds. It's also
> about performance, why calculate something if it's not needed.
What do you object to?
I'll explain what I mean by
Hi WanMil
Thanks for your thoughts. I'm building up a good picture of how
many of the options are used now.
Just a couple of points.
> [ --family-id , --family-name etc ]
> Of course keep them. But it would be helpful if at least the wiki gives
> some hints where the different values are used (
Hi Richard,
> as i encounter oddball situations with house numbers, i'll post links to
> examples
> here for consideration. not all of them may be easily solvable, i'm just
> http://www.openstreetmap.org/?lat=42.59767&lon=-73.5522&zoom=17&layers=M
Although that is certainly odd, I think that wo
Hi
On the numbering branch, which you can get from
here: http://www.mkgmap.org.uk/download/mkgmap.html
has the first working house numbers for mkgmap.
It is only for Polish input files and is limited to cases where the
numbers increase along the street, there is not too big a difference
between
t; 0) // TODO temporary, this option will become properly default of on.
addTdbBuilder();
} else if (opt.equals("tdbfile")) {
Index: src/uk/me/parabola/tdbfmt/TestTdb.java
=======
--- src/uk/me/parabola/tdbfmt/TestTdb.java (revision 2396)
+++ src/uk/me/parabola/tdbfmt/
Hi
> As one of the "too many" complainers, my issue was not so much that
> there were a lot of options, but that the typical new person's strategy
> of ignoring them all did not lead to success. What you're doing
> addresses that point, and also reduces unneeded options.
OK, although calling w
On 07/12/12 14:37, Minko wrote:
> Another test: I removed the option --preserve-element-order in my mkgmap
> options and it seems to render the relations fne now...
> Where is this option good for?
With the option it processes the elements in the order that they appear
in the input file.
Withou
Hi
I've been looking into house numbers a little.
They work by giving a range of numbers between two nodes on a road. A
node here is a routing node - where two roads meet - and not the
meaning of node in OSM.
You can say if the numbers are odd, even or both and if there are no
numbers down one
Hi
I've written up my thoughts on each option on the wiki at:
http://wiki.openstreetmap.org/wiki/Mkgmap/dev/option-review
I think there are a few obsolete/unworking options that can be removed
straight away.
I will come up with a mechanism for documenting and applying default
to options and
On 02/12/12 00:41, Greg Troxel wrote:
> I don't understand if the index code is stable enough, but I thought
> that generally people should want this. If that's off, though, it
> makes sense to default to off until such time as it's stable.
Oh I think it is stable enough. Its just that I often
==
--- src/uk/me/parabola/mkgmap/Option.java (revision 2383)
+++ src/uk/me/parabola/mkgmap/Option.java (working copy)
@@ -1,18 +1,14 @@
/*
- * Copyright (C) 2008 Steve Ratcliffe
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the
On 29/11/12 12:19, Richard Welty wrote:
> java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm \
> --index \
> --gmapsupp \
> --remove-short-arcs \
> --description="Emergency Response Map prototype" \
> --add-pois-to-areas \
> --route \
> --family-i
On 29/11/12 11:47, Richard Welty wrote:
> as far as i can recall, moving the input file to the end was the only change
> i made to the arguments. but i could be wrong.
OK. If there are any circumstances where changing the position of either
--index or --gmapsupp makes a difference then it is a bug
Hi
> There's something else that I think is highly non-obvious to new people:
> there are a ton of options (no surprise), but the defaults are not
> really useful. The norm among mkgmap users is to give a large number of
> options, but for some reason (perhaps trying to keep behavior
> consisten
>>> $ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar
>>> >>capitaldistrict-2012-11-23.osm --index --gmapsupp
>>> >>
>> > From mkgmap help:
>> >"Note that option order is significant: An option only applies to
>> >subsequent input files."
>> >So you should put your *.osm file last in the mkgmap ca
Hi
> In some cases, remove-short-arcs affect turn restriction relations, see
> this report https://github.com/maning/osmphgps/issues/48
OK understood. The short arcs need to be lengthened if they
can't be removed without also removing important information.
..Steve
Hi
> what do you mean by boundary nodes? Are these the nodes
> which are needed for tile-to-tile routing ?
Yes, exactly.
This was just my impression looking at this late last night,
I will have to look into the history of the code. I'm on a train heading
towards the floods at the moment, so not
Hi
I made this commit to make remove-short-arcs on by default. Due to my
misconfiguration of the email address it didn't go to the main list.
There is more to this than I thought. I remember the default being 5,
but the code currently has 0 as the default. So 0 shouldn't work
and that ties in w
On 26/11/12 09:25, Minko wrote:
> Maybe you can pick up some ideas how the NZ guys have done it?
> http://code.google.com/p/nzopengps/source/browse/trunk/scripts/processing_library/3_house_numbering.rb
It appears to use a database, rather than working directly from the
osm/pbf, as has the other e
Hi
On this day, 6 years ago, revision 1 was committed to svn.
$ svn log -r1
r1 | steve | 2006-11-26 20:46:08 + (Sun, 26 Nov 2006) | 1 line
Created mkosmgmap project
--
Hi
Does anyone know for sure that if you do not supply this option, you get
routing problems?
I'm either going to make it the default (with --route) or remove it by
the end of the day as it has been annoying me for years!
..Steve
___
mkgmap-dev maili
On 25/11/12 22:10, WanMil wrote:
> Anyhow Steve must have time to implement the garmin format or he must
> tell the list what he thinks how it works so that someone else can try
> an implementation.
I just thought of this today - what I would do is implement street
numbers from Polish format firs
> If you want to compile the sea-generator you need also the
> Geotools_ivy_config-2.patch, see here
> http://gis.19327.n5.nabble.com/PATCH-v1-Precompiled-sea-generator-tp5713654p5714211.html
I'll commit that. There is more to do to enable it to build, but those
dependencies can be checked in wit
On 23/11/12 17:18, GerdP wrote:
> Hi all,
>
> I am working on a better split algorithm. Now I wonder why the split
> algorithm in r202 makes sure that tiles are aligned in a special way. A
> comment in main says:
> // The maximum resolution of the map to be produced by mkgmap. This is a
> val
On 21/11/12 15:45, GerdP wrote:
> d:\splitter\branches\problem-list
> This sub-dir doesn't have a .svn directory (only the topmost directory has
> one with Tortoise svn 1.7.x)
I guess we could just remove the check for .svn
I always check out a branch separately so it always has a .svn
directory
On 21/11/12 15:45, GerdP wrote:
> Please look at the splitter-problem-list-r241.jar from
> http://www.mkgmap.org.uk/splitter/
> I assume the mkgmap-version.properties file is generated by some extra
> script ?
OK got you. Should be fixed now.
..Steve
_
On 21/11/12 15:23, GerdP wrote:
> With r240 I started to implement a version info, but this doesn't work yet.
> @Steve: please can you review the build script? In the jar file I see two
> files:
> mkgmap-version.properties contains the correct svn.version
> splitter-version.properties has the corre
Hi
> I have compiled the map of Cuba with r2332 and noticed no difference
> neither on MapSource nor on HCx or nuvi 300. If you want to have a look
> at the map I can put it somewhere to download.
Hmm, well perhaps I am wrong about it being a recent problem. I
thought that you said that this did
Hi
>> Mapsource and the devices do work very differently when it comes to
>> searching and it is possible that there is nothing that can be done
>> easily.
> I'm aware of such differences, but I had not faced a case like this one
> before, with missing countries (can't type Cuba on nuvi 300 addre
Hi
> Any idea why these differences happen and how to fix them? Why some
> POI/Countries are not found?
I will have a look at your map and see if anything could be changed
to make it work better.
Mapsource and the devices do work very differently when it comes to
searching and it is possible th
Hi
> If possible it would be better to allow using length() on its own in a
> rule. I think sooner or later some style implementors will try rules like:
> length() < 100 { set specialdistance=short }
> length() > 100 & length() < 1000 { set specialdistance=medium }
> length() > 1000 { set speciald
On 31/10/12 15:55, WanMil wrote:
>>
>> Version 2353 was commited by steve on 2012-10-31 14:15:43 + (Wed, 31 Oct
>> 2012)
>>
>> A few tests for WanMil's style functions.
>
> Thanks for adding these tests.
>
> Do you think a "negative" test would also be good?
Thanks, I can add that.
I've been
On 30/10/12 17:49, Minko wrote:
> I noticed that in mkgmap-r2349.tar.gz the address rules file is missing in
> the subdir examples\styles\default\inc\
Thanks. I've just fixed it.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http:
On 28/10/12 21:43, Minko wrote:
> Hi,
> Tested it on the whole Benelux and the results look quite good.
Great
> I have found some glitches with multipolygons however, but I dont know if it
> is related to the patch or an existing problem.
Right, my fix doesn't target multipolygons at all. I tri
On 28/10/12 20:25, WanMil wrote:
> So the mp alg sees the green and red polygon. Nor green neither red
> contain the other polygon completely. The problem lies in the overlap so
> the current mp algorithm ignores this and assumes that green contains
> red - but only if the original green way is not
On 27/10/12 21:02, Minko wrote:
> Steve,
> How do I use this is_closed() in my style files?
> Can you give an example?
My patch attempts to fix the problem without any changes needed to
the style file at all.
The is_closed() will come later.
..Steve
_
> OK here is a first attempt.
There is a major flaw in that patch, as only the Ways that are created
from reading the OSM file are dealt with.
There are many places where Ways are constructed and these never appear
to be closed with that patch.
If patched things so that doesn't happen here:
htt
> The two tags needn't be a memory problem just by changing a few other
> things (I will post a patch within the next days). Anyhow we could
> decide to set mkgmap:closed=true and mkgmap:autoclosing=true only.
> I think mkgmap:closed might make sense to have a chance in the lines
> style to skip
Hi
> Afer a quick code inspection I would say: Looks good! The only thing
> that must be checked carefully is the new meaning of the isClosed()
> method. I am quite sure that there are some places at least in the
> multipolygon code that relies on
> isClosed() == true =>
> getPoints().get(0).equal
m.Element;
import uk.me.parabola.mkgmap.reader.osm.GeneralRelation;
import uk.me.parabola.mkgmap.reader.osm.Node;
@@ -34,7 +33,6 @@
* @author Steve Ratcliffe
*/
public class OsmBinHandler extends OsmHandler {
- private static final Logger log = Logger.getLogger(OsmBinHandler.class);
pu
On 26/10/12 23:38, svn commit wrote:
>
> Version 2341 was commited by steve on 2012-10-26 23:38:41 +0100 (Fri, 26 Oct
> 2012)
> BRANCH: style-include
>
> Bump the style version to 1 and use the new include directive for all the
> address parts that
> are common to the points, lines and polygons f
Hi
> In my test case I haven't seen those issues yet. Even this canal which was
> split in two tiles
> http://www.openstreetmap.org/browse/way/53011144 was rendered as polygon,
> maybe because the first node
> was just within the overlap range (3000) of the other tile?
> So it would only be brok
Hi
> Rule rules;
> + way.addTag("mkgmap:closed",String.valueOf(way.isClosed()));
> + way.addTag("mkgmap:autoclosing", "false");
I don't much like the idea of adding two tags to every single way.
> + // the way may be closed autom
Hi
> - class AbstractMapReader should contain common code in (at least two)
> readers
> - class AbstractMapProcessor should contain common code in (at least two)
> processors
> - class AbstractOSMWriter should contain common code in (at least two)
> writers
Yes, that sounds fine.
> b) The Nod
On 22/10/12 12:34, Minko wrote:
> Thanks Steve,
> I've decided to use a Garmin category for place=locality that will not be
> indexed.
> Downloaded Spain with only place=locality, it won't open in JOSM so I think
> it is better not put it in the index at all ;-)
>
> Any idea what the warning mess
On 22/10/12 09:07, Minko wrote:
> This error was caused in my syle file, where I handled place=locality the
> same as villages:
>
> (place=locality | place=village) & mkgmap:area2poi!=true [0x0b00 resolution
> 21-20 continue]
> (place=locality | place=village) & mkgmap:area2poi!=true [0x0600 reso
Hello Gerd
> no, it is not (yet). I plan to add o5m support to mkgmap soon. With my
> patch you can use splitter
As an aside, what do you think it is about the o5m format that makes
it quicker than pbf?
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@l
On 17/10/12 19:44, Felix Hartmann wrote:
> However actually now that I think about it - I can only come up with one
> explication why rev 105 on splitter was done - that is so that tiles
> don't overlap. Because the current hack means all tiles will be expanded.
Yes, that is exactly right, the til
Hi
> It looks like you got these twisted around. CR is U+000D and LF is
> U+000A.
Oops! well spotted, thanks!
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
On 04/10/12 16:46, Chris66 wrote:
when there is a CR in the input data (coded as "
" or "
" )
splitter writes a real CR (ascii 13) to the output file.
Altough this is still legal XML, better IMHO is to keep the code sequence.
After a lot of research I now think there is a bug here.
Since
On 03/10/12 08:50, n Willink wrote:
I've noticed that , when creating a gmapsupp, the FIDs of a tdb file as set
by --family-id= does not necessarily tally with the FID of a TYP file - in
which case the TYP file is ignored by any gps device.
I had always intended that mkgmap would be able to fix
Hi
> I have attached a proper fix that deals with all the cases.
I just committed this fix, an email was not sent because I forgot to
restore the post-commit hook which sends it. Should be OK from now on.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev
Hi
> There must be something else missing. Placing both jar files into /lib
> the error is thrown at an earlier step (14 sec vs 2 min 13 sec), and the
> error message is slightly different:
> Bad file format: ethiopia.osm.pbf
Oh, so are you compiling several pbf files and some work and one
fails
On 10/10/12 10:07, Carlos Dávila wrote:
> If I move my compiled mkgmap.jar file to a location different than dist
> folder and run it, I get the error below:
> I have copied osmprotobuf.jar and protobuf.jar to the same location than
> mkgmap.jar, but it didn't help.
Those are old files.
You need
Hi
I am going to upgrade the server that runs subversion
(svn.mkgmap.org.uk), ivy.mkgmap.org.uk and file.mkgmap.org.uk
tomorrow, so those services will be unavailable for a short while.
Unless something goes wrong, I don't expect that it will be more than an
hour or two.
..Steve
___
http://www.aighes.de/data/rrk_style.zip ).
Should work now, sorry.
Thanks. I see that you had a slightly different case with '&' where
the error message was a little better.
I have attached a proper fix that deals with all the cases.
..Steve
Index: src/uk/me/parabola/mkgmap/osmstyle/eval/
On 28/09/12 13:41, aighes wrote:
I've got a NPE while testing my style-file (
http://www.aighes.de/data/rrk_style.zip ).
That file doesn't exist for me.
Any guesses were the fault could be? Maybe a better errormessage could
be generated by mkgmap in this case?
I'm guessing you have somethin
On 24/09/12 16:09, Roger Calvert wrote:
> Has the version with 'include' been committed yet?
Its committed, but on a branch and not in the main trunk.
However you can download it from http://www.mkgmap.org.uk/snapshots/
as mkgmap-style-include-r2332.jar
..Steve
___
On 26/09/12 18:08, n Willink wrote:
> I think I've discovered the reason: It seems --index has to be placed
> straight after --gmapsupp.
That is not true in general. There is perhaps a bug where the --index
option is swallowed if it occurs in a particular place, or a typo has
caused the index opt
On 26/09/12 12:04, Roger Calvert wrote:
> Another (minor) fault which would probably be easy to rectify: if the
> destination file is open in MapSource when mkgmap runs, it crashes
> (understandably), but leaves a number of temporary files around. Could
> these be deleted when the exception is proc
Hi
> Shall I commit the patch? There was no veto on the list so it should be
> ok to use the empty string "" for the name of unknown cities...(?!?)
Yes you should, it can always be changed if there is a problem.
..Steve
___
mkgmap-dev mailing list
mkg
Hi
> I read the documentation, and understand now that code-page is
> dependent on target device. I wonder though if --latin1 should be
> default, if it's supported by most non-ancient devices. (I do have
> a GPS V, but I haven't tried to build maps for it in a really long
> time!)
I think it
Hi
I've expanded the patch, because I found that the sort order parameters
were not set correctly with the gmapsupp option either.
Here it is if anyone wants to give it a whirl before I commit it, which
I plan to do soon.
..Steve
Index: src/uk/me/parabola/mkgmap/combiners/FileInfo.java
IDEA a
Hi
> It sounds like there is a bugfix for not using --latin1. I can try to
> narrow down the range further, or if that fix is put on trunk try it out
> and report back.
Yes you do not need --latin1, its just that the bug wasn't present if
you did use it. Please try the fixed version at
http://f
Hi Geoff
Thanks to your help, I figured out what the problem was and was able to
reproduce it. It happens when the map and index is built without
--latin1 or --code-page.
Attached is a fix that works for me.
A ready built version is at:
http://files.mkgmap.org.uk/download/68/mkgmap.jar
.
Hi
> I'm having an issue too, but I ran 'svn log' and it seems that while
> there are many revision numbers, there are far fewer commits under
> mkgmap, maybe 12ish. I will report back when I have some real data,
> but for the last few months I've been unable to select mkgmap-built maps
> in map
Hi
> Thank you again. I think the fundamental thing I hadn't grasped was that
> you can't just put a resolution tag on something to cause it to be
> displayed at that resolution or greater, but that you have to in some
> sense "create" the level first with the levels specification before you
Tha
On 13/09/12 16:16, John Aldridge wrote:
> Oh, thank you. So would it be worth amending the documentation for
> o level, to add...
>
> Note that if a level number is used which does not appear in the /levels/
> specification, then it is treated as the next larger (or should this be
> smaller?) leve
On 05/09/12 15:27, Felix Hartmann wrote:
> So you could decide to either include a file containing several sections
> (so you can have section XY1 section XY2 and so on, for one layout, and
> section XX1 XX2 for another layout)
> or
> include the full content from a file.
I don't really want to ad
Hi Geoff
> So r2306 is the first revision that fails, and r2210 is the last time it
> works correctly.
Thanks that is useful, but still a big range.
I should have added the version just before 2306, because 2306 was a
large change so we need to rule it out.
if that still fails then I have no m
On 09/09/12 16:38, Geoff Sherlock wrote:
> --verbose; but as can be seen from the attached output no errors were
> seen, ...
Just noticed, but there *is* an error in the attached output. Not sure
how it is happening, perhaps there is a file resources\LocatorConfig.xml
from where you are running m
801 - 900 of 1862 matches
Mail list logo
