Re: [mkgmap-dev] Memory problems since 1245

[Du Plessis, Bennie]

Steve, 
Thanks for your advice.

>I know that sometimes --generate-sea can take a long time.  Also if
>you are creating a map for a country that has lots of tags on every
>node, then it will take a lot more memory.  This is unfortunate and I
>plan to fix that problem, but it does mean that you should probably
>split the file into more pieces if that is the case.  You are running
>java with more virtual memory than you have physical memory on your
>machine which is also guaranteed to be slow.

Like Apollinaris says: --generate-sea takes very long. 
And it doesn't work well with tiles, and depends on --ignore-osm-bounds
which buggers intertile routing.
So I compiled --generate-sea with a style with nothing but the
coastline, which ran for 1.5 hr and gave me a lovely map with the land &
sea seperated but nothing else. The plan is to use this in a mapset if I
want to have a blue sea. Almost like an overlay, but maybe an underlay?

>For me, it takes just over 4 minutes to do the UK split into 14 tiles,
>and 8 seconds to make the index.

>I would recommend that you run the index creation separately from
>creating the .img files.  The index should only take a few seconds to
>create once you have some .img files to work with, and will give you a
>lot more time to experiment if things don't work the first time.

>Then run mkgmap with the --index on all the img file(s) that were
>created in the previous step, apart from the overview map file (called
>by default osmmap.img in the mdr branch, or 6324.img in the
>mainline).  Along with --index you will need as a
>minimum --family-id but there is no harm in repeating all the other
>options.

Then I compiled the img with 1260, --generate-sea off, --index on - I
think the mdr branch is not included in 1260 yet? Because I only got the
normal Imgs & tdbs.(this took max 5 minutes)

Then I compiled with 1257 and --index. Gave me the mdr's and mdx's
within 2 seconds.

(I just realised I did not make the maps transparent, so I'll probably
have to do it  again - no sweat it takes less than 10 min without
generate-sea.)

Now I try to send it to mapsource - 
And realise I am still as stupid as I've always been :-/

[HKEY_LOCAL_MACHINE\Software\Garmin\MapSource\Families\uk-test]  
   (uk-test = family-name?)
"ID"=hex:8d,03
(Family ID? How to convert 0005 to this format? Hex:05,00?)
"IDX"="c:\\maps\\osm\\osmmap.mdx" (overviewmapname.mdx)
"MDR"="c:\\maps\\osm\\osmmap_mdr.img"  (overviewmapname_mdr.mdx)

