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
Re: [mkgmap-dev] Garmin Nuvi asks province
Quoting Clinton Gladstone clinton.gladst...@googlemail.com: On Thu, Jul 30, 2009 at 4:39 PM, Valentijn Sessinkvalen...@blub.net 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] 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
[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] 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
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
[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
[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 21 ed template.args EOF g/^description:/d w EOF fi # --net is implied by --route java -enableassertions \ -Xmx2048m \ -jar mkgmap.jar \ --max-jobs=1 \ --gmapsupp \ --tdbfile \ --series-name=OSM_gdt_series \ --family-name=OSM_gdt_family \ --area-name=OSM_gdt_area \ --overview-mapname=6324 \ --family-id=632 \ --product-id=1 \ --country-abbr=US \ --country-name=United States \ --region-abbr=MA \ --region-name=Massachusetts \ --description=OSM_gdt \ --route \ --add-pois-to-areas \ --remove-short-arcs \ -c template.args \ OUT.02.mkgmap 21 #--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 21 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] [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) {
ListCoord 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
