Hi
> I didnt noticed it because I use my own style. So far so good, apart from the
> virtual tile issue.
I don't know what causes that and I expect it to be tedious to track
down!
> Maybe because the (osm)protobuf.jar is not included in the
> mkgmap-gmap-mdr-r2135? I run the jar file in a mkg
Well done Steve, another mystery solved :-)
I didnt noticed it because I use my own style. So far so good, apart from the
virtual tile issue.
Maybe because the (osm)protobuf.jar is not included in the
mkgmap-gmap-mdr-r2135? I run the jar file in a mkgmap-r2131 folder.
Another issue: when I try
On 27/11/11 22:31, Minko wrote:
> Thanks Steve, I tested mkgmap-gmap-mdr-r2125.jar:
>
> - Transparency in Basecamp: solved!
I guessed that this would probably fix the blurred map problem when
zooming in MapSource, and indeed it does appear to fix that problem as well.
The only question is now -
Thanks Steve, that does the trick.
Steve wrote:
It looks like this file wasn't created with --latin1. It is
important that the index is created with the same code page as the
tiles were.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://
On 03/12/11 11:36, Minko wrote:
> gmapsupp(2135-2).img (created in a second run)
>
> Map length s-f
> MAKEGMAP IDX668576 1 address search not working
It looks like this file wasn't created with --latin1. It is
important that the index is created with the same code page as the
Looks like it is working, but with one issue:
If I first run mkgmap to make a Mapsource version with working index,
and then a second run with --gmapsupp and --index on the already created img
tiles, I get no working address index in the gmapsupp. If I add the gmapsupp
line in the first run, it
Hi
I've now fixed the problems with mdr29 which might have
affected city and street search in maps with more than one
country.
One of the problems was long standing and affects the MapSource style
index. Its possible that it didn't matter for MapSource though.
..Steve
_
Hi
> Ok, that makes sense. I have uploaded a new test map version for
> Mapsource, generated without --gmapsupp and now the search index
> works as expected in Mapsource. I also added the gmapsupp(MS).img
> (image generated by Mapsource) to the test folder in case you need
> it, see http://mijnde
Ok, that makes sense. I have uploaded a new test map version for Mapsource,
generated without --gmapsupp and now the search index works as expected in
Mapsource. I also added the gmapsupp(MS).img (image generated by Mapsource) to
the test folder in case you need it, see
http://mijndev.openstree
On 29/11/11 10:14, Minko wrote:
> A few more observations:
> -The test map (mkgmap-gmap-mdr-r2130.jar) cannot use the address search in
> Mapsource, it crashes: TDB_regiondir.cpp-165-6.16.3.0 error
> -When sending the map with Mapsource or Mapinstaller to the GPS there is no
> search index create
A few more observations:
-The test map (mkgmap-gmap-mdr-r2130.jar) cannot use the address search in
Mapsource, it crashes: TDB_regiondir.cpp-165-6.16.3.0 error
-When sending the map with Mapsource or Mapinstaller to the GPS there is no
search index created, so address search fails
-Address search
> - Adress search
>
> Works in Nuvi and Dakota. Can't locate any Dutch cities though, only
> streetnames. It can locate addresses in Belgium and German cities.
I've noticed that finding cities was less reliable, but then it was
before when downloaded via mapsource.
As your map spans more than
Thanks Steve, I tested mkgmap-gmap-mdr-r2125.jar:
- Transparency in Basecamp: solved!
See http://img821.imageshack.us/img821/3453/gmap.jpg The map is bordered by a
thin blue line, which is normal. Underlying basemap is not visible anymore.
One issue: there is a small thin blue line within the ma
On 27/11/11 21:08, Minko wrote:
> Thanks Steve,
> Unfortunately I dont know how to compile a patched mkgmap so I can't test it,
> but this patch and a search index in gmapsupp is very good news!
OK I committed it to the branch, so you can get it from the download
page along with the address inde
Thanks Steve,
Unfortunately I dont know how to compile a patched mkgmap so I can't test it,
but this patch and a search index in gmapsupp is very good news!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listi
Hi
The uderlying basemap is still visible through the osm map,
and the line style of this basemap is defined by the osm typ file.
We have noticed it does not occur with generated maps by cgpsmapper.
The attached patch fixes this.
..Steve
Index: src/uk/me/parabola/mkgmap/general/MapDetails.j
Hi
> I meant indeed gmapsupps created by Mapsource (because I need a working
> address index).
Perhaps this is a good time to mention the gmap-mdr
branch which is about making a working address index!
It is now in a working state, at least for single countries.
..Steve
Steve wrote:
>That flag is not set by mkgmap, unless I'm mistaking what is meant. Is
>this for ones created by mapsource?
Sorry, I didnt check what happens with gmapsupp.img's generated with mkgmap.
I meant indeed gmapsupps created by Mapsource (because I need a working address
index).
>As far
Hi
> By default the Ms (Mapsource) flag is set to 1 but you can set it to 0 with
> Gmaptool:
That flag is not set by mkgmap, unless I'm mistaking what is meant. Is
this for ones created by mapsource?
> I have tried it with my Openfietsmap and it worked. However I
> discovered that my map is tr
I've found another advantage of making a gmapsupp.img visible in Basecamp:
If your map consists of many layers, like contours, bike routes and so on, it
was not possible to show them in one map in Mapsource (if those layers had
different FID/PID)
Now you can send all mapsets with Mapsource (or M
Update about the transparency of OSM maps that are read as gmapsupp.img in
Basecamp:
This behaviour does not occur with maps generated with cgpsmapper or MPC
(official Garmin editor).
Maps compiled with cgpsmapper gets a blue border:
http://forum.gps.nl/download/file.php?id=435
see the discuss
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 pro
On Sat, Oct 22, 2011 at 04:46:06PM +0200, Ben Konrath wrote:
>On my unit I've have seen a problem where the routing would use the
>basemap if a road from the basemap was closer than any road from in my
>map.
I have seen it when the way closest to the destination point in the
mkgmap-generated ma
Hi Minko,
I've seen a similar result in Basecamp where the basemap highways were
visible along with the OSM map. This was for a map with no TYP file
(or the default TYP file I'm not sure what mkgmap is doing these
days). This didn't happen with a commercial map so there's definitely
something miss
Hi Klaus,
I was curious if and how it worked, because Garmin is (probably) going to
deliver all its maps this way in the near future. With some products it's
already the case, like the official Garmin Benelux cycling map, no installer,
no DVD, just a map on muicro SD card. On the Dutch GPS for
Just for my understanding - What's your intention ?
As map creator it's possible to create BaseCamp map as well as GPSr maps.
Klaus
--
View this message in context:
http://gis.638310.n2.nabble.com/gmapsupp-visible-in-Basecamp-tp6917545p6919623.html
Sent from the Mkgmap Development mailing list a
On http://forum.gps.nl/viewtopic.php?f=109&t=36229 there are some screenshots
about the transparency problem of the gmapsupp.img files in Basecamp.
I have tried to put a background polygon 0x4b in my typ files (draw priority 1,
sea at 2 and the rest higher numbers) but it didn't help.
Other mkgma
Just found out that you can make a gmapsupp.img on micro SD card or in your GPS
unit visible in Basecamp. This becomes the common procedure by map sellers,
they only deliver a gmapsupp on microSD card so you don't have to install the
map on the pc anymore.
By default the Ms (Mapsource) flag is
28 matches
Mail list logo
