June 2009 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Commit: r1061: Don't use SizeFilter or DouglasPeuckerFilter for resolution 24.
by Marco Certelli 07 Jun '09

07 Jun '09

I Tried today the new mkgmap. I confirm the problem I noticed regarding the short arcs lost in Rome is solved. Routing is consistent. The short arc is back. Ciao, Marco. --- Dom 7/6/09, Johann Gail <johann.gail(a)gmx.de> ha scritto: > Da: Johann Gail <johann.gail(a)gmx.de> > Oggetto: Re: [mkgmap-dev] Commit: r1061: Don't use SizeFilter or DouglasPeuckerFilter for resolution 24. > A: "Development list for mkgmap" <mkgmap-dev(a)lists.mkgmap.org.uk> > Data: Domenica 7 giugno 2009, 13:59 > > > Version 1061 was commited by markb on 2009-06-06 > 17:18:47 +0100 (Sat, 06 Jun 2009) > > Don't use SizeFilter or DouglasPeuckerFilter for > resolution 24. > > > > This fixes the bug where the SizeFilter was zapping > tiny ways at that > > resolution. > > > > Also, the DP filter was a no-op at that resolution so > there's no > > point in invoking it. > > > > > Yes, I have seen this lack of optimization before but had > not had time to create a patch for it. I had the same idea > in not inserting the filters in the chain at highest > resolution. > > But I was not aware that there was a bug in it. > > Thank you! > > Regards, > Johann > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0

Commit: r1061: Don't use SizeFilter or DouglasPeuckerFilter for resolution 24.
by svn commit 07 Jun '09

07 Jun '09

Version 1061 was commited by markb on 2009-06-06 17:18:47 +0100 (Sat, 06 Jun 2009) Don't use SizeFilter or DouglasPeuckerFilter for resolution 24. This fixes the bug where the SizeFilter was zapping tiny ways at that resolution. Also, the DP filter was a no-op at that resolution so there's no point in invoking it.

2 1

Commit: r1064: Remove ref and associated methods and use the superclass versions.
by svn commit 06 Jun '09

06 Jun '09

Version 1064 was commited by markb on 2009-06-06 23:26:38 +0100 (Sat, 06 Jun 2009) Remove ref and associated methods and use the superclass versions.

1 0

Commit: r1063: Remove surplus call to setRef() as it's been done already in elementSetup().
by svn commit 06 Jun '09

06 Jun '09

Version 1063 was commited by markb on 2009-06-06 23:26:35 +0100 (Sat, 06 Jun 2009) Remove surplus call to setRef() as it's been done already in elementSetup().

1 0

Commit: r1062: Road name POI code now manipulates MapRoad objects instead of MapLine.
by svn commit 06 Jun '09

06 Jun '09

Version 1062 was commited by markb on 2009-06-06 23:26:31 +0100 (Sat, 06 Jun 2009) Road name POI code now manipulates MapRoad objects instead of MapLine. Code function hasn't changed but as the objects really are roads it made sense to change the types to match the objects.

1 0

[PATCH v2] - allow RNP type to be set on a road-per-road basis
by Mark Burton 06 Jun '09

06 Jun '09

v2 - split out the non-related changes (they have now been committed so this patch is based on r1064). -------------- OK Felix, here's something to play with. This patch allows you to specify the garmin type of a road's RNP using a mkgmap:rnptype tag. You can then set that tag in a style file when you match some other tag values. Like this (silly) example that makes the RNP generated for a footway to be a zoo: highway=footway {add mkgmap:rnptype=0x2c07; add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23] Alternatively, you could add that tag directly into the OSM XML or even pre-process the OSM XML to add the tag conditionally. The patch also contains a couple of other un-related changes that will be committed separately if they are OK. Cheers, Mark

1 0

Parsing of ":" and "."
by Felix Hartmann 06 Jun '09

06 Jun '09

