I'd also like to thank everyone involved in implementing this feature.
I have not yet tried the new overview map on a device, but I can confirm that
map display is considerably faster in Basecamp on Mac OS X. In addition, the
overview map makes the selection of map tiles in MapInstall far far
On May 17, 2012, at 21:27, WanMil wrote:
I have added the index like Gerd proposed. The number of files is now reduced
by 90%.
I have uploaded new precompiled files to
http://www.navmaps.eu/wanmil/sea_20120331.zip
Hi WanMil,
I tried patch v4 and the new precompiled sea files on the
On May 18, 2012, at 12:38, WanMil wrote:
sorry, my fault. I made some changes to the loader and didn't test it again
with pbf. One required method was missing for PBF...
Attached patch should fix that.
Thanks a lot WanMil! This works much better. I'm getting good results with the
Europe
On May 3, 2012, at 23:55, WanMil wrote:
I have already found a few tiles with flooding (e.g. NE of Russia). I
have to investigate that. But I will be happy if you find some other
things :-)
I've also been testing a little bit. So far the results have been pretty good.
One point I'm not
On Apr 29, 2012, at 22:07, WanMil wrote:
attached patch uses precompiled sea files to generate the sea areas.
Hi WanMil,
Thanks for doing this. This seems like a quite promising approach. I'll try to
test it in the next few days.
Coincidentally, I noticed a blog entry from Joachim Topf,
On Oct 22, 2011, at 17:24, Marko Mäkelä wrote:
I have seen it when the way closest to the destination point in the
mkgmap-generated map is part of a routing island. I guess that we
should consider translating highway=pedestrian as ways (not areas) in
the default style, to fix this problem.
On Oct 1, 2011, at 10:39, Bartosz Fabianowski wrote:
No problem. I have a batch job running that uploads fresh coastlines to
[1] every day. I will move this to our company webspace somewhere
underneath [2] eventually.
- Bartosz
[1] http://fabianowski.eu/osm/coastlines/
By the way, I
On Sep 5, 2011, at 0:43, Francisco Moraes wrote:
Does mkgmap support all possible highway shields that Garmin supports?
Is there any documentation on how to use them to achieve the US highway
symbols and some of the state symbols as well?
This is what I have from a previous response. It
On Jul 2, 2011, at 9:54, Peter Hendricks wrote:
This discussion has nothing to do with polygons. I don't know what any
of these codes are used for, nor do the users of the maps care.
You know, if you are unsatisfied with the default POI mapping, you are free to
define your own.
This is what
On Jun 14, 2011, at 13:26, maning sambale wrote:
I installed the map to mac RoadTrip. I can search
for streets using roadtrip. But when I send the maps to my nuvi 1310
using Garmin's MapInstall, I can't search for streets anymore. In
nuvi, Where to Address then a message will appear No
Hi maning,
The following should be the correct command line:
On Jun 3, 2011, at 7:34, maning sambale wrote:
python gmapi-builder.py -v -t for_mapsource/4001.tdb -b
for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i
for_mapsource/4001.mdx -m for_mapsource/4001_mdr.img
On Jun 2, 2011, at 15:49, Martin wrote:
I've made a map on a Windows-Machine, using the same files I used on my
Macbook and the nsis-compiler... And now it works...
Damn... So the problem comes from the gmapi-builder.
Anyone here who understand python to fix this problem?!
And sorry for
On Jun 2, 2011, at 16:12, Martin wrote:
I couldn't find any version in the file, so I attached the file.
Thanks, I'll take a look and see if I can find anything. Right now I'm
comparing the output produced by Garmin's MapConvert with that of gmapi-builder.
Cheers.
Hi maning,
I'm pretty sure that there is an error in your command line. I was able to
compile the map properly with the following:
python gmapi-builder.py -v -t for_mapsource/4001.tdb -b
for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i
for_mapsource/4001.mdx -m
On Jun 2, 2011, at 16:12, Martin wrote:
I use the following commands:
python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s ./master/basemap.TYP
-i osmmap.mdx -m osmmap_mdr.img osmmap.img 63240*.img osmmap_mdr.img
I compared the output from gmapi-builder with that produced by Garmin's
On May 30, 2011, at 23:23, Steve Ratcliffe wrote:
The attached patch seems to work better.
..Steve
city_region2.patch
This patch appears to be identical to the first one, with the exception of an
empty src/uk/me/parabola/imgfmt/app/mdr/Mdr20.java patch.
Did something happen to the patch
Processing for_mapsource/4001_mdr.img
MDR file
Processing for_mapsource/63240001.img
Missing part: 0 of
S?.ϻ in IMG-file.
On Thu, May 19, 2011 at 3:21 AM, Clinton Gladstone
clinton.gladst...@googlemail.com wrote:
OK, That Wiki version is missing some things, such as index file
On May 17, 2011, at 14:34, maning sambale wrote:
I downloaded the latest gmapi-builder and tried the following:
Where did you download this? I made some corrections, but I'm not sure if they
are in the version you downloaded.
Cheers.
___
mkgmap-dev
On May 2, 2011, at 21:46, WanMil wrote:
So r1935 has fixed the bug. The compiled boundaries need not be
downloaded again. Additionally I committed the changes in the trunk up
to r1932.
So far my tests with r1935 have been quite good.
I do have one issue though: when I send the maps to a
On May 1, 2011, at 21:50, WanMil wrote:
I have also errors in a boundary file. Something seem to be wrong with
the write or the reader. I am checking that...
I just updated to SVN revision 1935: the malformed input error has not yet
reappeared.
You may have caught the error here.
Cheers.
On May 1, 2011, at 19:54, WanMil wrote:
The European boundaries now compiled with the correct osmosis settings
are available for download:
With the new set of boundaries, I now get the following error in the log:
2011/05/01 21:37:31 SEVERE (BoundaryUtil): 9403.osm.gz: Cannot load
On Apr 30, 2011, at 8:51, navmaps wrote:
The European boundaries compiled by WanMil are available for download:
http://www.navmaps.eu/wanmil/europe_bounds_20110429.zip
Thanks for uploading the file.
Regarding the boundary function, when I compile, I notice a few errors in the
log file for
On Apr 30, 2011, at 13:43, WanMil wrote:
1. Maybe the boundary utils are not thread safe. Do you use more than
one thread?
Yes, I do. I'll try it in single threaded mode.
Cheers
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On Apr 30, 2011, at 13:43, WanMil wrote:
1. Maybe the boundary utils are not thread safe. Do you use more than
one thread?
I still get the error with only one thread.
By the way, I'm on Mac OS with Java version 1.6.0_24 (64 bit), if that's any
help.
Cheers.
On Apr 30, 2011, at 15:13, WanMil wrote:
Could you please try to run the BoundaryFile2Gpx converter for this
boundary file?
Does it throw the same error? I am not sure if I there is a problem with
the big- and little-endian order on Mac versus PC?
The converter does not produce an error.
On Apr 25, 2011, at 19:21, WanMil wrote:
I have committed changes to the locator branch which implements the
usage of separate precompiled splitted boundary files.
This seems like a quite plausible approach. I'll try it out.
By the way, for others who attempt this, there were a few typos in
On Apr 3, 2011, at 21:20, WanMil wrote:
Please test it soon. I plan to commit that within the next 2 days if noone
complains about it.
I've also done some initial testing and have not found any issues so far.
Cheers.
___
mkgmap-dev mailing list
On Feb 16, 2011, at 14:20, Henning Scholland wrote:
I think it would be better, if this file would be external, so every
user could edit this file.
If you place LocatorConfig.xml in a sub-directory called resources in the
same directory where you process the osm files (i.e., the directory
wrote:
El 12/02/11 23:54, Clinton Gladstone escribió:
On Feb 12, 2011, at 17:52, Carlos Dávila wrote:
Conversion to gmap format in both cases:
python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-14.TYP
5514*.img osmmap.img
Try the attached file. I quickly hacked it up
On Feb 13, 2011, at 16:14, Carlos Dávila wrote:
Thank you also for the tips about index. I had not seen any comment
about -i and -m parameters on the wiki [1] neither on
gmapi--builder_README.txt. According to [1] the version from [2] is
supposed to be newer than the one from [3], but the
On Feb 13, 2011, at 23:52, Steve Ratcliffe wrote:
So to make address search really useful the country names have to be cleaned
up, (other countries may be in a better state).
Does anyone have any good ideas about this?
I don't have any good ideas yet, but I can report that Germany is in a
On Feb 12, 2011, at 16:59, Carlos Dávila wrote:
I use gmapi-builder.py to transform my maps into BaseCamp format, but it
fails with those containing an Ñ (from España) in --country-name
--area-name --family-name or series-name. Do you know a way to get it
compiling? (other than changing
On Feb 11, 2011, at 20:11, Steve Ratcliffe wrote:
Some progress on the index branch.
This is the best thing I've heard all day. :-)
Thanks, I'll try this out.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On Feb 11, 2011, at 22:31, fla...@googlemail.com wrote:
Compiled germany with it. Compiling works.
Copy gmap.img to 60CSX. Map works. Search same as in older days.
Do i need Mapsource ? use OS X 10.6 ;-(
On OS X, you should be able to use Garmin Basecamp and Mapinstall to install
the maps.
It looks like the author has only published two parts of cgpsmapper so far:
cpreview - tool for index generation and preview files generation
mapRead - sub part of cpreview - allowing fast access to IMG file
That's interesting enough in itself though. The author indicates that the rest
of
On Sep 28, 2010, at 14:09, Hendrik Oesterlin wrote:
I was not able to handle mkgmap-crated gmapsupp.img with Mapsource...
I'm certain that it is simple as all the rest, but I can't see the
evidence...
MapSource will not read gmapsupp.img files. Instead you have to install a
mapset with
On Sep 22, 2010, at 20:33, Johann Gail wrote:
As far as I understand, the mkgmap --index option produces half-cooked
files that must be transferred by MapSource to the device. Once that is
done, the search should work. Others can hopefully chime in; I have
never used MapSource.
Same
On Sep 9, 2010, at 19:55, Scott Crosby wrote:
The format is stable, but I want to release one more RC, with a full
validation before I declare it stable. I expect no incompatible
changes.
Is this the binary format in discussion:
http://wiki.openstreetmap.org/wiki/OSMbin(file_format)
I had
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
release. I'm of course using Java 1.6:
$ java -version
Java version
On Aug 10, 2010, at 6:21, maning sambale wrote:
Any suggested hex others recylce for place_of_worship polygons?
I have this at the beginning of my polygons file:
amenity=place_of_worship (building!=*) {add building=yes}
Which ensures that a place of worship polygon will be treated as a
On Jul 19, 2010, at 20:02, Daniela Duerbeck wrote:
Hi Clinton!
Hm... with my Geofabrik extract and Mkgmap 1652 I get the following:
Rablstrasse 45
81669, München, DE, DE
Which, aside from the DE, DE part, seems to be correct. I'll try updating
mkgmap and recompiling to see if that
On Jul 16, 2010, at 14:48, Daniela Duerbeck wrote:
Today, with mkgmap 1655 and current Oberbayern from Geofabrik
http://download.geofabrik.de/osm/europe/germany/bayern/oberbayern.osm.bz2
I get:
Mitani
Rablstrasse 45
81669 Anzinger Siedlung 19
85560 Ebersberg
Hm... with my Geofabrik
Sorry for not replying earlier: I started to answer but then got distracted.
What I wanted to write, is exactly what you mentioned in your
self-comment: You have to use a POI type which support address data
Regarding naming, I will have to check again. I seem to recall that
the calculated name
On May 22, 2010, at 17:08, frmas wrote:
Do I have the right to write in my style points file something like that :
seamark:buoy_lateral:colour=green [0x1604 resolution 20]
seamark:buoy_lateral:colour=red [0x1605 resolution 20]
That looks about right. I have
On Fri, May 7, 2010 at 11:55 AM, Minko ligfiet...@online.nl wrote:
For instance, I would like to add a statement in the points style file like
addr:city which looksup the correct city name from the polygons style file,
if a poi that lies within a polygon with the tags place=city/town/village
On Fri, May 7, 2010 at 7:13 PM, Marko Mäkelä marko.mak...@iki.fi wrote:
I believe that these layer style files would have to include a TYP file.
I don't have a clear idea how to package the TYP files. Can mkgmap look
for TYP files inside a style directory? Should it?
The problem with the TYP
On Thu, Apr 29, 2010 at 6:34 PM, Daniela Duerbeck
daniela.duerb...@gmx.de wrote:
When a house number is mapped in osm as a POI, I can see the house
number in my device but when it is mapped in a polygon (e.g.with
building=yes) the POI is rendered but I can see just the word Punkt as
On Apr 18, 2010, at 9:37, maning sambale wrote:
2. I activated the transparent switch in order to integrate the map
into the regular maps. However, in etrex is see the keepright POIs
underneath the roads.
I think you might want to use the draw-priority option to ensure that your
FIXME map
On Apr 18, 2010, at 21:12, Valentijn Sessink wrote:
Mkgmap seems to crash on my brand new Ubuntu 10.04 installation with
OpenJDK and I can't make anything of it (not being a Java wizard, that is).
What does the attachment say? (I just hope it doesn't say Switch to Oracle
Java for
On Thu, Apr 8, 2010 at 10:00 AM, Minko ligfiet...@online.nl wrote:
Well, I compiled the map with version 1620,
and on my map the outlines of those pedestrian areas are rendered as footway,
and are routable (dotted lines). The polygon is rendered grey.
I'll check this out. It could be that the
On Thu, Apr 8, 2010 at 10:07 AM, Felix Hartmann
extremecar...@googlemail.com wrote:
Well I think routing over areas sucks, and I would not support it. There
should be clear distinction between ares and highways as lines for
routing.
This is true in general, but only an exception for
The attached patch is an updated version of an earlier patch which I submitted.
It adds a cheap but sub-optimal pedestrian routing option:
--route-pedestrian-areas
When this option is set, mkgmap will add a pedestrian way around the perimeter
of pedestrian areas (Squares and Plazas). This
On Apr 6, 2010, at 20:51, Lambertus wrote:
Someone on the forum seems to have found the solution:
Quote by Vclaw:
I noticed this same thing on some Garmin maps I was making. I think
its caused by the highway shields, as the Garmin can't display those
as well as the name at the same time.
On Mar 21, 2010, at 23:36, Mark Burton wrote:
So, those people who are tracking this patch series, please test and if
it doesn't bite your arse, I will commit it soonish
I tested v5 today. It seems to be OK. I'll try again with v6 tomorrow.
Cheers
On Mar 21, 2010, at 11:12, Felix Hartmann wrote:
On 21.03.2010 10:57, Mark Burton wrote:
BTW - do you think this v4 patch is working well enough to commit now?
yes
Me too! :-)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On Mar 21, 2010, at 14:21, Felix Hartmann wrote:
It seems that dipslay_name internally in mkgmap is not allowed to be set
to name. If identical it will not be set at all. Or is this really a
Garmin limitation?
To me it seems to be rather an mkgmap bug.
As far as I can tell, this behaviour
On Mar 21, 2010, at 14:21, Felix Hartmann wrote:
It seems that dipslay_name internally in mkgmap is not allowed to be set
to name. If identical it will not be set at all. Or is this really a
Garmin limitation?
To me it seems to be rather an mkgmap bug.
I haven't had time to properly think
On Mar 21, 2010, at 22:08, Mark Burton wrote:
Sure, what's the point in having multiple labels the same (apart from
the shield code)?
I suppose because Felix said so isn't a good argument is it? ;-)
___
mkgmap-dev mailing list
On Mar 18, 2010, at 20:51, Felix Hartmann wrote:
Hi, I just got this comment yesterday via my homepage. Seemingly mkgmap in
some circumstances puts ENQ - functional characters into the name of streets
(when adding the name from a route relation).
ENQ is ASCII 0x05, which is one of the codes
On Mar 18, 2010, at 22:49, Mark Burton wrote:
v3 - now works harder to clean up road names for use in MDR file
Er... this patch needs to be applied on top of the v2 patch does it not?
It just patches the MDR file, but does not contain the patches to all the other
files from the v2 patch.
Did
On Mar 14, 2010, at 1:09, Apollinaris Schoell wrote:
I have tried the patch and it's the first time generate-sea=multipolygon is
working for all my tiles.:)
highly recommended and should be commited
Although I see that the patch has already been committed, I can also confirm
that it appears
On Mar 13, 2010, at 20:26, Tony Groves wrote:
java.lang.OutOfMemoryError: Java heap space
This generally means that you need to allocate more memory to Java. Try
something like the following:
java -Xmx2048M -jar ...
Cheers.
___
mkgmap-dev mailing
On Wed, Mar 10, 2010 at 8:09 AM, Marko Mäkelä marko.mak...@iki.fi wrote:
If I include the Swedish, Russian and Estonian coastlines to reach the
tile borders, then mkgmap will take forever to generate the sea. Maybe
I should try with a grossly simplified coastline (just straight lines
to the
On Mar 9, 2010, at 20:20, Marko Mäkelä wrote:
I regularly take the entire Geofabrik extract of Europe and extract a
bounding-box containing all of Germany.
Have you been able to make it utilize all cores? I have a dual-core computer,
and java is eating only one CPU. Apparently, the bzip2
On Feb 28, 2010, at 21:24, Carlos Dávila wrote:
Yes, I also think some improvement is better than nothing. I wonder if
nobody else have seen these kind of anomalous turn instructions. More
cases could help guessing what is happening.
I also have been seeing such turn instructions. Patch v2
On Feb 21, 2010, at 1:38, Daniela Duerbeck wrote:
I know that generate-sea is still buggy but I cannot achieve any blue
sea. I try to generate a routable map of the Canary Islands.
With the mkgmap version 1580 I do not even get the coast lines.
With 1484 I got blue islands on yellow sea.
On Feb 12, 2010, at 12:46, Mark Burton wrote:
Is through route documented in the OSM Wiki? I was unable to find
any information on this.
Not yet, but it should be. I was rather hoping that some kind person
would add a page to the Wiki describing it.
So about adding this to the Wiki: is
On Feb 14, 2010, at 11:32, Minko wrote:
set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' | '${name}';
Just out of interest, should the parentheses surrounding mkgmap:boundary2_name
not be curly brackets ('{', '}')? I noticed this in the default style as well.
Or is this a syntax
On Feb 10, 2010, at 23:25, Lambertus wrote:
As a sidenote, I got a mail today about Gmapibuilder results claiming
that the MapInstaller gives an error with my latest map release. Since I
haven't changed gmapibuilder it might be something in Mkgmap (r1557)
that triggers this. Is someone
Hi All,
I, and others, have noticed that the original hosting server for Gmapibuilder
appears to be no longer available. Attempts to contact the original author have
also failed.
Fortunately the source is BSD licensed. I still have the source (which I
patched to convert .mdr and .mdx files as
On Feb 10, 2010, at 23:25, Lambertus wrote:
As a sidenote, I got a mail today about Gmapibuilder results claiming
that the MapInstaller gives an error with my latest map release. Since I
haven't changed gmapibuilder it might be something in Mkgmap (r1557)
that triggers this. Is someone
On Tue, Jan 19, 2010 at 3:26 PM, and...@inveneo.org
abjorn...@inveneo.org wrote:
However, when I turn off the unit, I
get I constant low alarm tone. The only way to make it stop is to remove
batteries.
This symptom is similar to that caused in certain units (eTrex) when a
SD card was used
On Jan 17, 2010, at 11:40, Marko Mäkelä wrote:
Have you tried using the source code?
I did take a look at this some time ago. I noted that there were a lot of
dependencies (such as imagemagick) which could cause troubles. Instead I used
the source code to help me understand the TYP file
I noticed that JOSM now has amenity=bar in the presets list. Also OSMdoc
indicates that there are 2096 nodes with this tag.
Would it make sense to add the following to the points style file:
amenity=bar [0x2d02 resolution 21]
(This is the same POI used by Pub and Nightclub.)
Party on dudes!
On Jan 9, 2010, at 12:41, WanMil wrote:
Is there any mkgmap tag yet to avoid this? (like mkgmap:noaddpoitoarea=yes)
POI generation from areas is disabled by default. Command line option
--add-pois-to-areas enables this.
Further, POIs will only be generated from areas if there is a
On Jan 1, 2010, at 22:34, Marko Mäkelä wrote:
Could someone give me a hand with map layers (families in Garmin speak,
if I understand correctly)? Would I have to invoke mkgmap multiple times,
once for each map layer (family) and finally to combine the families to
a single gmapsupp.img? Or
On Dec 28, 2009, at 19:54, Mark Burton wrote:
I have agreed to help produce a marine map of the Baltic so
it would be really nice if the sea was filled in without any really
major problems (flooded land, etc.)
I, unfortunately, can't help you specifically with the generate sea stuff. I
can
On Dec 23, 2009, at 0:55, Steve Ratcliffe wrote:
I don't think it would cause any problems with memory or cpu, but if
an extra argument is added to filter() then I would add the same one
to doFilter() since they are the really the same routine just split so
that the common code can be in the
On Dec 22, 2009, at 12:41, Charlie Ferrero wrote:
So I've solved the problem of getting the familysets properly visible in
the secondary map menu, but now individual tiles all share the same
family name, no matter which family they were originally in.
I'm pretty sure that to get correct
On Dec 22, 2009, at 10:29, Marko Mäkelä wrote:
OK, this is very useful. I would propose two things:
1. commit the not-equal filter to mkgmap
2. implement include files, possibly also a mkgmap --include option
so that you could include the Chinese sub-style from the command line
when
On Dec 22, 2009, at 18:13, Carlos Dávila wrote:
AFAIK you can put all this settings in the same args, in the section of
each layer. This is what I have in an args file I'm testing:
...
family-id=30
product-id=314
family-name=OSM España
series-name=OSM-Iberia-n
...
draw-priority=25
...
On Dec 22, 2009, at 21:06, Ben Konrath wrote:
What happens when you load an mkgmap
generated map for an area in Europe that overlaps the included Garmin
city maps for Europe? Does this work for you?
This also works flawlessly. I'm not sure what you can do differently:
- What happens if you
On Dec 22, 2009, at 20:27, Carlos Dávila wrote:
Maybe you remember a discussion on this issue back in October [1]. Then I
tried transparent/draw-priority as you suggest and the land layer covered the
sea, but I'll try again and report back.
Sorry, I had forgotten about this. From your
On Dec 21, 2009, at 9:52, Marko Mäkelä wrote:
In the next few days, I plan to implement special syntax for
variable substitution, because it will allow shorter style rules to be
written. See an example of the syntax at the bottom of my original message
below.
Thanks. I have not had time to
On Dec 21, 2009, at 20:20, Marko Mäkelä wrote:
I believe that the special name:* handling would be best implemented in
a special mkgmap option. I would try to avoid writing language suffixes
in style files.
The question of the logical comparisons is to avoid redundancies, some of which
On Dec 20, 2009, at 9:08, Marko Mäkelä wrote:
I do not really know anything about this. My not-so-well-educated
guess is that the house numbers could show up if you ran mkgmap --index
and uploaded the map to the device from MapSource. I have never tried
either.
I am fairly certain that the
On Dec 19, 2009, at 12:50, Charlie Ferrero wrote:
Is the continue patch the only way to apply a set of rules to ways that
are both oneway and bridges? Or can I do something more cunning in the
style file?
If the continue patch is the only way, is there a compiled version of
it, or
On Dec 15, 2009, at 16:00, Charlie Ferrero wrote:
Perhaps the problem is that I am not uploading the maps from Mapsource
but instead just copying the gmapsupp.img file directly to the SD card
(because this is many times quicker than uploading via the USB cable).
I know this won't help you
2009/12/11 Stéphane ALLEMANDI s.allema...@soneva-sbh.com:
Hi,
I am living on a little island, and I just can't see the blue coast line
anymore !!
Is there a way to display the sea??
Which release of mkgmap are you using? Do you use a custom style file?
And which little island are you living
On Dec 11, 2009, at 21:34, Simon Eugster wrote:
Good evening again,
http://granjow.net/projects.html#garmin
Problem solved. I'm manually renaming now.
I haven't looked closely at your script, but I assume that routing does not
work across country borders, if you use separate osm extracts
On Dec 6, 2009, at 23:21, Hadmut Danisch wrote:
Now I tried to fill the device with openstreetmaps and downloaded the
daily build of the german map
Hi Hadmut,
Could you perhaps let us know which daily build of the German map you
downloaded? (From what site, etc.)
Cheers.
On Dec 7, 2009, at 0:10, Hadmut Danisch wrote:
Ah, sorry, I thought that this was commonly known. It was taken from
http://dev.openstreetmap.de/aio/germany/gmapsupp.img.bz2
OK, this is the All in one map. If I recall correctly this map uses a TYP
file to display OSM items which cannot be
On Dec 5, 2009, at 18:00, Chris-Hein Lunkhusen wrote:
highway=pedestrian [... continue]
highway=pedestrian area=yes [... continue]
THEN it will not work. Only one copy, no more.
Hi,
anyone tried this out? I can't get this to work (v1414)
I have not yet tried this out, but it is perhaps
On Dec 2, 2009, at 0:46, Adrian wrote:
I am trying to view .img files on a Mac using Garmin RoadTrip. (I
haven't tried using QLandKarte GT because I think it would be a big job
to build Qt and then QLandKarte GT.)
I have done this using Macports and the QLandKarte GT source, but it took the
On Dec 2, 2009, at 0:45, Felix Hartmann wrote:
I changed some stuff to make routing a bit better. Anyone tried it out?
I tried the original patch, but found sadly (using Roadtrip on the Mac) that
routing actually got worse. This was for a map of Germany. The directions were
particularly
On Dec 2, 2009, at 20:53, Carlos Dávila wrote:
The second one (spain.args) gives the following error: Too many blocks.
Use a larger block size with an option such as --block-size=2048 or
--block-size=4096).
I also received this error about a week ago (you should be able to find the
relevant
On Dec 2, 2009, at 11:18, Ralf Kleineisel wrote:
On Wednesday 02 December 2009 11:10:54 Marko Mäkelä wrote:
Can the gmapsupp.img contain multiple TYP files that could be selected
by the user? That would allow one to use a single map file and select
profiles based on intended use on-the-go,
2009/12/1 Felix Hartmann extremecar...@googlemail.com:
As announced yesterday - here is a patch against the default-style-file to
heavily improve Autorouting for cars/motorcycles.
So this patch, if I understand it correctly, creates duplicate ways at
a higher resolution, but with a lower speed.
On Mon, Nov 30, 2009 at 11:31 AM, Marko Mäkelä marko.mak...@iki.fi wrote:
That sounds interesting (and an incentive for me to define some bus route
relations for nearby lines). Have you documented your process? I have
yet to create or use any map overlays.
I'll try to get around to
On Nov 30, 2009, at 16:08, Nolan Clifford wrote:
Could anyone post the two calls they make to mkgmap and gmapi-builder.py and
specify what data set they were successful with from the point of view of
getting Address Search to work in Roadtrip? Preferably data from the
Geofabrik extracts
1 - 100 of 206 matches
Mail list logo
