[mkgmap-dev] [PATCH] multipolygons not showing
The attached patch (which changes just one line) fixes a problem with multipolygons sometimes not showing. Best wishes Christian Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java === --- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (Revision 1115) +++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (Arbeitskopie) @@ -54,8 +54,7 @@ if (w != null) { List pts = w.getPoints(); int[] insert = findCpa(outer.getPoints(), pts); - if (insert[0] > 0) - insertPoints(pts, insert[0], insert[1]); + insertPoints(pts, insert[0], insert[1]); pts.clear(); } } ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] success with roadtrip, gmapibuilder
I have been trying for a while to build my own maps with mkgmap, and was getting bad maps into RoadTrip. I figured out what I was doing wrong and thought I'd share it. I had run the splitter and then mkgmap, creating a gmapsupp.img overall map file in addition to all the tiles. I ran gmapibuilder with the gmapsupp.img instead of the individual tiles, and this produces a totally broken gmapi. I spiffed up the caveats section under command line to try to warn others: http://wiki.openstreetmap.org/wiki/Gmapibuilder Here's what I'm doing now, and it seems to work except routing is broken on my vista hcx, perhaps due to some messed up ways in the mass data. #!/bin/sh INPUT=$1 if [ "$INPUT" = "" ]; then INPUT=massachusetts.osm fi cd $HOME/OSM || exit 1 if true; then rm -f 6324* 4001.* areas.list template.args java -Xmx2000m -jar splitter.jar \ --max-nodes=50 \ $INPUT \ > OUT.01.splitter 2>&1 ed template.args < OUT.02.mkgmap 2>&1 #--ignore-osm-bounds \ #--mapname=63249900 \ mkdir -p GMAPI /Users/gdt/SOFTWARE/GMAPIBUILDER/gmapi-builder/gmapi-builder.py -o GMAPI -t 6324.tdb -b 6324.img -v 6324*.img > OUT.03.gmapi 2>&1 ls -lh gmapsupp.img pgpuvNtEevGsm.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Magic highway symbols on Vista CX failing
Hello I seem to have a problem with the default style and the highway tagging on my Garmin Vista CX with mkgmap rev. 1114. When I tag highway=secondary, name=Grand River and ref=MI 123, the result is a road with name "Road". It works as expected, however, with highway=primary. So I did some research and I think the problem is that not all of the "magic" symbols in src/uk/me/parabola/mkgmap/osmstyle/actions/HighwaySymbolFilter.java are available on the unit. Also they are named wrongly for this unit. I made an OSM test file[1] to check all symbol names given in the above source file. It contains parallel road segments with ref=MI 43 name=Grand River I-VI and highway tags of motorway,trunk,primary,secondary,tertiary,residential respectively. Then I used a slightly modified default line style[2] (which assigns one highway symbol to each of the above road types) to generate a map[3] with the --gmapsupp command switch. After uploading the result to my Vista CX, it renders like in this picture[4]. The styles are (from bottom to top): interstate,shield,round,hbox,box,oval. Some remarks: * Styles "interstate" and "shield" look exactly like hbox and box but they prepend "US" and "Hwy." to the reference (only appears when hovering the pointer over the street). This is not so useful for OSM data, since the US tagging scheme in the Wiki says those should be included in the ref tag (i.e. ref="I 94" or ref="US 127"). * Style "box" is misnamed, as it produces an oval * Style "oval" does not work, it seems to break the entire name of the road * Style "round" is misnamed, it produces a framed box I don't know how other units render these symbols, so I can't say whether the names should be changed or not. But I do think that "oval" should at least not be used in the default style for secondary roads, as it actually breaks the name display on my (not quite uncommon) unit. If you need more information or want me to run more tests, please let me know. Alexander [1] http://alex.wittig.name/sonstiges/mkgmap/test.osm [2] http://alex.wittig.name/sonstiges/mkgmap/lines [3] http://alex.wittig.name/sonstiges/mkgmap/gmapsupp.img [4] http://alex.wittig.name/sonstiges/mkgmap/P1020125.JPG ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1115: Fix infinite loop when an action changes a tag in the condition.
svn commit schrieb: > Fix infinite loop when an action changes a tag in the condition. > > You should still avoid actually doing this. Why? Is there still some problem? My understanding is, that such a change would not help for selcting the actual conversion rule, since it is already selected when the action is performed. But I would think it would still have some effect on the post-processing performed on the element (for whatever reason you want to do something like that). And with the proposed stop/continue extension for the style, such an action would still have a result on the evaluation of th efollowing rules. In such a case it would be quite typical to use such a rule. When I have some time, I plan to look into mkgmap and see, whether I can extend the style rules, so that you can have a condition and an action but no conversion in a rule, or more precise: I'm thinking about an empty conversion, e.g. highway=* & surface=ground {set surface=unpaved} [continue] Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing across multiple tiles
Ralf Kleineisel wrote: > On 07/30/2009 11:25 PM, MarkS wrote: > Thanks for this. I've tried it but it doesn't seem to make much difference. A couple of routes did calculate different (in fact one was a bit odd as it took the M4 across the Severn Bridge and then the A48 up the side of the Severn before joining the M5, rather than just going up the M5). However, whilst some longer distances (over a couple of tiles are working), shorter ones sometimes break (unless within a single tile). Here is what I can tell: - The route is more likely to calculate in mapsource if I prefer highways. Using a garmin map it mapsource will calculate regardless of prefernce. - My Etrex has the same sort of issues (not exactly the same). Routing is more likely to work on quickest calculation than best route. - It isn't distance related (some routes were much longer than others) - It isn't purely crossing tiles (some crossing one tile, or going via another fail). - Cornwall and Mid-Wales seem to have more problems with routing to/from (note: might just be where I placed a marker rather than the whole of the area). It looks a bit as if a route that is more likely to involve minor roads (either because of the area or the preferences) the more likely a problem will occur. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1115: Fix infinite loop when an action changes a tag in the condition.
Version 1115 was commited by steve on 2009-07-31 11:44:16 +0100 (Fri, 31 Jul 2009) Fix infinite loop when an action changes a tag in the condition. You should still avoid actually doing this. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin Nuvi asks province
Hi, > Actually, on my GPSMap 76Cxs the address search kind-of-works even > without using the --road-name-pois option*. I have to enter a house > number of some kind for it to work though (even if the destination > doesn't actually have a number) and it only works for some addresses, > but I haven't tested it fully as it's not a facility I actually need. > > *At least, I haven't been enabling the --road-name-pois option when > invoking mkgmap and I assume it isn't enabled by default. Enabling road name POIs does not help the address search function. It's a completely separate function. It was provided as a cheap hack to get some form of road name searching. Arguably, it works better than the address search which, as we know, is less than perfect. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin Nuvi asks province
Quoting Clinton Gladstone : > On Thu, Jul 30, 2009 at 4:39 PM, Valentijn Sessink wrote: > >> java -enableassertions -Xmx1800m -jar >> ~/garmintest/mkgmap/dist/mkgmap.jar --country-name="" --country-abbr="" >> --family-name="Openstreetmap Netherlands `date -I`" --latin1 >> --remove-short-arcs --lower-case --preserve-element-order >> --location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args >> >> What am I doing wrong? I guess this is just a wrong option somewhere? > > If I recall correctly, the "--road-name-pois" option is necessary for > the address search. I do not have a NĂ¼vi, but this works (more or > less) on an eTrex. I believe I must always enter an arbitrary house > number (such as "1") for the search to work properly. Actually, on my GPSMap 76Cxs the address search kind-of-works even without using the --road-name-pois option*. I have to enter a house number of some kind for it to work though (even if the destination doesn't actually have a number) and it only works for some addresses, but I haven't tested it fully as it's not a facility I actually need. *At least, I haven't been enabling the --road-name-pois option when invoking mkgmap and I assume it isn't enabled by default. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing across multiple tiles
On 07/30/2009 11:25 PM, MarkS wrote: > I've also done a bit of experimenting: > > - My routing preference has been set at the mid point. If I move the > slider two notches up towards prefering highways then I don't have a > problem. suggesting that it might be complexity of the route. My eTrex doen't have that setting. I use "shortest time". > I wonder if it is something to do with minor roads (and inter-tile > connections). I use these settings in the style, together with a selfmade TYP file: highway=motorway {add oneway=yes; add bicycle=no; add foot=no; name '${ref|highway-symbol:hbox} ${name}' | '${ref|highway-symbol:hbox}' | '${name|highway-symbol:hbox} [0x01 road_class=4 road_speed=6 level 6] highway=motorway_link {add bicycle=no; add foot=no} [0x09 road_class=4 road_speed=3 level 4] highway=pedestrian & area!=yes [0x0d road_class=0 road_speed=0 level 2] highway=primary [0x02 road_class=3 road_speed=4 level 5] highway=primary_link [0x08 road_class=3 road_speed=3 level 4] highway=residential [0x06 road_class=1 road_speed=2 level 2] highway=living_street[0x06 road_class=0 road_speed=1 level 2] highway=secondary[0x04 road_class=2 road_speed=3 level 4] highway=service [0x07 road_class=0 road_speed=1 level 1] highway=steps {add access = no; add foot = yes} [0x17 road_class=0 road_speed=0 level 2] highway=tertiary [0x05 road_class=1 road_speed=3 level 3] highway=road [0x03 road_class=1 road_speed=2 level 3] highway=trunk {add bicycle=no; add foot=no} [0x01 road_class=3 road_speed=5 level 5] highway=trunk_link{add bicycle=no; add foot=no} [0x08 road_class=3 road_speed=3 level 4] highway=unclassified [0x03 road_class=1 road_speed=2 level 3] highway=unsurfaced [0x0a road_class=0 road_speed=1 level 2] highway=footpath {add access=no; add bicycle=no; add foot=yes} [0x0d road_class=0 road_speed=0 level 1] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev