date:20090708


--- Mer 8/7/09, WessexMario  ha scritto:

> Da: WessexMario 
> Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
> A: "Development list for mkgmap" 
> Data: Mercoledì 8 luglio 2009, 19:55
> 
> 
> Marco Certelli wrote:
> > No Dermod, it doesn't solve the issue.
> > 
> > In fact the Mark's patch just make in a clean way (in
> the IMG only) what I did before in a dirty way (in the OSM
> data): mark's patch surrounds the barrier with a couple of
> ways that has the access=no/foot=yes/bicycle=yes
> restrictions (exactly as if they were footways in OSM) but
> without touching OSM data.
> > 
> > I also do not see a solution for the routes
> starting/ending in the 2 short ways around the bollard: The
> problem is that garmin GPS checks the access only when it
> "enters" a way. If you are already into the forbidden way
> (becouse you start a route from within the way) the fact
> that the way is unaccessible is not checked by garmin.
> > 
> > I guess the only way to reduce the issue is to make
> the 2 ways as short as possible (maybe 10 meters might be
> enough) just to reduce the probability to start/end within
> them. After all, the precision of the GPS cannot tell you on
> which real side of the bollard you are if you actually are
> very close to the barrier.
> > 
> > Ciao
> I'm not sure of the issue here.
> Are you saying that for (say) car routing, if the user
> starts on a footpath, then it's not calculated correctly?.
> You could say "so what?" If the user asks for a route from
> a location that they shouldn't have access to (eg: car on
> "foot=yes, car=no" footpath), then ignore that local
> restriction  (as Garmin would from not entering the way
> ) and just route out as normal.
> If the request is illogical, does it make sense to apply
> too much logic to the answer?

My experience is that Mapsource tries as much as he can to respect access 
restrictions. But if there isn't any other way, it will not respect them.

So, if you start a route (or if you end a route) on a footway and you ask for a 
car routing it will find a route! On the footway. And if the only way to go 
from a road to another is a footway, it will route your car on that footway. 
This does not apply to oneways: oneways are always respected. 

This is what I've seen so far. The reason of this I do not know but maybe 
Garmin consider map errors:
1) if you are on a way, well it is clear you can go in that way. Maybe the map 
is wrong
2) if there is an unreachable road, this is probably a map error again.

Ciao.





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap can't handle multiple elements generated by JOSM

2009-07-08 Thread Johann Gail

IMHO the multiple bounds should be 'merged', ie. all content inside any 
of the bounds should be included in the img file. This would allow to 
define more complexe shapes which are not rectangles.


It is not a must have feature, but this is, was I would expect to happen 
when more than one boundraries are given.


Regards,
Johann



Steve Ratcliffe schrieb:

Hi

  

This resulted in a JOSM .osm file with multiple bounds elements.
mkgmap couldn't handle this and clipped the map to one of them
(presumably the first one) so my generated map showed only a part of
the area I had data for.



Yes the current behaviour is never what anyone expects.
I am want to change the behaviour so that the bounds are ignored
if there is more than one bounds element.

The bounds cutting is specifically for tiling and so it is unnecessary
for random downloaded areas such that you might get from JOSM.

There are other things that could be done, so if anyone has any arguments
either way let me know.

..Steve
___
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] Fwd: OpenStreetMap e-mail - mkgmap bug report


Hi Steve,

Well, that's a bit odd. If you download this area into
JOSM, it looks similar(ish) but by no means exactly the same. If you
then run that area through mkgmap and look at the result with
mapsource, it looks OK. I am wondering if the map image in the email
was made from out of date OSM data that contained the problems the
image shows?

Cheers,

Mark

---