[HKEY_LOCAL_MACHINE\Software\Garmin\MapSource\Families\uk-test\1]
 (1 = ?product ID? FamilyID?just 1?
"BMAP"="c:\\maps\\osm\\osmmap.img" (overviewmapname.img)
"LOC"="c:\\maps\\osm\\"
"TDB"="c:\\maps\\osm\\osmmap.tdb" (overviewmapname.tdb)

Thanks for the great work on this project.
Every new dev is as exciting as the birth of a new baby, 
and I love to read how you all work through the various hick-ups &
challenges!

BennieD
#
Scanned by MailMarshal - Marshal's comprehensive email content security 
solution. 
Download a free evaluation of MailMarshal at www.marshal.com
#
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Handling of Garmin magic label codes (highwayshields etc.) differs from mp-format input to osm-format ?

[Clinton Gladstone]

On Mon, Oct 5, 2009 at 8:02 PM, Gert Münzel  wrote:

> Clinton wrote:
>>highway=* {name '${ref|highway-symbol:oval}<0x1f>${name}'
>>Where "<0x1f>" is the actual hex code 1f, inserted with a hex editor.
>>This might be enough for Gert to test this out without requiring any
>>modifications to mkgmap.
> Maybe i missunderstood you, but you really mean that i should insert/modiy 
> single
> bytes with a hex editor in the imgfile?

Yes, you did misunderstand (or I provided an inappropriate
explanation): you need to insert the hex code directly into the style
file.

That means you need to open the style file with a hex editor, find the
byte between ${ref|highway-symbol:oval} and ${name}, and change the
byte to the hex equivalent of 1f.

I don't know if it will work properly here, but it might be worth
trying. As I said, this is how we initially tested out the highway
symbols function.

Cheers
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[Clinton Gladstone]

On Tue, Oct 6, 2009 at 9:29 AM, Du Plessis, Bennie
 wrote:
>
> Like Apollinaris says: --generate-sea takes very long.
> And it doesn't work well with tiles, and depends on --ignore-osm-bounds
> which buggers intertile routing.
> So I compiled --generate-sea with a style with nothing but the
> coastline, which ran for 1.5 hr and gave me a lovely map with the land &
> sea seperated but nothing else. The plan is to use this in a mapset if I
> want to have a blue sea. Almost like an overlay, but maybe an underlay?

This is the approach I am experimenting with: I create a map with a
lower draw priority which includes only coastline, and use the
--generate-sea option. Since the coastline does not change very much,
this map does not need to be generated very often. Also, since the map
is not relevant for routing, and is much smaller than normal maps, it
does not necessarily need to be split.

Of course, the other maps need to be transparent for this to work.

I've tried this out with a map of Ontario Canada, and it seems to work
quite well, with the exception of the usual generate-sea problems
(some flooded islands, etc.). I've tested it on a Nuvi and an eTrex.

Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[maning sambale]

I am interested in this approach as well.  Can you please post the
howto for this?
In our areas the sea gets broken sometimes due to newbie editing it
would be good if I have a permanent sea osm file to create a onetime
sea polygon.

On Tue, Oct 6, 2009 at 6:08 PM, Clinton Gladstone
 wrote:
> On Tue, Oct 6, 2009 at 9:29 AM, Du Plessis, Bennie
>  wrote:
>>
>> Like Apollinaris says: --generate-sea takes very long.
>> And it doesn't work well with tiles, and depends on --ignore-osm-bounds
>> which buggers intertile routing.
>> So I compiled --generate-sea with a style with nothing but the
>> coastline, which ran for 1.5 hr and gave me a lovely map with the land &
>> sea seperated but nothing else. The plan is to use this in a mapset if I
>> want to have a blue sea. Almost like an overlay, but maybe an underlay?
>
> This is the approach I am experimenting with: I create a map with a
> lower draw priority which includes only coastline, and use the
> --generate-sea option. Since the coastline does not change very much,
> this map does not need to be generated very often. Also, since the map
> is not relevant for routing, and is much smaller than normal maps, it
> does not necessarily need to be split.
>
> Of course, the other maps need to be transparent for this to work.
>
> I've tried this out with a map of Ontario Canada, and it seems to work
> quite well, with the exception of the usual generate-sea problems
> (some flooded islands, etc.). I've tested it on a Nuvi and an eTrex.
>
> Cheers.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Handling of Garmin magic label codes (highwayshields etc.) differs from mp-format input to osm-format ?

[Gert Münzel]

Clinton Gladstone wrotes on/Tue Oct  6 10:06:35 BST 2009:/
>Yes, you did misunderstand (or I provided an inappropriate
>explanation): you need to insert the hex code directly into the stylefile.
>That means you need to open the style file with a hex editor, find the
>byte between ${ref|highway-symbol:oval} and ${name}, and change the
>byte to the hex equivalent of 1f.

Yes, i simply misunderstood.
I tried it and it was successfull. I got a 061f in 
the img-file.

cheers
Gert

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[Clinton Gladstone]

On Tue, Oct 6, 2009 at 12:11 PM, maning sambale
 wrote:
> I am interested in this approach as well.  Can you please post the
> howto for this?
> In our areas the sea gets broken sometimes due to newbie editing it
> would be good if I have a permanent sea osm file to create a onetime
> sea polygon.

OK. I don't have my files here and I'm about to go on vacation, so
I'll try to list the steps here from memory:

1. Copy the style files to a new directory. Use this for the new
coastline styles.

2. In the new directory, remove everything from the points file,
remove everything except coastline from the lines file, and remove
everything except sea (or ocean) from the polygons file. (You might
have to add a sea polygon; I can't remember.)

3. Compile the map with appropriate options to use the coastline style
files, and to generate sea polygons.

- Make sure you give the new map a unique family ID, and unique file names.

- Set draw-priority to a low number (I used 10, I believe).

- You can leave away a lot of the other options (such as routing) as
they are not relevant for this map.

- If your map is small enough, you can run mkgmap on the entire osm
file instead of splitting it. (I would imagine that the Phillipines
would be small enough.)

- Set an appropriate map description, so you can easily recognise the
coastline map when you install it on your GPSr.

4. Wait a while for the map to generate. The generate-sea option
appears to always take a fair amount of time.

5. Install the map you just generated into MapSource/Roadtrip, or save
it for separate combination into a gmapsup file.

6. Compile your regular map. Make sure to set the transparent option,
and to ensure that the draw priority is higher than the coastline map
(I think 25 is the default draw priority.)

- Of course, do not use the generate-sea option here.
- Also remember to use unique family IDs, map file names, etc.

7. Install this map into MapSource/Roadtrip, if you use them.

8. Combine the two maps into one gmapsup file on the GPSr, using
MapSource/Map Install, or use another tool of your choice to create a
combined gmapsup file.

Once you install the maps on your device, you can also select and
deselect the entire maps for display.

- On an eTrex you can do this by paging to the map setup page.
- On a Nuvi you can do this by navigating to the map options area.

As others have mentioned, you can use a similar technique to create
map overlays with contours or other information. Just compile with an
appropriate new style file, a higher draw-priority, and the
transparent option. For example, I have created an overlay for public
transit in Toronto, Canada which I can turn on and off at will if I
want to find the nearest subway, tram or bus line.

I hope this helps.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r1261: Implement the reverse index.

[Steve Ratcliffe]

Hi

> 1. I used the same gmapsupp.img on my Vista HCx and going to find -->
> cities --> find by name I can find all cities and they pop up by name
> completion

For me, I always get find by name for cities, but for POIs
I don't get that option without the global index.

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [mkgmap-svn] Commit: r1261: Implement the reverse index.

[Steve Ratcliffe]

On 05/10/09 16:04, svn commit wrote:
> Version 1261 was commited by steve on 2009-10-05 16:04:55 +0100 (Mon, 05 Oct 
> 2009)

> Should allow the index to be transferred to a GPS unit using m/s.  However
> completely untested at this stage.  Looks OK for a small number of maps,
> however I am not convinced it is working when 3 byte pointers are needed
> for some sections.

With the current version I get a crash in Mapsource if I don't select
all the maps and try to transfer.

However if I select all the maps it successfully transfers them all
along with the index information to the device and I can search for
POIs by name and also addresses (but I do have to type 1 into the
street number field).

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[Du Plessis, Bennie]

Ahh,
I made a mistake
The reason why I could not see in mapsource what I expected is because I
used the wrong input file for the one --index creation.

I make SA in a one tile map, and also in a 4 tile map, to compare &
play.

The 4 tile version worked fine, but the 1 tile map still does not
compile and returns the same ArrayIndexOutOfBounds error.
This input file is 19MB.
As for the time to return the error - approx 11 seconds 

java -ea -Xmx1000M -jar ../mkgmap-mdr-r1257.jar^
 --name-tag-list=name:af,name^
 --tdbfile^
 --description=SdAf1TM1257^
 --product-id=0003^
 --overview-mapname=SdAf1TMOView1257^
 --mapname=3001^
 --family-name=SdAf1TMFam1257^
 --family-id=0003^
 --Region-name="SARegion"^
 --index^
 2000.img (created with 1260)

F:\MkGMap\Use\Make200910052>time
The current time is: 15:03:42.22

F:\MkGMap\Use\Make200910052>java -ea -Xmx1000M -jar
../mkgmap-mdr-r1257.jar --name-tag-list=name:af,name --tdbfile
--description=SdA
f1TM1257 --product-id=0003 --overview-mapname=SdAf1TMOView1257
--mapname=3001 --family-name=SdAf1TMFam1257 --family-id=0003 --Re
gion-name="SARegion" --index 2000.img

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -68
at java.util.ArrayList.get(Unknown Source)
at
uk.me.parabola.imgfmt.sys.BlockTable.physFromLogical(BlockTable.java:112
)
at
uk.me.parabola.imgfmt.sys.Dirent.getPhysicalBlock(Dirent.java:262)
at uk.me.parabola.imgfmt.sys.FileNode.read(FileNode.java:156)
at
uk.me.parabola.imgfmt.app.BufferedImgFileReader.fillBuffer(BufferedImgFi
leReader.java:256)
at
uk.me.parabola.imgfmt.app.BufferedImgFileReader.get(BufferedImgFileReade
r.java:86)
at
uk.me.parabola.imgfmt.app.BufferedImgFileReader.getChar(BufferedImgFileR
eader.java:103)
at
uk.me.parabola.imgfmt.app.trergn.RGNFileReader$RgnOffsets.(RGNFile
Reader.java:232)
at
uk.me.parabola.imgfmt.app.trergn.RGNFileReader$RgnOffsets.(RGNFile
Reader.java:196)
at
uk.me.parabola.imgfmt.app.trergn.RGNFileReader.getOffsets(RGNFileReader.
java:185)
at
uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNFileRe
ader.java:70)
at
uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.java:93
)
at
uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.java:156
)
at
uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:109)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:358)
at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:
124)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:121)

