the attached java classes together with the patch enables mkgmap to
create contour lines directly from digital elevation model (DEM)
data. This may be useful for those who don't want to ceate contour
lines with other tools and store them in huge(!) files.
That seems very cool, and I look
Christian Gawron writes:
>> output osm format data from the DEM (for other use, or later use, or
>> for intermediate reprocessing)
>>
> Actually this was the way my code worked before, but I don't like the
> size of the created osm files.
I realize the file size is problematic. I meant
I am trying to make an img/tdb/overview from massachusetts.osm
(downloaded from cloudmade). My computer is a mac with 2G of ram. The
.osm file is 2.4G. While running with 1024m heap size java ran out of
heap. With 2048, it is moving along, but paging a lot wiht a RSIZE of
1750M and getting onl
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.
[splitter not working with java 1.5]
I found a 1.6 update from apple and now the splitter seems to be running
ok. So it really does seem to need 1.6
pgpwnya2O9b6J.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgma
I took the Cloudmade massachusetts.osm.bz2 from July 1st, and because I
wanted a routable map tried to make my own. I ran the splitter just
fine (mac, with java 1.6), and then ran mkgmap like this:
java -enableassertions \
-Xmx2048m \
-jar mkgmap.jar \
--tdbfile \
--gmapsupp \
--family
> - write a little utility to paste GeoTIFF files together
>
> gdal tools should be able to do this.
Yes, the GDAL tools are able to do this, I have to do it this way for
elevation lines for mapnik rendering.
I wrote code to do this to render USGS DRGs, and while the code is not
p
Marko Mäkelä writes:
>> About the TYP file, are there any plans to have one included for use
>> with the default style? I don't actually know much about these files
>> yet so my question might be a bit naive.
>
> Same here. Maybe in the dark and rainy winter months when the
> conditions are wor
I've been trying to use mkgmap and having a bit of a hard time. I'm a
little compulsive about having all the lore be in the source tree, and
it seems the README is a bit behind the code. I have a bit of time here
and there but not enough to really dig into the code. So I'll be trying
to send pa
I've done some more README work. I am finding a lot of information on
wikis, including talk pages, and have tried to link to it rather than
duplicating it, at least for now.
This patch creates all the files, even if some of them have little
content. I did include an example of making gmapi-form
I am trying to build a routable map for all of Massachusetts as a first
step towards hopefully improving the style rules slightly (some ramps on
Rt. 2 are missing from the cloudmade img and I think it's because
trunk_link is missing in the style file, but I haven't figured that out
yet).
My comma
Ondrej Novy writes:
> this patch fix showing building too early on Garmin device. building=*
> should have same resolution as highway=residential.
No objections to that as an incremental improvement, but I am tempted to
say that building=yes without name= should not show up. In Mass we have
Ma
Ondrej Novy writes:
> i find building REALLY usefull when navigation. When you are not in car,
> but going by foot it's really usefull information.
>
> Or perhaps unnamed buildings should be shown only when POIs are shown.
Here's an example of what I'm talking about:
http://www.openstreetmap.
Ondrej Novy writes:
> hi,
>
> 2009/7/29 Greg Troxel
>
>> Here's an example of what I'm talking about:
>>
>>
>> http://www.openstreetmap.org/?lat=42.3921&lon=-71.15861&zoom=16&layers=B000FTF
>
> yes, exactly this is what i want
I have been trying for a while to build my own maps with mkgmap, and was
getting bad maps into RoadTrip. I figured out what I was doing wrong
and thought I'd share it. I had run the splitter and then mkgmap,
creating a gmapsupp.img overall map file in addition to all the tiles.
I ran gmapibuilde
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.
I would wish to have a Wiki page with all mkgmap options, their
functionality, their usage and their status (s
Here's a patch that:
adds some options to the help file
improves wording in the help file
adds TODO items in the help file when I think something should be
there but don't know the answer
a bit of general cleanup in the help file
removes option description from README, pointing pe
Use this patch instead - minor typo/whitespace fixups.
Index: README
===
--- README (revision 1118)
+++ README (working copy)
@@ -32,69 +32,43 @@
there. Another way would be to use a USB memory card writer.
Another convenient way
(This is also splitter-dev I think.)
I am trying to build the splitter on a mac (10.5.7 with java 1.6.0_13,
64-bit server VM), and failing. I have successfully built mkgmap and
run it, so my java setup is mostly ok.
Buildfile: build.xml
prepare:
compile:
[javac] Compiling 17 source fi
Steve Ratcliffe writes:
> On 05/08/09 10:48, Mark Burton wrote:
>>
>> +--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
While driving a while ago, I noticed highway ramps missing from my Vista
HCx. Now, they are present but dashed lines. The problem is a
combination of two things: a road that should be a motorway tagged as
secondary (state highway), and mkgmap's default style not having rules
for secondary_link a
Johann Gail writes:
> Just an thought from reading the thread:
> Multiple parsing runs with an bz2 zipped file could do worse to the
> performance. It would mean multiple decompressing of the input files.
> And in my experience decompressing bz2 costs a lot of resources.
>
> (In my case I'm di
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 soluti
I am trying to make a testmap and look at it in RoadTrip. The creation
process goes smoothly, and the gmapibuilder output looks reasonable. I
can use MapManager to add the map, but then RoadTrip crashes when I try
to select it. A similar process to build real maps (from cloudmade
extracts, with
Clinton Gladstone writes:
>> I am trying to build the splitter on a mac (10.5.7 with java 1.6.0_13,
>> 64-bit server VM), and failing. I have successfully built mkgmap and
>> run it, so my java setup is mostly ok.
>
> I regularly build splitter in a similar environment to yours. I have
> to be
Marko Mäkelä writes:
> When the resolution of highway=residential was reduced, highway=service
> should have been reduced as well. It looks odd to see highway=service
> but not the highway=residential that they are connected to.
>
> highway=residential | highway=living_street [0x06 road_class=
Charlie Ferrero writes:
> 1. Currently, if you invoke mkgmap with the --style-file= tag and point
> to a non-existent style file (or incorrect path), mkgmap continues
> regardless (and applies the inbuilt default style, afaict). Can I
> suggest a patch to mkgmap that at least makes it clear
Chris Miller writes:
>> For really old devices that have limited memory you may only be able
>> to load a few tiles at a time and then it would be more flexible to
>> have smaller tiles. But this is really from before OSM was started,
>> I've never had anyone complain that tiles were too big, i
Dermot McNally writes:
> 2009/8/10 Greg Troxel :
>
>> For receivers with a 2GB uSD, I think one wants tiles pretty big. I
>> have 2009 vintage Garmin proprietary maps, and all of New England is in
>> 2 tiles, and the .img I think are about 25 MB each. I also have a
Elrond writes:
> I don't know, if we really want to go ahead and create more
> styles directly shipped with mkgmap.
> Just some random thoughts:
A few more:
Maps for rural and urban areas should probably have different
resolutions. Eventually this should be dynamic.
I basically agree with yo
Clinton Gladstone writes:
> On Tue, Aug 4, 2009 at 10:40 PM, Mark Burton wrote:
>>
>> This patch is a first stab at providing support for the 3-byte extended
>> types that are used on marine maps.
>
> I tested this, and found that it works fine, both on my eTrex and in
> Roadtrip for Mac OS X.
>
Mark Burton writes:
> 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 until we really understand
> what's going on).
>
> I propose:
>
> If --route is specified bu
Felix Hartmann writes:
> D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar
> -Xmx1200M splitter.jar --mapid=6320 --maxnodes=100
> --resoultion=15 switzerland.osm
>
> /D:\Garmin\mkgmap>start /low /b /wait java -enableassertions -jar
> -Xmx1200M splitter.jar --mapid=6320
It would be good if people who have been obliged to use a minimum arc
length of > 0 would provide examples of where the routing is broken.
i.e. without using this patch, find an example which doesn't route when
--remove-short-arcs is specified but will route when
--remove-short-arcs=5 is
Clinton Gladstone writes:
> On Thu, Aug 13, 2009 at 8:52 PM, Greg Troxel wrote:
>
>> I am finding routing totally broken in Massachusetts; routes (etrex
>> vista hcx) are computed apparently using the basemap. I have not tested
>> enough to figure out why.
>
&g
Perhaps, the mappers should put some effort into cleaning up/validating
the data?
Absolutely we should. I had thought things were better than they seem
to be. But computing routes on a dataset with problems should still
'work', where work means you get a route that's obviously nonoptimal.
Clinton Gladstone writes:
> On Fri, Aug 14, 2009 at 2:44 PM, Greg Troxel wrote:
>
>> I most recently built with all 6 NE states (conn, ri, mass, vermont, new
>> hampshire, maine) all together, invoking the script 'do-mkgmap' which
>> follows as something like
frmas writes:
> Now according to the latest firmware, we no longer have to create a
> gmapsupp.img file to get multiple maps.
I tried this on an Etrex Vista HCx and it seems that it does not read
multiple map files.
> Maybe this has something to do with the way I use the mapname,
> description
frmas writes:
> So I suppose that once the mapname in the template.args file is given, I
> can't change it with a parameter on the mkgmap command line, as long as
> I use the "-c template.args" parameter ??
the mapname in the -c takes precedence if it is given later than
--mapname.
Why don't y
frmas writes:
> Greg Troxel a écrit :
>>> So I suppose that once the mapname in the template.args file is given, I
>>> can't change it with a parameter on the mkgmap command line, as long as
>>> I use the "-c template.args" parameter ??
>>
Felix Hartmann writes:
> I think we should open a wiki page where we should add what
> line/poi/polygon types are possible.
There is already resources/garmin_feature_list.csv. It would be nice to
add to that, so it's in the sources, rather than having a duplicate list
that has to stay in sync.
Mark Burton writes:
> I slurped most of I95 into josm and it's a bit of a mess. For example,
> The Northbound carriageway is disconnected at node 73082202
Perhaps a town boundary - see below.
> and just
> below that is a section of link road that's pointing in the wrong
> direction.
MassGIS d
Morten Kjeldgaard writes:
> The default version of mkgmap distributed with Ubuntu 9.04 (jaunty) is
> svn630. I tried upgrading to version svn1067 which has recently
> appeared in Debian unstable, but now I get a Java heap space
> exception on the _same_ .osm file that worked before.
>
> The map
Morten Kjeldgaard writes:
> On 21/08/2009, at 23.26, Steve Ratcliffe wrote:
>
>> When support for relations was added the memory required increased. I
>> think that was added along with routing, I believe, which was in
>> version
>> 684 or thereabouts, so that will explain what you see.
>>
>>
Morten Kjeldgaard writes:
> On 22/08/2009, at 01.53, Greg Troxel wrote:
>
>> With splitter/mkgmap, the general strategy I use is:
>>
>> set heap size to a bit less than RAM, to avoid paging
>>
>> use --max-nodes to splitter to make small enough areas.
>&
The reason for the high memory usage is that most nodes in the Danish
extract look like this:
This gets very messy, but I suppose tags could be trimmed on reading if
there is some way to know/declare that they won't be used. The problem
is then the relation matching
I have a newish macbook pro, bought around January of 2008. It had
10.5, and java 1.5. I was able to download java 1.6 from apple, but
apparently that only works for intel 64-bit macs (which means "amd64",
think). But, setting the preference only changes the JRE, and
apparently our ant build lo
Greg Troxel writes:
> While driving a while ago, I noticed highway ramps missing from my Vista
> HCx. Now, they are present but dashed lines. The problem is a
> combination of two things: a road that should be a motorway tagged as
> secondary (state highway), and mkgmap's
Morten Kjeldgaard writes:
> Success! I had to set maxnodes to 500K in the splitter and use 4G ram
> in the VM to make it work.
>
> However the resulting gmapsupp.img makes my Legend Cx crash when
> it's turned off: it continously beeps and the only way to stop it is
> to remove the batteries
Mark Burton writes:
> Hi,
>
>> GRAVE (RoadNetwork): Road null (OSM id 36913306) contains zero length arc
>> GRAVE (RoadNetwork):
>> http://www.openstreetmap.org/?lat=44.33355&lon=9.34585&zoom=17
>
> ...
>
>> Is it just a message to tell me that mkgmap has removed the zero length
>> arc or a prob
cool, but it would be good to fix up garmin_types.csv to explain this -
I was not able to figure it out.
When should we use 0x09 then?
pgpvENgMvAE3O.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://w
Clifford Nolan writes:
> I can't seem to find the right options so that I can output more than
> one map within a gmapsupp.img file and have those individual maps be
> selectable with the ticks on the gps itself.
>
> For example, if I have file_A.osm and file_B.osm how can make these two
> s
MarkS writes:
> This adds a new option "maxspeed". This can be set to:
>
> "ignore" - The maxspeed tag is ignored and road class from the style
> file is used.
> "heed" - The maxspeed tag is used. If it doesn't exist then road class
> from the style file is used
> "lower" - The lower of the maxs
Dermot McNally writes:
> 2009/8/30 svn commit :
>
>> I can't see a difference in mapsource, so 0x02 and 0x03
>> seem to be quite close.
>
> Ah, but you can see the difference with a suitable .typ file :)
As much as I hate checking in binary files, I wonder if it would be
useful for there to be
Ondrej Novy writes:
> Hi,
>
> 2009/8/30 Greg Troxel
>
>> the sources along with a description of what it is. When there's
>> adequate free software for .typ files in the glorious future, this could
>> be swapped out for the source description. I have bee
I've got a case locally where a tertiary road meets a primary road at a
shallow approach-angle of about 30 degrees. The Garmin does not announce
the junction, not warn of its approach when you're on the tertiary.
Coming from the other direction on the primary though, you get an "in
50
I have fairly recently used OSM maps I made with mkgmap in California
and Arizona. The good news is that they basically work, including
routing. This is in theory not news, but things seems tricky enough
that I thought I'd mention it.
In Grand Canyon Village (south rim), I found that at 20m-300
I updated mkgmap to r1337, and found that my overview img/tdb changed
names. I adjusted gmapibuilder invocation to reference those, and that
succeeded. But on loading into roadtrip I get a "The map you selected
contains some errors and cannot be displayed. The default map is being
shown instead.
massgis import has polygons with leisure=recreation_ground, and this is
logically like landuse=recreation_ground. Apparently mapnik already has
support for this, and the following makes such parks show up nicely:
Index: resources/styles/default/polygons
==
These aren't wicked important, but I found them in my tree and I think
they're more helpful than not:
Index: doc/README.invoking
===
--- doc/README.invoking (revision 1366)
+++ doc/README.invoking (working copy)
@@ -1,7 +1,35 @@
$I
Marko Mäkelä writes:
> I think that the default style should still be maintained. There is some
> value in having sensible defaults. I do see value in other styles and
> hacks, such as distinguishing different types of paths by drawing multiple
> lines per way or repurposing taxi/delivery/emer
Mark Burton writes:
> The attached patch allows you to add either unpaved=yes/true/1 or
> paved=no/false/0 to a way and then it will be ignored for routing
> purposes when the GPS has been told to avoid unpaved roads.
>
> Not sure if those are the best tags to use - any thoughts?
In the massgis
Version 1429 was commited by marko on 2009-12-09 22:11:45 + (Wed, 09 Dec
2009)
Cosmetic changes to the default style: Add comments and do not sort
the highway=* alphabetically but by descending order of class,
i.e., motorway, trunk, primary, secondary, tertiary, etc.
I'm glad to se
I updated this morning and ran the splitter with mass/conn/ri extracts
(3 files). I got a map that had only connecticut. SO I wonder if the
bounds code in r102 is using the last bound, rather than unioning them.
here's my log. search down for connecticut bounds, and the bounds
chosen for write
Greg Troxel writes:
> I updated this morning and ran the splitter with mass/conn/ri extracts
> (3 files). I got a map that had only connecticut. SO I wonder if the
> bounds code in r102 is using the last bound, rather than unioning them.
I updated to -r101, and that produced a m
We could do that, but I just got another idea: I will create a simple
TYP file with http://ati.land.cz/gps/typdecomp/ and try to decompile
it by hand into source file(s) that would be compiled with GNU Assembler
to the TYP file. That should be enough for my immediate needs, to define
so
That compiler is now under a BSD license, so I wonder about just making
it into a regular program instead of a cgi.
pgp5fbvfygeI2.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman
Have you tried using the source code? I tried, but failed. It does not
even claim to be the entire program. The web interface is deliberately
No, I have not tried. That doesn't sound encouraging.
pgp0tnJPvGn0a.pgp
Description: PGP signature
__
Does anyone have any objections to this? If not I'll take a look sometime
in the next few days. I'll also look at fixing the lack of support in the
splitter for relations containing other relations.
In all my struggles to deal with osm and mapmaking, disk space has been
the least of my tr
[need new home for gmapibuilder]
what about on mkgmap.org? While gmapibuilder is useful without mkgmap,
it would seem that it's basically used by the Free software garmin
community. It's not mine to offer of course
Assuming the owners of mkgmap.org are amenable, the only downside is the
Steve Ratcliffe writes:
> I'm not sure what what Greg's 'political point' is but I don't see how
> it would affect my thinking without further explanation.
Sorry, I meant:
gmapibuilder doesn't really have any particular affinity for mkgmap as
the one true map creator. It should be usable
I have a shapefile of property boundaries in my town (from MassGIS). It
has a bunch of polygons, with metadata about size and lot number (from
zoning maps, like R27-7).
Eventually I might import this, but I'm going very slow on that and
right now I'm trying to work out sensible conversions and g
I've written a small app in c that will generate an arbitrarily large
grid of POIs or polygons, each with a unique tag=key combination, and
the associated mkgmap style file to go with it. This lets you see how
garmin type codes associate to icons and categories on any given GPS unit.
Lambertus writes:
> There's a question on the OSM forum about the naming of highways in the
> default stylesheet which comes down to this: if a ref is available then
> that seems always used even if a name is also available, can this be
> changed to show the name as well?
>
> http://forum.ope
Measuring the avg. speed for sections of 10-20km on primarys is
something low like 35km/h on some parts and something like 55km/h on
fast parts. The max speed on these sections is mostly 80km/h but in
the end nobody gets that fast.
In Mass the speed limits are on most ways from the MassGI
For most people understanding which mkgmap options they should choose,
is not easy - as one first needs to have quite thorough
understanding. I think in general useful options should be the default
- and not stick for ages to old behavior. I'm afraid I make to many
mistakes if I change i
Felix Hartmann writes:
> On 30.04.2010 14:16, Greg Troxel wrote:
>>
>>--ignore-maxspeeds (the current handling sucks, If we would change
>>
>> I don't understand this; it seems simple to map maxspeed on ways to
>> garmin road speed but obviously I don
so we really need a tag for typical_speed, because you're saying that
speed limits and typical speeds are not all that well correlated. This
is not really about mkgmap.
pgpSW889d55F7.pgp
Description: PGP signature
___
mkgmap-dev mailing list
mkgmap-de
Felix Hartmann writes:
> On 30.04.2010 15:22, Greg Troxel wrote:
>> so we really need a tag for typical_speed, because you're saying that
>> speed limits and typical speeds are not all that well correlated. This
>> is not really about mkgmap.
>>
> Well
I am using an Etrex Vista HCx with mkgmap with good results. A friend
has an oregon 450 which seems ok in terms of maps/routing (waas issues,
apparently no way to display seconds for camera sync, awkward tracklog
saving).
I am unclear on how the nuvi line works for OSM, but it's a good question.
Chris Miller writes:
>> I in fact called it --output-dir initially. However when I first typed
>> it at the commandline, I caught myself writing --destdir. I realized
>> that --destdir is just the name of the option for a lot of tools when
>> specifying a target directory I'm used to.
>
I just got a garmin oregon 450 (for hacking OSM/mkgmap). It attaches as
two disks (internal flash and uSD slot):
umass0 at uhub4 port 2 configuration 1 interface 0
umass0: vendor 0x091e product 0x2380, rev 2.00/5.09, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 2 luns
trying to build a map with the latest svn and the cloudmade extract for
massachusettts fails with an exception. I'll try to send details
tomorrow, but I'm wondering if anyone else is having trouble.
pgpsfusIMSWy4.pgp
Description: PGP signature
___
mk
"Jeroen Muris" writes:
> My Oregon 550T shows two FAT32 formatted disks in Windows 7 and XP, and
> from memory (lost the Mac and the Slackware laptop) I could read/write
> these in both OS X and linux.
thanks.
> Maybe your OS lacks a driver for FAT32?
I can read a 16G CF from a dslr just fine,
Jeffrey Ollie writes:
> On Mon, Aug 30, 2010 at 8:19 PM, Greg Troxel wrote:
>>
>> trying to build a map with the latest svn and the cloudmade extract for
>> massachusettts fails with an exception. I'll try to send details
>> tomorrow, but I'm wondering if a
Clinton Gladstone writes:
> On Aug 31, 2010, at 20:37, Greg Troxel wrote:
>
>> no, sun java on intel mac.
>> I have tried openjdk but had trouble; it would be nice if i works someday
>
> I'm also on an Intel mac, and have not had troubles with the latest SVN
> r
I'm seeing comits to what I think is the same mkgmap svn with different
version numbers. So am I just missing something obvious, or is there
something unusual going on, or ??
Version 1707 was commited by steve on 2010-09-26 21:23:54 +0100 (Sun, 26 Sep
2010)
Version 230 was commited by stev
Steve Ratcliffe writes:
> If you are subscribed to the mkgmap-svn list (which you are :) you see
> the commits from the both the splitter and the display repositories.
> As you point out it is not obvious where the commit is happening. I'll
> see if I can include something in the message.
>
> T
Marko Mäkelä writes:
> On Sun, Oct 17, 2010 at 02:15:55PM +0100, char...@cferrero.net wrote:
>>Are you sure that the GPS won't try to route even when there is no
>>routing info in the map? I've got a vague memory (back when I didn't
>>know how to create a routable map) that my GPS still offer
I'm glad to see pbf support in mkgmap, but doing an svn checkout and
'ant dist' fails, or at least prints an error. The README does not
explain where to find the apparently missing jar files, or how to check
them out and build them.
Ideally, it would look in the system standard paths, so that on
Marko Mäkelä writes:
> On Tue, Nov 02, 2010 at 10:22:33AM +0100, Lambertus wrote:
>>Would it be possible that Mkgmap supports reading the OSM data from
>>stdin? Splitter is capable of doing so and it would eliminate the need
>>for a temporary file if Mkgmap could do so too.
>
> If you are usin
maning sambale writes:
> This way is tagged as a amenity=townhall and a multipolygon relation:
> http://www.openstreetmap.org/browse/way/24159829
> http://www.openstreetmap.org/browse/relation/452620
>
> In my style:
> polygons:
> building=* | man_made=* | amenity=* | tourism=* [0x13 resolution
Marko Mäkelä writes:
> On Wed, Nov 17, 2010 at 09:37:17PM +0800, maning sambale wrote:
>>Can anyone confirm this? (I don't read code sorry)
>
> If moving all tags from the role=outer way to the multipolygon relation
> fixes the problem, then Greg Troxel is right. If not,
I observed that a lot of admin_level boundaries (2,3,4,5 and sometimes
6,7,8,9,10,11) are not useable because they are not completely
contained in the tile data. The polygons are closed automatically but
this is only a good guess in which direction they have to be
closed. The probabilit
Marko Mäkelä writes:
> Actually, we do have a mean: if there are multiple parallel tracks (each
> drawn as a separate way with railway=*), it is a major railway. It
> should be doable to merge adjacent ways at lower resolutions and sum the
> "weights" of the ways, to decide what to draw. A st
Marko Mäkelä writes:
> A fellow mapper complained that some highways carry a 5-digit ref on the
> mkgmap-produced map, even though the ref is nowhere to be seen on street
> signs. OK, mkgmap cannot possibly know that, but I was wondering if we
> could split this rule in the default style:
>
>
Marko Mäkelä writes:
> It may be useful for road nerds to have the official 5-digit or
> 6-digit refs for ramps or cycleways in the database, but I do not
> think that they can be useful for a Garmin map user. A road nerd user
> can always tweak the mkgmap style. :-)
I agree that's true when th
Roger Calvert writes:
> I have mapped 'barrier=gate' to an unused Garmin code using the instruction
>
> barrier=gate {add name = 'gate'} [0x1600 level 2]
>
> in the 'points' style file, with a corresponding entry defining a
> graphic in the TYP file.
Two separate points to understand:
1) The
Lambertus writes:
> Hello list, Marko,
>
> Would it be possible that the default stylesheet does not show:
>
> - Admin levels 8, 9, 10 (admin_level=)
In my area, cities/towns are admin_level=8, and these should definitely
show up. I'm not sure what 9 and 10 are; in my state we have wards and
available under an OSM compatible license (the terms resemble CC-BY-SA),
but I guess I could convert it to .img tiles and let the end users
download and combine the topo tiles with the OSM .img tiles to a
gmapsupp.img.
Indeed - I have topo data in the US that I use in a separate .img
(
1 - 100 of 231 matches
Mail list logo
