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
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
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
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
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
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
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
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
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:
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
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
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
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.
13 matches
Mail list logo
