Hi Thilo,
> Has anybody had success controlling the drawing order with the "--
> preserve-element-order" option?
>
> The drawing order is random for me, with or without this option. Would
> be nice to get it working, though, especially for overlays.
When you say random, do you mean that each
Hi Garvan,
> Hi.
>
> I have a few questions related to MKGMAP that I could not find answers
> to in the archives. My data source is mostly OpenStreetmap, but I used
> gpsmapedit for editing and adding my own traces, so I am using mp format
> files with the compiler. I am open to other suggest
OK - recently committed change(s) will now report the Way's id (OSM or
RoadID) if an arc is too long to be encoded - this should help when
trying to find the overly long roads.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
htt
Hi Garvan,
> Thank you for the update. I downloaded the latest version from svn, and
> I can now easily identify the roads with problems.
Good.
> Do you know where I would find the patch you mentioned related to label
> styles? Is there a list of all patches someplace?
The mailing list ar
Shouldn't these symbol names be the same (the other symbol names are)?
HighwaySymbolFilter:
+ symbols.put("hbox", "\u0004"); // box with horizontal bands
PrependFilter.java:
+ symbols_6bit.put("boxx", "\u002d"); // box with horizontal bands
+ symbols_8bi
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 th
On the OSM forum, we get:
http://forum.openstreetmap.org/viewtopic.php?id=3879
The report says:
> when a border overlapes a street, the street is broken. The street is not
> recognized for routing. This happens in MapSource and on the Oregon 200
> device.
This must be because in the style fil
On Sun, 5 Jul 2009 11:42:03 +
Ævar Arnfjörð Bjarmason wrote:
> I was generating a map of Potsdam with mkgmap from an .osm file which
> I had produced by making multiple API requests in JOSM as no extract
> was available (and XAPI is down).
>
> This resulted in a JOSM .osm file with multiple
Hi Thilo,
Could you please produce a concrete example of this behaviour? A small
sample OSM file or area URL would be very useful to help investigate
this.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.u
Hi Garvan,
> I found an error in my map source, so I apologize for the previous post.
> I still don't understand the straight line jumps that resulted from my
> error, but at least it was a rubbish in - rubbish out case. If I can
> understand what conditions cause it, then I will file a bug r
Further to my earlier email about the problem of ways that have both
highway and boundary tags defined, here's a patch that possibly
provides a workaround.
It lets you specify pairs of tags. If a way has both of the tags
defined, it is cloned and one of the clones has one of the tags and
the oth
Hi Thilo,
> I think it would be advantageous to generalize this kind of behaviour.
> What about a "continue" flag in the Garmin type definition in the
> style files? This continue flag would indicate that a match with that
> rule generates a copy of the way, but that the processing continue
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, ev
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:
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,
M
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 the
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
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 c
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
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 "
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: exc
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
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
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 j
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 compr
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 g
Hi WessexMario,
> 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
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
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 cas
> 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 st
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 ro
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 da
+0200
Valentijn Sessink wrote:
> Hi Mark,
>
> (Let me introduce myself: hi, I'm the original problem submitter :)
>
> Mark Burton schreef:
> > Well, that's a bit odd. If you download this area into
> > JOSM, it looks similar(ish) but by no means exactly the s
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 Thilo,
> I've not forgotten about this bug, it is still biting me. The problem
> is that it I wasn't able to reproduce it with a small map. It seems to
> be related to the size of map. My maps are very POI ladden, so that
> might trigger it. By reducing the splitter tile size the frequen
Hi Paul,
> I don't know when this happened as I haven't tried long distance routing
> for a while but I noticed today that this is vastly improved. I (amongst
> others) have commented previously about the sometimes strange routes
> chosen when trying to route long distances and Mark suggested at
Hi Paul,
> Bury to CHester however starts along the M66, goes straight through
> junction 18 to the next junction where you go all the way round the
> roundabout, come back on yourself to junction 18 and then turn left onto
> the M60 where the route is then as expected.This odd behaviour then
> c
> If Paul used XAPI to extract a part of the country in order to build his
> Garmin map then it's possible that his XAPI excerpt isn't complete. I've
> been seeing more and more of this happening in South Wales where I'm
> doing exactly that.
>
> It seems (from other comments here) that there'
Howdy folks,
Shall I commit this stuff or does it need more work?
To recap, it stops routing across a bollard (or other POI that has
access restrictions). It works OK except in the case where the start and
end positions are close to the bollard. As previously discussed, that
is probably not fixa
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
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.413996&lon=121.01714&zoom=18&layers=B000FTF
>
Wh
> Yes, I noticed that - but could not reproduce it yesterday. Please
> notice however, that the route you found has both starting points at the
> lower map. That may or may not have anything to do with it. Your picture
> also shows that the upper map vanishes (which you confirmed already).
Well,
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 ignoranc
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 ever
Hi Maning,
I have a theory about why this is failing. To test my theory, please
partition way 5046155 at node 33780792 so that the small segment that
connects the two one-way streets together is a separate way (but still
connected at the same end points. Having done that, please rebuild your
map
I forgot to say, make sure you don't change the position of any of the
nodes. I just want the way split - nothing else changed.
Thanks,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 100644
Hi Valentijn,
> Mark Burton schreef:
> > Even better, don't partition the way as I requested but, instead,
> > please try this patch and see if it makes any difference.
>
> Yes it does:
> SEVERE (RoadNetwork): Road Provincialeweg (OSM id 35165518) contains
> zer
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
@@ -
OK, so it's proving to be a little harder to fix than I thought but I
have high hopes for this version.
BTW - Valentijn, this version could help routing through "the tunnel".
Please see if it changes anything.
diff --git a/src/uk/me/parabola/imgfmt/app/Area.java b/src/uk/me/parabola/imgfmt/app/Ar
Hi Valentijn,
> > BTW - Valentijn, this version could help routing through "the tunnel".
>
> Yes! Yes!
>
> Also, V1 and V2 had a couple of these "... contains 0 arc", and this
> version does not show any of these (checking patch if the code is still
> there... it is).
>
> Thanks! And thanks to
> 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 ha
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
--- a/
Hi Clinton,
> I have not yet had time to test this, but would it be an idea to
> optionally enable or disable this behaviour? I know that mkgmap is
> slowly growing an unmanageable number of command line options, but
> this still might help if we discover unwanted side effects.
I can do that. My
Hi Maning,
> The img file was definitely changed because the file size increased.
> BUT, routing problem persist :(
That's a shame.
I can't look at it right now, too busy with real work!
I think I need to get the same data and work on it here to solve this
now - I shall do that this evening.
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
http://www.mkgmap.
Hi Maning,
I got the data, split it, etc. but, no surprise, the tile boundaries
had changed so the problem has disappeared. I shall continue to ponder
the code with that particular location in mind.
In the meantime, I shall commit that fix anyway because it has to be
better than what we have cur
Hi Felix,
> Well but one allways has to remap these values to motorcar=yes for special
> purpose maps, as only car/motorcycle provides proper routing.
Never understood that need to route as a car, but I am happy to cater
for such a foible.
> I have not
> really read through the patch as it does
Hi Maning,
> The img file was definitely changed because the file size increased.
> BUT, routing problem persist :(
Can you route at all through that node? i.e. is the problem only for
routing in one direction or both?
Cheers,
Mark
___
mkgmap-dev mai
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
http:
> Yes I used the same split files from the previous compile.
Excellent, I shall commit that patch today.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Sven,
> Will this allow for Generation of fake cycleways for one-way streets
> which are tagged cycleway=opposite_lane?
We can already do that with this option:
--make-opposite-cycleways
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.m
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
Valentijn,
> No errors. Have not checked the routing. Should I?
I am not expecting the fix to introduce any routing issues and I did
look at the output using mapedit and it looked OK so I think it's safe
to commit this fix.
Cheers,
Mark
___
mkgmap-de
FYI, the bug that led to the error message being output is
reasonably subtle and to trigger it you needed to have a roundabout (or
some other looped way) that contained a node that was 2 points from
the end of the looped way and the node had to be close enough to the
penultimate point in the way t
Hi Valentijn,
> I just ran mkgmap without --route:
Thanks, that's another buglet squished. I've committed a fix.
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?
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.
>
> Wo
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 a
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
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 Fri, 24 Jul 2009 13:56:19 + (UTC)
Sven Geggus wrote:
> Mark Burton 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 mea
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
cyclew
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 wonder if when we generate a cycleway, we should be adding a
bicycle=no to the original way?
Cheers,
Mark
_
Hi Sven,
> Mark Burton 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 Ger
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 r
Hi Sven,
> > so that if the original way doesn't already have the bicycle routing
> > defined, it will be disallowed.
>
> Ah, nice!
I have put out a new patch that does that.
> There is another thing I found looking at the code.
>
> As far as left and right tags are concerned one should creat
Hi Johann,
> I get a lot of the same errors with the latest r1102:
> For example:
>
> 2009/07/25 09:07:47 SCHWERWIEGEND (RoadNetwork): Road Willishausener
> Straße (OSM id 24346402) contains zero length arc
> 2009/07/25 09:07:47 SCHWERWIEGEND (RoadNetwork): Road null (OSM id
> 32230489) contai
Hi Greg,
> As you can see I do have remove-short-arcs. I think I am r1048 but will
> update and try again.
That version is ancient! please try again with the latest version as I
have made some improvements in this area.
> So two thoughts:
>
> if ways are still messed up, maybe they should j
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,
> I have a problem with a zero length arc (mkgmap 1107):
>
> SCHWERWIEGEND (RoadNetwork): Road null (OSM id 34881225) contains zero
> length arc
> SCHWERWIEGEND (RoadNetwork):
> http://www.openstreetmap.org/?lat=47.83413&lon=11.70958&zoom=17
>
> This is a strange railway=platform. It i
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 breaka
Hi Rudi,
I have just posted a patch that should solve this problem.
Please test and report back.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Marco,
> What are the implications of having short arcs? Routing unable to
> follow the way across the short arc? What if there is an improvised
> short wooden bridge on a forest path that crosses a very narrow waterway?
You get a short arc wherever two (directly connected) nodes are so clo
Hi Clinton,
> I did a quick test of this patch: I could not observe any breakage. In
> addition, a number of short arc errors (in ways I didn't care about),
> which had cropped up in recent builds, disappeared.
>
> So this looks good.
OK - thanks for the report - sounds good.
As for the short
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
Hi Mark,
> I'm trying out maps with routing turned on. The routing seems to work
> fine within a single map tile, it also works fine when I route to a
> neighbouring tile.
>
> However, if I route across multiple tiles then it always fails.
> Mapsource just spends ages and then draws a straigh
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 can
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 tried the latest mapsource update, and I liked the rendering of the
> maps, but it was caching my maps so when I made updates, they were not
> immediately reflected in mapsource. It would still display the old map
> until I changed map to something else and back again a few time
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
mkgmap-dev@lists.mk
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
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,
> bu
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 Clinton,
> > I searched for a complete list of all mkgmap command-line options and
> > what they should do, but I couldn't find a good and up-to-date
> > list. The list in the wiki is much too old.
What I believe we need is some fascist check in the options processing
code that prints a me
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 c
Here's a list of Garmin types.
Don't know how recent it is.
;GPSmapper element types list
;
;RGN10 & RGN20 types-all types are two bytes, first byte is a major type byte,
second byte is a subtype.
;
;WARNING-RGN10 can use both bytes, RGN20 can use only the first byte, so if we
want-create a Din
1 - 100 of 986 matches
Mail list logo
