Re: [mkgmap-dev] MDR 9 & 10 groups
Hi Ticker, I also don't know what 0x28 is, but you are probably right that the code is wrong. A change from LinkedHashMap to TreeMap for field index in MDR9 should fix this, right? Gerd Von: mkgmap-dev im Auftrag von Steve Ratcliffe Gesendet: Montag, 15. April 2019 23:12 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] MDR 9 & 10 groups Hi Ticker > So, the first question is, does anyone know why 0x28 was given it's own > group. I've no idea why, but that is the way it is as far as I could determine. > The second problem is that the code that builds up the group start > indexes into Mdr10 for Mdr9 assumes that the type ranges of the POI > allocated for a group are in the same order as the groups, so, if you > actually have a POI of type 0x28 then, because it has a lower type but > a higher group than the 0x2a..30 range/groups, mdr9 is wrong. I don't see where that happens but that would be wrong and mdr9 should be ordered by group. Cheers Steve ___ 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
[mkgmap-dev] Commit r4286: mdr5.patch by Ticker Berkin:
Version mkgmap-r4286 was committed by gerd on Tue, 16 Apr 2019 mdr5.patch by Ticker Berkin: "If you have a map with cities but no streets, MDR5 sets the flag that indicates MDR20 indexes are present, and writes an erroneous byte after each record. Attached patch fixes and adds some more flag documentation." http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4286 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MDR 9 & 10 groups
Hi Ticker So, the first question is, does anyone know why 0x28 was given it's own group. I've no idea why, but that is the way it is as far as I could determine. The second problem is that the code that builds up the group start indexes into Mdr10 for Mdr9 assumes that the type ranges of the POI allocated for a group are in the same order as the groups, so, if you actually have a POI of type 0x28 then, because it has a lower type but a higher group than the 0x2a..30 range/groups, mdr9 is wrong. I don't see where that happens but that would be wrong and mdr9 should be ordered by group. Cheers Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mdr5 when no streets (mdr20)
Hi
Another problem discovered when investigating indexes.
If you have a map with cities but no streets, MDR5 sets the flag that
indicates MDR20 indexes are present, and writes an erroneous byte after
each record.
Attached patch fixes and adds some more flag documentation.
Regards
Ticker Index: src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java
===
--- src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java (revision 4285)
+++ src/uk/me/parabola/imgfmt/app/FileBackedImgFileWriter.java (working copy)
@@ -207,6 +207,7 @@
* @param val The value to write. Unsigned
*/
public void putNu(int nBytes, int val) {
+ assert nBytes >= 1 && nBytes <= 4: nBytes;
try {
file.write(val);
if (nBytes <= 1) {
Index: src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java
===
--- src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java (revision 4285)
+++ src/uk/me/parabola/imgfmt/app/mdr/Mdr5.java (working copy)
@@ -36,6 +36,7 @@
private List cities = new ArrayList<>();
private int maxCityIndex;
private int localCitySize;
+ private int mdr20PointerSize = 0; // bytes for mdr20 pointer, or 0 if no mdr20
public Mdr5(MdrConfig config) {
setConfig(config);
@@ -188,7 +189,6 @@
}
public void writeSectData(ImgFileWriter writer) {
- int size20 = getSizes().getMdr20Size();
Mdr5Record lastCity = null;
boolean hasString = hasFlag(0x8);
boolean hasRegion = hasFlag(0x4);
@@ -217,7 +217,8 @@
writer.put2u(region);
if (hasString)
putStringOffset(writer, city.getStringOffset());
- writer.putNu(size20, city.getMdr20());
+ if (mdr20PointerSize > 0)
+writer.putNu(mdr20PointerSize, city.getMdr20());
}
}
@@ -239,7 +240,7 @@
int size = sizes.getMapSize()
+ localCitySize
+ 3
-+ sizes.getMdr20Size();
++ mdr20PointerSize;
if (hasFlag(0x4))
size += 2;
if (hasFlag(0x8))
@@ -252,10 +253,15 @@
}
/**
- * Known structure:
- * bits 0-1: size of local city index - 1 (all values appear to work)
- * bit 3: has region
- * bit 4: has string
+ * Known structure bits/masks:
+ * 0x0003 size of local city index - 1 (all values appear to work)
+ * 0x0004 has region/country
+ * 0x0008 has string
+ * 0x0010 ? set unconditionally ?
+ * 0x0040 mdr17 sub section
+ * 0x0100 mdr20 present
+ * 0x0400 28_29 offset
+ * 0x0800 mdr20 offset
* @return The value to be placed in the header.
*/
public int getExtraValue() {
@@ -269,7 +275,10 @@
val |= 0x08; // string
}
val |= 0x10;
- val |= 0x100; // mdr20 present
+ if (getSizes().getNumberOfItems(20) > 0) {
+ mdr20PointerSize = getSizes().getMdr20Size();
+ val |= 0x100; // mdr20 present
+ }
return val;
}
Index: src/uk/me/parabola/imgfmt/app/mdr/MdrSection.java
===
--- src/uk/me/parabola/imgfmt/app/mdr/MdrSection.java (revision 4285)
+++ src/uk/me/parabola/imgfmt/app/mdr/MdrSection.java (working copy)
@@ -215,5 +215,9 @@
public int getSize(int sect) {
return sections[sect].getSizeForRecord();
}
+
+ public int getNumberOfItems(int sect) {
+ return sections[sect].getNumberOfItems();
+ }
}
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] MDR 9 & 10 groups
Hi
While trying to diagnose a indexing problem, I find that a bit code in
imgfmt/app/mdr/MdrUtils.java:getGroupForPoi() troublesome:
...
* 4-5 Recreation / Entertainment / Attractions
* 6 Shopping
* 7 Auto Services
* 8 Community
* 9 ?
*
*/
public static int getGroupForPoi(int fullType) {
// We group pois based on their type. This may not be
the final thoughts on this.
int type = getTypeFromFullType(fullType);
int group = 0;
if (fullType <= 0xf)
group = 1;
else if (type >= 0x2a && type <= 0x30) {
group = type - 0x28;
} else if (type == 0x28) {
group = 9;
...
type 0x28 is, according to my device, "Island", but not the one that is
findable under Geographic Points/Water Features, as used by the default
style, which is 0x650c.
So, the first question is, does anyone know why 0x28 was given it's own
group.
The second problem is that the code that builds up the group start
indexes into Mdr10 for Mdr9 assumes that the type ranges of the POI
allocated for a group are in the same order as the groups, so, if you
actually have a POI of type 0x28 then, because it has a lower type but
a higher group than the 0x2a..30 range/groups, mdr9 is wrong.
Unless there is a good reason to have 0x28=group 9, then the simplest
fix is just to remove the lines of code and put in a comment that the
types must be in order.
I'm trying to fix something else in this area so I can include this in
some future patch.
Regards
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Building map with Hebrew characters
Hi Gerd
Attached is a patch that takes Steve's changes for Hebrew and a merges
his other changes with my patch from 8th Apr that removes a lot of
pointless swapping between byte/char and int and also fixes the sign
-extension problem.
Regards
Ticker
On Mon, 2019-04-08 at 21:22 +0100, Steve Ratcliffe wrote:
> Hi
>
> There is a problem that is specific to cp1255 in that there is a
> primary
> character with more than 15 secondary variations.
>
> I've split the first line up in cp1255.txt for lack of any better
> idea
> of what to do.
>
> The attached patch fixes both 1255 and unicode.
>
> Steve
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: resources/sort/cp1255.txt
===
--- resources/sort/cp1255.txt (revision 4285)
+++ resources/sort/cp1255.txt (working copy)
@@ -5,7 +5,8 @@
characters
-=0008=000e=000f=0010=0011=0012=0013=0014=0015=0016=0017=0018=0019=001a=001b=001c=001d=001e=001f=007f=00ad=05bd=200e=200f,0001,0002,0003,0004,0005,0006,0007 ; 05b0 ; 05b1 ; 05b2 ; 05b3 ; 05b4 ; 05b5 ; 05b6 ; 05b7 ; 05b8 ; 05b9 ; 05bb ; 05c2 ; 05c1 ; 05bc ; 05bf
+=0008=000e=000f=0010=0011=0012=0013=0014=0015=0016=0017=0018=0019=001a=001b=001c=001d=001e=001f=007f=00ad=05bd=200e=200f,0001,0002,0003,0004,0005,0006,0007
+ < 05b0 ; 05b1 ; 05b2 ; 05b3 ; 05b4 ; 05b5 ; 05b6 ; 05b7 ; 05b8 ; 05b9 ; 05bb ; 05c2 ; 05c1 ; 05bc ; 05bf
< 0009
< 000a
< 000b
Index: src/uk/me/parabola/imgfmt/app/srt/CodePosition.java
===
--- src/uk/me/parabola/imgfmt/app/srt/CodePosition.java (revision 4285)
+++ src/uk/me/parabola/imgfmt/app/srt/CodePosition.java (working copy)
@@ -20,19 +20,19 @@
* @author Steve Ratcliffe
*/
public class CodePosition {
- private char primary;
- private byte secondary;
- private byte tertiary;
+ private int primary;
+ private int secondary;
+ private int tertiary;
- public char getPrimary() {
+ public int getPrimary() {
return primary;
}
- public byte getSecondary() {
+ public int getSecondary() {
return secondary;
}
- public byte getTertiary() {
+ public int getTertiary() {
return tertiary;
}
@@ -47,23 +47,23 @@
case Collator.PRIMARY:
return primary;
case Collator.SECONDARY:
- return secondary & 0xff;
+ return secondary;
case Collator.TERTIARY:
- return tertiary & 0xff;
+ return tertiary;
default:
return 0;
}
}
- public void setPrimary(char primary) {
+ public void setPrimary(int primary) {
this.primary = primary;
}
- public void setSecondary(byte secondary) {
+ public void setSecondary(int secondary) {
this.secondary = secondary;
}
- public void setTertiary(byte tertiary) {
+ public void setTertiary(int tertiary) {
this.tertiary = tertiary;
}
}
Index: src/uk/me/parabola/imgfmt/app/srt/SRTFile.java
===
--- src/uk/me/parabola/imgfmt/app/srt/SRTFile.java (revision 4285)
+++ src/uk/me/parabola/imgfmt/app/srt/SRTFile.java (working copy)
@@ -106,16 +106,16 @@
int secondary = sort.getSecondary(i);
int tertiary = sort.getTertiary(i);
if (isMulti) {
- assert primary <= 0x;
- assert secondary <= 0xff;
- assert tertiary <= 0xff;
+ assert primary <= 0x : primary;
+ assert secondary <= 0xff : secondary;
+ assert tertiary <= 0xff : tertiary;
writer.put2u(primary);
writer.put1u(secondary);
writer.put1u(tertiary);
} else {
- assert primary <= 0xff;
- assert secondary <= 0xf;
- assert tertiary <= 0xf;
+ assert primary <= 0xff : primary;
+ assert secondary <= 0xf : secondary;
+ assert tertiary <= 0xf : tertiary;
writer.put1u(primary);
writer.put1u((tertiary << 4) | (secondary & 0xf));
}
Index: src/uk/me/parabola/imgfmt/app/srt/Sort.java
===
--- src/uk/me/parabola/imgfmt/app/srt/Sort.java (revision 4285)
+++ src/uk/me/parabola/imgfmt/app/srt/Sort.java (working copy)
@@ -135,7 +135,7 @@
for (int i = 0; i < 256; i++) {
if (((p.flags[i] >>> 4) & 0xf) == 0) {
if (p.getPrimary(i) != 0) {
- byte second = p.getSecondary(i);
+ int second = p.getSecondary(i);
maxSecondary = Math.max(maxSecondary, second);
if (second != 0) {
maxTertiary = Math.max(maxTertiary, p.getTertiary(i));
@@ -361,7 +361,7 @@
// We need +1 for the null bytes, we also +2 for a couple of expanded characters. For a complete
// german map this was always enough in tests.
byte[] key = new byte[(chars.length + 1 + 2) * 4];
- int needed = 0;
+ int needed;
try {
needed = fillCompleteKey(chars, key);
} catch (ArrayIndexOutOfBoundsException e) {
@@ -597,7 +597,7 @@
/**
* Allocate space for up to n pages.
- * @param n
+ * @param n Number of pages
*/
public void
