Re: [mkgmap-dev] [PATCH v3] - beware of the bollards!
Mark Burton wrote: 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. As a map user and data contributor I get frustrated by the lack of resolution. I'm not sure exactly where in the map rendering process the detail being discussed here lies, but it would be my preference to resolve nodes down to 1m. There are plenty of instances where complex junctions have many roads, footpaths, gates, bollards, cattle grids and stiles all within a 10m radius, on both sides of a country road, expanding the resolution to 25m would make a mess of carefully plotted features and make it even more difficult to render at the highest zoom. If the rendering produces a cluttered map, then that's a rendering issue, but for routing, complex junctions need fine resolution. WessexMario ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter/mkgmap/gmapibuilder on massachusetts.osm, errors
Hi Greg, > 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 ... If you specify the --remove-short-arcs option, those errors should go away. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter/mkgmap/gmapibuilder on massachusetts.osm, errors
try to remove option mapname. this didn't work in Mapsource. After switching to gmapibuilder it worked without any problems in Roadmap with my options Also ignore-osm-bounds doesn't make sense if you split with splitter. splitter creates aligned bounds and uses some overlaps to let mkgmap work out the exact clipping. tiles will align perfect. On 7 Jul 2009, at 18:38 , Greg Troxel wrote: 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=4001 \ --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. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter/mkgmap/gmapibuilder on massachusetts.osm, errors
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=4001 \ --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. pgpAltlqMBeqq.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and java 1.5?
[splitter not working with java 1.5] I found a 1.6 update from apple and now the splitter seems to be running ok. So it really does seem to need 1.6 pgpwnya2O9b6J.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] splitter and java 1.5?
I tried to run the splitter on massachusetts.osm (from cloudmade) because my mac with a paltry 2G of ram couldn't cope in one piece. I got an exception about bad versoin number in class file, and I wonder if the splitter requires java 1.6? It would be nice if all the osm java code worked with 1.5, which is still current with even OS X 10.5.x, or at least if the splitter page at http://www.mkgmap.org.uk/page/tile-splitter explained the prereqs. pgp3EctM578JZ.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] contours
Nop schrieb: Hi! Christian Gawron schrieb: This version of the patch (to be applied against rev. 1080) has a HGTDEM which reads SRTM .hgt files and an optional GeoTiffDEM which contains inner classes to read CGIAR and ASTER. I would like to try out this patch, but first I have to ask a very basic question: How do you apply this sort of patch? Sorry, I have no tool to generate a patch file which contains new files. You have to apply the contours_v4.patch with the patch command (patch < contours_v4.patch) and copy the Java files by hand (HGTDEM.java to src/uk/me/parabola/mkgmap/reader/dem and GeoTiffDEM.java to src/uk/me/parabola/mkgmap/reader/dem/optional). Best wishes Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] - beware of the bollards!
Hi,
On Tue, Jul 07, 2009 at 11:03:41PM +0100, Mark Burton wrote:
[...]
> diff --git a/resources/styles/default/points b/resources/styles/default/points
> index 1c3ae8f..a97fc13 100644
> --- a/resources/styles/default/points
> +++ b/resources/styles/default/points
> @@ -166,3 +166,7 @@ tourism=theme_park [0x2c01 resolution 20]
> tourism=viewpoint [0x2c04 resolution 20]
> tourism=wine_cellar [0x2c0a resolution 20]
> tourism=zoo [0x2c07 resolution 20]
> +
> +barrier=bollard {add access = no; add bicycle = yes; add foot = yes} [0x660f
> resolution 20]
> +barrier=cycle_barier {add access = no; add bicycle = yes; add foot = yes}
> [0x660f resolution 20]
> +
[...]
Haven't looked to closely at the rest...
At least commit that part, it doesn't hurt anything, I'd
say.
Elrond
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] - beware of the bollards!
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
diff --git a/resources/styles/default/points b/resources/styles/default/points
index 1c3ae8f..a97fc13 100644
--- a/resources/styles/default/points
+++ b/resources/styles/default/points
@@ -166,3 +166,7 @@ tourism=theme_park [0x2c01 resolution 20]
tourism=viewpoint [0x2c04 resolution 20]
tourism=wine_cellar [0x2c0a resolution 20]
tourism=zoo [0x2c07 resolution 20]
+
+barrier=bollard {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
+barrier=cycle_barier {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
+
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index aa5bab1..4754d07 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -42,6 +42,7 @@ import uk.me.parabola.mkgmap.general.MapPoint;
import uk.me.parabola.mkgmap.general.MapRoad;
import uk.me.parabola.mkgmap.general.MapShape;
import uk.me.parabola.mkgmap.general.RoadNetwork;
+import uk.me.parabola.mkgmap.reader.osm.CoordPOI;
import uk.me.parabola.mkgmap.reader.osm.Element;
import uk.me.parabola.mkgmap.reader.osm.GType;
import uk.me.parabola.mkgmap.reader.osm.Node;
@@ -426,6 +427,89 @@ public class StyledConverter implements OsmConverter {
}
}
+ // process any Coords that have a POI associated with them
+ if("true".equals(way.getTag("mkgmap:way-has-pois"))) {
+ List points = way.getPoints();
+ final double stubSegmentLength = 25; // metres
+ for(int i = 0; i < points.size(); ++i) {
+Coord p = points.get(i);
+// check if this POI denies access and if so, copy its
+// access restrictions to the way
+if(p instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p;
+ Node node = cp.getNode();
+ if(node.getTag("access") != null) {
+ if((i + 1) < points.size()) {
+ Coord p1 = points.get(i + 1);
+ double dist = p.distance(p1);
+ if(dist >= (2 * stubSegmentLength)) {
+// insert a new point after the POI to
+// make a short stub segment
+p1 = p.makeBetweenPoint(p1, stubSegmentLength / dist);
+points.add(i + 1, p1);
+ }
+
+ // split the way at the next point to
+ // limit the region that has restricted
+ // access (taking care not to produce a
+ // short arc)
+ if(!p.equals(p1) &&
+ ((i + 2) == points.size() ||
+!p1.equals(points.get(i + 2 {
+Way tail = splitWayAt(way, i + 1);
+// recursively process tail of way
+addRoad(tail, gt);
+ }
+ }
+
+ // copy all of the POI's access restrictions
+ // to the way segment
+ for (AccessMapping anAccessMap : accessMap) {
+ String accessType = anAccessMap.type;
+ String accessModifier = node.getTag(accessType);
+ if(accessModifier != null)
+way.addTag(accessType, accessModifier);
+ }
+ }
+}
+
+// see if the next point restricts access and if so,
+// split the way either here, or at a new point that's
+// closer to the POI
+if((i + 1) < points.size()) {
+ Coord p1 = points.get(i + 1);
+ if(p1 instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p1;
+ Node node = cp.getNode();
+ if(node.getTag("access") != null) {
+ boolean newPointAdded = false;
+ double dist = p.distance(p1);
+ if(dist >= (2 * stubSegmentLength)) {
+// inse
Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
Hi Marco, > Maybe I'm wrong in this and access restrictions and turn restrictions are > used in different parts of the IMG file stucture. That's right, they are separate. There may well be a way of specifying that a turn restriction only applies to a certain class of traffic but, if so, it's just another thing we don't know about (add it to the list!) Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] contours
Hi! Christian Gawron schrieb: This version of the patch (to be applied against rev. 1080) has a HGTDEM which reads SRTM .hgt files and an optional GeoTiffDEM which contains inner classes to read CGIAR and ASTER. I would like to try out this patch, but first I have to ask a very basic question: How do you apply this sort of patch? bye Nop ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
Steve Ratcliffe schrieb: > You cannot set the same tag that you are matching. (Currently there is > a bug and it will hang, but the intended result would be just that it is > ignored > as it is too late.) > > All actions will be run before the final matching rule is selected and the > action rules are not run in any particular order. So anything that relies > on the order of the action rules will not work reliably. Ok, so I will check my style, where I have to change something according to above two rules. > So yes, could you think of what kind of preprocessing rules you want > and then we can either make the existing system do that or have a > separate pre-processing phase for that. I think a defined order of the rule processing would be a nice start. But first I will try, how far I can get with the actual implementation. Once again many thanks for your work on mkgmap. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
-- Mar 7/7/09, Mark Burton ha scritto: > Da: Mark Burton > Oggetto: Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards! > A: mkgmap-dev@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@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
Hi > http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Cycle_map > http://svn.openstreetmap.org/applications/utils/export/garmincyclemap/network/ > http://www.openstreetmap.org/user/Richard/diary/6949 Looks great! Is there anything that you would really like it to do that it doesn't yet? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
Hi
> And I think, if I would change the second line to
>
> highway=* tag_a!=yes {set tag_b=yes}
adding in the missing '&' sign:
highway=* & tag_a!=yes {set tag_b=yes}
Then that is allowed, and the result would still be that all
highways were 0x01.
> it wouldn't change anything, or would it?
> What would happen, if the second lien would be changed to the following:
> tag_a!=yes {set tag_a=no; set tag_b=yes}
You cannot set the same tag that you are matching. (Currently there is
a bug and it will hang, but the intended result would be just that it is ignored
as it is too late.)
All actions will be run before the final matching rule is selected and the
action rules are not run in any particular order. So anything that relies
on the order of the action rules will not work reliably.
> So basically I am trying to use the action rules as a preprocessor for
> the OSM data.
So yes, could you think of what kind of preprocessing rules you want
and then we can either make the existing system do that or have a
separate pre-processing phase for that.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1079: Create contour lines directly from a SRTM (or CGIAR, ASTER) file.
2009/7/7 Ralf Kleineisel > On 07/06/2009 12:57 AM, svn commit wrote: > > > --dem-increment Verical distance between the contour lines (default is > 10m). > > I have a suggestion here: > > Currently I use SRTM2OSM to make the contour layers. I use two different > styles to make two SRTM maps with different family IDs. One contains only > the minor contours, the other one the major and medium. Then you can switch > the layers on and off individually in the GPS and have 10 m contours in > flat > areas and only 20 m contours in the mountains. Which means you need different tdb file for Mapsource, otherwise in Mapsource you have no contourlines at all BTW anyone successfully converted the new ASTER data already with mkgmap? > > > It would be great if that would be possible with the new mkgmap contour > mode, too. For example supply more than one output file name for the > different (minor/medium/major) contours. > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Hi Apollinaris, > > I had already considered doing that but it's not worth it unless > > the real GPS units behave differently from mapsource. > > yes they behave different. don't ask how. couldn't figure out a > pattern yet. Well, if necessary, I can add the stub segments either side of the POI. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Hi Martin, > But what about using turn restrictions instead of manipulating the > nearest segments of the ways? See recent posts. > The reason is: if my destination is on side "A" of the bollard on the > restricted segment, garmin would still send me via the bollard whe > it's shorter because it ignores all restrictions if the destination is > within a restricted zone, right? My testing with mapsource did not do that. It took the long way around even though the destination was close to the other side of the bollard. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
2009/7/7 Torsten Leistikow
> Steve Ratcliffe schrieb:
> >> highway=* {set tag_a=yes}
> >> tag_a!=yes {set tag_b=yes}
> >> tag_a=yes [0x01 resolution 20]
> >> tag_b=yes [0x02 resolution 20]
> >> highway=* [0x03 resolution 20]
> >>
> >> Will all highways be converted to 0x01, 0x02 or 0x03?
> >
> > My guess was 0x01. But it turns out that I was wrong :) Actually
> > it is not a valid style because you can't have tag_a!=yes all by itself.
>
> In OSM you can have any tags you like, so there is no reason, why such a
> style would be invalid (e.g. you could use such a scheme, to set all
> highway=footway to highway=path and foot=designated).
>
> And I think, if I would change the second line to
>
> highway=* tag_a!=yes {set tag_b=yes}
>
> it wouldn't change anything, or would it?
>
> I am still trying to figure out, how the rules are working at the
> moment. So what is the result of the above? (I haven't tried it myself.)
> Which lines are processed in which are left out?
>
> What would happen, if the second lien would be changed to the following:
> tag_a!=yes {set tag_a=no; set tag_b=yes}
>
> > It seems that the action rules are being used a lot more than I thought
> > going some way beyond what they were designed for. We need to look at
> what
> > the actions are being used for. I get the impression that a lot of it is
> > to normalize inconsistent tagging, so perhaps we need a separate stage
> > where that is done explicitly.
>
> I don't know, what is possible with the action rules right now, since I
> am still trying to figure out, how they are working.
you can have tags only, but they dont create a copy of the map. whereas
lines seem to be taken for polygons if not asked for in the style-file (i.e.
if you set have_riverbank=yes to display water in the polygon file and any
simple line is joined to become a polygon, often with the generated water
layed over large areas, lines will only be drawn if they are somehow
attached to highway=* & asdf
also when creating style-rules the order is important. highway=* has to be
first, or else some rules will not work so while asdf & highway=* [0x01
resolution 24] does not work, highway=* & asdf [0x01 resolution 24] does
work. might be that this problem only appears on more complex rules (I have
a ruleset of around 10.000 checks running, and needed to tweek the position
of highway=* quite a lot until it actually showed up. I consider the
style-rules to be quite buggy therefore.
>
> Right now I am trying to use the action rules, to generate a bicycle
> routing map, which uses the Garmin-Navi in car-mode, because of the
> better routing algorithms. Therefor I am tweeking the road classes and
> the access restrictions.
> So basically I am trying to use the action rules as a preprocessor for
> the OSM data.
>
> Oh, and by the way: Would it be possible, to add support for a "txt"
> extension for the style files? It is quite anoying on a windows system,
> that you always have to choose manually the application, when you open a
> style file.
You can associate any program to open up files without extensions. google
it. .txt would be more beginner friendly though.
>
>
> Gruss
> Torsten
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
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! Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
I had already considered doing that but it's not worth it unless the real GPS units behave differently from mapsource. yes they behave different. don't ask how. couldn't figure out a pattern yet. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
2009/7/7 Mark Burton : > > 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. Wow, cool! I was actually silently waiting for someone to implement that feature.. ;) But what about using turn restrictions instead of manipulating the nearest segments of the ways? The reason is: if my destination is on side "A" of the bollard on the restricted segment, garmin would still send me via the bollard whe it's shorter because it ignores all restrictions if the destination is within a restricted zone, right? Thank you for working on this! :) -Martin ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
Steve Ratcliffe schrieb:
>> highway=* {set tag_a=yes}
>> tag_a!=yes {set tag_b=yes}
>> tag_a=yes [0x01 resolution 20]
>> tag_b=yes [0x02 resolution 20]
>> highway=* [0x03 resolution 20]
>>
>> Will all highways be converted to 0x01, 0x02 or 0x03?
>
> My guess was 0x01. But it turns out that I was wrong :) Actually
> it is not a valid style because you can't have tag_a!=yes all by itself.
In OSM you can have any tags you like, so there is no reason, why such a
style would be invalid (e.g. you could use such a scheme, to set all
highway=footway to highway=path and foot=designated).
And I think, if I would change the second line to
highway=* tag_a!=yes {set tag_b=yes}
it wouldn't change anything, or would it?
I am still trying to figure out, how the rules are working at the
moment. So what is the result of the above? (I haven't tried it myself.)
Which lines are processed in which are left out?
What would happen, if the second lien would be changed to the following:
tag_a!=yes {set tag_a=no; set tag_b=yes}
> It seems that the action rules are being used a lot more than I thought
> going some way beyond what they were designed for. We need to look at what
> the actions are being used for. I get the impression that a lot of it is
> to normalize inconsistent tagging, so perhaps we need a separate stage
> where that is done explicitly.
I don't know, what is possible with the action rules right now, since I
am still trying to figure out, how they are working.
Right now I am trying to use the action rules, to generate a bicycle
routing map, which uses the Garmin-Navi in car-mode, because of the
better routing algorithms. Therefor I am tweeking the road classes and
the access restrictions.
So basically I am trying to use the action rules as a preprocessor for
the OSM data.
Oh, and by the way: Would it be possible, to add support for a "txt"
extension for the style files? It is quite anoying on a windows system,
that you always have to choose manually the application, when you open a
style file.
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
--- Mar 7/7/09, Mark Burton ha scritto: > Da: Mark Burton > Oggetto: Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards! > A: mkgmap-dev@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@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
Steve Ratcliffe wrote: It seems that the action rules are being used a lot more than I thought going some way beyond what they were designed for. We need to look at what the actions are being used for. If it helps, I finished (\o/) the map I was working on, and have uploaded both it and the source. http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Cycle_map http://svn.openstreetmap.org/applications/utils/export/garmincyclemap/network/ http://www.openstreetmap.org/user/Richard/diary/6949 (Thanks again for all the help!) cheers Richard ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
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. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style rules and 'generated' tags
Hi
> So what will happen with this example.
>
> highway=* {set tag_a=yes}
> tag_a!=yes {set tag_b=yes}
> tag_a=yes [0x01 resolution 20]
> tag_b=yes [0x02 resolution 20]
> highway=* [0x03 resolution 20]
>
> Will all highways be converted to 0x01, 0x02 or 0x03?
My guess was 0x01. But it turns out that I was wrong :) Actually
it is not a valid style because you can't have tag_a!=yes all by itself.
If it were tag_a=yes then the answer would still be 0x01
because that is the first rule with a definition that matches.
It seems that the action rules are being used a lot more than I thought
going some way beyond what they were designed for. We need to look at what
the actions are being used for. I get the impression that a lot of it is
to normalize inconsistent tagging, so perhaps we need a separate stage
where that is done explicitly.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
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? Ciao. --- Mar 7/7/09, Mark Burton ha scritto: > Da: Mark Burton > Oggetto: [mkgmap-dev] [PATCH v2] - beware of the bollards! > A: mkgmap-dev@lists.mkgmap.org.uk > Data: Martedì 7 luglio 2009, 16:58 > > 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@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Hi Dermot, > Yes but... > > 2009/7/7 Mark Burton : > > > My testing indicates the later. If there is no other route, mapsource > > at least, ignores the restriction. > > Consider a case where you have a very simple configuration which I > shall try to draw in ASCII: > > > > | > | > | > +---x-o--- > | > | > | > > > Let "o" be the bollard and x your destination. For badness, let's also > assume that there is only a single way segment between o and the > junction at "+". > > So now the entire piece of road from junction to x is access=no. Do > you think the restriction will be ignored in this case? Yes, mapsource ignores the restriction. > (maybe this won't matter in the real world, I'm just saying it now in > case it could be. I suppose the harder and more correct solution would > be to carve off 5m either side of the bollard into separate restricted > segments) I had already considered doing that but it's not worth it unless the real GPS units behave differently from mapsource. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Yes but... 2009/7/7 Mark Burton : > My testing indicates the later. If there is no other route, mapsource > at least, ignores the restriction. Consider a case where you have a very simple configuration which I shall try to draw in ASCII: | | | +---x-o--- | | | Let "o" be the bollard and x your destination. For badness, let's also assume that there is only a single way segment between o and the junction at "+". So now the entire piece of road from junction to x is access=no. Do you think the restriction will be ignored in this case? (maybe this won't matter in the real world, I'm just saying it now in case it could be. I suppose the harder and more correct solution would be to carve off 5m either side of the bollard into separate restricted segments) Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - beware of the bollards!
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
diff --git a/resources/styles/default/points b/resources/styles/default/points
index 1c3ae8f..a97fc13 100644
--- a/resources/styles/default/points
+++ b/resources/styles/default/points
@@ -166,3 +166,7 @@ tourism=theme_park [0x2c01 resolution 20]
tourism=viewpoint [0x2c04 resolution 20]
tourism=wine_cellar [0x2c0a resolution 20]
tourism=zoo [0x2c07 resolution 20]
+
+barrier=bollard {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
+barrier=cycle_barier {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
+
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index aa5bab1..47fac9b 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -42,6 +42,7 @@ import uk.me.parabola.mkgmap.general.MapPoint;
import uk.me.parabola.mkgmap.general.MapRoad;
import uk.me.parabola.mkgmap.general.MapShape;
import uk.me.parabola.mkgmap.general.RoadNetwork;
+import uk.me.parabola.mkgmap.reader.osm.CoordPOI;
import uk.me.parabola.mkgmap.reader.osm.Element;
import uk.me.parabola.mkgmap.reader.osm.GType;
import uk.me.parabola.mkgmap.reader.osm.Node;
@@ -426,6 +427,65 @@ public class StyledConverter implements OsmConverter {
}
}
+ // process any Coords that have a POI associated with them
+ if("true".equals(way.getTag("mkgmap:way-has-pois"))) {
+ List points = way.getPoints();
+ for(int i = 0; i < points.size(); ++i) {
+Coord p = points.get(i);
+// check if this POI denies access and if so, copy its
+// access restrictions to the way
+if(p instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p;
+ Node node = cp.getNode();
+ String access = node.getTag("access");
+ if(accessExplicitlyDenied(access)) {
+ // split the way at the next point to limit
+ // the region that has restricted access
+ // (taking care not to produce a short arc)
+ if((i + 1) < points.size() &&
+ !p.equals(points.get(i + 1)) &&
+ ((i + 2) == points.size() ||
+ !points.get(i + 1).equals(points.get(i + 2 {
+ Way tail = splitWayAt(way, i + 1);
+ // recursively process tail of way
+ addRoad(tail, gt);
+ }
+
+ // copy all of the POI's access restrictions
+ // to the way segment
+ for (AccessMapping anAccessMap : accessMap) {
+ String accessType = anAccessMap.type;
+ String accessModifier = node.getTag(accessType);
+ if(accessModifier != null)
+way.addTag(accessType, accessModifier);
+ }
+ }
+}
+
+// if this is not the first point in the way, see if
+// the next point restricts access and if so, split
+// the way here
+if(i > 0 && (i + 1) < points.size()) {
+ Coord p1 = points.get(i + 1);
+ if(p1 instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p1;
+ Node node = cp.getNode();
+ String access = node.getTag("access");
+ if(accessExplicitlyDenied(access)) {
+ // split the way here to limit the region
+ // that has restricted access (taking care
+ // not to produce a short arc)
+ if(!p.equals(p1)) {
+Way tail = splitWayAt(way, i);
+// recursively process tail of road
+addRoad(tail, gt);
+ }
+ }
+ }
+}
+ }
+ }
+
// if there is a bounding box, clip the way with it
List clippedWays = null;
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/CoordPOI.java b/src/uk/me/parabola/mkgmap/reader/osm/CoordPOI.java
new file mode 100644
index 000..409965b
--- /dev/null
+++ b/src/uk/me/parabola/mkgmap/reader/osm/CoordPOI.java
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2008 Steve Ratcliffe
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Hi Torsten, > How about a little more general approach? I would propose the following: > > If a way has a note with an access restriction, the segments of the way > that connect to the node have the access restrictions from the node > placed on them. > > This would have the following advantages: > - With such an a feature, you would not only handle bollards, but also > gates and other obstacles. Well, the existing code can handle other barriers if it's told about them. > - You need not to use a default access restrictions, but you can rely on > the restriction in the data base. If no access restriction is defined in > the data, you can still imply one via the style file. (I don't know, > whether such a style rule would be applied in time before you place the > restrictions on the way?) > > - The maps would be still usable, if it is run with with false vehicle > settings. (Only the car setting seems to provide a real good routing, so > to get good a bicycle routing, you need a specially generated map run in > the car-mode). > > What do you think about such a modification? I think your suggestion is a good idea. In fact, while working on this it occurred to me that the same technique could be used to apply other attributes to the way, such as width and speed limitations. So a general approach is probably best. I shall work on it. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Hi Dermot, > I like what you're doing here, but won't that have negative impact if > the adjoining way segments are fairly long? Might it prevent you from > being routed to within, say, 200m of the bollard? Or will an > only-viable-route logic kick in here? My testing indicates the later. If there is no other route, mapsource at least, ignores the restriction. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
2009/7/7 Mark Burton : > 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. I like what you're doing here, but won't that have negative impact if the adjoining way segments are fairly long? Might it prevent you from being routed to within, say, 200m of the bollard? Or will an only-viable-route logic kick in here? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Hi Marco, > I read on wiki that cycle_barrier has no "default" access rule. I think you > should be more conservative and, in absence of explicit tags, let bicycles > passing through (wiki says that cycle_barrier should only imply > motor_vehicle=no) You're right, will fix for v2. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - beware of the bollards!
Mark Burton schrieb: > 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. How about a little more general approach? I would propose the following: If a way has a note with an access restriction, the segments of the way that connect to the node have the access restrictions from the node placed on them. This would have the following advantages: - With such an a feature, you would not only handle bollards, but also gates and other obstacles. - You need not to use a default access restrictions, but you can rely on the restriction in the data base. If no access restriction is defined in the data, you can still imply one via the style file. (I don't know, whether such a style rule would be applied in time before you place the restrictions on the way?) - The maps would be still usable, if it is run with with false vehicle settings. (Only the car setting seems to provide a real good routing, so to get good a bicycle routing, you need a specially generated map run in the car-mode). What do you think about such a modification? Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
R: [mkgmap-dev] [PATCH v1] - beware of the bollards!
--- Mar 7/7/09, Mark Burton ha scritto: > Da: Mark Burton > Oggetto: [mkgmap-dev] [PATCH v1] - beware of the bollards! > A: mkgmap-dev@lists.mkgmap.org.uk > Data: Martedì 7 luglio 2009, 15:30 > > 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. Mark, I read on wiki that cycle_barrier has no "default" access rule. I think you should be more conservative and, in absence of explicit tags, let bicycles passing through (wiki says that cycle_barrier should only imply motor_vehicle=no) Ciao. > > Cheers, > > Mark > > -Segue allegato- > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - beware of the bollards!
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
diff --git a/resources/styles/default/points b/resources/styles/default/points
index 1c3ae8f..28d1fc2 100644
--- a/resources/styles/default/points
+++ b/resources/styles/default/points
@@ -166,3 +166,5 @@ tourism=theme_park [0x2c01 resolution 20]
tourism=viewpoint [0x2c04 resolution 20]
tourism=wine_cellar [0x2c0a resolution 20]
tourism=zoo [0x2c07 resolution 20]
+
+barrier=bollard [0x660f resolution 20]
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index aa5bab1..05f60ac 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -42,6 +42,7 @@ import uk.me.parabola.mkgmap.general.MapPoint;
import uk.me.parabola.mkgmap.general.MapRoad;
import uk.me.parabola.mkgmap.general.MapShape;
import uk.me.parabola.mkgmap.general.RoadNetwork;
+import uk.me.parabola.mkgmap.reader.osm.CoordPOI;
import uk.me.parabola.mkgmap.reader.osm.Element;
import uk.me.parabola.mkgmap.reader.osm.GType;
import uk.me.parabola.mkgmap.reader.osm.Node;
@@ -426,6 +427,88 @@ public class StyledConverter implements OsmConverter {
}
}
+ // process any Coords that have a POI associated with them
+ if("true".equals(way.getTag("mkgmap:way-has-pois"))) {
+ List points = way.getPoints();
+ for(int i = 0; i < points.size(); ++i) {
+Coord p = points.get(i);
+// check if this point is a barrier and if so,
+// transfer any access restrictions to the way
+if(p instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p;
+ Node node = cp.getNode();
+ String barrier = node.getTag("barrier");
+ if(barrier != null) {
+
+ // split the way at a point after the barrier
+ // to limit the region that has restricted
+ // access (taking care not to produce a short
+ // arc)
+ if((i + 1) < points.size() &&
+ !p.equals(points.get(i + 1)) &&
+ ((i + 2) == points.size() ||
+ !points.get(i + 1).equals(points.get(i + 2 {
+ //log.warn("Splitting way " + way.getName() + " at point " + (i + 1) + " after " + barrier);
+ Way tail = splitWayAt(way, i + 1);
+ // recursively process tail of road
+ addRoad(tail, gt);
+ }
+
+ String access = node.getTag("access");
+ String foot = node.getTag("foot");
+ String bicycle = node.getTag("bicycle");
+ if("bollard".equals(barrier)) {
+ if(access == null)
+access = "no";
+ if(foot == null)
+foot = "yes";
+ if(bicycle == null)
+bicycle = "yes";
+ }
+ else if("cycle_barrier".equals(barrier)) {
+ if(access == null)
+access = "no";
+ if(foot == null)
+foot = "yes";
+ }
+
+ if(access != null)
+ way.addTag("access", access);
+ if(foot != null)
+ way.addTag("foot", foot);
+ if(bicycle != null)
+ way.addTag("bicycle", bicycle);
+
+ log.info("Way " + way.getName() + " has " + barrier);
+ }
+}
+
+// if this is not the first point in the way, see if
+// the next point is a barrier and if so, split the
+// way here
+if(i > 0 && (i + 1) < points.size()) {
+ Coord p1 = points.get(i + 1);
+ if(p1 instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p1;
+ Node node = cp.getNode();
+ String barrier = node.getTag("barrier");
+ if(barrier != null) {
+ // split the way at a point before the
+ // barrier to limit the region that has
+ // restricted access (taking care not to
+ // produce a short arc)
+ if(!p.equals(p1)) {
+//log.warn("Splitting way " + way.getName() + " at point " + i + " before " + barrier);
+Way tail = splitWayAt(way, i);
+// recursively process tail of road
+addRoad(tail, gt);
+ }
+ }
+ }
+}
+ }
+ }
+
// if there is a bounding box, clip the way with it
List clippedWays = null;
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/CoordPOI.java b/src/uk/me/parabola/mkgmap/reader/osm/CoordPOI.java
new file mode 100644
index 000..409965b
--- /dev/null
+++ b/src/uk/me/parabola/mkgmap/reader/osm/Coor
Re: [mkgmap-dev] routing error example
Quoting Mark Burton : Hi Garvan, 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. I can't find the point on the map the graphic is showing. What are the coordinates of the junction between the two flags? Sorry , the junction is near N13.10330 E100.91647 Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1079: Create contour lines directly from a SRTM (or CGIAR, ASTER) file.
On 07/06/2009 12:57 AM, svn commit wrote: > --dem-increment Verical distance between the contour lines (default is 10m). I have a suggestion here: Currently I use SRTM2OSM to make the contour layers. I use two different styles to make two SRTM maps with different family IDs. One contains only the minor contours, the other one the major and medium. Then you can switch the layers on and off individually in the GPS and have 10 m contours in flat areas and only 20 m contours in the mountains. It would be great if that would be possible with the new mkgmap contour mode, too. For example supply more than one output file name for the different (minor/medium/major) contours. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] routing error example
Hi Garvan, > 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. I can't find the point on the map the graphic is showing. What are the coordinates of the junction between the two flags? > 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)? A short arc is where two routing nodes are so close together that they are located at the same point. The minimum distance between routing nodes is approx 2.5 metres. > gpsmapedit reports that all nodes are greater than 5m apart in the input. Good, then it's probably not short arcs that are the issue here. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
