- mkgmap-dev - The mkgmap lists

Restriction relations and additional (cycle) ways
by GerdP 01 Apr '14

01 Apr '14

Hi, the via-ways branch is almost done, but I wonder what to do when make-opposite-cycleways is used or when the style creates multiple routable lines for one OSM way. The Garmin format for restrictions reqires nodes and arcs. The OSM format specifies from and to ways and via nodes or ways. Assume that a via way of an only_left restriction has also an opposite cycleway. Should mkgmap create all possible combinations of restrictions to make sure that also bicycles are only routed left ? Or should it make sure that the bicycle ways are not affected? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Restriction-relations-and-additional-cycle-w… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 17

Possible mkgmap GPL v2 license infringement
by Paulo Carvalho 01 Apr '14

01 Apr '14

> > ---------- Mensagem encaminhada ---------- > From: Steve Ratcliffe <steve(a)parabola.me.uk> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Date: Mon, 31 Mar 2014 22:41:54 +0100 > Subject: Re: [mkgmap-dev] Possible mkgmap GPL v2 license infringement > > Hi > > Recently "Projeto Tracksource" released a new version of its TSuite tool >> with Garmin compilation feature. >> > > The jar contains a version of cgpsmapper as a windows executable. > I couldn't find (or see *shame*) it. I used Ark to inspect the Jar contents. Thanks for the finding. > I also believe that they bought the source to cGPSMapper, so it may > be a modified version. > That's right. They bought the source code. > > I do not see anything that suggests they are using mkgmap. > Reading the software manual, it states that it only works on Windows, which explains the .EXE you found. regards, Paulo

1 0

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 68, Issue 97
by Paulo Carvalho 31 Mar '14

31 Mar '14

Greetings, Steve 2014-03-31 17:28 GMT-03:00 <mkgmap-dev-request(a)lists.mkgmap.org.uk>: > > From: Steve Ratcliffe <steve(a)parabola.me.uk> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Date: Mon, 31 Mar 2014 16:23:46 +0100 > Subject: Re: [mkgmap-dev] Incorrect line number in error report > Hi > > As I was experimenting with the style files, I introduced an error >> in one of the rules. Then mkgmap naturally reported an error at, say >> "line 60:20", but the error line was actually several lines further >> down, say line number 73. >> > > This was reported a few days ago and I created a fix, but I can't see > that I sent it out. > > I've attached a patch and I will commit it soon anyway. > > ..Steve > Thanks, Steve. > ---------- Mensagem encaminhada ---------- > From: Steve Ratcliffe <steve(a)parabola.me.uk> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Date: Mon, 31 Mar 2014 20:49:34 +0100 > Subject: Re: [mkgmap-dev] Character decoding used by mkgmap when reading > style files > Hi Paulo > > highway=* & name ~ '(?i)pra[c็ว]a\s+.*' { add >> streettype:movedend='${name|subst:(?i)pra[c็ว]a\s+~>}, Pc.'} # >> > > I tried to reproduce this, but I could not. All seemed to work well > with my quick test. There was a bug that was fixed very recently > (in r3111 and later) about this very problem. Are you using the latest > version? > > Best wishes > > ..Steve > I'm using the latest stable release: 3138. Please, consider this a non-issue for now. I'll double check my procedures. Probably I was mistaken. all the best, Paulo

1 0

Possible mkgmap GPL v2 license infringement
by Paulo Carvalho 31 Mar '14

31 Mar '14

People, Recently "Projeto Tracksource" released a new version of its TSuite tool with Garmin compilation feature. Out of a sudden the JAR grew from 2.5MB to 4.5MB. Probably this tool incorporates mkgmap code. TSuite is distributed as close-source and does not mention mkgmap. TSuite JAR is obfuscated, which casts suspicion itself. But being obfuscated, it also makes proving GPL infringement difficult. Is there any other way to prove that a Garmin map has been compiled with mkgmap? Something like a water mark or some digital fingerprint? "Projeto Tracksource" website: http://www.tracksource.org.br . You can dowload the JAR file here: http://www.tracksource.org.br/index.php/desenvolvimento.html . Hit a button called "TSuite jar" to download it. regards, Paulo

