- mkgmap-dev - The mkgmap lists

Commit: r1066: Minor bug fix - remove extra decrement of loop variable.
by svn commit 17 Jun '09

17 Jun '09

Version 1066 was commited by markb on 2009-06-17 20:43:05 +0100 (Wed, 17 Jun 2009) Minor bug fix - remove extra decrement of loop variable. The extra decrement provided a small speed optimisation but it could also lead to a CoordNode being discarded erroneously. Also, removed a comment that isn't true (although a similar comment elsewhere in this file is true).

1 0

Re: [mkgmap-dev] Overview map: tiny patch/review series
by Marco Certelli 17 Jun '09

17 Jun '09

--- Mar 16/6/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: [mkgmap-dev] Overview map: tiny patch/review series > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Martedì 16 giugno 2009, 18:19 > > Hi Thilo, > > > > At the distances we're (mostly) interested in, > the curvature of the > > > earth's surface has a tiny effect (much less than > the effect of > > > hills & > > > valleys) so I guess (hope) that leaving out that > factor is OK. > > > > The curvature may have a tiny effect, but nonetheless > you should > > consider the coordinate system you are using. > Interpreting lat and lon > > as cartesian coordinates (don't know whether you are > really doing > > that) will give large errors at high latitudes. > > I have to admit that I'm not much of a mathematician so I > am quite > happy to take advice as to the soundness of the current > algorithm. I > did test it against what we were using before and for the > latitudes I > was using, it appeared to work OK. > > > > I know that this isn't your code but it's as good > a place as any > > > to comment about it: looking at the DP code (for > the first time), I > > > immediately see that the loop that finds the max > distance is > > > (potentially) doing many more sqrts and divisions > than it needs to. So > > > even if the code is correct, it could be somewhat > faster which would > > > be > > > worthwhile given that it gets called for every > line. Eg, it could be > > > changed to look like this: > > > > > > // Find > point with highest distance. > > > // Loop > runs downwards, as the list length gets modified while > > > > running > > > for(int i = > endIndex-1; i > startIndex; i--) { > > > > Coord p = points.get(i); > > > > double ap = p.distance(a); > > > > double bp = p.distance(b); > > > > double abpa = (ab+ap+bp)/2; > > > > double dd = abpa * (abpa-ab) * (abpa-ap) > * (abpa-bp); > > > > if (dd > maxDistance) { > > > > maxDistance = dd; > > > > maxIndex = i; > > > > } > > > } > > > maxDistance > = 2 * Math.sqrt(maxDistance) / ab; > > > > > > Also - you get a division by zero if ab is 0, > perhaps adding a test > > > for that before the loop would be advisable. > > > > Do you understand that formula for the distance > calculation? If so > > could you explain it for me? I don't get it. > > Sorry, no. > Just speculation: I've a and b that defines a line. I look for the distance between a point p and the line. Given the triangle p-a-b where p is the vertex and a-b is the "base", the area of the triangle can be calculated from the lenght of its 3 sides (pa, pb, ab). After that, since the area is also base x height / 2 we can calculate the height = area / base * 2 well, the height is exactly the distance of the point p from the line a-b Maybe... > > > > > Another minor nit - the comment is inaccurate as > the list length > > > doesn't change in this loop. > > > > It is accurate, because the list length does get > changed by the way > > the recursion works. It is not obvious, therefore this > comment is > > really needed! > > The loop I mention does not contain any recursion. The loop > in > doFilter() does (it is adorned with a similar comment). > > > Another question, just out of curiosity: Does it > really mattern in > > Java how many sqrts or sin or cos I do? Doesn't that > kind of > > difference get swamped by all that interpretation and > memory > > allocation things etc. going on? With modern FPUs that > kind of > > operation isn't that expensive (if it is done > native). > > You're quite possibly right but some maths ops are > hideously slow (i.e. > acos which is used in the original distance() method). In > the example > above, I would argue that taking the sqrt and division > outside of the > loop doesn't make the code harder to understand and may > yield some > speedup. > > > I would start working on the DP code if it makes > sense. If somebody > > understands that distance formula and could explain it > it would be > > very much appreciated. Otherwise I will have to make > up my own formula > > (sigh...) > > Well, I think Johann wrote the code so maybe he will > enlighten you! > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

4 3

route recalculation senstivity bug found
by Felix Hartmann 16 Jun '09

16 Jun '09

I found out the problem associated to route recalculation not working (well working but only far too late). We currently set the TRE header at 1,3,17 IF we change this over to 1,4,23 route recalculation kicks in at around 25-30m instead of 300-400 (as it happens with 1,3,17 we currently use) on my Vista HCx. I don't know how this is set because the value introduced with the patch about this seems to be organized differently. I changed this with gmaptool and now it works very well. Would be great if these values could be set directly by mkgmap.

6 14

Re: [mkgmap-dev] route recalculation senstivity bug found
by Marco Certelli 14 Jun '09

14 Jun '09

Nuvi 255 here. Route recalculation works very well now (25/30m). I remember a month ago (+/-) it was much worse (say > 100m). Mark, do you have some advice about OSM tagging for address search? Ciao. --- Sab 13/6/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: [mkgmap-dev] route recalculation senstivity bug found > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Sabato 13 giugno 2009, 20:26 > > Hi Felix, > > > I found out the problem associated to route > recalculation not working > > (well working but only far too late). We currently set > the TRE header at > > 1,3,17 IF we change this over to 1,4,23 route > recalculation kicks in at > > around 25-30m instead of 300-400 (as it happens with > 1,3,17 we currently > > use) on my Vista HCx. > > > > I don't know how this is set because the value > introduced with the patch > > about this seems to be organized differently. I > changed this with > > gmaptool and now it works very well. Would be great if > these values > > could be set directly by mkgmap. > > With my vista hcx and using the current value of 0x110301, > the route > recalculates if I go off course by no more than about 25m. > I believe > other people are also getting similar results. Perhaps > people could > confirm that? > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

3 2

Re: [mkgmap-dev] route recalculation senstivity bug found
by Marco Certelli 13 Jun '09

13 Jun '09

I tried also adding tag is_in: no way. What happen is that I search for an address, I insert the name, it founds the address name I look for and shows me a short list of names starting with the chars I input, as soon as I select the address I look for, it says "no match found". :-( I don't know if it may help you: If I search for a city (any city), it doesn't find any city. Ciao. --- Sab 13/6/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: [mkgmap-dev] route recalculation senstivity bug found > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Sabato 13 giugno 2009, 23:31 > > Hi Marco, > > > Mark, do you have some advice about OSM tagging for > address search? > > If a road has a name or reference it will have an entry in > the address > search data structure. It needs also to have a city > associated with it > which can either be the nearest city (town, village, etc.) > or the > road can be tagged explicitly using an is_in tag. > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0

Commit: r1065: Deal with the case where full pathnames are given on the command line.
by svn commit 13 Jun '09

13 Jun '09

Version 1065 was commited by steve on 2009-06-13 12:54:03 +0100 (Sat, 13 Jun 2009) Deal with the case where full pathnames are given on the command line.

1 0

Re: [mkgmap-dev] Search for address
by Marco Certelli 13 Jun '09

13 Jun '09

--- Sab 13/6/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: [mkgmap-dev] Search for address > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Sabato 13 giugno 2009, 11:00 > > Hi Marco, > > > How can I make a map that is serchable for addresses? > Is there a specific tagging in OSM to make search working > (the search for address in Italy in my nuvi 255 always find > "no address match"). > > By default, maps are generated with as much address info as > we know > how to encode. > > It's far from perfect and how well it works depends on > which gps you > have. I just wonder if there is an OSM tagging scheme for ways that is better to use for coding of address search info. Can you show me a city or an area where the address search works? Or an OSM file example? Ciao. > > > And what about street numbers: is it supported in any > way? > > No, street numbers are not yet supported as we don't know > how to encode > them. > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0

Search for address
by Marco Certelli 13 Jun '09

13 Jun '09

Sorry if I ask something already discussed. How can I make a map that is serchable for addresses? Is there a specific tagging in OSM to make search working (the search for address in Italy in my nuvi 255 always find "no address match"). And what about street numbers: is it supported in any way? Many thanks Marco.

2 1

adding typ filename and path gives me an error
by frmas 13 Jun '09

13 Jun '09

Hi, Everything is in the subject. If I run mkgmap with the pathname and name of my .typ file, it gives me an error. If I copy my xxxx.TYP file in the same directory as mkgmap and give no path on the command line, it works. The error is the following one : Exception in thread "main" java.lang.IllegalArgumentException: File extension is wrong size at uk.me.parabola.imgfmt.sys.Dirent.setExt(Dirent.java:213) at uk.me.parabola.imgfmt.sys.Dirent.<init>(Dirent.java:81) at uk.me.parabola.imgfmt.sys.Directory.create(Directory.java:75) at uk.me.parabola.imgfmt.sys.ImgFS.create(ImgFS.java:141) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:285) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.addFile(GmapsuppBuilder.java:189) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.addAllFiles(GmapsuppBuilder.java:160) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:109) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:326) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:123) at uk.me.parabola.mkgmap.main.Main.main(Main.java:100) Francois --

2 1

Background Fill Polygon
by Felix Hartmann 11 Jun '09

11 Jun '09

Etrex and Gpsmaps units (maybe others too) display the map background in yellow, this is not good for contrast and makes reading the display difficult while in forest or other places with quickly changing light conditions between sun/shadow. One can define 0x4b polygon color in typfile, with white or greay to remedy the situation. However this makes the gps draw the background twice and reduces performance when scrolling the map. Would it be possible to have mkgmap fill up any area where there is no polygon defined? It should be customizable which polygon to map instead (0x01 would probabely work well for people not using typfiles). It simply should not be 0x4a or 0x4b.

1 0