- mkgmap-dev - The mkgmap lists

error in NumberPreparer?
by Gerd Petermann 22 Apr '15

22 Apr '15

Hi Steve, it seems that NumberPreparer (in trunk) doesn't completely ignore the start/end values when numberStyle == NONE. See line 116: if (first.getLeftStart() > first.getLeftEnd() || first.getRightStart() > first.getRightEnd()) initial = Math.max(initial, rightStart); else if (rightStart > 0) initial = Math.min(initial, rightStart); In normal processing, the fields are 0 when style is NONE, but NumberRangeTest.java sets them to -1 and this really produces different bit streams in some cases, e.g. when iter == 306 the following test case is generated: [0,O,9,7,O,7,5, 1,B,8,2,O,3,5, 2,O,1,1,N,-1,-1] and the patch numbers-v0.patch causes a test failure. Attached version 1 of the patch solves this issue, but I think the problem should be fixed in the preparer and the test should be adapted? Gerd

2 9

MapFailedException when parsing a commented line in text TYP file
by Paco Tyson 21 Apr '15

21 Apr '15

Hi all, I've stumbled upon a MapFailedException when compiling a text TYP file. I use TYPViewer to create TYP files and I chose to create an empty icon to a POI. This leads to the following error : Severe (MapFailedException): /path/to/typfile.txt: (thrown in TypCompiler.makeMap()) Compiling TYP txt file: Error: (/path/to/typfile.txt:3454): Expecting ", instead saw ; Typ file extract : [_point] Type=0x00b SubType=0x00 ExtendedLabels=Y FontStyle=SmallFont CustomColor=No DayXpm="1 1 0 1" Colormode=16 ;Couleurs 24 bits : pas de palette <- line 3454 "#D4D0C8" "#D4D0C8" ;1 [end] If I delete the faulty line, mkgmap compiles the TYP file successfully. In this format, a line starting with ; is a comment. Shouldn't any comment be ignored by the parsing algorithm ? Paco

2 1

class Numbers
by Gerd Petermann 20 Apr '15

20 Apr '15

