[mkgmap-dev] SOLVED: Multiple .img files in one gmapsupp.img: Some will not show up

Good ... uh, morning. As it seems, I've now solved the problem. Which was that I did not change the *Map ID* for each map. The Map ID is also known as Map Name in mkgmap (-n option). It seems that the Map ID has to be unique. See here about how to change it: http://svn.parabola.me.uk/display/

Re: [mkgmap-dev] Map ID: In-file replacing

Ralf Kleineisel wrote: On 01/13/2010 09:14 PM, Simon Eugster wrote: I thought it would be enough to just search for the map ID in a .img file and replace it by a new one. Well, after some research I found out that this is not true. http://svn.parabola.me.uk/mkgmap/trunk/src/uk/me/parabola/img

Re: [mkgmap-dev] Splitter details question

Hi WanMil, > What do you mean with "at import of osm files"? The Osm5XmlHandler does > not clip things, does it? Osm5XmlHandler does a "soft clip" - what I mean by that is it adds nodes to ways where they intersect the tile's boundaries. This is only for lines, not areas. By adding those bounda

Re: [mkgmap-dev] Splitter details question

> >> 2nd: Ways should be included if they intersect the bounding box. >> For me it would be perfect if ways are included with all nodes. But it >> is also ok if all inner nodes and for all parts of the way the first >> node out of the bounding box is included. This enables me (and others) >> to cal

Re: [mkgmap-dev] Splitter details question

> 1) determine where the tile boundaries lie, based on the distribution of > nodes in the osm file. None of these tiles will overlap. > 2) for each node, determine which tile (or tiles) it belongs to. A node is > considered to belong to a tile if it falls anywhere within the tile itself > OR th

Re: [mkgmap-dev] Split barrier=* and traffic_calming=* to a separate layer?

I'd also think that the multi-layered approach would add a whole new level of complexity to mkgmap. And it is a feature that no official Garmin map has ever used AFAIK. You even get different results depending on your MapSource *version*. So I don't think it is a something that should be built i

Re: [mkgmap-dev] Splitter details question

> I've investigated doing this in the past however it's very tricky to do > correctly > without having a huge impact on performance and/or memory requirements. I > do have one idea that might work without too much slowdown. If I was to build > up a big disk index of all nodes (there is already

Re: [mkgmap-dev] Splitter details question

> 2nd: Ways should be included if they intersect the bounding box. > For me it would be perfect if ways are included with all nodes. But it > is also ok if all inner nodes and for all parts of the way the first > node out of the bounding box is included. This enables me (and others) > to calcul

Re: [mkgmap-dev] Map ID: In-file replacing

On 01/13/2010 09:14 PM, Simon Eugster wrote: > I thought it would be enough to just search for the map ID in a .img file > and replace it by a new one. Well, after some research I found out that > this is not true. > http://svn.parabola.me.uk/mkgmap/trunk/src/uk/me/parabola/imgfmt/app/trergn/Map

[mkgmap-dev] Map ID: In-file replacing

Good evening, I thought it would be enough to just search for the map ID in a .img file and replace it by a new one. Well, after some research I found out that this is not true. http://svn.parabola.me.uk/mkgmap/trunk/src/uk/me/parabola/imgfmt/app/trergn/MapValues.java I tried to check out TreCal

Re: [mkgmap-dev] Splitter details question

W> ok, I understand. W> For me it's no problem if points that fall outside the bounding box W> are included in the tile. They can be easily filtered. W> I have the following requirements: W> 1st and most important: All nodes that fall inside the bounding box W> should reliably be contained i

Re: [mkgmap-dev] Split barrier=* and traffic_calming=* to a separate layer?

On Wed, Jan 13, 2010 at 05:00:36PM +0100, Torsten Leistikow wrote: > I do not think, that a set of such scripts should be included into mkgmap. > It is too much overhead for the different style developer to keep their > scripts in the mkgmap repository up to date. You may be right. I was about to

Re: [mkgmap-dev] Split barrier=* and traffic_calming=* to a separate layer?

Marko Mäkelä schrieb am 13.01.2010 10:05: > I am not suggesting that mkgmap should generate multi-layered maps by default. > What I would like to have is a simple set of scripts and styles that users > could adapt. Currently, several people have built multi-layered maps and > many have not release

Re: [mkgmap-dev] Garmin

On 13.01.2010 11:42, Mark Burton wrote: > Hi Felix, > > >> set "TRE 0-4-23" and it might work. >> > Err, sorry to be thick but where is this set? > You told it once to me I think, or at least how to write the values. Here is the patch I'm using currently because of some problems

Re: [mkgmap-dev] Garmin

Hi Felix, > set "TRE 0-4-23" and it might work. Err, sorry to be thick but where is this set? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Garmin

On 12.01.2010 01:12, Markus wrote: > Dear professionals, > > Mark has made a very nice nautical chart for www.OpenSeaMap.org > > It works very well on handhelds! > > Next week we will exhibit OpenSeaMap on the boa

Re: [mkgmap-dev] Split barrier=* and traffic_calming=* to a separate layer?

Hi Charlie, > > I was wondering if it would be worthwhile to split all barriers > > (fences, gates, bollards, whatever) and traffic_calming to a separate > > layer? These objects are not usually searched for or routed to, and > > they are not relevant for navigation much of the time. > To an exte

Re: [mkgmap-dev] Split barrier=* and traffic_calming=* to a separate layer?

Marko Mäkelä wrote: > Some time ago, I faced some opposition against adding this to > styles/default/points: > > +traffic_calming=* [0x6614 resolution 21] > > I was wondering if it would be worthwhile to split all barriers > (fences, gates, bollards, whatever) and traffic_calming to a separate >

Re: [mkgmap-dev] Splitter details question

Hi WanMil, W> ok, I understand. W> For me it's no problem if points that fall outside the bounding box W> are included in the tile. They can be easily filtered. W> I have the following requirements: W> 1st and most important: All nodes that fall inside the bounding box W> should reliably be contai