- mkgmap-dev - The mkgmap lists

adding pois in the style file
by maning sambale 10 Jun '09

10 Jun '09

Hi, I'm trying to add new POIs in my garmin styles, following this code from cgpsmapper http://cypherman1.googlepages.com/type_point in the points file: natural=spring [0x6511 resolution 20] natural=cave_entrance [0x6413 resolution 20] The map was compiled without any problem, but the icon doesn't appear in Mapsource 6.11. Just blue points. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 1

Re: [mkgmap-dev] change default name "OSM map" in mapsource
by Marco Certelli 08 Jun '09

08 Jun '09

In my script (http://mce66.altervista.org/software.html) I use the mkgmap switch --series-name=OSM-%country% Hope this help. --- Ven 5/6/09, maning sambale <emmanuel.sambale(a)gmail.com> ha scritto: > Da: maning sambale <emmanuel.sambale(a)gmail.com> > Oggetto: Re: [mkgmap-dev] change default name "OSM map" in mapsource > A: "Development list for mkgmap" <mkgmap-dev(a)lists.mkgmap.org.uk> > Data: Venerdì 5 giugno 2009, 16:29 > Thanks! But this is not an > optimal solution especially when you > distribute the map to other users. > > 2009/6/5 Carlos Dávila <cdavilam(a)jemila.jazztel.es>: > > maning sambale escribió: > >> Hi, > >> > >> In mapsource you can select different maps. I > want to compile various > >> maps. How do I change default name "OSM map"? > >> For instance I have a different map name for > contour, osm-cycle, and > >> osm-default. > > I use MapSetToolKit to install osm maps in MapSource. > It has a "Edit" > > button that you can use to change map name to whatever > you want. > > Cheers > > Carlos > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > -- > cheers, > maning > ------------------------------------------------------ > "Freedom is still the most radical idea of all" -N.Branden > wiki: http://esambale.wikispaces.com/ > blog: http://epsg4253.wordpress.com/ > ------------------------------------------------------ > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1

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