- mkgmap-dev - The mkgmap lists

mkgmap and relation 406175
by Jeffrey Ollie 21 Apr '10

21 Apr '10

Can someone take a look at relation 406175 (Skunk River and some related waterways in central Iowa)? With my most recent attempt at rendering with mkgmap (rev 1631) it doesn't show up at all. Prior to that it was the source of some flooding... As far as I can tell the relation is correctly defined, but maybe is is getting damaged by the splitter since it covers such a large area? I'm trying to generate a whole US map using extracts from the planet (currently using planet-100401): bzcat planet-100401.osm.bz2 | ~/osmosis-0.34/bin/osmosis -verbose --read-xml file=/dev/stdin enableDateParsing=no --bounding-box top=50 bottom=23 right=-66 left=-125 idTrackerType=BitSet completeWays=yes completeRelations=yes --write-xml file=usa-100401.osm java -Xmx4000M -jar ~/splitter.jar --cache=cache --max-areas=128 --max-nodes=800000 --mapid=70000001 --geonames-file=cities15000.zip usa-100401.osm <edit template.args> java -Xmx4096M -enableassertions -jar ~/mkgmap.jar -c template.args I'm using splitter rev 105 (the patch in rev 106 doesn't look like it affects me since I'm using a single OSM input file). -- Jeff Ollie

3 5

Unnecessary routing instructions
by Andrew McCarthy 20 Apr '10

20 Apr '10

Hi there, Recently my Etrex has started giving some entirely unnecessary routing instructions, in particular in the middle of roads where there are no junctions. It seems to occur where ways have been split. For example, heading south along this dual-carriageway, I get the instruction "keep left on N11" at this point: http://www.openstreetmap.org/?node=19223905 Interestingly, I don't seem to get those unnecessary instructions at actual junctions. Any hints where in the code I could start looking? Thanks, Andrew

1 0

Java crash - any idea?
by Valentijn Sessink 19 Apr '10

19 Apr '10

Hi list, Mkgmap seems to crash on my brand new Ubuntu 10.04 installation with "OpenJDK" and I can't make anything of it (not being a Java wizard, that is). What does the attachment say? (I just hope it doesn't say "Switch to Oracle Java for €1,837,838 per seat" ;) Best regards, Valentijn

3 2

Re: [mkgmap-dev] Description text
by Minko 19 Apr '10

19 Apr '10

Hi, It would be great to be able to add more information to the pois. At the moment the information that can be seen is streetname, number, postal codes and placenames in the properties of some of the pois (the gps can't show this properties box on all kinds of pois unfortunately) I have been experimenting to 'fool' my Garmin to use addr:streetname etc for some other information and this trick worked. tourism=information { add addr:street='${opening_hours}'; add addr:postcode='${website}' ; add addr:city='${note}' ; } [0x.... resolution ..] Cheers, Minko

4 12

addr or is_in tags
by maning sambale 19 Apr '10

19 Apr '10

Hi, (posting this discussion to the list, hoping others have an idea on this topic) --- addr:street & addr:city seems to work well with mkgmap & garmin mapsource at the moment, all others tags doesnt matter, like addr:state, addr:village, addr:country (they don't seem to affect mapsource's find function), but one thing I think is important (which is currently missing in osmph): there is a "state/province" dropdown menu i discovered in mapsource, that mkgmap can supply using osm data, if said POI has tag: is_in='(province),(leaveblank),Philippines' eg. is_in=Rizal,,Philippines <---- the particular POI will be searchable under (State/Province dropdown)=Rizal, but will be shown as "capitalized" RIZAL, followed by PH or PHI (wherein Philippines is automatically replaced by the country code defined in mkgmap. Definitely, this is intended for U.S. maps where the 2-letter codes of States are always capitalized. But since the search-function is already there, it's possible for garmin to narrow down the search of cities & town in OSMPH if any distinctive province-tag is available, which will make us garmin user very happy :-) Advantage: while addr:state doesn't seem to work with mkgmap (at the moment when I tried it), i think we should still push for it on osm (considering there are lots of towns & cities in the philippines with similar name (isabela, rizal, taytay...), and it's a bit tricky when filtering them out. addr:state or addr:province can easily be converted to is_in='(province),(blank),Philippines' fprmat (for the mean time that it is not supported by mkgmap just yet) -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

1 0

garmin directives in different blocks?
by Valentijn Sessink 18 Apr '10

18 Apr '10

Hello list, As far as I understand, if I wanted to make, let's say, a hypothetical interstate cycleway from any OSM motorway with the mkgmap, I'd have a line in my style like: highway=motorway {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=4 road_speed=1 resolution 14] (Or something alike). Now I'm wondering, shouldn't this be something like: highway=motorway [0x16 road_class=4 road_speed=1 access=XYZ resolution 14] i.e. have the Garmin controls really in the Garmin action block and not in the mkgmap-block? Because the stuff between the curly brackets has effects on the following Garmin actions, i.e. if I wanted to make both a cycleway and a motorway, as far as I understand, I can't do: highway=motorway {add bicycle = no; add foot = no} [0x16 road_class=4 road_speed=1 resolution 14 continue] highway=motorway {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=4 road_speed=1 resolution 14] ... because now my cycleway will be inaccessible to bicycles. And if I use "set" instead of "add", I can't know if foot should be yes or no, as the motorway added it. Now I'm not completely sure my remarks are true, as I've only started building styles, but maybe someone could comment? How should I make the above cycleway plus motorway? Best regards, Valentijn

2 2

a FIXME map style
by maning sambale 18 Apr '10

18 Apr '10

Hi, Just got this idea of creating Garmin maps designed for fixing the data (I use Garmin primarily to collect and fix OSM). Some have started doing this like the nonames style and the All in One Garmin (http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map#Openstreetbugs) but I hope to expand the style to include all the QA tools available in OSM. Some data/style we can integrate are: * No name roads (use the noname style) * Openstreetbug reports * Keep Right reports * POI with names but no other tags Anyone doing a similar map? Maybe you can share some tools. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

8 21

Description text
by Toby Speight 16 Apr '10

16 Apr '10

POIs with address information have this in their description when viewed on my eTrex, but the generation of this appears to be hard-coded. It would be nice to be able to have different information in there - opening hours for shops, or telephone numbers for pubs and hotels, for example. So, would it be possible to make this more general? I'm thinking of having a tag, say "mkgmap:description", that if set would be used for this content. Then our style rules could be used to apply the above.

3 3

Commit: r1634: Destinguish between exceptions that are likely to affect
by svn commit 16 Apr '10

16 Apr '10

Version 1634 was commited by steve on 2010-04-16 12:29:26 +0100 (Fri, 16 Apr 2010) Destinguish between exceptions that are likely to affect only a single map and those that are more likely to mean that the whole process has, or is likely to, fail. New Exception MapFailedException is used instead of ExitException for map specific errors. This will only make a difference when the --keep-going option is supplied. Now map specific errors will no longer abort the whole process when that option is supplied. The exception processing in Main needs some work which will need a separate patch.

1 0

Commit: r1633: At the moment processing of multipolygon boundary relations creates a lot of unwanted effects
by svn commit 16 Apr '10

16 Apr '10

Version 1633 was commited by steve on 2010-04-16 11:41:53 +0100 (Fri, 16 Apr 2010) At the moment processing of multipolygon boundary relations creates a lot of unwanted effects (artificial boundaries on tile bounds, lots of warnings etc.). The patch excludes the boundary relations from the multipolygon processing. This can be changed with the new option --process-boundary-relations. An additional spin-off is the improved performance and less warnings. - WanMil

1 0