> I'm am forwarding this email, with permission, in the hope that someone
> can help before I able to look at it at the weekend.
> 
> - Forwarded message from Valentijn 
> 
> Date: Wed, 08 Jul 2009 10:47:43 +0100
> Subject: OpenStreetMap e-mail - mkgmap bug report
> 
> Hello Steve,
> 
> Marvellous piece of work, mkgmap! Incredible, really. Although, naturally, 
> there are a few glitches and here's one of them.
> 
> It could be that there's glitches between the connections between two parts 
> of a map (as I'd guess that the position is somewhere between two sub-maps), 
> but I'm not 100% sure of that.
> 
> This 
> http://tile.openstreetmap.nl/?zoom=17&lat=52.01375&lon=5.11781&layers=B0FF
>  is the position on OSM, and this 
> http://valentijn.sessink.nl/temp/CIMG7132.JPG is how it shows up on my Garmin 
> Nüvi 250, while what I did follows shortly. Please note that I did not use 
> "remove-short-arcs" before, I added it *because* there were a few of these 
> unconnected roads in this region and I thought that --remove-short-arcs would 
> fix that. Now I'm not so sure anymore ;-)
> 
> I'll be happy to test new options and I hope this will help to improve mkgmap 
> (if not, please ignore ;-)
> 
> Best regards,
> 
> Valentijn Sessink
> 
> #!/bin/sh
> memory=1700m
> kaart=`mktemp -d`
> 
> cd $kaart
> echo 'Downloading Netherlands...'
> wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2'
> bunzip2 netherlands.osm.bz2
> echo "Downloading mkgmap.jar...
> wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz'
> tar -zxf mkgmap-latest.tar.gz # this turns out to be mkgmap-r1080
> echo "Downloading splitter... "
> wget 'http://www.mkgmap.org.uk/splitter/splitter.jar'
> echo "Splitting Netherlands.osm... "
> java -Xmx$memory -jar ./splitter.jar --max-nodes=100 netherlands.osm 
> echo "done."
> echo "Rendering map... "
> java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland 
> --country-abbr
> =NL --latin1 --remove-short-arcs=4 --lower-case --route 
> --preserve-element-order
>  --location-autofill-1 --gmapsupp --net -c template.args
> echo "done."
> echo $kaart
> 
> ___
> 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 v3] - beware of the bollards!

2009-07-08 Thread WessexMario

Marco Certelli wrote:

No Dermod, it doesn't solve the issue.

In fact the Mark's patch just make in a clean way (in the IMG only) what I did
before in a dirty way (in the OSM data): mark's patch surrounds the barrier
with a couple of ways that has the access=no/foot=yes/bicycle=yes restrictions
(exactly as if they were footways in OSM) but without touching OSM data.

I also do not see a solution for the routes starting/ending in the 2 short ways around
the bollard: The problem is that garmin GPS checks the access only when it
"enters" a way. If you are already into the forbidden way (becouse you start a
route from within the way) the fact that the way is unaccessible is not checked by garmin.

I guess the only way to reduce the issue is to make the 2 ways as short as
possible (maybe 10 meters might be enough) just to reduce the probability to
start/end within them. After all, the precision of the GPS cannot tell you on
which real side of the bollard you are if you actually are very close to the
barrier.

Ciao

I'm not sure of the issue here.
Are you saying that for (say) car routing, if the user starts on a
footpath, then it's not calculated correctly?.
You could say "so what?" If the user asks for a route from a location
that they shouldn't have access to (eg: car on "foot=yes, car=no"
footpath), then ignore that local restriction (as Garmin would from not
entering the way ) and just route out as normal.
If the request is illogical, does it make sense to apply too much logic
to the answer?

___
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

2009-07-08 Thread Stuart Poulton

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).


Not having much joy trying to do anything with the patch.

Heres' the steps I've take (n00b altert). Any guidance welcome.

1 - svn checkout of 1080
2 - Save the patch content of the e-mail to contours_v4.patch
3 - Apply the patch output below.

gateway:/home/g-dev/svn # patch < contours_v4.patch can't find file to  
patch at input line 5

Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--
|Index: src/uk/me/parabola/mkgmap/reader/dem/DEM.java
|===
|--- src/uk/me/parabola/mkgmap/reader/dem/DEM.java  (revision 1080)
|+++ src/uk/me/parabola/mkgmap/reader/dem/DEM.java  (working copy)
--
File to patch:

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Fwd: OpenStreetMap e-mail - mkgmap bug report


Hi

I'm am forwarding this email, with permission, in the hope that someone
can help before I able to look at it at the weekend.

- Forwarded message from Valentijn 

Date: Wed, 08 Jul 2009 10:47:43 +0100
Subject: OpenStreetMap e-mail - mkgmap bug report

Hello Steve,

Marvellous piece of work, mkgmap! Incredible, really. Although, naturally, 
there are a few glitches and here's one of them.