2 1

Character decoding used by mkgmap when reading style files
by Paulo Carvalho 31 Mar '14

31 Mar '14

Dear mkgmap developers, I was developing some string substitution rules in the lines file and we use non-ASCII characters in certain street names prefixes, then I have the following rule: highway=* & name ~ '(?i)pra[cçÇ]a\s+.*' { add streettype:movedend='${name|subst:(?i)pra[cçÇ]a\s+~>}, Pc.'} # Which does not work because mkgmap is using a character decoding to read the style files that is messing with my regexes. I had configured my text editor to save the files in UTF-8 and Latin-1 (ISO-8859-1) for no avail. I ended up in Unicode escaping the accented characters to make them work: highway=* & name ~ '(?i)pra[c\u00E7\u00C7]a\s+.*' { add streettype:movedend='${name|subst:(?i)pra[c\u00E7\u00C7]a\s+~>}, Pc.'} # My suggestion is to make mkgmap read the style files using some broader character decoding (eg.: UTF-8). A side note: the (?u) modifier is not working. This enables Unicode case. Without this I must expand, say "ç" into a character class [cCçÇ]. The (?iu) modifier would cause "ç" to match "c", "C", "ç" and "Ç", for example. This applies to the dozens of other accented characters found throughout the world. And given the multitude of street name prefixes (Brazil, my country, has 50+), this results in quite large and complex style files. This is low priority. I can get along with Unicode escaping but this turns the rules more difficult to read and to maintain. Good job in your latest stable release! Paulo

2 1

bitmasks for garmin vehicle types
by Gerd Petermann 31 Mar '14

31 Mar '14

Hi programmers, I don't know why, but Garmin uses slightly different bitmasks for vehicles in restrictions and roads. (mkgmap:car, mkgmap:taxi, ...) The current code sometimes uses these hard to understand bitmasks (e.g. RoadDef.tabAAccess, RouteRestriction.exceptMask) sometimes more or less similar arrays or lists like StyledConverter.ACCESS_TAGS or RoadMerger.mergeTagsNotBool I'd prefer to use one internal format for these 8 types and only translate them to the Garmin format when the data is written to the img file. This could be a single byte field which is filled after style processing, the corresponding tags in ways would be obsolete after that. A new class Vehicle could translate tags to bits in this byte and vice versa, a toString() method would make debugging easier. How does that sound to you? Gerd

4 3

character encoding failed unexpectedly
by Andrzej Popowski 31 Mar '14

31 Mar '14

Hi, this is the message which I get when compiling Asia map: character encoding failed unexpectedly There is no other hint, I can't guess which tile gives an error. After this message mkgmap ends execution. I use current mkgmap r3145. My options include: code-page=65001 name-tag-list=name:en,name route housenumbers index Any suggestions? -- Best regards, Andrzej

2 4

Incorrect line number in error report
by Paulo Carvalho 31 Mar '14

31 Mar '14

People, As I was experimenting with the style files, I introduced an error in one of the rules. Then mkgmap naturally reported an error at, say "line 60:20", but the error line was actually several lines further down, say line number 73. I think mkgmap is skipping lines with comments #..... or blank lines. I think comment or blank lines should be computed for line numbering matter, which helps a lot in locating them in text editors. To reproduce the issue, just corrupt some rule (I experienced it in inc/address file), taking note of its line number, and compile. thanks, Paulo

2 1

Commit: r3145: use name-tage-list also for apply rules in relations file
by svn commit 30 Mar '14

30 Mar '14

Version mkgmap-r3145 was committed by gerd on Sun, 30 Mar 2014 use name-tage-list also for apply rules in relations file (rel-name-tag-v2.patch)

1 0

Name-tag-list parameter not used in relations processing
by paco.tyson＠free.fr 30 Mar '14

30 Mar '14

Hi, I noticed that the name-tag-list parameter is ignored by mkgmap when processing relations with the "apply" directive. It works as expected for all the other types. If I hard-code the name:xx tag in my relations file, mkgmap uses it and the right language is displayed. I tried putting the parameter in the "-c" config file and on the command line, same buggy behaviour (tested on r2673 and r2889). Regards, Paco

3 11