Hi Steve, I am still struggling with the new structures for city/zip codes. We may add new fields like leftCity,rightCity,leftZip,rightZip to class Numbers, but I'd prefer to change the code completely. Instead of the left/right prefix I'd prefer to have class Numbers{ int start,end; NumberStyle style; CityInfo city; // class CityInfo contains fields city,region,country String zip; } and a higher class,e,g. class RoadNumbers{ int nodeNumber, rnodNumber ; // do we need both? Numbers left,right; } and finally in RoadDef: List<RoadNumbers> numbers; What do you think about that? Gerd

2 4

Bug in created maps?
by Helge Olav Helgesen 20 Apr '15

20 Apr '15

Hi Over the last few days I have experienced a problem that I have not seen before. My Garmin GPS have severe issues routing me to/from my home. Basically the GPS makes big jumps from something that I can’t see as anyting on OSM before it merges with an existing road. Have a look at these images: https://flic.kr/s/aHsk6DUitu This started sometimes after April 2nd and happens for all maps I create. I have not changed anything to make the problem start but I have tried to upgrade mkgmap to the latest version to see if that solved the issue. I have verified this issue on two Garmin GPS’es; Nüvi 3597 and GPSMAP60CSx. This problem is often near my home (https://www.openstreetmap.org/node/3124665591) but if I drive around other parts of the city it seems to work fine. I am not sure if this is an issue with mkgmap or if it is an issue with the underlaying data - but I can’t figure out where to look for any solution. Can anyone please advice me? … Helge

2 3

address search and case significance of street name
by Gerd Petermann 19 Apr '15

19 Apr '15

Hi all, in some areas, esp. in CZ, I see quite a lot of houses where the addr:street name is slightly different to that of the nearest road. Sample: http://www.openstreetmap.org/way/296555634 has name="K Zahrádkám" (with capital "Z") while some houses, e.g. http://www.openstreetmap.org/way/53658380 have addr:street="K zahrádkám" I thought that this is handled by a bot, but this difference exists now for quite a while. I assume that mkgmap should always ignore case when it compares these tags? Or should that depend on the option "--lower-case" ? Gerd

4 9

incompatibility with Garmin eTrex 30
by Hadmut Danisch 17 Apr '15

17 Apr '15

Hi, I have a question about Garmin device compatibility. I'm generating maps from openstreetmap for my garmin devices, using the workflow * download several pbf map segments as needed for the next trip (usually from www.geofabrik.de ) * combining them into one pbf file with osmosis * split it with splitter * convert the split fragments into garmin format with mkgmap The resulting gmapsupp.img works well on my very old Garmin eTrex Venture Cx , all functions as expected including address search. But on my new Garmin eTrex 30, the address search does not find streets (sometimes 3 or 4 of them). It does display streets in the map view including their correct street names. You can point onto a street and it mentions it's correct name. But address search does not find Streets in most cases. Only a very little number of streets gets known to the device. Any hint or idea about the problem or how to fix it? regards Hadmut

1 0

inc/address and --housenumbers
by GerdP 17 Apr '15

17 Apr '15

Hi all, the default style uses the include inc/address in the finalize rules for points and lines. That means that OSM elements which are not added to the map do not have corresponding tags like mkgmap:city. The problem: For the --housenumber option we want to analyse all elements with addr:housenumber, we don't care if the house is displayed as a polygon or as a point or not at all. With the current default style most houses (= elements with addr:housenumber) do NOT have a tag like mkgmap:city or mkgmap:country. Now, this isn't a big problem in most cases because mkgmap has to attach the address information to a road, and the road is added to the map and therefor is passed through the inc/address rules. I faced two situations where this is not sufficient: 1) A road can connect two or more cities. The current code doesn't care about that. In the LocationHook we set the tags like mkgmap:admin_level8 only once for the road (typically for a point near the middle of the road), we don't recognize the case that different points on the roads are in different cities. A possible solution would be to call the LocationHook for each point on the road and split the road into parts before style processing. 2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed. I'll implement that in the housenumber2 branch. Please let me know when you see a better solution. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/inc-address-and-housenumbers-tp5840656.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 27

change inc/address to be a standalone ?
by Gerd Petermann 16 Apr '15

16 Apr '15

Hi experts, I am not happy with the current code regarding address data. My understanding so far: - we have the --bounds option to specify precompiled bounds - we have the LocationHook that is used to assign tags mkgmap:admin_level2 to. mkgmap:admin_level10 and mkgmap:postcode. - we have inc/address to which uses either the data from the LocationHook or that from the OSM element to set mkgmap:city, mkgmap:region etc. The file inc/address in the default style doesn't care about any other tags, means, the result doesn't depend on the exstence of a highway tag or whether the element is a node, way, or polygon. I think we should change that. My proposal: Instead of inc/address we have a file address (on the same level like points, lines, etc) this file is evaluated before the rules in points/lines/polygons when it exists. Probably the class RuleFileReader should make sure that the files points/lines/polygons do not include another inc/address. Gerd

3 10

housenumbers like 1a
by Gerd Petermann 15 Apr '15

15 Apr '15

Hi Steve, I see that you already started to change display tool. Maybe you can also find out whether the img format supports to distinguish numbers like 1a and 1b ? This is frequently used in Germany and I was surprised to see that Garmin ignores it. Typically one can assume that 1a and 1b are close together, but sometimes they are not. Gerd

3 2

Commit: r3539: Be less sensitive to extra spaces and case differences in the Polish format.
by svn commit 15 Apr '15

15 Apr '15

Version mkgmap-r3539 was committed by steve on Wed, 15 Apr 2015 Be less sensitive to extra spaces and case differences in the Polish format.

1 0