Hi Chris,
is mkgmap able to handle inverse oneways (oneway=-1) correctly
(routing opposite to the ways direction) ?
Yes, that has been implemented.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Blast, just discovered that clipping all ways before doing short arc
removal breaks polygons that straddle tile boundaries. The problem is
that at the time the clipping is done, it is not known whether the way
is a line or a polygon. Oh well, back to square one.
v4
I have gone back to the original ordering of doing short arc removal
before clipping as the previous version of this patch badly broke
polygons
As for arcs whose length is less 5m, I am not convinced they are
actually a problem as far as routing is concerned as my tests show that
mapsource
Hi Chris,
The tags vehicle and motorvehicle are not recognised so you will
need to add style rules to convert them to one of the access tags that
are recognised which are:
access (applies to everything)
bicycle
foot
hgv
motorcar
motorcycle (same as motorcar)
psv
taxi
Hi Chris,
When I get a chance in the next couple of days, I'll have a play around with
some of the official Garmin maps and see if they can be made to exhibit the
same problem. If so then the limitation is most likely in the routing
algorithm
in MapSource and/or on the device. If that's
Using a recent GB tiled map on my eTrex, I have found that it performs
differently (better?) to mapsource with regard to the problem of not
routing across a boundary and back to the source tile.
An example route I tried used a road that snaked across a boundary.
Mapsource failed miserably in the
Hi Thilo,
The attached will merge lines that are similar* after styling. It is
activated by the switch --merge-lines.
As there are less way fragments, the Douglas-Peucker filter will work
better and the routing should improve somewhat, because the ways will
be longer and the routing
Hi Hanno,
I just noted with a garmin map from kleineisel.de that my local supermarket
is
not listed.
The reason is that it's an area, not a point. I think this is caused by not
applying --add-pois-to-areas (?)
I think it's reasonable to make this option the default and only disable
Not a basemap, but a real routable tile.
It doesn't matter what area it is for.
If so, can you please zip it up and send to me or otherwise make it
available to download.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Mario,
Shouldn't there be a subtle difference between Delivery and Truck?
As I understand it, Truck should allow routing THROUGH an area, whereas
Delivery should also allow routing INTO an area.
Each allowing or denying routing conforming to the UK motoring
restriction 'HGV - Access
Hi Chris,
Do I understand correct that the garmin maps have a flag for
motorcar=destination which is different from motorcar= no ?
Yes, motorcar=no bars car traffic from a way but motorcar=destination
only bars car traffic if the destination is not that way (or a
connected way that also has
I have 3 patches currently out for evaluation:
mb-min-arc-length-v4.patch
various tweaks related to short arcs including making
remove-short-arcs enabled by default with a min arc length of 5m -
could effect any map that has routing
mb-extended-types-v2.patch
Support the 3-byte
Hi Garvan,
Thanks for the feedback, much appreciated.
Cheers,
Mark
On Mon, 17 Aug 2009 08:58:04 +0700
garvan.m...@online.com.kh wrote:
Quoting Mark Burton ma...@ordern.com:
I have 3 patches currently out for evaluation:
mb-min-arc-length-v4.patch
various tweaks related
Hi Chris,
Does the error messages mean that the tile is simply too big and
I have to split into smaller tiles ?
Yes, I think that is the case.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
I discovered that the latitude value in the boundary nodes (NOD3) table
should have 180 degrees added to it (aka 0x80) to make it
consistent with Garmin maps.
The fact that we can route between (our) tiles without this mod shows
that it doesn't really matter but we may as well be as
Hi Felix,
I did not look into the patch, but does it mean that I could use in my
style-file the following:
[0x01234 resolution 22]?
And then off course add a definition for this type in my typfile.
Or is there more that needs to be changed?
Actually, my knowledge of extended types
That list is in my eyes just crap when it comes to extended types, as
any of those lines / points / polygons will only be shown if defined in
typfile, and many others if defined too. I only don't know whether there
are any regions that will not be shown, or only shown in Mapsource.
My
On Wed, 19 Aug 2009 23:18:02 +0200
Felix Hartmann extremecar...@googlemail.com wrote:
Could you or someone try to modify this patch so that it compiles
against mkgmap 1140.
Try attached.
Not been tested, so please verify it works as expected.
Cheers,
Mark
diff --git
Hi Felix,
Could some other people please try out whether the overlays and
relations file still work with 1140?
I have currently the problem that no more routes are visible when
compiling maps with 1140. Also overlays file seems to have stopped working.
Are you using a stock 1140 or do
Hi Felix,
Is this still a problem or did it get better?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
No I'm still unable to get routes and overlays to show up on the map.
either using 1140 with multiple elements patch (no other patches), nor with
clean svn version.
That's sad.
I don't know what you mean by routes or overlays so I can't imagine
what the problem is. If you could
Hi Felix,
Overlays. I mean the overlays file in the style-files. Before 1139 if you
had a line in your lines file saysing for example:
highway=footway highway=cycleway [0x123 resolution 20] you could now
define in the overlays file 0x123: 0x2a, 0x0c
and both 0x2a and 0x0c were
Yo Landlubbers,
Here's the first cut at encoding support for extended type attributes.
This is mostly concerned with marine entities like (wreck depths, buoy
types, light types, colours, etc.) As there is quite a lot of it and I
haven't sussed it all out yet, I thought it would make sense to
v2 - moving swiftly on.
Added support for lights and reworked a few things.
mkgmap:xt-foundation-colour is now just mkgmap:xt-colour
mkgmap:xt-light-colour has been replaced with mkgmap:xt-light (more on
this below)
mkgmap:xt-light-type is now just mkgmap:xt-type
Light colour, range (in nm)
Hi Torsten,
I am trying to attend the mkgmap devellopment, but I have still some
trouble with the build process, partly because I am also not familiar
with the Linux environment.
You don't have to use Linux. I do but other people use Windows or
Macs.
As a start I installed Suse Linux and
v4 - no functional change, just reworked slightly to improve efficiency.
I've tested this stuff with noddy examples but as I don't expect anyone
is in a great rush to use it big time, we will have to wait to see what
issues emerge (from the deep?)
Anyway, as all of this code should have no
Hi David,
It may be a surprise but colored lighthouses and morse code worked on
Etrex Vista HCx before you added extended types. I used only style rules
to obtain this map (see the capture).
Yes, there's already some marine widgets in the non-extended types.
But if you want the really
As per OSM Wiki, it expects vehicle classes to be separated with ';'
Works in mapsource, not tried on a real GPS.
Doesn't appear to work for either pedestrians or emergency vehicles.
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteRestriction.java
Hi Felix,
Using the same style-file as before but changing many streets from 0x??
into 0xe10?? I needed to reduce by 70-75% the maxnodes settings of the
map so that it compiles without error.
What error do you get? Please post the message.
Is there possibly a bug or is it normal that
Looks like the extended type stuff has triggered an ancient bug.
Please try attached patch and see if you can process bigger maps again.
diff --git a/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java b/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java
index 37d5509..b1d6fb2 100644
I notice that isClosed() uses equals() (the points have the
same coords) but I think it should use == (the points are the same
object).
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mark,
Thanks for the contribution - it sounds like a good idea.
One thought, how about using words and not numbers, words are easier to
interpret when you come back to them 3 months (5 minutes?) later. So
you could have something like:
ignore-maxspeeds (same meaning as now for compatibility
Mark,
I'll change it. The original intention was to avoid creating another
option (as I'd seen some comment about yet another option). But I'm
happy to go down that route.
Personally, i'd rather see a new option added than an old option
obscured!
Also, if we introduce a new option to
v5 - added support for facility (point type 0x010903) and also now
catches and reports exceptions incurred during processing of attributes.
A facility point can have a mkgmap:xt-facilities attribute which is a
bitmask made from these values:
0x01 boat ramp
0x02 drinking water
Hi Torsten,
And please let me know, whether the attached patch is usable, since this
is my first generated patch. I simply asked svn for the differences
between my local copy and the head version.
I haven't tried the patch but a quick look shows that it attempts to
add some stuff that is
Spotted the problem, some of the patch is relative to 1143 and some of
it relative to 1148. Don't know how you managed that. Perhaps an svn
wizard can help.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Ok, I tried a different button in svn and now got a patch relative 1143
only. Is this one better usable?
Yes, it applies to 1148 OK and builds OK.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi,
If I understand you correctly, your v4 patch is in svn now, so if I run
into strange routing, I should report and/or check if v5 performs any
better?
No, only a portion of the v4 patch has been committed because it's a
useful fix to have independently of whether the rest of the patch is
Hi Valentijn,
First, a remark. Since the oneway=yes/cycleway=opposite roads have
(cycleway) attached to their names, a GPS unit will randomly show
either the regular name, or the (cycleway) name. Which isn't too bad for
testing, I'd suggest you leave it this way until we're set and done with
Hi Gert,
Hi, guys
first time with a prebuild version r1152 i tried to use this extended
type in an overlay.
Unfortunately i got an error message from mkgmap.( i can provide it if
needed but i guess it doesn't).
Input file was in polish-format.
Could it be that the polish format reader
Hi Gert,
I just took a quick look at the code and I can't see why extended types
are not acceptable in mp files. Please post the error message you got.
The extended type attributes are not yet supported for mp files but I
will look at implementing that.
Cheers,
Mark
Hi V,
Yes, using mapsource, if the cycleway=opposite tag is present it will
route a car into the last segment of Hembrugstraat using the cycleway
but if the destination is not the last segment of that road or the
cycleway tag is not present, it will route the car correctly.
Experimentally, I
Hi Maning,
Several problems with Search by Address in Garmin Mobile XT reported
by some of my users.
- unable to search for road names via Address Search option using
Where to? - Addresses
-Step 1 0f 5 in Address Search requires entry of State, no state is
listed and no matches found if
Hi,
While looking into the make-cycleway-code, I notice that a simple tag
with cycleway=lane (or equivalent) would be enough to make a cycleway.
However, if there's no access restriction for cyclists, there's no real
need to build an extra way here - or is there?
You have a point. Of
Valentijn,
I've tried a couple of different methods to build opposite-cycleways,
namely forbid all motoring traffic, make a real cycleway, but all of
them make the Garmin turn to the last part of the oneway Hembrugstraat.
So I conclude it's a Garmin issue. I'm sure we could come up with all
On Fri, 28 Aug 2009 14:11:41 +0100 (BST)
svn commit s...@mkgmap.org.uk wrote:
Version 1153 was commited by steve on 2009-08-28 14:11:41 +0100 (Fri, 28 Aug
2009)
Fix error reporting.
Normal errors that are detected by mkgmap should just be printed but since
multithreading was added,
Gert,
I just took a quick look at the code and I can't see why extended types
are not acceptable in mp files. Please post the error message you got.
Ok. here it is.
D:\GPS\mkgmap-r1152java -Xmx512m -jar mkgmap.jar -c wkr_options.txt *.mp
SCHWERWIEGEND (Main):
Hi Garvan,
I spent some time testing short arcs and managed to find some routing
problems where mapsource will route in one direction but not in the
reverse direction. This looks like a mapsource bug to me, so I am
curious if it is seen with all versions of mapsource, or even if others
Hi Gert,
I just run a small test.
r1155 you commited now seems to work fine with polish format datafiles and
extended Garmin types.
Good.
Upcoming commited version of extended types + attributes i will test after it
is available.
I shall commit that stuff soon as although it probably
Hi Gert,
i just build mkgmap out of svn trunk and test it with a single
marine/ext poi in an mp-file.
It works.
Good.
But i discovered that neither the flashing nor the morsing works in
Mapsource or in my 60csx . I guess these functions are only avaiable
with special marine gps of
Hi,
Just playing around with TYP files and wondered if it is possible to
change the Garmin yellow background to anything else using a TYP file?
If not, is there any other way of doing that?
Cheers,
Mark
___
mkgmap-dev mailing list
Hi Felix,
yes, simply set background polygon 0x4b to a color (if using maptk watch
out to set one pixel to something else, because usually if you go for a
single color only maptk will put second color transparent and
performance sucks, this is a bug in maptk, the online typfile editor is
Hi Felix.
Strange, try to look in gpsmapedit what polygon is used for background.
Have you patched it to 0x4a, i have seen some people doing that (though
I don't know what for)?
No, it's still 0x4b.
drawing level 0, and make sure no other is on 0 or it might be displayed
behind the
Hi Felix,
You can simply download a small country from my website, both thin??.TYP
and white??.TYP have white background set.
http:///openmtbmap.org/download
and try it out and look for differences.
Err, I can't read that archive format, please just email me a TYP file.
Cheers,
Mark
I've had zero success in setting the background colour on the etrex. I
can happily change styles of lines and polygons so the type file is
working to a degree.
Has anyone managed to change the background colour on an etrex vista
hcx?
Thanks
___
Hi Michael,
--ignore-osm-bounds
If you ignore the bounds, the ways don't end at the same coordinates.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mark,
However, I seem to recall that when I first played around with this the
background reverted to yellow quite early on as I zoomed out. In the end
this problem went away when I reduced the number of levels in my style
file - originally I was using the default style which seemed to
Hi Ralf,
My TYP works on my eTrex Legend HCx which is very similar.
Could you please email that typ file to me?
Also, what levels are you using?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
This is reporting a bug in the fixed error reporting (introduced
in rev 1153). I have committed a fixed fix but even if that does the
right thing, you will still get an exception reported because there
must be something else going wrong for there to be an exception that
needs reporting!. So
Thanks to everyone who has responded to my question - I have read all
the replies.
As I want the Nuvi primarily for navigation, I don't really mind if
logging isn't possible or, if possible, not good quality. The
fact that it works well with our maps is enough.
Cheers,
Mark
Hi Valentijn,
Just one small remark (at the moment you have probably ordered your Nuvi
already): if you're going to use it on a (motor)bike, you might want to
check the availability of a mounting kit for it.
Actually, it's for car use only because I already have an etrex vista
hcx which I
Hi,
I thought I would make myself a traffic light icon using the TYP file.
The icons appear where you expect but they are visible at higher
zoom levels than the built in icons for pois that have the same
resolution.
I tried a few different type codes without noticing any obvious
difference.
So
Hi Felix,
Just committed a bug fix that could be relevant. Please see if 1165
behaves any differently.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
3. delete 1/3 of the lines in my polygons style-file or delete this last
section:
leisure=* fixme!=yes import!=*[0x2a
resolution 24]
tourism=* fixme!=yes import!=*[0x2b
resolution 24]
sport=* fixme!=yes import!=*
Felix,
2. there is also a mapsource installation in the subfolder, just install
by doubleclicking (with admin rights) install_openmtbmap_at.bat
Or create a gmapsupp with gmaptool for your gps by doubleclicking on
create_gmapsupp.bat
I installed the AT map into mapsource and can view it OK
Felix,
If you are on medium detail between 1km and 3km (resolution 20) there is a
small area where if you pan either nothing happens (screen not refreshing),
or you can not see the roads. With 1165 routing is not broken anymore, so I
think that patch solved something. Simply set detail to
Felix,
It does look odd around:
http://www.openstreetmap.org/?lat=47.605lon=15.638zoom=11
but that's how the OSM data is.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gert,
Hi, Mark
So what's going on? Are custom pois treated differently with regard to
zoom levels?
AFIAK i would say no.
For me it seems more like that the pois in general will be treaten different,
e.g. settelements will be shown longer by zooming out than other pois though
the
Hi Felix,
Well one thing that this patch makes, is much much bigger filesize
(around 30% increase).
To be expected.
Furthermore it really crashes Mapsource. Not even possible to move out
anymore.
Hmm, not so expected.
After panning around a bit and choosing a well working zoomscale,
This v2 patch makes squarer subdivisions than v1 - otherwise works
the same.
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/RGNFile.java b/src/uk/me/parabola/imgfmt/app/trergn/RGNFile.java
index f0300e8..5c0dc77 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/RGNFile.java
+++
Hi Gert,
What I can see on my etrex is that the custom icon will disappear at
the level you expect (given the resolution value it has) but some of the
built in poi icons disappear sooner.
Which type ?
Umm, can't remember exactly what I tried but I think it was 0x1b16
(lighted navaid,
Felix,
Well, on v1 patch, the problem at this place appeared even without
having the problematic polygons in the polygons file.
That's interesting.
With v2 it's back to normal and only happens with the problematic
polygons or without deleting a fair bit of my lines in the lines
Felix,
Please enable info logging by using the attached logging.properties file
and add this to the java options (note - it's a java option not a
mkgmap option)
-Dlog.config=logging.properties
rerun with v2 of the patch and email me the mkgmap.log file(s). They
should contain some diagnostic
Felix,
Okay, here are the output files. Once including the problematic
landuse=* line, once without.
Thanks. Unfortunately, they have too much other crap in them and not
enough of what I want to see. Did you use the logging.properties file I
sent to you?
Mark
Ahh, you're adding POIs to areas, aren't you. Have you tried building
with that option turned off?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
Wild guess here: I wondered if the POI index was overflowing and
trashing some other stuff because in the bad map example you sent, it
contained just over 32K entries. So commit 1170 disables POI index
generation. It wasn't useful anyway, so that's no loss. Please see if
that makes any
Hi Maning,
Apologies if this is a stupid question. What is the benefit of
creating poi index? for search?
That's not a stupid question at all. The POI index sounds like it
should help with searching for POIs and maybe it does but, at this
time, it appears to make no difference to the search
Playing with my shiny new Nuvi 255, I notice that it can route across
an OSM map of the UK pretty well. It can find long routes
reasonably quickly. In comparison, mapsource 6.13.6 often fails to
determine a route at all and when it does it is rather slow about it.
Do other people see good
Hi Felix,
Please try the attached patch on the original tile and see if it fixes
the problem.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java b/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
index 122d811..9fb07a2 100644
---
Yeah great, Finally fixed.
I could not find any errors in the map.
That's good.
The problem was that a polygon was being generated that only
contained 2 points. The more recent mapsource versions must
ignore degenerate polygons (and lines as well, presumably) but the
older mapsource and at
Felix,
I was all the time using it without problems. I don't know whether there
have been improvements, but nothing became worse in any case. I
subjectively think map panning got a tiny bit quicker, but might be
mistaken.
Ok, good.
If the patch is working right, it should be reducing
Hi Maning,
I encountered routing across tiles again.
Using mkgmap ver 1163 and splitter r83.
This photo shows routing detours to the cemetery when I used a split file:
http://farm3.static.flickr.com/2593/3892530364_d80a7546b4_o.png
But no problems when no split file was used:
Hi Maning,
I had an inspiration!
Contrary to my last message, I think we can probably do something
about this. Please try the attached patch on the same OSM data as
before and see if the routing changes (hopefully, for the better).
Use the same options as before.
It's based upon my previous
Hi Maning,
Same routing problem. The problematic segment is approx 6 meters
That's a shame, I had great hopes for the patch.
It would be useful if I had the OSM files for the two tiles in
question. Can you please zip them up (gzip or zip) and either email
them to me or make them available on
Hi Maning,
Thanks for the files.
I have found the problem that was stopping the new code from working as
expected (it was an old bug in the line clipping code).
So, please test the new patch. I have tried it myself on your data
files and it works OK as long as you give --remove-short-arcs=5.
Maning,
wohoo! routing works. The merging of points is a good solution. Does
this affect only the nodes along the clipped line?
It affects all nodes that need merging to avoid a short arc being
created. Any connected nodes whose separation is less than the
specified distance (5m in your
Hi Chris,
does mkgmap auto-merge points which have exactly the same coords?
I though the remove-short-arcs option would do this, but last week
I found a routing problem on a netherland motorway which
was caused by such a double node and the map was created
with the remove-short-arcs
Committed a bunch of stuff that improves subdivision generation and
removal of short arcs that reach tile boundaries. I've tested it all on
GB, NL and PH? tile sets with no problems.
Apologies in advance if they break anything.
Cheers,
Mark
___
Hi Chris,m
does mkgmap auto-merge points which have exactly the same coords?
I though the remove-short-arcs option would do this, but last week
I found a routing problem on a netherland motorway which
was caused by such a double node and the map was created
with the
Hi Chris,
I was just wondering that OpenRouteService.org was able to route
over such a spot.
The fact that other routing services choose to do that does not make me
any more enthusiastic about the idea.
Cheers,
Mark
___
mkgmap-dev mailing list
Hi Maning,
One user reported that lane assist works on my mkgmap generated map.
I don't know what lane assist do and not so sure if it works with
mkgmap. Anybody here can confirm that this works for newer garmin
nuvis?
I have a brand new Nuvi 255 and it doesn't have lane assist but it
Hi Paul,
I've just updated to the latest mkgmap from trunk and am now having
problems processing tiles that I have previously successfully processed.
The error I am receiving is
java.lang.IllegalStateException: Polygon offset too large
Please try attached patch.
Cheers,
Mark
diff --git
Hi Thilo,
I will modify the code that the merging is applied even earlier.
Shouldn't be too hard to do.
Did you do that? I would be keen to try a version because I notice on
my first few trips with the Nuvi that sometimes it says keep
right/left when it should say turn right/left. I think
Hi Felix,
Some remarks about the merge lines concept, and the reasoning why it
will not help much and needs to be extended/changed.
Your remarks are most interesting. I have been considering writing some
code to tweak the arc headings to help make the routing directions more
sensible. In my
Please try attached patch.
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index c45f2d9..c5f5bde 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++
Hi Steve,
- private final void incArcCount(MapCoord, Integer map, Coord p, int
inc) {
+ private void incArcCount(MapCoord, Integer map, Coord p, int inc) {
Why zap the final? It was there for a reason.
Cheers,
Mark
___
mkgmap-dev
I seem to remember someone mentioning that Garmin supports non-rectangular
map tiles. Would that help? Or would it be too much effort with too little
gain to implement that in mkgmap (and splitter)?
I have seen a Garmin map with boundary points that do not lie on a
rectangle so, it's
Hello Nop,
mkgmap r1196 quits with an error polygon offset too large. When I use
mkgmap r1163 with exactly the same data and parameters, no error occurs.
What does this message mean?
It means that the change I made could have been better. I will
investigate.
Mark
Nop,
Please try 1197 and see if the problem is still there.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reduce number of Table A entries.
Previously, Table A entries were unique for each combination of start node,
end node and RoadDef. But no information from the start and end nodes goes
into Table A so we can ignore the start and end nodes and all roads
within a given routing
101 - 200 of 644 matches
Mail list logo
