Hi Arndt
As a matter of interest, does any text show for
https://www.openstreetmap.org/node/9122388694
or
https://www.openstreetmap.org/node/9115233473
The text is mostly 'Old Hungarian' and I wonder if the java encoder
tries any transliteration. What code-page are you using?
Ticker
On Tue, 2
Hi Nick
Thanks.
Interesting, but not maybe not relevant to the Huffman stuff, in
mdr16austria.txt the MDR headers go out of sync after MDR30
Ticker
On Tue, 2021-12-28 at 18:28 +, nick wrote:
> Hi Gerd
>
> OK thanks will check that tomorrow.
>
> I think it's amazing how far both of you go
Hi Gerd
Some of the old maps don't have Mdr sections after 19 and 29. Also some
code didn't spot it should test after Mdr19, so Summary, Display and
Check could give errors. I've added logic to stop getting sections
after all the header lengths I've found in the various samples.
Patch attached.
think any
others will cause problems. There might just be a few str.length() and
str.charAt() or other indexing that might need attention but this would
require a lot more searching. I've left the handling for
MALFORMED_INPUT so these shouldn't matter.
Ticker
On Wed, 2021-12-29 at 09:16
Hi Gerd
Sorry about that - had been copy&pasting strange chars but it wasn't
from here! The Oracle java documentation has this character between:
int offsetByCodePoints
and
(int index, int codePointOffset)
Ticker
On Thu, 2021-12-30 at 15:26 +, Gerd Petermann wrote:
> Hi Ticker,
>
> p
Hi Gerd
Some thoughts on this:
Dividing the \0 count by some factor between 3 and 6 should reduce the
overall length of the strings. This is because there will be 0..7 bits
free after each string
To make the canonical tree: after using the standard algo to make a
normal tree, just remember the c
Hi all style users
I've noticed that the code and style manual differ in the meaning of
the highway-symbol max-length parameters.
The manual says the text is truncated to this length.
In the code: if the text is longer than the length it is left
untouched. No shield is added, spaces are not remo
ud get negative and that will fail.
> I guess that Garmin produces an empty level in that case...
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 31. Dezember 2021 10:57
> An: mkgmap development
&
Hi Gerd
In the resource/sort/cp*.txt sort definitions, I notices that all but
cp1252.txt/Western European and cp65001.txt/unicode don't handle "#"
correctly and cp1252.txt/Western European and cp1254.txt/Turkish don't
add expansions for all their double-characters.
Patch attached that fixes these
Hi Karl
1. include inc/name processing happens at the point of inclusion
2. I don't think variable expansion works within the context of filter
parameters - your difficulties suggest it really doesn't.
3. {set name= ... probably works correctly, but it is the
{name ...} statement that sets
Hi Karl
I suspect this won't work directly, the ":" you want to look for is
being taken as the operator. Maybe you can subst it first
name='{name|subst:":=>#"|part:"#:-1"}'
Ticker
On Sun, 2022-01-02 at 19:58 +0100, 7770 wrote:
> Hi.
>
> On page 16 and 17 in the styles manual the part oprerat
derstand how it works. if name is set to anything, what will {name
> '$
> {name}'} actually do?
>
> add and set are described in the style manual, but not the case
> without add or
> set (or i don't understand where to look for it).
>
>
> Regards
> K
Hi Gerd
Sorry - I hadn't noticed these changes. They don't show up with
$ svn log resources/sort/cp1252.txt or cp1254.txt
All the other mkgmap sort files have all the expansions possible
including the eszett and diphthongs if applicable.
The two non-mkgmap sort files (848.SRT/Turkey and
I000
12-13 at 09:17 +, Ticker Berkin wrote:
> Hi Gerd
>
> Yes, this seemed to be the result of a bit of code where someone was
> starting to look at showing expansions and then stopped. The
> information in this list is shown more clearly while it is being read
> in the SRT 4 Ch
, Gerd Petermann wrote:
> Hi Ticker,
>
> here it is.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 4. Januar 2022 11:20
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-d
| id1 1
> 0044 | 04 | 01 00 | id2 1
> 0046 | 06 | e4 04 | codepage 1252
>
> Maybe I should repeat those tests with the mdr2 branch?
>
> Gerd
>
>
>
>
>
&g
rd Petermann wrote:
> Hi Ticker,
>
> OK, maybe you find more on that.
> BTW: Voßberg is very special as it probably also influences the MDR 17
> content.
>
> I think I'll merge the faster-mp branch into trunk this afternoon and
> continue on
> the Huffman encoding la
Hi Gerd
On my eTrex 30x:
Same --lower-case map as before. Also loaded is GB map that is disabled
in Setup>Map; it uses same charset & sort, sort has same id1 but
different id2.
Where To? > Cities > Spell Search > "VOS" gives "No Results Found"
Spell Search has option to change the keyboard lang
Hi Gerd
Did the '5' nibble in byte 2 indicate the size of lookup table? if so,
could reduce the table size so it overflows. I assume that setting byte
3 to <= table size didn't work
Ticker
On Thu, 2022-01-06 at 09:25 +, svn commit wrote:
> Version mkgmap-r4848 was committed by gerd on Thu, 0
Hi Gerd
Just starting to read the new code more carefully and a few comments:
In Mdr17 the following line should be deleted:
len = (len << 1) + 1;
Mdr15 is not written forDevice so can skip all the compression stuff.
Have you seen an example with unicode. There seem to be too many
assum
Hi Gerd
I tried various approaches to fixing "Find" when the fixed length Mdr17
(maybe also Mdr12) prefix contains sort.expand chars and couldn't make
it work. I could documents these attempts in Sort.java if you feel this
is worthwhile.
New patch attached that, for cp1252, leaves "ß" as its own
It is possible to enter these characters in MapSource and I think
> MapSource uses MDR12
> when you type only a few characters for the name of a POI and don't
> pick up an entry from the list.
>
> Gerd
>
>
> Von: mkgmap-dev im
It looks like the LBL file could be Huffman compressed with an ENCODING
value of 11.
Is there scope for having the new Huffman logic with
app/labelenc/CharacterEncoder /CharacterDecoder interface?
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkg
Hi Gerd
More minor stuff - Still haven't understood the mincode parts
mdr/Mdr16.java:
loopupBits/lookupBits is very confusing.
Can you have lookupBits for table2 size and something else for table1
size
If maxDepth < initial size (5 or 6), can't you just set table1 size to
maxDepth and set table
like
> ...".
>
> I plan to recode MdrDisplay now that I undestand almost all data.
> I also want to implement this in MdrCheck during the next days.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
idn't try it: Will mkgmap complain when building an indexed
> gmapi/gmapsupp
> where some tiles where freshly compiled with the new version and
> others with
> an older (like Felix and Carlos do)?
>
> Gerd
>
> ________
> Von: mkgmap-d
Hi Jose
I don't see from your display which you mean, but, from the OSM area, I
think I understand.
You could consider adding something like this to
highway=footway {
existing stuff;
set mkgmap:set_unconnected_type=none;
set mkgmap:set_semi_connected_type=none;
} [existing stuff]
Ti
Hi Gerd
I'm just starting to look at this, but won't be able to do much today,
but some initial findings:
If just making gmapi from .img, unless --code-page is given it doesn't
do compression, however the Mdr generated with the expected charset.
MdrCheck and MdrDisplay, including string dump, lo
fter 1stLevWithStruct and rowsIn1stTable is still
troubling, as I'd have expected it to be associated with the
prefixTable
Ticker
On Sun, 2022-01-16 at 12:37 +, Ticker Berkin wrote:
> Hi Gerd
>
> I'm just starting to look at this, but won't be able to do much
>
Hi Gerd
More unicode problems: The data structures for the frequency analysis
and then the list of chars to encode will all need attention.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mk
oder must understand what a codepoint
> is?
> I don't think so. The only important thing is that utf-8 still can
> use a single 0
> to terminate strings.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
Hi Gerd
I'm looking at GPXSee at the moment.
Significant to the problem lots of symbols:
The size of the tab1 offset into the symbol list is the same as the
size of the size (the 1+ bytes after the 8/symbol width), so, if more
than 127, it needs an extra byte.
Ticker
On Mon, 2022-01-17 at 04:
Hi
I was noticing MdrCheck problems in Mdr7 with unicode and string
compression - not using mdr7-del so probably because of the
shield/prefix/sep/suffix markers. Looks like a slightly related
problem.
Ticker
On Mon, 2022-01-17 at 16:20 +, Gerd Petermann wrote:
> Hi Mike,
>
> I fear it is ev
Hi Gerd
Patch attached to fix offsetSize in check16 and have readVarLength()
return the size.
Ticker
Index: src/test/display/MdrCheck.java
===
--- src/test/display/MdrCheck.java (revision 593)
+++ src/test/display/MdrCheck.java (work
A quick and dirty method is just to edit the .osm file to move the
... to after the last ...
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
I'm trying understand all this, so maybe what I'm trying to say here is
rubbish.
How is it that --split-name-index didn't also break Find > Street
select list.
If it is required that Mdr7 index entries refer to a label, then,
maybe, can have multiple index entries to the same label with
Hi Gerd
I'm struggling to understand the possibilities of Mdr7 (ordering,
partialInfo, nameOffset, string different to label, etc etc)
My initial thought about nameOffset was that it was for skipping over
the shield prefix or text before the 0x1b marker.
partialInfo is very strange; it seems to
t(maxSuffixCount))
> + 1;
>
> The two counters are never increased in the current code. In r3968
> there's some commented code which used them.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
>
Hi Gerd
I got confused between Mdr15 (full string for gmapi) and Mdr17 (partial
string for device), so what I wrote here makes little sense.
I need to think about it more. Sorry for wasting your time.
Ticker
On Thu, 2022-01-20 at 20:42 +, Ticker Berkin wrote:
> Hi Gerd
>
> It
| | | mdr33 string: SOLDEN
> | | | mdr33 string:
> TIMMELSJOCHSTRAßE
>
> No idea how the data is used. My Oregon cannot find any address
> and shows garbage for the region name when I install the
> gmapsupp.
| | |
> | | | Record 842
> 001a1d3a | 002423 | 13 | 19 map number
> 001a1d3b | 002424 | 79 18 80 | Pointer back into LBL:
> 001879
> 001a1d3e | 002427 | 76 01 0f
Hi Gerd
Looking at the mask logic in MdrDisplay printSect30/32 I'd guess that
the pointer size is always governed by the size of Mdr31/33 and any
extra bytes are something else, probably the length of the string.
I've haven't managed to find any maps with these sections so I can't be
sure. How bi
Hi Gerd
When I looked at this (not very closely) a couple of weeks ago, it
seemed as if LBL could be huffman encoded, with ENCODING_FORMAT set to
11, and the decoding table somewhere in RGN
Ticker
On Tue, 2022-01-25 at 08:10 +, Gerd Petermann wrote:
> Hi Steve,
>
> if I got that right data
Garmin map, and I don't know any
> site which still offers a download.
> Can't you just write code to fill 32/33 or and see if it has the
> effect that you expect?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von T
Hi Mike
Would the tag filter not-contained (4.4.1) do the job?
Ticker
On Tue, 2022-01-25 at 13:51 +, Mike Baggaley wrote:
> Hi,
>
> Section 4.2.3 of the style manual shows how to compare the values of
> two
> tags, but does not indicate whether it is possible to use tag values
> within
> a
oesn't contain the tag
value or name, but have now realised that the example has been truncated.
Regards,
Mike
-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 25 January 2022 15:03
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] tag value within regu
Hi Gerd
Attached is patch for Style Manual:
1/ Keep |not-contained filter example within the page.
2/ Fix the highway-symbol documentation to agree with the code.
3/ Describe road_class more accurately; consistent with default style.
4/ Adjust various table widths to stop some long, unbreakable w
Hi Jose
GPSMapEdit from
https://www.geopainting.com/
can tell you some of this. The free version should do; install it and
open gmapsupp.img or an individual tile. Then look at Map Properties >
Statistics tab.
Ticker
On Thu, 2022-01-27 at 15:31 +0100, jose1711 wrote:
> Hello,
> can someone re
f
> the changes, so please double check.
>
> Gerd
>
>
>
>
> ____
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Mittwoch, 26. Januar 2022 18:12
> An: mkgmap development
> Betreff: [mkgmap-dev] Style Manual
Hi Gerd
I looked more carefully after your last post and I agree; except "p"
increases when the partialString is at the end and "s" when at the
start.
There were some cases that confused, but I think these were mostly
where there was a 0x1f (zoomSuffix) in the string; p & s > 1.
I notice that wo
Hi Gerd
Subdivision.write needs adjusting to merge startRgnPointer and
getType()
MAX_RGN_OFFSET_SIZE limits to 16 bits rather than 24 so probably not be
directly related.
The 24 to 28 bit increase presumably covers all the subdivisions in the
tile and so should allow larger maps. I didn't notice
Hi Gerd
Patch attached to fix MdrSummary readHeaderLen, cope with different hdr
lengths more clearly and improve output.
I've found I can now split my old "City Navigator Europe NT" map and
look at the MDR, which includes sections 30/31, 32/33, 34, 37 & 38
codePage=1252 id1=18 id2=1 unk=0x0011
Hi Gerd
I feel there are too many disparate and significant changes in mdr2 to
merge it into trunk in 1 go. Is it possible do a topic at a time,
starting with the least likely to cause problems, leaving time between
for any problem to emerge?
Ticker
On Thu, 2022-02-10 at 11:35 +, Gerd Peterm
Hi Gerd
Although the comment might have inaccuracies and be ambiguous, it
contains useful information about how the extra flags for POI might be
represented, which could be different from just reading 4 bytes.
One way of interpret it is if (first byte & 0x80), then read/write
extra bytes; the 3
Hi Gerd
Reading it more carefully, probably the basic flag set is 16 bits, with
0x0100 indicating more bytes to read/write
Ticker
On Sat, 2022-02-12 at 12:36 +, Ticker Berkin wrote:
> Hi Gerd
>
> Although the comment might have inaccuracies and be ambiguous, it
> con
on in the flags field instead of
> ignoring them.
> I am not aware of any code in mkgmap that reads or fills those
> bits,yet.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 12. Febr
Hi all
To improve routing, I'd like to get information about the POIS that are
being linked to a WAY that can be used as part of the style/lines
processing.
The problem I'm trying to solve is to restrict car routing through some
types of very low level roads (eg service) when there is a barrier.
error in the map data produced by mkgmap
> or maybe you used wrong routing settings. Please let me know how to
> reproduce.
>
> No idea if your proposed change would improve routing, but feel free
> to experiment with that.
>
> Gerd
>
> _____
2-16 at 09:25 +, Gerd Petermann wrote:
> Hi Ticker,
>
> reg. routing problems in Basecamp: Maybe you hit the problem
> described for --max-routing-island-len?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
nual.
Ticker
On Tue, 2022-02-15 at 16:41 +, Ticker Berkin wrote:
> Hi Gerd
>
> highway=street_lamp was just an example of a POI that can get linked
> to
> a WAY that can be ignored. There are others that are valid OSM
> tagging
> that are irrelevant to the highway behavi
ker,
>
> I don't see a problem with the patch, but I also don't see how it
> solves a problem
> with wrong routing.
>
> Please give me some examples for highways where this would help.
>
> Gerd
>
>
>
> ____
> Von: mk
2-17 at 10:11 +, Gerd Petermann wrote:
> Hi Ticker,
>
> with examples I meant links to OSM ways.
>
> My current understanding is that these OSM ways may need different
> tagging.
>
> Gerd
>
> ____
> Von: mkgmap-dev
Let's see if anybody else wants this.
>
> Gerd
>
>
>
>
>
>
>
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 17. Februar 2022 13:39
> An: Development list for mkgmap
> Betreff: Re: [mkgm
or
> causes a split of the way and I don't see how this is related.
>
> Let's see if anybody else wants this.
>
> Gerd
>
>
>
>
>
>
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
&g
roblem it is but my
> current
> understanding is that you had some mistagged OSM ways which happened
> to have
> a barrier node which probably also missed proper access tags.
> Adding a special rule for those is likely to cause trouble somewhere
> else.
>
> Gerd
>
> _
Hi Gerd
Fantastic work.
I've never see any effect of having a Mdr6 section (where the zips end
up) either from mkgmap or any zip searching ability from a GARMIN NT
map; both of which had MDR 6 sections.
Ticker
On Wed, 2022-03-16 at 15:55 +, Gerd Petermann wrote:
> Hi devs,
>
> one of the
Hi Joris
My opinion is that using TYPViewer to edit the the mkgmap held typ-
files is too dangerous; it deletes language strings it can't cope with
and makes textual changes that make it very difficult to see the actual
difference between versions.
Unless TYPViewer supports and generates a unicod
ons are less important I guess.
>
> Kind regards,
> Joris
>
>
>
>
> -----Oorspronkelijk bericht-
> Van: mkgmap-dev Namens
> Ticker Berkin
> Verzonden: vrijdag 18 maart 2022 18:59
> Aan: Development list for mkgmap
> Onderwerp: Re: [mkgmap-dev] Update
Hi
I don't see a way to control the placement of the POI for a
multipolygon; it sets it to the centre point of the biggest area.
You could suppress the POI if it isn't within the area by using the
is_in() function, something like:
tag=value & mkgmap:area2poi=true & is_in(tag, value, in_or_on)=tr
Hi
The * needs to be quoted in the param list:
boundary=* & ... & is_in(boundary, '*', ...
Ticker
On Wed, 2022-04-06 at 13:02 +, lig fietser wrote:
> I also want to use it for all boundaries but this line is not
> working:
> boundary=* & mkgmap:area2poi=true & is_in(boundary,*,in_or_on)=fal
Hi Gerd
I've just rebuilt britain-and-ireland-latest.osm.pbf with the current
trunk and find that many tiles on the coast have flooded rectangles.
The coastline is all correct and these flooded area are normally well
inland and unrelated to where the coastline crosses the tile boundary.
I use opt
, Gerd Petermann wrote:
> Hi Ticker,
>
> thanks, I'll take a look at it. My understanding was that
> SeaGenerator should produce an outer way which is slightly larger
> than the tile.
> Did I change that?
>
> Gerd
>
> __
disable the partitioning in class MultiPolygonRelation.
> I've not yet understood why, but I fear your patch simply works
> around this problem.
> The partitioning seems to produce parts where an inner and an outer
> rectangle both seem to cover the same area.
> I think I have to f
Hi
Firstly:
I don't get a crash from:
if (mkgmap:style-option:test=true) then
() echo {"test"}
end
with or without --style-option=test.
Also, don't you mean "... mkgmap:option:test ..."
Next:
The "test" part of a rule must contain at least 1 "positive" limiting
clause, as per the sty
Hi Andrez
On Tue, 2022-05-31 at 00:23 +0200, Andrzej Popowski wrote:
> Hi Ticker!
>
> > I don't get a crash
>
> Maybe there are other factors? I'm using AMD Ryzen, Windows 10,
> OpejJDK
> 18.0.1 (just have updated, 17.02 worked the same). I can create a set
> which cause crash, if you are inte
Hello Raphael
I'm not quite sure what you mean but the variable mkgmap:label:1 put
the label information into the map. This can be set directly and the
name command also sets it
The default style has, in the section of
points/lines/polygons, the command:
name=* {name '${name}'}
Ticker
On Thu,
Hi John
Adding to what Thorsten has written:
It can be impossible to reliably deduce what should be sea when just
using the coastline data from within an OSM area extract. The extract
area is expanded to be within a set of rectangular tiles and, as a
result of this, coastline data might just stop
Hi Steve
Assuming you haven't overridden the default style, these boundary lines
are triggered by:
boundary=administrative {name '${mkgmap:boundary_name}'}
boundary=administrative & admin_level<3 [0x1e resolution 12]
boundary=administrative & admin_level<5 [0x1d resolution 19]
boundary=administra
Hi
Looking at common values for this, I'm going to have:
tourism=information & (
information=office | information=visitor_centre |
information=board | information=map
) {add name='${information}'} [0x4c00 resolution 24]
I think it is bad that "points" does include 'inc/name' so early
Hi
0x11 is rendered as a thin black line on my eTrex HCx and a white line
on my eTrex 30x
Ticker
On Sun, 2022-11-27 at 17:35 +, ael wrote:
> On Sun, Nov 27, 2022 at 04:13:44PM +, Gerd Petermann wrote:
> > Hi ael,
> >
> > the "default typ" is the one that comes with the firmware of the
>
Hi
My understanding of the default Garmin usage is that
0x20..0x22 are land/height contours (Minor to Major)
0x23..0x25 are sea/depth ""
Ticker
On Thu, 2023-03-02 at 08:52 +, Gerd Petermann wrote:
> Hi Vadim,
>
> I see code in mkgmap to handle the statement with Elevation=m or
, contour/Non NT
> 0x02400=Contour Lines/INT_BATHY_CONTOUR/Intermediate bathymetric, or
> depth, contour (should be used for about every 5th contour line)/Non
> NT
> 0x02500=Contour Lines/MAJOR_BATHY_CONTOUR/Major bathymetric, or
> depth, contour (should be used for about every 10th c
Hi Felix
Your syntax looks correct, but, given that the example WAY you quote is
a private driveway, I'd suspect the settings of hgh:*, being set to
meet these conditions for the way in question and the road and wall
Ticker
On Sun, 2023-03-05 at 22:35 +0100, Felix Herwegh wrote:
> Hi,
> I seem
Hi Diego
If you get 'incomplete multipolygon relation' errors from the splitter,
for significant areas to be rendered, it is quite likely that you get
the effects you see. I don't know if the splitter makes any attempt to
complete the polygon along the edge of input area, but I suspect not as
tryi
Hi Thomas
Have you looked at the code and output from the mkgmap display tool? It
was available for svn at
https://svn.mkgmap.org.uk/mkgmap/display
but I can't access it at the moment
Ticker
On Wed, 2023-03-15 at 19:57 +0100, tho...@ankarsvik.nu wrote:
> Hi,
>
> Sorry if this is slightly of
Hi Frank
Some quick comments:
1/ Whatever you need to do to make it run on old versions of Java.
2/ I've always used the pre-build bounds-latest.zip file from
https://www.mkgmap.org.uk/download/mkgmap.html
which redirects to the site you mention.
This global file is designed to avoid th
Hi Carlos
I've tried this on my latest build which is r4907 + quite a few other
changes and I don't get the problem, but using an older, downloaded,
version I can reproduce it.
My changes don't look relevant to this issue; mainly character set
issues and some line/polygon filter reordering. The
Hi
Things to check:
Have you set 'allow tolls' on your routing options - most ferries cost.
Ferry ports can have complicated road systems with barriers, gates,
one-way systems, service roads, parking/holding lots etc; it can
require very careful checking to see that there is a valid route
throug
Forgot to mention access=customers or similar, which might cause
mkgmap:throughroute=no
Ticker
On Thu, 2023-06-01 at 10:50 +0100, Ticker Berkin wrote:
> Hi
>
> Things to check:
>
> Have you set 'allow tolls' on your routing options - most ferries
> cost.
>
>
Hi Gerd & Carlos
I've found the problem and attach a patch which reduces the Subdivision
line limit to 254.
Subdivisions/areas have a set of limits, one of which was <= 255 lines.
These lines can be of any type including roads. When --route, a
reference to each line/road part is created, but thes
Hi
Sorry - this isn't the correct explanation.
Reducing MapSplitter.MAX_NUM_LINES fixes the problem but there must be
something else going on that adds 1 more line. I'll investigate a bit
more.
Ticker
On Fri, 2023-06-02 at 16:47 +0100, Ticker Berkin wrote:
> Hi Gerd & Carlo
ome unit tests need changes. Please check if
> my changes are plausible. Something might be wrong on my system
> because SimpleRouteTest failed also without your patch.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
&
e to trunk.
Ticker
Forwarded Message ----
From: Ticker Berkin
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Problems with sea in overview map
Date: Fri, 21 May 2021 17:10:07 +0100
Hi Gerd
I'd been doing some investigation of filters ordering (based on trunk).
I'd a
f the counter?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Sonntag, 4. Juni 2023 10:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error processing tile
>
> Hi Gerd
>
Hi Gerd
The added comments are helpful but overall I think the readability is
worse; it takes careful reading to see where the dp filter is placed.
If other tweaks to different orderings between normal and parallel
chains are necessary it will become even more confusing.
Ticker
On Mon, 2023-06-
Hi Carlos
The first message is related to forming subdivisions that obey all
required restrictions:
(area.getNumLines() > MAX_NUM_LINES
|| area.getNumPoints() > MAX_NUM_POINTS
|| (sizes[MapArea.POINT_KIND] + sizes[MapArea.LINE_KIND]) >
MAX_RGN_OFFSET_SIZE
Hi Diego
It is probably better to have something like this in "lines":
natural=valley & is_closed()=false [0x12005 resolution 21]
then the rule won't be triggered for closed ways and will be passed on
to "polygons" processing:
natural=valley [0x10f09 resolution 21]
If you wanted both line and
Hi
You need to have ... --input-file=otm-hungary.img ... to fix the file
doesn't exist errors.
I have no idea if the rest of what you are asking for will work.
Ticker
On Thu, 2023-07-13 at 16:35 +0200, Tamas Gal wrote:
> Hi all,
>
> maybe I got that wrong but I thought I can merge multiple IM
Hi Joao
There isn't a way to change the type of the background polygon/area of map
coverage.
Can you disable the night-mode switching in your device?
Can you define the rendering for the 0x4b polygon in your typ-file, with both a
day and night
mode?
Transparent maps don't set the background.
Hi
I was thinking that gaps like this could often happen when adjacent polygons
share the points
along the common boundary, but, during the various point-removal optimisations,
esp. Douglas
Peucker, different points along this boundary are chosen to represent the 2
polygons.
Regarding LineClip
301 - 400 of 1134 matches
Mail list logo