F:\MkGMap\Use\Make200910052>time
The current time is: 15:03:53.49
Enter the new time:

Files created: SdAf1TMOView1257_mdr.img sizer 0 kb
Does this mean the input file is just too big?

The opinions contained in this message are those of the sender only and do not 
reflect those of Sappi Limited or any of its subsidiary or associated 
companies. 

"This message, including any attachment(s), may contain information which is 
private, privileged or confidential and is intended solely for the use of the 
individual or entity named in this message. If you are not the intended 
recipient of this message, please notify the sender thereof and destroy/delete 
the message. Neither the sender nor Sappi Limited (including its subsidiaries 
and associated companies, jointly referred to as 'Sappi') shall incur any 
liability resulting directly or indirectly from accessing any of the attached 
files which may contain a virus or the like. Any opinions, statements, 
conclusions and other information contained in this message and/or its 
attachment(s) that do not relate or refer to the official business of Sappi 
Limited or any of its subsidiary or associated companies shall be regarded as 
neither provided nor approved by any Sappi company. Views expressed in this 
message or its attachment(s) may not necessarily be those of Sappi and Sappi 
canno
 t be held liable for any direct or indirect loss or injury resulting from the 
contents of a message and/or its attachments."


Directors names

A list of Sappi companies and the names of their directors can be retrieved 
from 
http://www.sappi.com/SappiWeb/Investor+info/Corporate+governance/Board+resumes


#
Scanned by MailMarshal - Marshal's comprehensive email content security 
solution. 
Download a free evaluation of MailMarshal at www.marshal.com
#
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[charlie]

Quoting "Du Plessis, Bennie" :

> Ahh,
> I made a mistake
> The reason why I could not see in mapsource what I expected is because I
> used the wrong input file for the one --index creation.
>
> I make SA in a one tile map, and also in a 4 tile map, to compare &
> play.
>
> The 4 tile version worked fine, but the 1 tile map still does not
> compile and returns the same ArrayIndexOutOfBounds error.
> This input file is 19MB.
[snip]
>
> Files created: SdAf1TMOView1257_mdr.img sizer 0 kb
> Does this mean the input file is just too big?
In my experience you can have much bigger input files than that before  
mkgmap breaks: I have successfully used input files of up to 25Mb
See http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/003584.html
--
Charlie

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [mkgmap-svn] Commit: r1261: Implement the reverse index.

[Nakor]

   Hello,

I tried 1262 with MapSource 6.15.6 and still can see:

* crash when uploading to the GPS uni. I have one map in my family but other
maps in other families. Should I either uninstall the other families or try
to upload everything?
* crash when trying to enter a city under the Fetaures tab in the Find
PLaces window.

  Thanks,

N.



On Tue, Oct 6, 2009 at 7:12 AM, Steve Ratcliffe wrote:

> On 05/10/09 16:04, svn commit wrote:
> > Version 1261 was commited by steve on 2009-10-05 16:04:55 +0100 (Mon, 05
> Oct 2009)
>
> > Should allow the index to be transferred to a GPS unit using m/s.
>  However
> > completely untested at this stage.  Looks OK for a small number of maps,
> > however I am not convinced it is working when 3 byte pointers are needed
> > for some sections.
>
> With the current version I get a crash in Mapsource if I don't select
> all the maps and try to transfer.
>
> However if I select all the maps it successfully transfers them all
> along with the index information to the device and I can search for
> POIs by name and also addresses (but I do have to type 1 into the
> street number field).
>
> ..Steve
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1263: Several fixes to the reverse index MDR 1.

[svn commit]

Version 1263 was commited by steve on 2009-10-06 15:02:18 +0100 (Tue, 06 Oct 
2009) 
BRANCH: mdr

Several fixes to the reverse index MDR 1.

Major error in the mdr10 record number fixed.

Deal with sections that are less than 256 records in the reverse index.

Now I am able to select a subset of the available map tiles and send them to the
GPS unit.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [mkgmap-svn] Commit: r1261: Implement the reverse index.

[Steve Ratcliffe]

Hi

On 06/10/09 14:23, Nakor wrote:
> I tried 1262 with MapSource 6.15.6 and still can see:
>
> * crash when uploading to the GPS uni. I have one map in my family but
> other maps in other families. Should I either uninstall the other
> families or try to upload everything?
> * crash when trying to enter a city under the Fetaures tab in the Find
> PLaces window.

Thanks for the report.

I've made a number of fixes and I am now getting good results, so I
would try version r1263 of mkgmap-mdr.  I doubt uninstalling the other
families will make a difference.

Thanks

..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r1262: Rework the city code.

[Gert Münzel]

svn commit  

 
*on* /Mon Oct 5 22:17:25 BST 2009 wrotes:/

Version 1262 was commited by steve on 2009-10-05 22:17:25 +0100 (Mon, 05 Oct 
2009) 
BRANCH: mdr

Also with this version i got a MDR_TRIM_ADDR.CXX exception by Mapsource if i 
try to send the map to my gps.
The last mdr-version which i used with suceess was 1259.

Things i observed by trying search and find with "Search citys" in Mapsource:
1: there seems to be a problem with german umlauts.
   "City" page:
   You can't enter Citys which contains characters like Ö, ä,ü in the 
City-field.
   But if i only enter some leading characters like e.g "Zer" i get as result 
also "Zerm?Llen".
   If i press then "search" sometimes(not always) Zermüllen(which is the 
correct form of writing) will
   be found with "Zermüllen,Zermü?Len" in the "Places" window
2: for citys without umlauts i get always multiple outputs in the result 
(Places) window
   even if only one city with the searched name exist
3: "feature" page i can't enter a single character in the city field
4: "adress" page i can't enter a single character in the city field

cheers Gert

P.S
r1263 => same procedure as with 1262



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r1262: Rework the city code.

[Gert Münzel]

Gert wrotes:
<1: there seems to be a problem with german umlauts.
<   "City" page:
<   You can't enter Citys which contains characters like Ö, ä,ü in the 
City-field.
<   But if i only enter some leading characters like e.g "Zer" i get as result 
also "Zerm?Llen".
<   If i press then "search" sometimes(not always) Zermüllen(which is the 
correct form of writing) will
<   be found with "Zermüllen,Zermü?Len" in the "Places" window

