Re: [mkgmap-dev] TYP files and character encoding
Hi Gerd I've just noticed that a change to a function profile stopped a test from compiling, so here is a patch for that Ticker On Tue, 2020-01-14 at 09:43 +, Ticker Berkin wrote: > Hi Gerd > > Here is updated patch that closes the file, although I find many > files > in mkgmap that don't have explicit close(), but I presume .finalize() > will close them eventually. > > I'll do another patch for other text file handling, using > StandardCharset where possible and fixing TokenScanner message for > bad > characters if not utf-8 and, if reasonable, allowing a BOM even if > the > file is opened as utf-8 anyway. > > Ticker > > On Tue, 2020-01-14 at 08:21 +, Gerd Petermann wrote: > > Hi Ticker, > > > > thanks for the patch. > > > > Please review TypCompiler.CharsetProbe. BufferedReader br is not > > closed. Is that intended? > > > > I see that we have a mix of "utf-8" and "UTF-8" in the mkgmap > > sources. I think it would be good to use StandardCharsets.UTF_8 > > where > > possible > > and unify the rest. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Montag, 13. Januar 2020 11:34 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] TYP files and character encoding > > > > Hi Gerd > > > > I've updated this patch with changes to TypCompiler CharsetProbe: > > > > 1/ looks for unicode BOM in various encodings near start of file. > > 2/ looks for line containing "-*- coding: charset -*-" near start > > of > > the file. > > 3/ retains the check for "CodePage=" coding for compatibility. > > 4/ in the absence of the above, sets the reading charset to utf-8 > > if > > the file is valid utf-8, otherwise to Cp1252. > > 5/ fixes the bad character message from the scanner to say what the > > charset really is rather than saying "uft-8" regardless. > > 6/ removes the logic to that checks if String... lines, read in the > > charset it is currently trying, can be encoded in the presumed > > output > > CodePage. > > > > The final result of this patch should be that: > > > > a/ No existing usage is broken > > b/ 2 methods to indicate the charset/encoding of the file that are > > commonly used by text editors can be used and are taken notice of. > > Previously, just the UTF-8 BOM was detected. > > c/ Typ files can, and should from now on, be written in utf-8 > > d/ labels for languages not supported in the --code-page of the > > output > > img just generate a warning in mkgmap.log.x > > > > Ticker > > > > > > On Sat, 2019-12-21 at 16:11 +, Ticker Berkin wrote: > > > Hi Gerd > > > > > > Attached is a patch that: > > > > > > Doesn't use the 'CodePage=' command in the typ-file to determine > > > output > > > character encoding of the typ-file, rather it uses the main map > > > encoding from the --code-page argument. > > > > > > log.warn's any typ labels that can't be encoded in the --code > > > -page, > > > rather than just giving up with message like: > > > > TYP file cannot be written in code page 1252 > > > > > > The message: > > > > WARNING: SortCode in TYP txt file different from command line > > > > setting > > > that was written direct to system.out is changed to a log.warn > > > and > > > it > > > shouldn't happen anyway now > > > > > > For the moment, the 'CodePage=' command in the typ-file is, under > > > some > > > circumstances, used to determine the encoding of the typ-file > > > itself > > > and I've left this alone for compatibility with existing useage. > > > Sometime in January I'll provide a better method for this > > > > > > Ticker > > > > > > > > > On Wed, 2019-12-18 at 19:54 +, Ticker Berkin wrote: > > > > Hi Gerd > > > > > > > > I think it is best to continue with the ideas for typ-files > > > > that: > > > > > > > > 1/ they can be in any character set and we just need a better > > > > way > > > > of > > > > working out the correct one - see my posting earlier today. > > > > > > > > 2/ it can include as many languages as anyone can be bothered > > > > to > > > > add, > > > > and so has to be an a character set that allows the languages > > > > to > > > > be > > > > added, implying unicode for a common one (more particulary, UTF > > > > -8) > > > > > > > > 3/ the codepage= statement should be redundant and ignored for > > > > controlling the output character set, which should be taken > > > > from > > > > the > > > > map, but its use for determining the input coding might need to > > > > be > > > > kept > > > > for a while for compatability. > > > > > > > > 4/ the messages my hack generates should be turned into 1 > > > > warning > > > > or > > > > information message per language or maybe suppressed > > > > altogether. > > > > If > > > > someone is generating a map with a character set that doesn't > > > > support > > > > a > > > > particular language, they really won't care that that data for > > > > other > > > > languages that have an incompatible representation
Re: [mkgmap-dev] Level number too large
Hi Gerd, just after expressing hope for good work of resolution, I got following error in r4420: Error in style: Error: Cannot use type [0x2f17 resolution 24] with level 0 at resolution 23 in style file points, line 270 It is again something, that I have used for a long time. My understanding is that object defined with "resolution 24" simply won't appear on level with resolution 23, regardless if it is level 0 or 1. Maybe you could change this error into a warning? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Gerd, thanks! I never cared about levels in style, I have always used options. My guess is, that levels doesn't need much control, only there should be foolproof conversion from levels to resolution. I expect, that objects defined with resolution are processed correctly. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Andrzej, yes, the important change was in StyleImpl.java With your options the old version read the style using the hard coded default levels "0:24, 1:22, 2:20, 3:18, 4:16" With the new version the levels from the command line option is used instead. It seems I did not expect that the options file in the style doesn't set levels. I'll try to find out if I can implement the wanted check in another way. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Donnerstag, 16. Januar 2020 19:56 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Level number too large Hi Gerd, maybe the problem depends not only on levels. I have uploaded simplified version of a set for creating my map. You can examine, what is going on. http://files.mkgmap.org.uk/detail/460 -- Best regards, Andrzej ___ mkgmap-dev mailing list 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] Level number too large
Hi Gerd, maybe the problem depends not only on levels. I have uploaded simplified version of a set for creating my map. You can examine, what is going on. http://files.mkgmap.org.uk/detail/460 -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Andrzej, yes, I posted a link to the same change. I tested this: 1) create copy of default style (r4323) 2) comment line overview-levels = 4:17, 5:16, 6:15, 7:14, 8:12 3) change line levels to levels = 0:24 4) add rule to polygons landuse=land[0x02 level 3] So, I assume you have a different way to set the levels option and that is causing the problem... Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Donnerstag, 16. Januar 2020 17:00 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Level number too large Hi Gerd, tested again, the error really appeared somewhere after v4323. And I'm compiling the same map since 2014, this is the modification date on my scrips and style. See for example this changelog: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4345 Looks like changes include reading of levels from options - file StyleImpl. -- Best regards, Andrzej ___ mkgmap-dev mailing list 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] Level number too large
Hi Gerd, tested again, the error really appeared somewhere after v4323. And I'm compiling the same map since 2014, this is the modification date on my scrips and style. See for example this changelog: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4345 Looks like changes include reading of levels from options - file StyleImpl. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Andrzej, please double check. I get the same error when I use r4323 (as expected): D:\mkgmap-4323>java -jar dist\mkgmap.jar --style-file=c:\mystyles\level f:\osm\dummy.osm Time started: Thu Jan 16 16:11:26 CET 2020 Error in style: Error: Level number too large, max=0 Maybe you get a different error message? The only change in TypeReader since 4223 was here: http://www.mkgmap.org.uk/websvn/listing.php?repname=mkgmap=%2Fbranches%2FNET-no-NOD%2F=4345#a7829a7e53a360b6e4dc93855915e8189 Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Donnerstag, 16. Januar 2020 16:01 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Level number too large Hi Gerd, probably some other changes made this error to appear. I have checked that v4323 compiles my map, while v4386 reports error. I'm not sure about the purpose of the patched function, but I'm afraid there could be problems with following example: options: levels=0:24,1:22 style: [... level 2-3] I don't know which part of code would be responsible for discarding an object with levels higher than maximum. If this is due to patched function, then maybe better would be something like: if (level > max) return levels[0].getBits() -1; -- Best regards, Andrzej ___ mkgmap-dev mailing list 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] Level number too large
Hi Gerd, probably some other changes made this error to appear. I have checked that v4323 compiles my map, while v4386 reports error. I'm not sure about the purpose of the patched function, but I'm afraid there could be problems with following example: options: levels=0:24,1:22 style: [... level 2-3] I don't know which part of code would be responsible for discarding an object with levels higher than maximum. If this is due to patched function, then maybe better would be something like: if (level > max) return levels[0].getBits() -1; -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd, although quiet on this thread so far, I think that returning a coded bitstring would be less than ideal. I suggest using something like the following: is_in(all_inside) -> return true only if the whole object is inside the area is_in(touching) -> return true if the object is either all inside, or some of it is inside and some of it is touching is_in(all_touching) -> return true if the object is all inside, or some inside and some touching, or all touching is_in(some_inside) -> return true if any of the object is inside is_in(some_touching) -> return true if any of the object is inside or touching As you can see, the return values are cumulative, with a keyword returning true for the preceding keywords and adding some extra, so for example all_touching returns true for an object that has all its points touching the area, as well as for an object that would return true for all_inside or for touching. The inverses might also be required as in: is_out(all_outside) -> return true only if the whole object is outside the area is_out(touching) -> return true if the object is either all outside, or some of it is outside and some of it is touching is_out(all_touching) -> return true if the object is all outside, or some outside and some touching, or all touching is_out(some_outside) -> return true if any of the object is outside is_out(some_touching) -> return true if any of the object is outside or touching I can't see any use for non-cumulative use (e.g. return true only if some of it is inside and some of it is touching) , except for one case that possibly might be useful: is_in(coincident) -> returns true only if all points of the object match all points of the area However, if really required, one could always use something like is_in(touching) & !is_in(all_inside) to handle very obscure cases. I think this approach would give more useful functionality. Regards, Mike -Original Message- From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] Sent: 16 January 2020 10:22 To: Ticker Berkin ; Development list for mkgmap Subject: Re: [mkgmap-dev] Branch is_in ready for a first test Hi all, For a single point we can compute 'inside', 'on boundary', or 'outside'. reg. the results and the method options I thought about a very different alternative: Instead of true or false the function might return a bit string containing three digits, e.g. 001 - 1st (leftmost) bit 0 means "no point inside found", 1 means "at least one point inside found" - 2nd bit 0 means "no point on boundary found", 1 means "at least one point on boundary found" - 3rd bit 0 means "no point outside found", 1 means "at least one point outside" found We can describe 2^3 combinations with that, but obviously the combinations 000 and 101 are impossible, so we have the 6 cases on Tickers list as 1: all of the line is outside the polygon -> 001 2: some of the line is outside and the rest touches or runs along the polygon edge -> 011 3: all of the line runs along the polygon edge -> 010 4: some of the line is inside and the rest touches or runs along -> 110 5: all of the line is inside the polygon 100 6: some is inside and some outside the polygon. Obviously some point is on -> 111 This would allow to remove the 3rd parameter, but user has to remember the order of the bits when writing the style rules. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 16. Januar 2020 10:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi My earlier postings were to get an idea of what was wanted regarding combinations of IN/ON/OUT for 'lines' and also what was reasonable to implement. I didn't like some of the method keywords that I had suggested either. The advantages of the keyword, even if ugly/unwieldy, to say what is wanted for the different 'line' cases, over a 'details' option are that: - for many methods, optimisation is possible (ie can stop early, handle the target polygons one-by-one, etc) - the result of the 'details' would probably have to be some ugly composite string, maybe requiring a regex test to decipher. My summary: For 'polygons', methods 'all' and 'any' cover the requirements. 'points' hasn't been discussed. Are methods for IN, IN or ON, ON needed? If so, what keywords to use; 'any' and 'all' are wrong... 'lines', as per 04-Jan posting with Jan's alternative. a) some-in-none-out IN and not OUT b) all-in-or-on (IN or ON) and not OUT c) all-on ON and not (OUT or IN) d) any-in IN e) any-in-or-on IN or ON So, are all cases required and what keywords to use? 'all' could be used for a) or b), but with the function being called is -in, it would more naturally apply to a). Likewise 'any' for d) rather than e). Ticker On Wed, 2020-01-15 at 06:38 +, Gerd Petermann wrote: > Hi Jan, > > thanks for testing. > Reg. the ways: Yes, that's an error.
Re: [mkgmap-dev] Branch is_in ready for a first test
Hi all,
For a single point we can compute 'inside', 'on boundary', or 'outside'.
reg. the results and the method options I thought about a very different
alternative:
Instead of true or false the function might return a bit string containing
three digits, e.g. 001
- 1st (leftmost) bit 0 means "no point inside found", 1 means "at least one
point inside found"
- 2nd bit 0 means "no point on boundary found", 1 means "at least one point on
boundary found"
- 3rd bit 0 means "no point outside found", 1 means "at least one point
outside" found
We can describe 2^3 combinations with that, but obviously the combinations 000
and 101 are impossible, so we have the 6 cases on Tickers list
as
1: all of the line is outside the polygon -> 001
2: some of the line is outside and the rest touches or runs along the polygon
edge -> 011
3: all of the line runs along the polygon edge -> 010
4: some of the line is inside and the rest touches or runs along -> 110
5: all of the line is inside the polygon 100
6: some is inside and some outside the polygon. Obviously some point is on ->
111
This would allow to remove the 3rd parameter, but user has to remember the
order of the bits when writing the style rules.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 16. Januar 2020 10:48
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi
My earlier postings were to get an idea of what was wanted regarding
combinations of IN/ON/OUT for 'lines' and also what was reasonable to
implement.
I didn't like some of the method keywords that I had suggested either.
The advantages of the keyword, even if ugly/unwieldy, to say what is
wanted for the different 'line' cases, over a 'details' option are
that:
- for many methods, optimisation is possible (ie can stop early, handle
the target polygons one-by-one, etc)
- the result of the 'details' would probably have to be some ugly
composite string, maybe requiring a regex test to decipher.
My summary:
For 'polygons', methods 'all' and 'any' cover the requirements.
'points' hasn't been discussed. Are methods for IN, IN or ON, ON
needed? If so, what keywords to use; 'any' and 'all' are wrong...
'lines', as per 04-Jan posting with Jan's alternative.
a) some-in-none-out IN and not OUT
b) all-in-or-on (IN or ON) and not OUT
c) all-on ON and not (OUT or IN)
d) any-in IN
e) any-in-or-on IN or ON
So, are all cases required and what keywords to use?
'all' could be used for a) or b), but with the function being called is
-in, it would more naturally apply to a). Likewise 'any' for d) rather
than e).
Ticker
On Wed, 2020-01-15 at 06:38 +, Gerd Petermann wrote:
> Hi Jan,
>
> thanks for testing.
> Reg. the ways: Yes, that's an error. I'll have a look at it.
> Reg. your rules: I would add the clause & isin!=* in the 2nd rule to
> avoid a 2nd execution of the is_in function.
> Reg. ON:
> The current implementation of is_in accepts only 'all' or 'any'. I
> think we can also detect the cases 2 and 3 on Tickers list (1) but I
> didn't like the suggested method 'all-on' in combination with the
> function name is_in and I did not yet find a better alternative.
> An alternative I was thinking about is to implement a 'details'
> option which might return one of the values in Tickers list. We just
> have to define values for points and polygons, as Tickers list is
> only for rules in lines.
>
> Gerd
> (1) http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook
> -tp5954103p5954828.html
>
>
> Von: mkgmap-dev im Auftrag
> von jan meisters
> Gesendet: Dienstag, 14. Januar 2020 23:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
>
> Hi Gerd, hi Ticker,
>
> sorry for the delay, until the weekend I didn´t found time to test
> the new versions.
>
> I´m very impressed, my results now are so precise that I could revert
> all the gaps I created for the first hook.
> Many thanks for all your efforts to realize this accuracy!
>
> Still I´m only on lines inside cemetery/allotments, so I have no clue
> about the buildings in v4 samples, sorry.
>
> I check for „all“ and for „any“, giving two new values and then
> reduce them to one if another match, ie:
> highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1}
> highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2}
> highway=* & isin=1 {set highway=path}
> highway=* & isin=2 bicyle=no {set highway=path}
>
> That works as I expect: reduce all-in, and any-in only if specified.
> I didn´t understood yet : could ON still be a value to ask for,
> beside IN and OUT?
> Or has it become obsolete? In anyway, with my rule above I see no
> complaint about it.
>
> Only one unclear example so far I found - probably caused by the
> multipolygon?
> The first line is not matched by the
Re: [mkgmap-dev] Branch is_in ready for a first test
Hi
My earlier postings were to get an idea of what was wanted regarding
combinations of IN/ON/OUT for 'lines' and also what was reasonable to
implement.
I didn't like some of the method keywords that I had suggested either.
The advantages of the keyword, even if ugly/unwieldy, to say what is
wanted for the different 'line' cases, over a 'details' option are
that:
- for many methods, optimisation is possible (ie can stop early, handle
the target polygons one-by-one, etc)
- the result of the 'details' would probably have to be some ugly
composite string, maybe requiring a regex test to decipher.
My summary:
For 'polygons', methods 'all' and 'any' cover the requirements.
'points' hasn't been discussed. Are methods for IN, IN or ON, ON
needed? If so, what keywords to use; 'any' and 'all' are wrong...
'lines', as per 04-Jan posting with Jan's alternative.
a) some-in-none-out IN and not OUT
b) all-in-or-on (IN or ON) and not OUT
c) all-on ON and not (OUT or IN)
d) any-in IN
e) any-in-or-on IN or ON
So, are all cases required and what keywords to use?
'all' could be used for a) or b), but with the function being called is
-in, it would more naturally apply to a). Likewise 'any' for d) rather
than e).
Ticker
On Wed, 2020-01-15 at 06:38 +, Gerd Petermann wrote:
> Hi Jan,
>
> thanks for testing.
> Reg. the ways: Yes, that's an error. I'll have a look at it.
> Reg. your rules: I would add the clause & isin!=* in the 2nd rule to
> avoid a 2nd execution of the is_in function.
> Reg. ON:
> The current implementation of is_in accepts only 'all' or 'any'. I
> think we can also detect the cases 2 and 3 on Tickers list (1) but I
> didn't like the suggested method 'all-on' in combination with the
> function name is_in and I did not yet find a better alternative.
> An alternative I was thinking about is to implement a 'details'
> option which might return one of the values in Tickers list. We just
> have to define values for points and polygons, as Tickers list is
> only for rules in lines.
>
> Gerd
> (1) http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook
> -tp5954103p5954828.html
>
>
> Von: mkgmap-dev im Auftrag
> von jan meisters
> Gesendet: Dienstag, 14. Januar 2020 23:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
>
> Hi Gerd, hi Ticker,
>
> sorry for the delay, until the weekend I didn´t found time to test
> the new versions.
>
> I´m very impressed, my results now are so precise that I could revert
> all the gaps I created for the first hook.
> Many thanks for all your efforts to realize this accuracy!
>
> Still I´m only on lines inside cemetery/allotments, so I have no clue
> about the buildings in v4 samples, sorry.
>
> I check for „all“ and for „any“, giving two new values and then
> reduce them to one if another match, ie:
> highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1}
> highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2}
> highway=* & isin=1 {set highway=path}
> highway=* & isin=2 bicyle=no {set highway=path}
>
> That works as I expect: reduce all-in, and any-in only if specified.
> I didn´t understood yet : could ON still be a value to ask for,
> beside IN and OUT?
> Or has it become obsolete? In anyway, with my rule above I see no
> complaint about it.
>
> Only one unclear example so far I found - probably caused by the
> multipolygon?
> The first line is not matched by the any-rule, but the second is.
> Both should match according to style:
> https://www.openstreetmap.org/way/117416117
> https://www.openstreetmap.org/way/117416120
>
> As said, only one. With is_in render time is increased by only 5-10%,
> pretty cheap.
> Thanks to all for the ideas read here how to play with this wonderful
> new option.
>
> Jan
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Level number too large
Hi Andrzej, I am a bit confused. If I got that right the check was introduced together with the levels option with r692 in the year 2008 and seems unchanged since then. http://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmap=%2Fbranches%2Fstyle%2Fsrc%2Fuk%2Fme%2Fparabola%2Fmkgmap%2Fosmstyle%2FTypeReader.java=692=692 On the other hand I see no problem with your patch, though I would use slightly different code, see my version. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Mittwoch, 15. Januar 2020 21:41 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Level number too large Hi All, since something is wrong with downloads on mkgmap site, I have compiled version 4419. I guess this is the latest official release. Now with some old maps I get a new error: Error in style: Error: Level number too large, max=0 I guess this is a conflict between arguments: levels=0:24 and style with declarations like: [... level 3] In my opinion, this should be no error, as it wasn't in older versions of mkgmap. It is harmless and quite useful, that style defines higher levels then a particular map compiled with the style. I have attached a patch, but I'm not sure what I'm really changing. Please look at it. -- Best regards, Andrzej maxlevels-v2.patch Description: maxlevels-v2.patch ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