Hallo, Sorry Mark for probably bugging you again.... First the probably easier question, why is it not possible to use a line like 1. highway=* & source=plan.at [0x07 resolution 24] in my style file? The point in plan.at throws an exception. 2. highway:plan.at=* &..... Same problem. In Austria due to the import many ways can be identified like this, and one could decrease the road_class and/or road_speed because the quality of the data is very bad. Now the harder part, would it be possible to enable in the osm5xmlhandler.java the parsing of ":" ? String mtb:scaleTag = currentWay.getTag("mtb:scale"); if ( ("0".equals(mtb:scaleTag)) || ("1".equals(mtb:scaleTag) ) || ("true".equals(mtb:scaleTag) )) { // Add additional mtb:scale over old highway long mtb:scaleId = currentWay.getId() + MTB_ID_OFFSET; Way mtb:scaleWay = new Way(mtb:scaleId); wayMap.put(mtb:scaleId, mtb:scaleWay); List<Coord> points = currentWay.getPoints(); for(int i = 0; i < points.size(); ++i) mtb:scaleWay.addPoint(points.get(i)); mtb:scaleWay.addTag("mtb:scale", "11"); log.info("Making additional mtb:scale '" + mtb:scaleWay.getTag("name") + "'"); } If I have these lines added, mkgmap.jar does not compile. Felix

2 3

Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length
by Marco Certelli 06 Jun '09

06 Jun '09

Great Job, Mark. "Making the best possible Gramin map with the available OSM Data" That should be the mkgmap driver, and you actively support that intent. I'll give a try to the new version tomorrow... Thanks again. Ciao, Marco. --- Sab 6/6/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Sabato 6 giugno 2009, 17:25 > > Hi Marco, > > > I've experienced the same problem: a short arc > disappered in Rome (I'm still looking for it...). And the > routing gets broken. Did you understand why those short arcs > (with no collapsing end nodes) get deleted? > > Bug found, fix committed. > > The min arc length can still be specified with > --remove-short-arcs (note > correct name!) but it shouldn't be needed any more. > > Zero length arcs must still be removed so you do need to > specify > --remove-short-arcs (but without the min length). > Once this has proven > to be trustworthy, we could think about making the zero > length arc > removal the default behaviour when routing is enabled. > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0

Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length
by Marco Certelli 06 Jun '09

06 Jun '09

Hi Mark, I've experienced the same problem: a short arc disappered in Rome (I'm still looking for it...). And the routing gets broken. Did you understand why those short arcs (with no collapsing end nodes) get deleted? Ciao, Marco. --- Gio 4/6/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Giovedì 4 giugno 2009, 19:57 > > Hi Felix, > > > Shame on me, I had in my batch the call for the > unpatched mkgmap > > version, which of course did not. > > OK. > > > What can I say about the patch? Get it into TRUNK!!!! > > I will commit it soon as it won't affect the default > operation. > > > Finally Routing over longer distances IS possible. > Route calculation > > time decreased in mapsource by up to 50%, and possible > route length > > increased about 20-25%. > > Also no single Mapsource Crash since!!!!!!!!!!!!! > > Good. > > > At least in Austria where because of the import, many > roads are not > > connected, this patch is absolutely essential! > > The patch only merges nodes that are close and already > connected. > It doesn't merge nodes that are close and not connected. > > > On my Vista HCx also many destinations that previously > took 2-3 minutes > > to calculate just calculated only 20-30 seconds! > > Great. > > > Maybe don't enable it by default, I have not really > tested whether now > > there are any problems with roads connected that > should not be > > connected, but so far it has been working great! > > I will commit something that has the same effect as the > patch you have > tried. > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

4 8

Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length
by Marco Certelli 06 Jun '09

06 Jun '09

The disappearing way id is 25774907 Sorry, I'm leaving now. See you later. Ciao. --- Sab 6/6/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Sabato 6 giugno 2009, 15:40 > > Hi Marco, > > > 41°52.367' N > > 12°30.477' E > > > > I attach a small zipped osm file that compiles with > that problem (it is between two tracks at a cross in the > center of the osm). > > I'm looking at that but can't identify the problem - do you > have the > OSM ids for nodes/ways where it is failing? > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

1 0