It could be that there's glitches between the connections between two parts of 
a map (as I'd guess that the position is somewhere between two sub-maps), but 
I'm not 100% sure of that.

This 
http://tile.openstreetmap.nl/?zoom=17&lat=52.01375&lon=5.11781&layers=B0FF 
is the position on OSM, and this http://valentijn.sessink.nl/temp/CIMG7132.JPG 
is how it shows up on my Garmin Nüvi 250, while what I did follows shortly. 
Please note that I did not use "remove-short-arcs" before, I added it *because* 
there were a few of these unconnected roads in this region and I thought that 
--remove-short-arcs would fix that. Now I'm not so sure anymore ;-)

I'll be happy to test new options and I hope this will help to improve mkgmap 
(if not, please ignore ;-)

Best regards,

Valentijn Sessink

#!/bin/sh
memory=1700m
kaart=`mktemp -d`

cd $kaart
echo 'Downloading Netherlands...'
wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2'
bunzip2 netherlands.osm.bz2
echo "Downloading mkgmap.jar...
wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz'
tar -zxf mkgmap-latest.tar.gz # this turns out to be mkgmap-r1080
echo "Downloading splitter... "
wget 'http://www.mkgmap.org.uk/splitter/splitter.jar'
echo "Splitting Netherlands.osm... "
java -Xmx$memory -jar ./splitter.jar --max-nodes=100 netherlands.osm 
echo "done."
echo "Rendering map... "
java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr
=NL --latin1 --remove-short-arcs=4 --lower-case --route --preserve-element-order
 --location-autofill-1 --gmapsupp --net -c template.args
echo "done."
echo $kaart

___
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

2009-07-08 Thread Garvan & maew


garvan.m...@online.com.kh wrote:

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


I converted the polish format file to osm format, and I still get the 
same problem. However it look s like I can work around it by splitting 
long roads (it worked in my small test file)? I will keep testing.


Garvan

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1081: Move boundary rule below the highway rules to prevent

2009-07-08 Thread svn commit

Version 1081 was commited by steve on 2009-07-08 17:58:43 +0100 (Wed, 08 Jul 
2009) 

Move boundary rule below the highway rules to prevent
roads being ommited.

This spoils the alphabetic arrangement of the rules :(
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap style precedence problem reported on OSM forum

> Personally, I think the highway tag should take precedence over the
> boundary tag and these lines should be moved below the highway stuff.
> 
> Whaddyathink?

I say, lets do it.

..Steve
___
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?

On Wed, Jul 08, 2009 at 07:59:16AM -0700, Apollinaris Schoell wrote:
> Soylatte is a Java 1.6 implementation for Intel based Mac. Details are  
> available here
> http://landonf.bikemonkey.org/static/soylatte/

Have you tried the OpenJDK6 Beta 1 version, does it work well?

..Steve
___
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?

2009-07-08 Thread Apollinaris Schoell

Soylatte is a Java 1.6 implementation for Intel based Mac. Details are  
available here

http://landonf.bikemonkey.org/static/soylatte/

64 bit Macs have a native 1.6 Java version


On 8 Jul 2009, at 7:22 , Steve Ratcliffe wrote:




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.


OK I have added a note that java 1.6 is required to that page.

I believe that this is a problem mostly for 32 bit Mac versions.
If you or someone else that uses a Mac can let me know where to
get 1.6 for the different versions of the Mac then I will gladly
add the instructions.

Regards,

..Steve
___
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] 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.

OK I have added a note that java 1.6 is required to that page.

I believe that this is a problem mostly for 32 bit Mac versions.
If you or someone else that uses a Mac can let me know where to
get 1.6 for the different versions of the Mac then I will gladly
add the instructions.

Regards,

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!




--- Mer 8/7/09, Dermot McNally  ha scritto:

> Da: Dermot McNally 
> Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
> A: "Development list for mkgmap" 
> Data: Mercoledì 8 luglio 2009, 11:59
> 2009/7/8 Mark Burton :
> 
> > As previously mentioned, the case where both start and
> destination are
> > within the restricted area does not work right and,
> currently, I don't
> > have a plan for fixing this. I can't see how that can
> be achieved.
> 
> Wouldn't Marco's approach of surrounding the bollard with a
> tiny piece
> of footpath do the trick?

No Dermod, it doesn't solve the issue.

In fact the Mark's patch just make in a clean way (in the IMG only) what I did 
before in a dirty way (in the OSM data): mark's patch surrounds the barrier 
with a couple of ways that has the access=no/foot=yes/bicycle=yes restrictions 
(exactly as if they were footways in OSM) but without touching OSM data.

I also do not see a solution for the routes starting/ending in the 2 short ways 
around the bollard: The problem is that garmin GPS checks the access only when 
it "enters" a way. If you are already into the forbidden way (becouse you start 
a route from within the way) the fact that the way is unaccessible is not 
checked by garmin.

I guess the only way to reduce the issue is to make the 2 ways as short as 
possible (maybe 10 meters might be enough) just to reduce the probability to 
start/end within them. After all, the precision of the GPS cannot tell you on 
which real side of the bollard you are if you actually are very close to the 
barrier.

Ciao.


> 
> 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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!

2009-07-08 Thread Dermot McNally

2009/7/8 Mark Burton :

> As previously mentioned, the case where both start and destination are
> within the restricted area does not work right and, currently, I don't
> have a plan for fixing this. I can't see how that can be achieved.

Wouldn't Marco's approach of surrounding the bollard with a tiny piece
of footpath do the trick?

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 v3] - beware of the bollards!


