July 2009 - mkgmap-dev - The mkgmap lists

routing error example
by Garvan & maew 08 Jul '09

08 Jul '09

Hi, I have made a cut down sample map showing an error in routing as displayed in mapsource. The source is in polish format, and includes the junction where the errors are found, and a portion of a city to the south. If I delete more roads from the city, the error disappears, even though the error itself is apparently north of the city. The routing works correctly in gpsmapedit. The graphic file shows the junction where the errors are happening. The route should be west and south from one waypoint to the other, and instead it jumps about, sometimes following roads, sometimes making straight-line jumps. In another post, I was told there are “short arcs” errors in the polish format input. Could somebody describe exactly what a short arc is, (length between nodes, length between routing nodes or something else, and what is the minimum length arc)? gpsmapedit reports that all nodes are greater than 5m apart in the input. Thanks for any suggestions, Garvan

3 3

mkgmap style precedence problem reported on OSM forum
by Mark Burton 08 Jul '09

08 Jul '09

On the OSM forum, we get: http://forum.openstreetmap.org/viewtopic.php?id=3879 The report says: > when a border overlapes a street, the street is broken. The street is not > recognized for routing. This happens in MapSource and on the Oregon 200 device. This must be because in the style file, these lines are at the top: aeroway=runway [0x27 resolution 20] boundary=administrative [0x1c resolution 18] boundary=national [0x1e resolution 17] boundary=political [0x1c resolution 17] and so the way, which is tagged as both a road and a boundary, has garmin code 0x1c (not a road code). Personally, I think the highway tag should take precedence over the boundary tag and these lines should be moved below the highway stuff. Whaddyathink? Cheers, Mark

2 1

R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
by Marco Certelli 08 Jul '09

08 Jul '09

--- Mer 8/7/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: [mkgmap-dev] [PATCH v3] - beware of the bollards! > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Mercoledì 8 luglio 2009, 00:03 > > v3 > > now adds extra points either side of the POI to reduce > length of > way that has restricted access. Currently points are 25m > away from the > POI. It would be nice if they were really close (like 5m) > but if you > try that, the map looks crap due to the limited coordinate > resolution. > So, 25m is a compromise between visual appearance and > minimising the > extent of the restricted zone. > Why either side? shoudn't be enough one side only for restrict the access to the whole way? I hope you force the add of an extra node in the way only if another point within 25m does not exists already... moreover, if a point exist in the way between 25m and 50m, you shoud add the new node by cutting the arc in 2 (otherwise you have a 25m arc on a side and a shorter arc on the other. so, my proposal might be: the first point from the barrier is at a distance <25m: use the existing node >25m & <50m: put a new node in the middle >50m: add a node at 25m. Marco. > ------------ > > v2 - quick update based on instantaneous feedback from ML! > > Now works for any POI that sets "access=no" (could use the > more general > test of any of the access tags being set but let's see how > this works > for now). > > Default access rights now set in style file. > > Any suggestions for a better code for cycle_barrier? > > ------------ > > Fed up of being routed in your car down city streets only > to find the > way is blocked by a bollard? Well, if so, this is the patch > for you. > > If a way has a bollard on a point, the segments of the way > that > connect to the bollard have access restrictions placed on > them. By > default, a bollard implies: access=no, foot=yes, > bicycle=yes. > > Testing using mapsource shows that it generally works as > expected > although if the destination cannot be reached by any other > route, it > routes straight through the bollard rather than failing! If > the > destination can be reached by some other route, even if the > route is > really long, it will avoid the bollard. > > I have chosen Garmin code 0x660f (pillar) for the bollard. > On my etrex > it appears as a small dot in the way. > > As usual, all feedback is welcome. > > Cheers, > > Mark > > -----Segue allegato----- > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 1

[PATCH v3] - beware of the bollards!
by Mark Burton 08 Jul '09

08 Jul '09

