Hi Marko,
Has anyone written a lint program for *.img files that would validate
all the cross-references? Or a program to pretty-print the data structures
in sorted format? The sorted pretty-print should be identical across runs.
There are various programs around for printing out the stuff
Hi Paul,
Thanks for the figures.
real4m13.508s
user4m39.725s
sys 0m16.205s
Time duration: 254 secs.
real3m25.462s
user5m21.408s
sys 0m15.697s
Time duration: 205 secs.
The first is without --max-jobs and the second is with and both are a
considerable
Hi Clinton,
I have also tested this patch on my Windows machine: the error which I
previously reported regarding missing files no longer occurs. Sorry
for not responding earlier, but I was away.
No problem, glad it has fixed the issue.
A superficial examination of the map revealed no
Hi Robert,
Many thanks for the feedback.
how much difference is tolerable...?
enabling your diagnostic code, i've observed differences typically in
the range of .25% to .4%, with some exceptions like...
quickDistance() = 1.4536911305450404 slowDistance() = 1.446011378093334
Hi Thilo,
So if you like to integrate the switch for
the maxspeed handling into the trunk I will be happy, but I also
understand that you might not want mkgmap to be cluttered with lots of
special options.
Well, I don't have a problem with lots of options so I am happy to
commit that
Hi Marko,
What would it take to duplicate the way in mkgmap, as highway=cycleway,
oneway=-1? This could of course be done relatively easily by preprocessing
the OSM data before feeding it to mkgmap, but I would consider it an ugly
workaround.
This has been discussed before but I don't
Hi Marco,
I want to say: duplicated nodes and almost duplicated nodes are map errors
(expecially if they describe an highway). We do not know wich was the right
intention of the mapper (make routing possible/impossible).
I think that the best we can do when mkgmap finds 2 nodes that
Hi Marco,
Mark, I'd like to help but I've no way to build mkgmap. Could you please send
me a compiled mkgmap.jar to test the patch?
Wilco.
But why can't you build mkgmap? I believe it can even be done on
Windows boxes so it can't be that difficult.
Please, don't give up in searching for
Hi Clinton,
I have had this patch applied for some time, and have used it for car
and bicycle routing: I have not noticed any difference in routing
behaviour. It is probably safe to commit.
Excellent.
Cheers,
Mark
___
mkgmap-dev mailing list
Hi Marko,
Many thanks for your suggestion about avoiding adding an arc from a node
to itself. Your detective work/thinking has paid off.
Actually, the real problem is much earlier in the processing and I have
now committed a fix.
The problem is that you can't use Coord objects as keys in
v12
Great stuff, I found out why I was getting occasional differences in
the output files. It was another occurrence of a non-deterministic
iteration order of a HashMap but this one was real hard to understand
because it only had an effect if the OSM map data had a badly formed
restriction
Hi Felix,
I think this has not yet been mentioned on the mailing-list:
There seems to be some code missing in the road-name-pois. I changed the
ID to several values that if used inside the Points file, would be
findable with the search function. If however I use the same ID for the
Hi Felix, Thilo,
Is it possible to produce a small example OSM file that shows this
problem? If so, please zip it up and send it to me or put it on a
website I can access.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Robert,
http://page.mi.fu-berlin.de/vollmert/tmp/neud.osm.gz
Yes, that file contains lot's of duplicate ways/nodes sitting on top of
each other so it will never be able to be sub-divided (hence mkgmap
blows up). Personally, I don't think we need to fix mkgmap to handle
this because the data
Hi Felix,
Well it does not look so bad that mkgmap should crash. There are about
40-50 nodes that have no tags attached to them at all (except if someone
cleaned up before me looking at it). In my eyes this should not lead
mkgmap to crash.
Ideally, yes, it shouldn't crash on any data
I fired up JOSM and deleted the myriad duplicate ways as no one else had
bothered to do it. With luck, the austria map will build now.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Clinton,
You know, I'm not too crazy about the croak part.
For example, yesterday I attempted to compile a map of a large portion
of Europe from Geofabrik.de, which provides daily extracts. The entire
procedure took many hours (osmosis - split - mkgmap) on my
antiquated (2 years old)
Let's see how this does - I have tried it out on 63660006.osm and the
resulting map loads into mapsource OK and is generally fine. Trying to
route through the broken region does cause mapsource to either draw a
straight line or pop up the your map's broken dialog. A real gps
would probably hang
I downloaded again, made a map and this is what it looks like in
mapsource. I can't explain why your image is broken.
Cheers,
Mark
attachment: modling-2.png___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Just discovered a weirdness in that map.
The short segment at the northern end of the bridge is actually two
ways (one on top of the other). Using the middle mouse button in josm
you can see that. Perhaps, this is the cause of your problems.
Cheers,
Mark
Hi Felix,
I have just uploaded my source data, try your calculation on it, I think
it will fail too for you as well.
http://openmtbmap.x-nation.de/maps/Debug/63660008.osm.gz
That's more like it. With that map, the little segment at the N of the
bridge weirds out. If you check the
Hi Felix,
Do you see any solution to this problem?
Sorry, I don't have a plan at this time.
I think if a way is shorter than 3.4m we get the problem. I don't think
it is because of the duplicate ways.
It's more subtle than that because I could make a small map (just a few
100ms height and
Hi,
I have created IRC channel #mkgmap-dev on irc.oftc.net for discussion
related to mkgmap development.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Marco,
I've experienced the same problem: a short arc disappered in Rome (I'm still
looking for it...). And the routing gets broken. Did you understand why those
short arcs (with no collapsing end nodes) get deleted?
Sorry, no I don't.
When you discover where it is, please let me know
Hi Marco,
41°52.367' N
12°30.477' E
I attach a small zipped osm file that compiles with that problem (it is
between two tracks at a cross in the center of the osm).
I'm looking at that but can't identify the problem - do you have the
OSM ids for nodes/ways where it is failing?
Cheers,
Hi Dermot,
If you want to have a routable map for bicycles why not just remove all
the oneway tags?
Because cyclists are required to obey oneway restrictions.
Silly me, I was forgetting that. So how about zap the oneway tags for
roads that have the opposite cycleway tags?
Cheers,
Mark
Hi Felix,
Sorry, just wanted to say that I had misinterpreted tortoiseSVN diff
files. I though those lines were deleted, but it only showed differences
to my version. I just wondered why (which was falsely assumed by me) the
lines were deleted.
OK, I was thinking that you were asking
Hi Felix,
Sorry Mark for probably bugging you again
First the probably easier question, why is it not possible to use a line
like
1.
highway=* source=plan.at [0x07 resolution 24] in my style file? The
point in plan.at throws an exception.
2.
highway:plan.at=* .
Same
v2 - split out the non-related changes (they have now been committed so
this patch is based on r1064).
--
OK Felix, here's something to play with. This patch allows you to
specify the garmin type of a road's RNP using a mkgmap:rnptype tag. You
can then set that tag in a style file
Hi Felix,
I found out the problem associated to route recalculation not working
(well working but only far too late). We currently set the TRE header at
1,3,17 IF we change this over to 1,4,23 route recalculation kicks in at
around 25-30m instead of 300-400 (as it happens with 1,3,17 we
Hi Felix,
Let's hear them. I got many many complaints that my maps don't
recalculate...
Speak up chaps, how's the recalculating working out?
How can I change 0x110301 so that it sets 1,4,23 instead of 1,3,17?
Change line 170 of src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java
to output
Hi Felix,
BTW - thanks to those who have responded re performance of the current
value.
Strange that it's working for you. I'm allways on SVN latest wit hVista
HCx, I even think that before the updates it worked better. Anyhow I now
use the different value and am happy. Could it be that
Felix,
O.k. so there must be another reason.
Maybe its as well related to road_speed or road_class?
(Garmin may think that the lower the road_speed the higher the chance
that there are buildings that obstruct GPS reception, or the lower the
accuracy of the maps, cause minor roads are
Hi Marco,
Mark, do you have some advice about OSM tagging for address search?
If a road has a name or reference it will have an entry in the address
search data structure. It needs also to have a city associated with it
which can either be the nearest city (town, village, etc.) or the
road can
Hi Thilo,
The DP code contains another distance calculation. What you must
calculate there is the distance of one point to a line. The
Coord.distance() is used in that formula, but I do not understand the
formula itself. Maybe it's some genius trick to simplify the
calculation, but
Hi Thilo,
At the distances we're (mostly) interested in, the curvature of the
earth's surface has a tiny effect (much less than the effect of
hills
valleys) so I guess (hope) that leaving out that factor is OK.
The curvature may have a tiny effect, but nonetheless you should
On Tue, 16 Jun 2009 17:19:21 +0100
Mark Burton ma...@ordern.com wrote:
In the example
above, I would argue that taking the sqrt and division outside of the
loop doesn't make the code harder to understand and may yield some
speedup.
Well, a quick test showed a barely perceptible gain so may
Hi Johann,
But you are right. If point 4 is a CoordNode then the endpoint should
not be zapped. So it is a small bug, but will probably not help at the
overview map. Well watched. Please commit that change.
OK, I will remove the --i and commit that change.
What are your thoughts on the
Hi Johann,
What are your thoughts on the patch (I think it was by Thilo) that
replaces the lost last point in each polygon? Seems like a good idea to
me.
I have looked at the patch only one minute. Seems correct.
May thoughts was that the last segment ist not needed, if it is a
A side effect of this commit is to make address search even less usable
than it was before (surely not possible, I hear you say) because it
redefines a road's name to include its reference and the highway
shield thingy (if appropriate).
So, for example, a road called Letsbe Avenue (where all the
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
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
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
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:
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
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
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
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
Hi,
I promise to never again turn assertions off.
Yes, unless you are desperate to save time, I would always keep
assertions turned on. After all, mkgmap is a work in progress and it's
bound to have issues - some of which the assertions will catch.
The real issue here is surely why aren't we
Hi Valentijn,
Did anyone else notice this problem before? Were you able to reproduce
it? If it helps, I can prepare a map that will have a routing problem
just at the edge (there's a biking tunnel that MapSource avoids, no
matter how hard I try, while letting mkgmap render the map without a
Hi Maning,
The road intersection Daang Hari is exactly at the edge of my tile
(made with splitter) routing does not work. But when I created
another mapset without the splitter, routing works.
http://www.openstreetmap.org/?lat=14.413996lon=121.01714zoom=18layers=B000FTF
Which part of
Hi,
Since you know what you're talking about: is there a discussion,
explanation or otherwise for the reason that you did not let the maps
overlap? An overlap of 300 meters sounds like a good idea for the
routing - but as said before, I'm saying this from a position of
blessful ignorance.
This issue of the area near a tile boundary not being drawn is weird
because when I was first working on the inter-tile routing, I never
noticed this occurring. So either I was lucky and just didn't come
across it or something has changed since then to introduce this issue.
So, a question to
Hi Maning,
Even better, don't partition the way as I requested but, instead,
please try this patch and see if it makes any difference.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/general/LineClipper.java b/src/uk/me/parabola/mkgmap/general/LineClipper.java
index 55aa51d..9bf224d
Hi Maning,
Here's another attempt at a fix. Please try.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java
index 54cdc5f..84df73c 100644
--- a/src/uk/me/parabola/imgfmt/app/Coord.java
+++ b/src/uk/me/parabola/imgfmt/app/Coord.java
@@
Yeah, I'm still wondering how on earth did I do that :). Can't wait
to try it tonight!
It better well work then otherwise you're going to be really
disappointed!
Well, I now understand what the problem is so even if the latest patch
isn't perfect, I'm in the right area (ho ho).
I should
This version should do the same as v3 as far as the bug fix is
concerned but I have cleaned things up a little so please test this
version if possible.
Thanks,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Area.java b/src/uk/me/parabola/imgfmt/app/Area.java
index 13b0ee4..9279b40 100644
---
Maning,
No prob. Will test again if you there is a new patch.
I need to work from the same data, what splitter params and original
data file are you using?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Maning,
I am happy to report that it is working now either in patch v4 or v5. Thanks!
Are you sure that the boundary is still in the same place?
If so, that's great.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Valentijn,
SEVERE (RoadNetwork): Road null (OSM id 34394107) contains zero length arc
Ah, that's a completely different problem. Please try attached patch.
Cheers,
Mark
mb-loop-split-fix-v1
Description: Binary data
___
mkgmap-dev mailing list
Hi Sven,
quite a lot of cycleways around here alongside major roads
(primary,secondary,trunk) are tagged as cycleway=track. In this case the
Garmin device does not use this ways if Avoid Highways is enabled in
routing option. The result is a very strange routing in these places.
Would it
As requested, here's an option (--make-cycleway-tracks) to enable the
synthesis of cycleways when a (non-cycleway) way is tagged
cycleway=track.
I have also tweaked the code for making opposite cycleways - it now
gives the synthesised way a highway=cycleway tag which it wasn't doing
before.
So
Hi,
Incidentally, that way, Road Diemerdreef (OSM id 24975519), is a really
dumb bit of OSM. It's a roundabout with about 20 points and has a
diameter of about 1m! Why do people do that?
I wouldn't know, I'm an IT person. My wife though is a psychologist. Do
you want me to file a bug?
Hi Sven,
Anyway looking at the patch this seems to be incomplete. We should
synthesise a cycleway for the following tags:
track,left,rigt,lane and yes.
Where left or right will imply oneway=yes.
I have no problem with matching more tags. However, left, right and yes
are not discussed on
On Fri, 24 Jul 2009 13:56:19 + (UTC)
Sven Geggus li...@fuchsschwanzdomain.de wrote:
Mark Burton ma...@ordern.com wrote:
I have no problem with matching more tags. However, left, right and yes
are not discussed on http://wiki.openstreetmap.org/wiki/Key:cycleway
how are they meant
v2 - Now matches extra tags (lane, left, right, both).
Commented out setting of highway=cycleway until it's agreed that it's a
good idea.
-
As requested, here's an option (--make-cycleway-tracks) to enable the
synthesis of cycleways when a (non-cycleway) way is tagged
Hi Sven,
Mark Burton ma...@ordern.com wrote:
Here's a question: when you have a cycleway lane/track, are bicycles
prohibited from using the road or can they use the road if they wish to?
I suppose that this is different in different countries. In Germany
there is a term called
v3
renamed option for enabling this to --make-cycleways
added --make-all-cycleways option to turn on all cycleway synthesising
options
Now removes bicycle access from the original way (unless that way has a
bicycle tag) to force the routing to use the cycleway.
BTW - this may be a complete
This works for me:
I have a directory called mkgmap-burto-style. In it are:
info lines options points polygons relations version
I use the following option:
--style-file=mkgmap-burto-style
That assumes that mkgmap-burto-style is in the current directory.
Obviously, you need to put in a
Hi Rudi,
Yes, I have a custom style file and I want to see the platform as a footway
(routing enabled):
railway=platform {set ...} [0x0d road_class=0 road_speed=0 level 0]
OK - I have just processed that map using a similar rule and I don't get
the short arc message. Sorry, I don't know
This patch should cure the problem where something that isn't a highway
or a ferry route is mutated into a routable way by the style file and,
subsequently, due to its shape/size/topology/etc introduces a short
arc.
I would be grateful if as many people as possible test this and
report any
Hi Rudi,
Your patch works very well, thanks a lot! I also created a map for germany
with your patch, it was generated without errors and the map seems to be ok.
In my opinion you can commit the changes.
Thanks for the report, I shall commit that change if no one reports any
breakage (which I
Hi Mark,
Sorry forgot to add that bit. I'm using splitter on the UK extracts from
geofabrik.
OK.
The most recent trials have used r1099, but before that I was using
r1067 and r1072 all with the same results.
OK.
As I say going from one tile to an adjacent one works; but anything
Hi Valentijn,
What's really fascinating about your example is that mapsource will
happily route from A to a point within the tile containing B passing
right past point C. For example, route from A to the end of Plutoniumweg
(damn it, why can't we have funky road names like that instead of
the
Hi,
For me, routing to the Plutoniumweg doesn't work at all - but my
Mapsource is older than yours, I could not read your Plutoniumweg.gdb
(MapSource complains about the file being newer).
I am using the latest version (as downloaded by the check for
software updates option on the help
Hi Garvan,
I just deleted this folder
C:\Documents and Settings\markb\Application Data\GARMIN\MapSource\TileCache
and I think it did the trick (obviously, change the user name to your
own)
Cheers,
Mark
___
mkgmap-dev mailing list
Hi Valentijn,
A bit of a strange thing: my Garmin mkgmap maps ask the provincie
(Province? State? County? Whatever you guys call it over there ;) when I
want to route to an address.
I normally build my map with country=Netherlands and country-abbr=NL,
I also tried no country and abbrev,
Hi,
Actually, on my GPSMap 76Cxs the address search kind-of-works even
without using the --road-name-pois option*. I have to enter a house
number of some kind for it to work though (even if the destination
doesn't actually have a number) and it only works for some addresses,
but I
Hi Garvan,
Should now be fixed.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Should now be fixed.
Err, that's only for OSM input.
For Polish input it's not fixed - you have to fix your data instead.
Just make sure that no road is longer than 25Km between nodes. If
necessary, add extra nodes.
I don't know what the distance constraint is here but with your sample
data,
Hi Felix,
This is not a comment on your proposed scheme but I do believe that the
current handling of name and ref (and the highway shields, etc.) is
completely fucked up. IMHO, munging the element name and its refs
together in the style file is completely bogus.
Cheers,
Mark
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended
types that are used on marine maps.
Extended types are specified as a 6 digit hex number. The first two
digits are always 01. An example type is 0x010200 (point type Buoy).
Points, lines and polygons
+--enable-assertions
+ Turn on assertions in the code. This will make the program
+ more likely to abort and less likely to do the wrong thing.
+ Use of this option is recommended.
+
Surely this is either -ea or -enableassertions and the option goes to
the java runtime and
Are you a heavy duty styler? If so, read on:
I notice that quite a lot of postings on the list are from people who
are having problems with complex style files. This little patch won't
(directly) solve those problems but it does provide a useful capability
that could be part of a solution for
v2
now supports ~[0x??] syntax within name to specify highway shields
to reduce the number of tags required, you can now specify all the
values in the mkgmap:gtype tag like this example:
mkgmap:gtype=0x20,19,,1,2
type = 0x20
minres = 19
maxres not specified
roadclass = 1
roadspeed = 2
The
v3
Now only has 1 tag (mkgmap:gtype) to specify everything.
tag has the format 'kind,code,minres,maxres,roadclass,roadspeed'
Where kind is 1 for node, 2 for polyline and 3 for polygon.
kind, code and minres are all required to be present, the other values
can be ommitted.
Note, this format
Hi Garvan,
Thanks for the feedback.
I tested this patch today, and it worked as advertised. Thanks for your
work.
Good.
I have a suggestion.
Would it be better to use
tag k=mkgmap:gtype v=0x06,21,,1,2/
instead of
tag k=mkgmap:gtype=0x06,21,,1,2/
I know nothing about osm format,
v2
Space optimisation - no longer outputs per-subdivision 13-byte record if
the map contains no elements that have an extended type.
---
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended
types that are used on marine maps.
Extended
Hello Nop,
I am just having my first look at creating a routable map. It appears
that the default style completely disregards the access tags access=no,
vehicle=no, motorvehicle=no and motorcar=no. Naturally I'd like to
exclude these from routing, but there seem to be no rules evaluating
Hi Steve,
Is there any problem with this option, such that you might not want
to use it?
I am not aware of any problem.
As I understand it, if you do not give it then routing will not work,
as we know (or believe) that all routing arcs have to be more than 5.4m.
I believe that the
Hi Felix,
Mark Burton wrote:
Hi Steve,
Is there any problem with this option, such that you might not want
to use it?
I am not aware of any problem.
As I understand it, if you do not give it then routing will not work,
as we know (or believe) that all
Hi Felix,
Until we have those patches, I am a bit sceptical about dropping the
support to specify the arc length.
I am not suggesting that we drop the ability to specify the min arc
length but I do think it's reasonable for it to default to zero rather
than some length like 3 or 5 (at least
Hi Steve,
On 12/08/09 11:23, Mark Burton wrote:
I believe that the mimimum distance will depend on lat/lon because the
real constraint is that the source and target nodes must not have the
same coordinates (resolution being 360 deg / 2^24)
Are you sure that is the real constraint
What we want is that the result of RouteArc.convertMeters() is
not less than 1. So with the values it has at the moment that requires
a min arc length of 4.878 metres. If we set the default to 5m, we
should be chuckling.
It could look like the attached patch.
diff --git
Hi Steve,
OK and how about we take the opportunity to check out convertToMeters()
The numbers it uses at the moment suggest that the Garmin wants
the arc length in unit of 16 feet.
Could anyone that has a route that they know or can measure the exact
length of and compare to the length
v2 of this patch not only enables remove-short-arcs by default when
routing is in use (as previously discussed on ML) but it also fixes some
problems in the way splitting code.
I would be grateful if people could test this patch because it could
possibly cure some routing failures.
Cheers,
Hi Valentijn,
Thanks for the feedback.
I can see where the problem is occuring. Wherever you have a node that
is within the minimum arc length from a tile boundary you will get an
error message. The question is: Is the routing actually broken at those
locations?
Cheers,
Mark
At Wed, Aug 12, 2009 at 10:37:14PM +0200, Valentijn Sessink wrote:
The question is: Is the routing actually broken at those locations?
Will check. Tomorrow.
Actually, while thinking about it: I'm not sure what to test. Should I check
one of the sites that has a SEVERE message? Does your
v3
This patch is getting serious!
To reduce the number of short arcs that are being generated at tile
boundaries, this now clips the ways before the short arc removal is
done. However, it isn't a perfect solution because some map data is
very hard to deal with:
a - If a way crosses a tile
Hi Valentijn,
Thanks for the feedback.
I have now posted a new patch that should fix the majority of the short
arcs introduced by the clipping. It's not perfect but (I hope) a step
in the right direction.
My own testing shows that the presence of a short arc does not
guarantee that the routing
1 - 100 of 644 matches
Mail list logo