Just to make it clearer:
This example always will be found, but some other City with Umlauts (ö,ü,ä)will 
be found and some not.


Gert

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] MDR success and a couple of questions

[Alexander Atanasov]

On Sun, Oct 4, 2009 at 1:58 PM, Steve Ratcliffe  wrote:
> Hi
>
>> MDR7 - Roads
>> 1/2 bytes IMG id from MDR1
>> 3 bytes - unknown, may be a pointer in NOD, it's not a label or NET offset
>
> This definitely is or can be a pointer to LBL as I have now got working
> street search based on it being a pointer into LBL.

I was wrong it is a LBL.  i've got this from 3 different maps and it's
all labels in LBL.
Only the first is interesting, others are all 0x80 flagged:
garmin_mdr.c:1262:1|mdr7: 376772 391769 7 3
garmin_mdr.c:337:1|1[] IMG:[03D0900D] roadptr: 803BBC
lbl[28BE]:[^D1] left=0 :02 BC 3B 80 BE 28 00
garmin_mdr.c:337:1|2[0007] IMG:[03D0900E] roadptr: 6EFE
lbl[28BE]:[^D1] left=0 :03 FE 6E 00 BE 28 00
garmin_mdr.c:337:1|3[000E] IMG:[03D0900F] roadptr: 73B4
lbl[28BE]:[^D1] left=0 :04 B4 73 00 BE 28 00
garmin_mdr.c:337:1|4[0015] IMG:[03D09010] roadptr: BDE6
lbl[28BE]:[^D1] left=0 :05 E6 BD 00 BE 28 00
garmin_mdr.c:337:1|5[001C] IMG:[03D09011] roadptr: 11DB3
lbl[28BE]:[^D1] left=0 :06 B3 1D 01 BE 28 00
garmin_mdr.c:337:1|6[0023] IMG:[03D09012] roadptr: 7159
lbl[28BE]:[^D1] left=0 :07 59 71 00 BE 28 00
garmin_mdr.c:337:1|7[002A] IMG:[03D09013] roadptr: 8C15
lbl[28BE]:[^D1] left=0 :08 15 8C 00 BE 28 00
garmin_mdr.c:337:1|8[0031] IMG:[03D09014] roadptr: 7626
lbl[28BE]:[^D1] left=0 :09 26 76 00 BE 28 00

Note that 0x80, looks like a new label flag, not repeated. (^D is
from the special road codes).

This is from another map.
garmin_mdr.c:1262:1|mdr7: 536473 52440 8 67
And yet another, which is very small.
garmin_mdr.c:1262:1|mdr7: 3267 896 8 67

for the last two there is one more byte at the end which is 01.
I think this hides in the mdr header, not the section flags, most of
the flags looks like
an alignment.(arm cpus?)
1.garmin_mdr.c:1233:1|hdr: codepage: 1252 0001 000E0001
 this doesn't have extra byte at the end. (new zeland map)
2.garmin_mdr.c:1233:1|hdr: codepage: 1252 0007 00170002
3.garmin_mdr.c:1233:1|hdr: codepage: 1251 0008 00170001
this two have one or two bytes at the end of records, not only in mdr7.

This one is from a map with mdr17, no mdr15.
garmin_mdr.c:1233:1|hdr: codepage: 1252 0007 00170002
MDR17 is read so so and it contains 7 bit ascii.

The code page i clear, next is 1,7,8 - labels coding?
1 and 7 are 7bit ascii
8 is 8bits  based on cp1251(cyrillic) is read okay.

0x0E and 0x17 i think this are like the poi properties in the lbl file,
and specifiy what's in the records and/or what sections are in the mdr.
the last 1,2 may be too.

One more thing in the mg v9 map:
garmin_mdr.c:1248:1|mdr4: 116876308 228 3 0
garmin_mdr.c:1251:1|max_possible_type=4c(76)
garmin_mdr.c:1084:1|POI Type
garmin_mdr.c:337:1|1(0)[] type=0x0100 x=2(2) :01 02 00
[cut]
garmin_mdr.c:337:1|12(b)[0021] type=0x0D00 x=2(2) :0D 02 00
garmin_mdr.c:337:1|13(c)[0024] type=0x2800 x=2(2) :28 02 00
garmin_mdr.c:337:1|14(d)[0027] type=0x2A00 x=0(0) :2A 00 00
garmin_mdr.c:337:1|15(e)[002A] type=0x2A01 x=0(0) :2A 00 01
garmin_mdr.c:337:1|16(f)[002D] type=0x2A02 x=0(0) :2A 00 02
garmin_mdr.c:337:1|17(10)[0030] type=0x2A03 x=0(0) :2A 00 03

0x2800 is in the MDR4 and looks like correctly sorted.

> But perhaps it can be different things, I previously had it down
> as a pointer into NET.  This would make sense as net contains the
> locations of the road.  With a pointer to LBL the software has to
> perform several lookups to locate the road and its city, region etc.

I belive than the longer records found in some mdrs, even go further,
to the point of where to route to. Like
poi = image, pnt:sdiv, lbl, region, road, node, ...


-- 
have fun,
alex
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] MDR success and a couple of questions

[Felix Hartmann]

Alexander Atanasov wrote:

On Sun, Oct 4, 2009 at 1:58 PM, Steve Ratcliffe  wrote:
  

Hi



MDR7 - Roads
1/2 bytes IMG id from MDR1
3 bytes - unknown, may be a pointer in NOD, it's not a label or NET offset
  

This definitely is or can be a pointer to LBL as I have now got working
street search based on it being a pointer into LBL.



I was wrong it is a LBL.  i've got this from 3 different maps and it's
all labels in LBL.
Only the first is interesting, others are all 0x80 flagged:
garmin_mdr.c:1262:1|mdr7: 376772 391769 7 3
garmin_mdr.c:337:1|1[] IMG:[03D0900D] roadptr: 803BBC
lbl[28BE]:[^D1] left=0 :02 BC 3B 80 BE 28 00
garmin_mdr.c:337:1|2[0007] IMG:[03D0900E] roadptr: 6EFE
lbl[28BE]:[^D1] left=0 :03 FE 6E 00 BE 28 00
garmin_mdr.c:337:1|3[000E] IMG:[03D0900F] roadptr: 73B4
lbl[28BE]:[^D1] left=0 :04 B4 73 00 BE 28 00
garmin_mdr.c:337:1|4[0015] IMG:[03D09010] roadptr: BDE6
lbl[28BE]:[^D1] left=0 :05 E6 BD 00 BE 28 00
garmin_mdr.c:337:1|5[001C] IMG:[03D09011] roadptr: 11DB3
lbl[28BE]:[^D1] left=0 :06 B3 1D 01 BE 28 00
garmin_mdr.c:337:1|6[0023] IMG:[03D09012] roadptr: 7159
lbl[28BE]:[^D1] left=0 :07 59 71 00 BE 28 00
garmin_mdr.c:337:1|7[002A] IMG:[03D09013] roadptr: 8C15
lbl[28BE]:[^D1] left=0 :08 15 8C 00 BE 28 00
garmin_mdr.c:337:1|8[0031] IMG:[03D09014] roadptr: 7626
lbl[28BE]:[^D1] left=0 :09 26 76 00 BE 28 00