v3 now adds extra points either side of the POI to reduce length of way that has restricted access. Currently points are 25m away from the POI. It would be nice if they were really close (like 5m) but if you try that, the map looks crap due to the limited coordinate resolution. So, 25m is a compromise between visual appearance and minimising the extent of the restricted zone. ------------ v2 - quick update based on instantaneous feedback from ML! Now works for any POI that sets "access=no" (could use the more general test of any of the access tags being set but let's see how this works for now). Default access rights now set in style file. Any suggestions for a better code for cycle_barrier? ------------ Fed up of being routed in your car down city streets only to find the way is blocked by a bollard? Well, if so, this is the patch for you. If a way has a bollard on a point, the segments of the way that connect to the bollard have access restrictions placed on them. By default, a bollard implies: access=no, foot=yes, bicycle=yes. Testing using mapsource shows that it generally works as expected although if the destination cannot be reached by any other route, it routes straight through the bollard rather than failing! If the destination can be reached by some other route, even if the route is really long, it will avoid the bollard. I have chosen Garmin code 0x660f (pillar) for the bollard. On my etrex it appears as a small dot in the way. As usual, all feedback is welcome. Cheers, Mark

3 3

splitter/mkgmap/gmapibuilder on massachusetts.osm, errors
by Greg Troxel 08 Jul '09

08 Jul '09

I took the Cloudmade massachusetts.osm.bz2 from July 1st, and because I wanted a routable map tried to make my own. I ran the splitter just fine (mac, with java 1.6), and then ran mkgmap like this: java -enableassertions \ -Xmx2048m \ -jar mkgmap.jar \ --tdbfile \ --gmapsupp \ --family-id=632 \ --mapname=63249900 \ --overview-mapname=40000001 \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="MA" \ --region-name="Massachusetts" \ --description="OSM gdt" \ --ignore-osm-bounds \ --net \ --route \ --add-pois-to-areas \ -c template.args This produced a gmapsupp.img, as well as overview img and tdb, with the following errors: SEVERE (RoadNetwork): Road null (OSM id 9208777) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 9325924) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 9563279) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road NEW HOPE WAY (OSM id 11175820) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 29730871) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30158233) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30574585) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30574585) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30574531) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30575415) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 9252537) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road NEW HOPE WAY (OSM id 11175820) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 29730871) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30158233) contains consecutive identical nodes - routing will be broken I ran gmapibuilder.py, and that seemed to be ok, but RoadTrip claims the map has errors and cannot be displayed. This is with mkgmap 1048. I will update to the latest and try again. I will also omit the --mapname argument, but the gmapi dir seems ok. Any hints would be appreciated.

3 2

Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
by Marco Certelli 07 Jul '09

07 Jul '09

-- Mar 7/7/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards! > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Martedì 7 luglio 2009, 18:38 > > Hi Marco, > > > Mark, the wiki page about restrictions > > > > http://wiki.openstreetmap.org/wiki/Relation:restriction > > > > says I can put a key except with the following > values/meaning: > > > > except - psv/bicycle/hgv/motorcar - The restriction > does not apply to these vehicle types (more than one: > except=bicycle;psv) > > > > So do you mean that mkgmap does not actually > support/handle the except key in a relation restriction? > > Err, no - sorry. > > Almost certainly, there is some Garmin magic to express > such an > exception but we don't know about it! > Mark, my last post about this issue, since I really know too little about garmin IMG and mkgmap. I thought that the restriction relations were utilized in the routing IMG data base exacly as the way access tags. I thought both were utilized by mkgmap to build the same access vector (the per vehicle access vector). Maybe I'm wrong in this and access restrictions and turn restrictions are used in different parts of the IMG file stucture. Ciao. > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1

Style rules and 'generated' tags
by Richard Fairhurst 07 Jul '09

07 Jul '09