Marco,

> I still do not see the reason to make 2 unaccessible arcs on both sides 
> instead of one.

Imagine that you have only one restricted arc that is on one side of
the bollard. Now if you are within that region and try to route to a
point that is on the other side of the bollard, it will route straight
through the bollard because you are leaving the restricted area and not
entering it. If you have two restricted areas, one each side of the
bollard and your starting point is within one of the areas, it will now
not route through the bollard if the destination is outside of the
restricted area on the other side of the bollard.

As previously mentioned, the case where both start and destination are
within the restricted area does not work right and, currently, I don't
have a plan for fixing this. I can't see how that can be achieved.

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!


--- Mer 8/7/09, Mark Burton  ha scritto:

> Da: Mark Burton 
> Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
> A: mkgmap-dev@lists.mkgmap.org.uk
> Data: Mercoledì 8 luglio 2009, 11:15
> 
> Hi Marco,
> 
> > Why either side? shoudn't be enough one side only for
> restrict the access to the whole way?
> 
> Hey, thanks for that question, it reminded me that I needed
> to make the
> POI a routing node to stop routing across the POI when the
> start point
> is within the restricted region.
> 
> The only case it doesn't work for now is when both the
> start and end
> points are within the restricted region (one each side of
> the POI).
> 

Mark,
this is how I "solved" the issue so far: a short piece (say 10m) of footway on 
one side of the bollard

http://www.openstreetmap.org/?lat=41.895031&lon=12.414956&zoom=18&layers=B000FTF

I still do not see the reason to make 2 unaccessible arcs on both sides instead 
of one.

Ciao.





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v4] - beware of the bollards!

> v4
> 
> forgot to make the POI a routing node - it is now - this stops routing
> across the POI when the start and end points are within the restricted
> area.

Sorry, my comment is incorrect. It only stops routing across the POI
when the start point is in the restricted area not when both the start
and destination points are within the area - that case is still not
handled right.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!


Hi Marco,

> Why either side? shoudn't be enough one side only for restrict the access to 
> the whole way?

Hey, thanks for that question, it reminded me that I needed to make the
POI a routing node to stop routing across the POI when the start point
is within the restricted region.

The only case it doesn't work for now is when both the start and end
points are within the restricted region (one each side of the POI).

> I hope you force the add of an extra node in the way only if another point 
> within 25m does not exists already...

Actually, I force it only if the other point is more than 50m away.
 
> 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.

Go on, try that, see what it looks like. I think it will be ugly when
the existing point is closer than 30m or so.

Cheers,

Mark


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] [PATCH v4] - beware of the bollards!


v4

forgot to make the POI a routing node - it is now - this stops routing
across the POI when the start and end points are within the restricted
area.

-

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..668f1fd 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,115 @@ 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();
+
+			// at this time, we are only looking for POIs that have
+			// the "access" tag defined - if they do, copy the access
+			// permissions to the way - what we want to achieve is
+			// modifying the way's access permissions where it passes
+			// through the POI without affecting the rest of the way
+			// too much - to that end we split the way before and
+			// after the POI - if necessary, extra points are inserted
+			// before and after the POI to limit the size of the
+			// affected region
+
+			final double stubSegmentLength = 25; // metres
+			for(int i = 0; i < points.size(); ++i) {
+Coord p = points.get(i);
+// check if this POI modifies access and if so, split
+// the way at the following point (if any) and then
+// 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 this or the next point are not the last
+		// points in the way, split at the next point
+		// taking care not to produce a short arc
+		if((i + 1) < points.size()) {
+			Coord p1 = points.get(i + 1);
+			// check if the next point is further away
+			// than we would like
+			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);
+			}
+
+			// now split the way at the next point to
+			// limit the region that has restricted
+			// access
+			if(!p.equals(p1) &&
+			   ((i + 2) == points.size() ||
+!p1.equals(points.get(i + 2 {
+Way tail = splitWayAt(way, i + 1);
+

R: [mkgmap-dev] [PATCH v3] - beware of the bollards!




--- Mer 8/7/09, Mark Burton  ha scritto:

> Da: Mark Burton 
> Oggetto: [mkgmap-dev] [PATCH v3] - beware of the bollards!
> A: mkgmap-dev@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@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 v3] - beware of the bollards!