Note that 0x80, looks like a new label flag, not repeated. (^D is
from the special road codes).

This is from another map.
garmin_mdr.c:1262:1|mdr7: 536473 52440 8 67
And yet another, which is very small.
garmin_mdr.c:1262:1|mdr7: 3267 896 8 67

for the last two there is one more byte at the end which is 01.
I think this hides in the mdr header, not the section flags, most of
the flags looks like
an alignment.(arm cpus?)
1.garmin_mdr.c:1233:1|hdr: codepage: 1252 0001 000E0001
 this doesn't have extra byte at the end. (new zeland map)
2.garmin_mdr.c:1233:1|hdr: codepage: 1252 0007 00170002
3.garmin_mdr.c:1233:1|hdr: codepage: 1251 0008 00170001
this two have one or two bytes at the end of records, not only in mdr7.

This one is from a map with mdr17, no mdr15.
garmin_mdr.c:1233:1|hdr: codepage: 1252 0007 00170002
MDR17 is read so so and it contains 7 bit ascii.

The code page i clear, next is 1,7,8 - labels coding?
1 and 7 are 7bit ascii
8 is 8bits  based on cp1251(cyrillic) is read okay.

0x0E and 0x17 i think this are like the poi properties in the lbl file,
and specifiy what's in the records and/or what sections are in the mdr.
the last 1,2 may be too.

One more thing in the mg v9 map:
garmin_mdr.c:1248:1|mdr4: 116876308 228 3 0
garmin_mdr.c:1251:1|max_possible_type=4c(76)
garmin_mdr.c:1084:1|POI Type
garmin_mdr.c:337:1|1(0)[] type=0x0100 x=2(2) :01 02 00
[cut]
garmin_mdr.c:337:1|12(b)[0021] type=0x0D00 x=2(2) :0D 02 00
garmin_mdr.c:337:1|13(c)[0024] type=0x2800 x=2(2) :28 02 00
garmin_mdr.c:337:1|14(d)[0027] type=0x2A00 x=0(0) :2A 00 00
garmin_mdr.c:337:1|15(e)[002A] type=0x2A01 x=0(0) :2A 00 01
garmin_mdr.c:337:1|16(f)[002D] type=0x2A02 x=0(0) :2A 00 02
garmin_mdr.c:337:1|17(10)[0030] type=0x2A03 x=0(0) :2A 00 03

0x2800 is in the MDR4 and looks like correctly sorted.

  

But perhaps it can be different things, I previously had it down
as a pointer into NET.  This would make sense as net contains the
locations of the road.  With a pointer to LBL the software has to
perform several lookups to locate the road and its city, region etc.



I belive than the longer records found in some mdrs, even go further,
to the point of where to route to. Like
poi = image, pnt:sdiv, lbl, region, road, node, ...
  
This is possible, Nuvis can search for POI near to a calculated route. 
Outdoor units like 60CSx or Vista/Legend can't. I'm unsure about 
Oregon/Dakota

maybe this is related.


  
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[Charlie Ferrero]