Hi all, Ive been trying to work on some style rule files and am running into a few problems. The rules Im using (in lines) are this: ncn_ref=* { set ncn=yes; echo 'Converting from ${ncn_ref}'; } ( highway=bridleway | highway=byway | highway=cycleway | highway=track | highway=footway) & ( ncn=yes | rcn=yes ) { set offroad='yes'; echo 'Offroad route'; } ncn=yes { echo 'Is NCN'; } offroad=yes { echo 'Is offroad'; } ncn=yes & offroad=yes { echo 'NCN Offroad'; set highway=ncn_offroad; } ncn=yes & offroad!=* { echo 'NCN Onroad'; set highway=ncn_onroad; } (As you can see I added an echo statement to aid debugging... thats about the limit of my Java. :) ) Unfortunately, the penultimate rule (NCN Offroad) never fires. Instead, the next one (NCN Onroad) always does. The debug output for one way looks like this: 31346279: Is NCN testing for offroad <-- debug statement from get in Tags testing for offroad 31346279: NCN Onroad 31346279: Converting from 5 testing for offroad set offroad yes <-- debug statement from perform in AddTagAction 31346279: Offroad route 31346279: Creating NCN on-road with 5 <-- highway=ncn_onroad [0x01] 31346279: Is NCN testing for offroad testing for offroad 31346279: NCN Onroad 31346279: Is offroad 31346279: Creating NCN on-road with 5 So although the Is offroad test is working, the next line isnt. The fact its iterating over the rules a couple of times is a bit odd, too. From what I can tell, get (in Tags.java) isnt coping very well with the ExtraEntry tags. But despite poking around for a couple of hours, Ive not pinned it down - like I say my Java knowledge is verging on non-existent. Or maybe Im just doing something stupid with the rules. Any clues? cheers Richard

4 10

Commit: r1079: Create contour lines directly from a SRTM (or CGIAR, ASTER) file.
by svn commit 07 Jul '09

07 Jul '09

Version 1079 was commited by steve on 2009-07-05 23:57:03 +0100 (Sun, 05 Jul 2009) Create contour lines directly from a SRTM (or CGIAR, ASTER) file. It introduces the following new options: --contours If set, create contours. --dem-type Valid values are CGIAR (CGIAR geotiff), ASTER (ASTER geotiff) or SRTM (.hgt files). Default is CGIAR. --dem-path Path to the DEM data files. The default is type-dependant. --dem-increment Verical distance between the contour lines (default is 10m). - Code written by Christian Gawron

4 3

[PATCH v1] - beware of the bollards!
by Mark Burton 07 Jul '09

07 Jul '09

Fed up of being routed in your car down city streets only to find the way is blocked by a bollard? Well, if so, this is the patch for you. If a way has a bollard on a point, the segments of the way that connect to the bollard have access restrictions placed on them. By default, a bollard implies: access=no, foot=yes, bicycle=yes. Testing using mapsource shows that it generally works as expected although if the destination cannot be reached by any other route, it routes straight through the bollard rather than failing! If the destination can be reached by some other route, even if the route is really long, it will avoid the bollard. I have chosen Garmin code 0x660f (pillar) for the bollard. On my etrex it appears as a small dot in the way. As usual, all feedback is welcome. Cheers, Mark

5 10

Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
by Marco Certelli 07 Jul '09

07 Jul '09

--- Mar 7/7/09, Mark Burton <markb(a)ordern.com> ha scritto: > Da: Mark Burton <markb(a)ordern.com> > Oggetto: Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards! > A: mkgmap-dev(a)lists.mkgmap.org.uk > Data: Martedì 7 luglio 2009, 17:50 > > Hi Marco, > > > Mark, may I suggest a totally different approach? > > > > why not to use a couple of restriction relations? > > > > a no_straight_on between the segment before (from) and > after (to) the bollard node (via) and a second > no_straight_on relation the way round. > > > > Of course with the right "except": bicycle, foot, ... > > > > You could also invent an "internal" relation > restriction like "no_passage" > > > > The issue here seems that the "except" key does not > foresees "foot". > > > > Would it be feasible? > > I don't think so because turn restrictions affect all > traffic except > foot so you could not distinguish between a car and a > bicycle. Mark, the wiki page about restrictions http://wiki.openstreetmap.org/wiki/Relation:restriction says I can put a key except with the following values/meaning: except - psv/bicycle/hgv/motorcar - The restriction does not apply to these vehicle types (more than one: except=bicycle;psv) So do you mean that mkgmap does not actually support/handle the except key in a relation restriction? Ciao, Marco. > > Cheers, > > Mark > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1