Clinton Gladstone wrote:
> On Tue, Oct 6, 2009 at 12:11 PM, maning sambale
>  wrote:
>> I am interested in this approach as well.  Can you please post the
>> howto for this?
>> In our areas the sea gets broken sometimes due to newbie editing it
>> would be good if I have a permanent sea osm file to create a onetime
>> sea polygon.
> 
> OK. I don't have my files here and I'm about to go on vacation, so
> I'll try to list the steps here from memory:
> 
> 1. Copy the style files to a new directory. Use this for the new
> coastline styles.
> 
> 2. In the new directory, remove everything from the points file,
> remove everything except coastline from the lines file, and remove
> everything except sea (or ocean) from the polygons file. (You might
> have to add a sea polygon; I can't remember.)
> 
> 3. Compile the map with appropriate options to use the coastline style
> files, and to generate sea polygons.
> 
> - Make sure you give the new map a unique family ID, and unique file names.
> 
> - Set draw-priority to a low number (I used 10, I believe).
> 
> - You can leave away a lot of the other options (such as routing) as
> they are not relevant for this map.
> 
> - If your map is small enough, you can run mkgmap on the entire osm
> file instead of splitting it. (I would imagine that the Phillipines
> would be small enough.)
> 
> - Set an appropriate map description, so you can easily recognise the
> coastline map when you install it on your GPSr.
> 
> 4. Wait a while for the map to generate. The generate-sea option
> appears to always take a fair amount of time.
> 
> 5. Install the map you just generated into MapSource/Roadtrip, or save
> it for separate combination into a gmapsup file.
> 
> 6. Compile your regular map. Make sure to set the transparent option,
> and to ensure that the draw priority is higher than the coastline map
> (I think 25 is the default draw priority.)
> 
> - Of course, do not use the generate-sea option here.
> - Also remember to use unique family IDs, map file names, etc.
> 
> 7. Install this map into MapSource/Roadtrip, if you use them.
> 
> 8. Combine the two maps into one gmapsup file on the GPSr, using
> MapSource/Map Install, or use another tool of your choice to create a
> combined gmapsup file.
> 
> Once you install the maps on your device, you can also select and
> deselect the entire maps for display.
> 
> - On an eTrex you can do this by paging to the map setup page.
> - On a Nuvi you can do this by navigating to the map options area.
> 
> As others have mentioned, you can use a similar technique to create
> map overlays with contours or other information. Just compile with an
> appropriate new style file, a higher draw-priority, and the
> transparent option. For example, I have created an overlay for public
> transit in Toronto, Canada which I can turn on and off at will if I
> want to find the nearest subway, tram or bus line.

To make life easier, you could craft an XAPI call just to download the 
coastline for a particular area of interest (makes the OSM file much 
smaller so more likely that you'll have enough memory to process it). 
I've been trying with
wget 
http://www.informationfreeway.org/api/0.6/way[natural=coastline][bbox=9.31641,49.49668,2.28516,61.27023]
 
-O UK_coastline.osm

but it doesn't seem to work.  Does anyone have any experience of XAPI 
and know where I'm going wrong?
-- 
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[Carlos Dávila]

Charlie Ferrero escribió:
> Clinton Gladstone wrote:
>   
>> On Tue, Oct 6, 2009 at 12:11 PM, maning sambale
>>  wrote:
>> 
>>> I am interested in this approach as well.  Can you please post the
>>> howto for this?
>>> In our areas the sea gets broken sometimes due to newbie editing it
>>> would be good if I have a permanent sea osm file to create a onetime
>>> sea polygon.
>>>   
>> OK. I don't have my files here and I'm about to go on vacation, so
>> I'll try to list the steps here from memory:
>>
>> 1. Copy the style files to a new directory. Use this for the new
>> coastline styles.
>>
>> 2. In the new directory, remove everything from the points file,
>> remove everything except coastline from the lines file, and remove
>> everything except sea (or ocean) from the polygons file. (You might
>> have to add a sea polygon; I can't remember.)
>>
>> 3. Compile the map with appropriate options to use the coastline style
>> files, and to generate sea polygons.
>>
>> - Make sure you give the new map a unique family ID, and unique file names.
>>
>> - Set draw-priority to a low number (I used 10, I believe).
>>
>> - You can leave away a lot of the other options (such as routing) as
>> they are not relevant for this map.
>>
>> - If your map is small enough, you can run mkgmap on the entire osm
>> file instead of splitting it. (I would imagine that the Phillipines
>> would be small enough.)
>>
>> - Set an appropriate map description, so you can easily recognise the
>> coastline map when you install it on your GPSr.
>>
>> 4. Wait a while for the map to generate. The generate-sea option
>> appears to always take a fair amount of time.
>>
>> 5. Install the map you just generated into MapSource/Roadtrip, or save
>> it for separate combination into a gmapsup file.
>>
>> 6. Compile your regular map. Make sure to set the transparent option,
>> and to ensure that the draw priority is higher than the coastline map
>> (I think 25 is the default draw priority.)
>>
>> - Of course, do not use the generate-sea option here.
>> - Also remember to use unique family IDs, map file names, etc.
>>
>> 7. Install this map into MapSource/Roadtrip, if you use them.
>>
>> 8. Combine the two maps into one gmapsup file on the GPSr, using
>> MapSource/Map Install, or use another tool of your choice to create a
>> combined gmapsup file.
>>
>> Once you install the maps on your device, you can also select and
>> deselect the entire maps for display.
>>
>> - On an eTrex you can do this by paging to the map setup page.
>> - On a Nuvi you can do this by navigating to the map options area.
>>
>> As others have mentioned, you can use a similar technique to create
>> map overlays with contours or other information. Just compile with an
>> appropriate new style file, a higher draw-priority, and the
>> transparent option. For example, I have created an overlay for public
>> transit in Toronto, Canada which I can turn on and off at will if I
>> want to find the nearest subway, tram or bus line.
>> 
>
> To make life easier, you could craft an XAPI call just to download the 
> coastline for a particular area of interest (makes the OSM file much 
> smaller so more likely that you'll have enough memory to process it). 
> I've been trying with
> wget 
> http://www.informationfreeway.org/api/0.6/way[natural=coastline][bbox=9.31641,49.49668,2.28516,61.27023]
>  
> -O UK_coastline.osm
>
> but it doesn't seem to work.  Does anyone have any experience of XAPI 
> and know where I'm going wrong?
>   
I have just used wget
http://osmxapi.hypercube.telascience.org/api/0.6/way%5Bnatural=coastline%5D%5Bbbox=-9.580078125,41.044921875,-4.04296875,43.9453125%5D
-O yuorfile.osm and it to worked fine.
Cheers
Carlos
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[Charlie Ferrero]

Carlos Dávila wrote:
> Charlie Ferrero escribió:
>> Clinton Gladstone wrote:
>>   
>>> On Tue, Oct 6, 2009 at 12:11 PM, maning sambale
>>>  wrote:
>>> 
 I am interested in this approach as well.  Can you please post the
 howto for this?
 In our areas the sea gets broken sometimes due to newbie editing it
 would be good if I have a permanent sea osm file to create a onetime
 sea polygon.
   
>>> OK. I don't have my files here and I'm about to go on vacation, so
>>> I'll try to list the steps here from memory:
>>>
>>> 1. Copy the style files to a new directory. Use this for the new
>>> coastline styles.
>>>
>>> 2. In the new directory, remove everything from the points file,
>>> remove everything except coastline from the lines file, and remove
>>> everything except sea (or ocean) from the polygons file. (You might
>>> have to add a sea polygon; I can't remember.)
>>>
>>> 3. Compile the map with appropriate options to use the coastline style
>>> files, and to generate sea polygons.
>>>
>>> - Make sure you give the new map a unique family ID, and unique file names.
>>>
>>> - Set draw-priority to a low number (I used 10, I believe).
>>>
>>> - You can leave away a lot of the other options (such as routing) as
>>> they are not relevant for this map.
>>>
>>> - If your map is small enough, you can run mkgmap on the entire osm
>>> file instead of splitting it. (I would imagine that the Phillipines
>>> would be small enough.)
>>>
>>> - Set an appropriate map description, so you can easily recognise the
>>> coastline map when you install it on your GPSr.
>>>
>>> 4. Wait a while for the map to generate. The generate-sea option
>>> appears to always take a fair amount of time.
>>>
>>> 5. Install the map you just generated into MapSource/Roadtrip, or save
>>> it for separate combination into a gmapsup file.
>>>
>>> 6. Compile your regular map. Make sure to set the transparent option,
>>> and to ensure that the draw priority is higher than the coastline map
>>> (I think 25 is the default draw priority.)
>>>
>>> - Of course, do not use the generate-sea option here.
>>> - Also remember to use unique family IDs, map file names, etc.
>>>
>>> 7. Install this map into MapSource/Roadtrip, if you use them.
>>>
>>> 8. Combine the two maps into one gmapsup file on the GPSr, using
>>> MapSource/Map Install, or use another tool of your choice to create a
>>> combined gmapsup file.
>>>
>>> Once you install the maps on your device, you can also select and
>>> deselect the entire maps for display.
>>>
>>> - On an eTrex you can do this by paging to the map setup page.
>>> - On a Nuvi you can do this by navigating to the map options area.
>>>
>>> As others have mentioned, you can use a similar technique to create
>>> map overlays with contours or other information. Just compile with an
>>> appropriate new style file, a higher draw-priority, and the
>>> transparent option. For example, I have created an overlay for public
>>> transit in Toronto, Canada which I can turn on and off at will if I
>>> want to find the nearest subway, tram or bus line.
>>> 
>> To make life easier, you could craft an XAPI call just to download the 
>> coastline for a particular area of interest (makes the OSM file much 
>> smaller so more likely that you'll have enough memory to process it). 
>> I've been trying with
>> wget 
>> http://www.informationfreeway.org/api/0.6/way[natural=coastline][bbox=9.31641,49.49668,2.28516,61.27023]
>>  
>> -O UK_coastline.osm
>>
>> but it doesn't seem to work.  Does anyone have any experience of XAPI 
>> and know where I'm going wrong?
>>   
> I have just used wget
> http://osmxapi.hypercube.telascience.org/api/0.6/way%5Bnatural=coastline%5D%5Bbbox=-9.580078125,41.044921875,-4.04296875,43.9453125%5D
> -O yuorfile.osm and it to worked fine.
> Cheers
> Carlos
Yep, my fault: I omitted a - sign on the very first bound.  It's working 
now.

-- 

Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1264: Move code that determines bearing of one point from another into Coord class.

[svn commit]

Version 1264 was commited by markb on 2009-10-06 21:29:57 +0100 (Tue, 06 Oct 
2009) 

Move code that determines bearing of one point from another into Coord class.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1265: Added --drive-on-left, --drive-on-right and --check-roundabouts options.

[svn commit]

Version 1265 was commited by markb on 2009-10-06 21:30:02 +0100 (Tue, 06 Oct 
2009) 

Added --drive-on-left, --drive-on-right and --check-roundabouts options.

--drive-on-left
--drive-on-right
Explicitly specify which side of the road vehicles are
expected to drive on. If neither of these options are
specified, it is assumed that vehicles drive on the right
unless --check-roundabouts is specified and the first
roundabout processed is clockwise.

--check-roundabouts
Check that roundabouts have the expected direction (clockwise
when vehicles drive on the left). Roundabouts that are complete
loops and have the wrong direction are reversed.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [mkgmap-svn] Commit: r1261: Implement the reverse index.

[Nakor]

  Hi Steve,
>> * crash when uploading to the GPS uni. I have one map in my family but other 
>> maps in other families. Should I either uninstall the other
>> families or try to upload everything?
>> * crash when trying to enter a city under the Fetaures tab in the Find 
>> Places window.
>> 
> I would try version r1263 of mkgmap-mdr. 
>   

I tried r1265 and it is pretty much the same.

  Thanks,

  N.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[Charlie Ferrero]

Charlie Ferrero wrote:
> 
> Carlos Dávila wrote:
>> Charlie Ferrero escribió:
>>> Clinton Gladstone wrote:
>>>   
 On Tue, Oct 6, 2009 at 12:11 PM, maning sambale
  wrote:
 
> I am interested in this approach as well.  Can you please post the
> howto for this?
> In our areas the sea gets broken sometimes due to newbie editing it
> would be good if I have a permanent sea osm file to create a onetime
> sea polygon.
>   
 OK. I don't have my files here and I'm about to go on vacation, so
 I'll try to list the steps here from memory:

 1. Copy the style files to a new directory. Use this for the new
 coastline styles.

 2. In the new directory, remove everything from the points file,
 remove everything except coastline from the lines file, and remove
 everything except sea (or ocean) from the polygons file. (You might
 have to add a sea polygon; I can't remember.)

 3. Compile the map with appropriate options to use the coastline style
 files, and to generate sea polygons.

 - Make sure you give the new map a unique family ID, and unique file names.

 - Set draw-priority to a low number (I used 10, I believe).

 - You can leave away a lot of the other options (such as routing) as
 they are not relevant for this map.

 - If your map is small enough, you can run mkgmap on the entire osm
 file instead of splitting it. (I would imagine that the Phillipines
 would be small enough.)

 - Set an appropriate map description, so you can easily recognise the
 coastline map when you install it on your GPSr.

 4. Wait a while for the map to generate. The generate-sea option
 appears to always take a fair amount of time.

 5. Install the map you just generated into MapSource/Roadtrip, or save
 it for separate combination into a gmapsup file.

 6. Compile your regular map. Make sure to set the transparent option,
 and to ensure that the draw priority is higher than the coastline map
 (I think 25 is the default draw priority.)

 - Of course, do not use the generate-sea option here.
 - Also remember to use unique family IDs, map file names, etc.

 7. Install this map into MapSource/Roadtrip, if you use them.

 8. Combine the two maps into one gmapsup file on the GPSr, using
 MapSource/Map Install, or use another tool of your choice to create a
 combined gmapsup file.

 Once you install the maps on your device, you can also select and
 deselect the entire maps for display.

 - On an eTrex you can do this by paging to the map setup page.
 - On a Nuvi you can do this by navigating to the map options area.

 As others have mentioned, you can use a similar technique to create
 map overlays with contours or other information. Just compile with an
 appropriate new style file, a higher draw-priority, and the
 transparent option. For example, I have created an overlay for public
 transit in Toronto, Canada which I can turn on and off at will if I
 want to find the nearest subway, tram or bus line.
 
>>> To make life easier, you could craft an XAPI call just to download the 
>>> coastline for a particular area of interest (makes the OSM file much 
>>> smaller so more likely that you'll have enough memory to process it). 
>>> I've been trying with
>>> wget 
>>> http://www.informationfreeway.org/api/0.6/way[natural=coastline][bbox=-9.31641,49.49668,2.28516,61.27023]
>>>  
>>> -O UK_coastline.osm
>>>
As an update, I've tried running mkgmap on this coastline extract (the 
OSM input file is about 90MB.) but after two hours there is still no 
sign of anything and not even an empty .img file has been created.  Java 
is chuntering away at 50% CPU utilisation.

I assume this isn't right - but can anyone who has successfully got 
--generate-sea to work let me know how they can tell it is working or not?



-- 

Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [mkgmap-svn] Commit: r1261: Implement the reverseindex.

[Du Plessis, Bennie]

Hi,

By doing the img in one go and the -index in a subsequent run, I can
finaly compile my area with 1262 if I split it in 4.

Mdr & Mdx gets created.

I send it to mapsource succesfully, (whenever I get the Hex conv
correct:-/

But I can not use it.

The benefit is that family-name works, but I still can not use the find
function in mapsource.

Only find nearby places & recent finds.

I then send it to the GPS - fine

But the separate families is not un-selectable. ie each different family
is visible on its own line with a tick box next to it.

But I can not de-select any one seperately.

This is propably a device error. Nuvi200W, old, warranty expired,
patched to re-enable stolen  tracking ability,,,

Important thing 

- finding cities - works, as it has always done

- finding addresses - no go, asks province as always

- Crossings - no go, asks province as always

Troubling is that others can use find option in mapsource 6156 while I
cannot, so I'm doing something wrong!

Use -index; --family-id; --family-name; --product-id, is there any other
options that I should use?

I use a custom style, but I don't think the style will have an effect on
the index?

 

I will try 1263 tommorow, tonight I'm taking off for my little girls
birthday

BennieD

 

>I tried 1262 with MapSource 6.15.6 and still can see:
>
>* crash when uploading to the GPS uni. I have one map in my family but
other maps in other families. Should I either uninstall >the other
families or try to upload everything?
>* crash when trying to enter a city under the Fetaures tab in the Find
PLaces window.
>
 > Thanks,
>
>N.
>

>On Tue, Oct 6, 2009 at 7:12 AM, Steve Ratcliffe 
wrote:

>On 05/10/09 16:04, svn commit wrote:
>> Version 1261 was commited by steve on 2009-10-05 16:04:55 +0100 (Mon,
05 Oct 2009)

>> Should allow the index to be transferred to a GPS unit using m/s.
However
>> completely untested at this stage.  Looks OK for a small number of
maps,
>> however I am not convinced it is working when 3 byte pointers are
needed
>> for some sections.

>With the current version I get a crash in Mapsource if I don't select
>all the maps and try to transfer.
>
>However if I select all the maps it successfully transfers them all
>along with the index information to the device and I can search for
>POIs by name and also addresses (but I do have to type 1 into the
>street number field).
>
>..Steve

 


#
Scanned by MailMarshal - Marshal's comprehensive email content security 
solution. 
Download a free evaluation of MailMarshal at www.marshal.com
#
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Memory problems since 1245

[Carlos Dávila]

Charlie Ferrero escribió:
> Charlie Ferrero wrote:
>   
>> Carlos Dávila wrote:
>> 
>>> Charlie Ferrero escribió:
>>>   
 Clinton Gladstone wrote:
   
 
> On Tue, Oct 6, 2009 at 12:11 PM, maning sambale
>  wrote:
> 
>   
>> I am interested in this approach as well.  Can you please post the
>> howto for this?
>> In our areas the sea gets broken sometimes due to newbie editing it
>> would be good if I have a permanent sea osm file to create a onetime
>> sea polygon.
>>   
>> 
> OK. I don't have my files here and I'm about to go on vacation, so
> I'll try to list the steps here from memory:
>
> 1. Copy the style files to a new directory. Use this for the new
> coastline styles.
>
> 2. In the new directory, remove everything from the points file,
> remove everything except coastline from the lines file, and remove
> everything except sea (or ocean) from the polygons file. (You might
> have to add a sea polygon; I can't remember.)
>
> 3. Compile the map with appropriate options to use the coastline style
> files, and to generate sea polygons.
>
> - Make sure you give the new map a unique family ID, and unique file 
> names.
>
> - Set draw-priority to a low number (I used 10, I believe).
>
> - You can leave away a lot of the other options (such as routing) as
> they are not relevant for this map.
>
> - If your map is small enough, you can run mkgmap on the entire osm
> file instead of splitting it. (I would imagine that the Phillipines
> would be small enough.)
>
> - Set an appropriate map description, so you can easily recognise the
> coastline map when you install it on your GPSr.
>
> 4. Wait a while for the map to generate. The generate-sea option
> appears to always take a fair amount of time.
>
> 5. Install the map you just generated into MapSource/Roadtrip, or save
> it for separate combination into a gmapsup file.
>
> 6. Compile your regular map. Make sure to set the transparent option,
> and to ensure that the draw priority is higher than the coastline map
> (I think 25 is the default draw priority.)
>
> - Of course, do not use the generate-sea option here.
> - Also remember to use unique family IDs, map file names, etc.
>
> 7. Install this map into MapSource/Roadtrip, if you use them.
>
> 8. Combine the two maps into one gmapsup file on the GPSr, using
> MapSource/Map Install, or use another tool of your choice to create a
> combined gmapsup file.
>
> Once you install the maps on your device, you can also select and
> deselect the entire maps for display.
>
> - On an eTrex you can do this by paging to the map setup page.
> - On a Nuvi you can do this by navigating to the map options area.
>
> As others have mentioned, you can use a similar technique to create
> map overlays with contours or other information. Just compile with an
> appropriate new style file, a higher draw-priority, and the
> transparent option. For example, I have created an overlay for public
> transit in Toronto, Canada which I can turn on and off at will if I
> want to find the nearest subway, tram or bus line.
> 
>   
 To make life easier, you could craft an XAPI call just to download the 
 coastline for a particular area of interest (makes the OSM file much 
 smaller so more likely that you'll have enough memory to process it). 
 I've been trying with
 wget 
 http://www.informationfreeway.org/api/0.6/way[natural=coastline][bbox=-9.31641,49.49668,2.28516,61.27023]
  
 -O UK_coastline.osm

 
> As an update, I've tried running mkgmap on this coastline extract (the 
> OSM input file is about 90MB.) but after two hours there is still no 
> sign of anything and not even an empty .img file has been created.  Java 
> is chuntering away at 50% CPU utilisation.
>
> I assume this isn't right - but can anyone who has successfully got 
> --generate-sea to work let me know how they can tell it is working or not?
>
>
>
>   
I usually build map of Spain with --generate-sea using 7 tiles I get
splitting Europe extract from Geofrabrik with the following command line:
java -Xmx1000m -enableassertions -jar mkgmap.jar --generate-sea --route
--latin1 --code-page=1252 --description="OpenStreetMap-Iberia"
--gmapsupp --country-name=ESPAÑA --country-abbr=ESP --family-name="Open
Street Map" --family-id=18 --product-id=318 --series-name="OSM-Iberia-s"
--road-name-pois --ignore-maxspeeds --remove-short-arcs
--add-pois-to-areas --location-autofill=1 --style=mio -c spain-s.args
I didn't notice an special increase in the processing time. However I
have done some attempts with only coastline (only 27 MB) and it take
more than ten minutes, which I find too long fo