The type you've picked for tunnels (0x11501) is not routable.
On 11 Dec 2012, at 21:24, "Geoff Sherlock"
wrote:
> I decided I wanted to show bridges and tunnels on my maps; bridges were easy
> but I have trouble with tunnels.
>
> If I try the following as a catchall for all highways which a
On 10 Dec 2012, at 15:32, Steve Ratcliffe wrote:
>
>
> What sub-options to generate-sea does everyone use? Are the defaults
> most likely to result in an un-flooded map or does it depend too much
> on which part of the world you are creating a map for?
>
> .
I use
generate-sea:polygons,exte
On 27 Oct 2012, at 09:26, Minko wrote:
> I understand it is not good tagging but please help me to tell Potlatch they
> are wrong:
> https://trac.openstreetmap.org/ticket/4510
>
> If I change it to correct tagging there will be someone else who notice this
> as "Lake" and again tag it to wa
On 28 Aug 2012, at 11:36, Felix Hartmann wrote:
> Well it's quite a long time, there has been no discussion about this,
> however it's more and more common to put the unit into the main key.
> Could mkgmap do a clean up on this?
>
> It would be great if mkgmap could do the following:
> Remov
You might be interested in my style and typ files which capture a lot of the
elements you're after:
http://www.cferrero.net/maps/map_downloads.html
On 27 Jul 2012, at 04:07, Jaromír Mikeš wrote:
>> Od: Marko Mäkelä
>
> Hi Marko,
>
>>> Marko, is somewhere some kind of chart which shows symb
--generate-sea:polygons on the other hand creates a land
polygon which you can specify in a TYP file, which is much nicer. :)
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 18/02/2012 18:14, toc-rox wrote:
> This works for me:
>
> generate-sea:multipolygon,no-sea-sectors,extend-sea-sectors,close-gaps=5000,land-tag=natural=land
>
> Klaus
>
> --
>
Yes, multipolygon works fine, but I need the polyg
On 18/02/2012 01:02, WanMil wrote:
> Hi Charlie,
>
> I have no idea yet.
>
> I think there are only two commits that may be relevant:
> r2163 and r2168.
> It would be great if you can retry with r2163 to narrow down the
> problem. You might also upload the OSM data o
On 18/02/2012 01:02, WanMil wrote:
> Hi Charlie,
>
> I have no idea yet.
>
> I think there are only two commits that may be relevant:
> r2163 and r2168.
> It would be great if you can retry with r2163 to narrow down the
> problem. You might also upload the OSM data o
ackground
Can someone see what bug was introduced?
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Weird that it gives the option to avoid roundabouts. I would have thought
people would want to do the opposite (ie *prefer* roundabouts).
On 11 Feb 2012, at 14:17, toc-rox wrote:
> BaseCamp 3.3 offers some new features concerning routing:
>
> http://gis.19327.n5.nabble.com/file/n5474741/Routi
Under the default style they will all be drawn as lines. Ideally the polygons
would also have an area=yes tag and you could test for this with a custom style
rule. The same problem occurs for man_made=pier.
On 3 Feb 2012, at 12:obl42, Roger Calvert wrote:
> The OSM data for the Lake District
On 14 Jan 2012, at 03:03, Richard Hansen wrote:
> On 2012-01-13 17:48, Roger Calvert wrote:
The order of options intentionally matters. Options only affect files
that follow them on the command line (or within a command file). So I
don't think that there is a bug there.
>>>
>>>
e-on-left or drive-on-right be set on a per-tile basis e.g.
mapname:63240001
description=UK
drive-on-left
input-file=63240001.osm.gz
mapname:63240002
description=France
drive-on-right
input-file=63240002.osm.gz
Is this currently possible?
--
Charlie
___
On 11 Dec 2011, at 04:43, steve sgalowski wrote:
> converted a pbf file to osm with convert osm and pbftoosm the file size = 20
> gb in size after a 937 mb pbf file
> but when i go to split the 20 gb file into smaller parts before combining
> with mkgmap to img file .
> the splitter has a ma
On 17 Nov 2011, at 17:10, Adrien ANDRE wrote:
>
>
> Le 17/11/2011 08:58, Charlie Ferrero a écrit :
>>
>>
>> On 17 Nov 2011, at 15:50, Adrien ANDRE wrote:
>>
>>> Hi everybody,
>>>
>>> i'm trying to load custom polygons to
On 17 Nov 2011, at 15:50, Adrien ANDRE wrote:
> Hi everybody,
>
> i'm trying to load custom polygons to Garmin GPS using ogr2osm and mkgmap.
>
> The problem is that i can't see my polygons on the GPS maps.
> However, everything is OK with a downloaded OSM file.
>
> Here is the script i use :
On 16 Nov 2011, at 14:42, Steve Hosgood wrote:
> On 2011-07-30 13:41, WanMil wrote:
>> Hi,
>>
>> I have created a short HowTo in the wiki for first time users:
>> http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map
>>
>
> A suggestion for an addition to this page:
>
> Please put i
Greg Troxel (g...@ir.bbn.com) wrote:
>
> I've been using Charlie Ferrero's TYP file. Generally I really like it,
> and I can't imagine going back.
> But I have two issues:
>
> There isn't open source code to create TYP files from representations
> th
If there are maxspeed tags they are used to set the road speed, overriding the
default values (that are defined by the highway class and the style rules)
On 20 Oct 2011, at 15:51, Henning Scholland wrote:
> Hi WanMil,
> could you explain, what mkgmap do with maxspeed-tagg?
> I haven't care abou
You can find a traffic light symbol in my typ file at
cferrero.net/maps_index.html
On 11 Oct 2011, at 06:03, Kimon Berlin wrote:
> On 10/10/2011 5:30 AM, Carsten Schwede wrote:
>> Hi there,
>>
>>
>> Am 10.10.2011 00:04, schrieb svn commit:
>>> This patch lets you set --code-page=932; with it,
u can see how the POI for the hotel is being
placed outside the boundary of the hotel polygon.
-- Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
.
I would really like to see this bug fixed as it can add many duplicate
POIs to a map.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ld certainly agree with you on the addr: tags; the way it is
currently done internal to the mkgmap code is a little confusing and
it would be much more flexible if the address treatment was moved to
the points style file.
Not sure about addr:phone though - isn't this deprecated and instead
On 02/08/2011 01:18, Peter Lerner wrote:
>
> Zsolt,
>
> ...
>> What am I doing wrong? If you need any more detail I'd be glad to
>> provide it.
>
> not an answer to your problem, but a question to the list:
>
> Do we have a bugtracking tool that we can use to document software problems?
>
> Peter
>
routes are being specified in the OSM
data, but it strikes me that the most generic solution would be to
create your own TYP file which contains ways with the correct offset,
and combine this with new rules in mkgmap's lines and/or relations style
files. I think Felix Hartmann does this
otorway_junction could be used,
irrespective of how the ramp was labelled.
On 14/07/2011 14:07, Felix Hartmann wrote:
> If you use the default style, it should be automatic (if it's a ramp,
> then the name of the street behind will be, so it is exit to Street B,
> instead of drive on Street
Hello list,
Is there any way to get mkgmap to embed exit refs (where they exist) in
the routing directions, so that instead of getting:
"Exit right onto ramp" you get
"Take exit 32 right onto ramp" or something similar?
Is this something that official Garmin maps
On 11/07/2011 04:51, maning sambale wrote:
> Dear steve,
>
> Here's a bit of explanation from one of our colleagues.
>
>> So can you explain exactly what is better and worse between the
>> city-region-index branch r1867 and r1870.
>
>> Do the different "San Fernando's" have different regions? If no
On 04/07/2011 12:50, Bill Lancashire wrote:
> Charlie, thanks for your response.
>
> I have been doing a few controlled tests and I am now fairly sure that
> it is the GPSMap62s that will not display the 'extended' polygon codes.
>
> What I did was to compile a map us
/99899455)
name=Khalidiya Palace Tower C
building=yes
In Mapsource (6.16.3) these labels render differently (see attached).
Building 1 renders as Khalidiya Palace Tower a
Building 2 label renders as Khalidiya Palace Tower C
Is this a bug in mkgmap or a bug in Mapsource?
--
Charlie
* [*?*], Drawing order: *3 **(Placeholder only)
>
> *Then follows Drawing Level 4 with codes 0x02, 0x03 etc.
>
> Any ideas on this please?.
Bill,
If you can post a link to a small gmapsupp.img file (including your
TYP), we can try it on our own devices and see if this i
]
place=state [0x1400 resolution 16]
place=county & population > 50 [0x1400 resolution 16]
place=island [0x1e00 resolution 16]
place=suburb | place=municipality | place=district [0x1e00 resolution 20]
place=locality [0x1e00 resolution 23]
--
Charlie
_
On 09/06/2011 23:09, WanMil wrote:
> If addr:street is not set the addr:housename tag is used as proposed by
> Charlie.
>
> The patch is for the trunk and not for the locator branch.
>
> WanMil
>
>
>
The patch works! Thanks for this.
Charlie
___
On 06/09/2011 11:09 PM, WanMil wrote:
If addr:street is not set the addr:housename tag is used as proposed
by Charlie.
The patch is for the trunk and not for the locator branch.
WanMil
I've tried to apply this patch to r1968 by copying it into the root
directory, then typing
tive to individual addr:street, addr:housenumber
>> etc.
>
> I wonder how to achieve that. The garmin format has some address fields
> like street, zip, city, region, country (and housenumber - but we don't
> know how to code it?!). All information must be put into these fields.
> Do you have an idea how to convert addr:full into this schema?
I would suggest that you either parse addr:full (harder, more error
prone) and split it down to fields, or just shove it all into
addr:housename (if there is no character limit).
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
heir new catalogue to all domestic residences and it
actually made national news as the sheer logistics of trying to do
this when you don't actually know what all the domestic residences are
was considered newsworthy!
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
addition of processing of the addr:full tag if that is
present as an alternative to individual addr:street, addr:housenumber
etc.
Just my two fils worth...
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
a?
>
> Best regards,
>
> Marko
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Charlie
___
g. This way, when browsing the
map you see the display road (because it's wider), but when the
routing instruction pops up you see road styles that correspond to the
overall map style, rather than thin grey lines.
--
Charlie
_
Torsten Leistikow (de_m...@gmx.de) wrote:
> Charlie Ferrero schrieb am 28.04.2011 09:46:
>> Why is the warning correct? The wiki says that a boundary multipolygon
>> can contain a node tagged admin_centre. Isn't this mkgmap warning a
>> false positive?
>
> Actual
ry Cottage
London
A workaround to this bug is to use the following additional style rule
in the points file:
addr:housename=* & addr:housenumber!=* & addr:street!=* {set
addr:housenumber= '${addr:housename}'}
But obviously fixing the bug would be nicer.
How big is it?
On Thu, 28 Apr 2011 23:52:15 +0400, mkgmap-dev-boun...@lists.mkgmap.org.uk
wrote:
>
> > With a boundsdirectory it went fine. I haven't paid attention to the
> > performance, with a few tiles it was ok I guess. I'll try to compile the
> > whole Benelux end of this week and compare
On 28/04/2011 14:32, Dominik Röttsches wrote:
[snip]
>> I have a vague recollection that it is also possible to get the splitter
>> to ignore the bounds in the input file.
>
> Any more thoughts on this coming back in the meantime?
>
> Dominik
It's definitely possible in mkgmap using --ignore-osm-bo
until I have finish correcting
> all other multipolygon errors detected by mkgmap.
Why is the warning correct? The wiki says that a boundary multipolygon
can contain a node tagged admin_centre. Isn't this mkgmap warning a
false positive?
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 26/04/2011 21:00, Dominik Röttsches wrote:
> Hi,
>
> I created a merged map using osmosis:
> $ ./osmosis --rb finland.osm.pbf --rb germany.osm.pbf --rb us-west.osm.pbf
> --merge --merge --wx DE_FI_USW.osm
> which results in an uncompressed XML output map DE_FI_USW.osm of ~36G in size.
>
> So th
:
Frankie's
Fix My Address
Abu Dhabi
+971 2 654 3238
Whereas I would have expected it to say:
Frankie's
Fairmont Bab al Bahr
Abu Dhabi
AE
+971 2 654 3238
Does mkgmap ignore addr:housename? What about addr:full and
addr:housenumber...?
Thanks,
-
, region
specific (i.e. out here only motorway, trunk and primary/secondary
roads have refs, and even then not all of them do, in fact most of
them don't).
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Mon, 4 Apr 2011 10:11:18 +0300, mkgmap-dev-boun...@lists.mkgmap.org.uk wrote:
> On Sun, Apr 03, 2011 at 09:20:55PM +0200, WanMil wrote:
> >Based on the proposal of Ralf Kleineisel the patch tries to cut
> >multipolygons at multiples of 2048 in Garmin coordinates. This
> >reduces artefacts at
Hi,
Currently via ways are not used by mkgmap to generate turn restrictions.
Is this a limitation in the mkgmap code base, or a fault of the
underlying Garmin routing data model? If the former, are there any
plans to add support for via ways?
--
Charlie
ccept address information. As a rule
of thumb, assume that the only type codes that can are in the range:
0x2a00 to 0x32ff
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
e.
>
> The algorithm in general would be:
> - Increase all polygons/lines with a outline.
> - Check all increased polygons, if some of them overlap.
> - If so, merge the original version of them.
>
> But I expect this to be a really resource hungry task.
>
> Rega
On 25/03/2011 17:17, Steve Ratcliffe wrote:
> Hi
>
> There is a new branch for an overhaul of the options. There are a
> number of recent (and not so recent!) posts about options that are
> badly documented, have the wrong defaults or just plain shouldn't
> exist.
>
> The first couple of things I p
the maps it is applied to.
The styles create routeable, single layer maps, with variable road
thicknesses depending on zoom.
Screenshots of the CF_Mapsource style in action are here:
http://www.cferrero.net/maps/screenshots_index.html
--
Charlie
___
going on with the national border around
Sardinia:
http://www.cferrero.net/maps/img/sardinia.png
And with the Isle of Man and the Lake District National Park in the UK:
http://www.cferrero.net/maps/img/lake_district.png
mkgmap r1893, by the way.
--
Charlie
ap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
Here's an old post to this list on the subject:
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg01509.html
--
Charlie
___
mkgmap-dev mail
very error
relating to roundabouts and their flare roads appear in triplicate. I'm
not sure when this started, but it definitely didn't use to happen.
Have the numerous recent changes resulted in these checks being called
three times per object by acc
Torsten Leistikow (de_m...@gmx.de) wrote:
> Ralf Kleineisel schrieb am 08.03.2011 18:09:
>> Lines file:
>> junction=roundabout & highway=secondary [0x11f02 road_class=2
>> road_speed=3 level 4]
>>
>> Overlays file:
>> 0x11f02: 0x0c, 0x04
>>
>> Then I created a test typ file with a very broad pink
should have been, or because it was open in another programme locked
for access, or because it had the wrong family ID. Just a thought.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
he
moment I have buildings set to appear at resolution 24, but some huge
buildings (malls, conference centres) are big enough to be sensibly
displayed at resolution 23 and this patch would avoid displaying lots
of specks for the normal hous
on via
halfpipes? ;)
Also, you might want to include a few polygon lines to capture those
man_made features that are actually areas, e.g.
man_made=pier & area=yes [0xyourPolygonCode resolution 24 etc]
--
Charlie
___
mkgmap-dev m
ule to account
for this type of case:
man_made=pier & area=yes [etc]
Though this depends, of course, on someone tagging the pier properly.
A mkgmap error message would help me to identify where this hasn't
been done.
--
Charlie
ted ability to compile patched versions of mkgmap. If you
can share a jar file I can give it a test.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 22/02/2011 23:50, WanMil wrote:
> Hi Bill,
>
> which patch do you mean? Can you give a link to it?
>
> WanMil
>
This might be what he's referring to:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007920.html
___
mkgmap-dev mailing list
mkgmap-de
On 21/02/2011 11:42, Felix Hartmann wrote:
>
>
> On 21.02.2011 07:09, Charlie Ferrero wrote:
>> On 21/01/2011 18:17, Felix Hartmann wrote:
>>>
>>> On 21.01.2011 15:12, char...@cferrero.net wrote:
>>>> Minko (ligfiet...@online.nl) wrote:
>>
using Mapsource 6.16.3, my base map has mapname 63247001 and the
contour tiles are 63247201-63247209, compiled with higher draw priority
and --transparent
The levels definition in both basemap and contours is
levels = 0:24, 1:23, 2:22, 3:20, 4:18, 5:16
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
=fence [0x?? resolution 23 continue]
This enables the landuse to be processed by the polygons style file
subsequent to the lines processing.
You can see a working example of this in this screenshot:
http://www.cferrero.net/maps/shot_AD_detail2.html (park with wall around
the outside).
--
Charli
seful for navigation when trekking
(e.g. towers, lighthouses etc) and obstacles to walking (fences, hedges,
ditches).
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
a
default style that is suitable for all uses (hiking, cycling, driving,
tourism etc).
Have you tried one of the "out-of-bounds" codes around the 0x2b area?
Maybe 0x2b06 or 0x2b07 (tent icon) or 0x2b08 to 0x2b1f (green/white
bed)?
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ben Konrath (b...@bagu.org) wrote:
> Hi Charlie,
>
> On Mon, Jan 31, 2011 at 8:35 AM, wrote:
>> Sorry, can't help with your problem, but can you explain what
>> --ignore-unnamed-areas is? I can't find any reference to it elsewhere.
>
> That's a custom
gt; --product-id=1 --generate-sea=extend-sea-sectors,multipolygon
> --make-all-cycleways
> -c template.args --description=ALL
>
Sorry, can't help with your problem, but can you explain what
--ignore-unnamed-areas is? I can't find any reference to it elsewhere.
--
20100207/b6f54347/attachment.bin
Also available here:
http://www.cferrero.net/maps/map_downloads.html
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
e contourlines.
>
No way! Is this why I can't get contour lines to display in MapSource
(even though I know they're there because I can see the contour
elevation labels)??? I'd given up on ever getting contours to work
properly in MapSource. Prize for obscurest workar
polygon code starts.
The only way I can currently solve it is to remove the surface=sand rule
completely, which I don't want to have to do.
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
resolution 20]
Nor does
natural=coastline & surface=sand {delete surface}
make any difference whether I put it in the lines file or the polygons file
Does anyone have a suggestion on how to fix this?
Thanks!
--
Charlie
___
mkgmap-dev mailin
; elev/*.osm - elevation contour in 133 osm files (1,6G)
>
> I try to delete one of any elev file - mkgmap work without error. Or
> I use old
> osm data file (2-3 month age) with less data - mkgmap work.
>
> p.s. mkgmap: 1749, 1733, 1727.
maning sambale (emmanuel.samb...@gmail.com) wrote:
> @Charlie,
>
> That is correct, but in the case of the name below, this is what I saw
> on the ground (street sign).
>
Fair enough - but how is your GPS supposed to know that E stands for
Eulogio??? In fact, forget the dumb GP
quot;St. Thomas" which should be "Saint Thomas" was announced as
> "Street Thomas"
> - "E. Rodriguez" which should be "Eulogio Rodriguez "was announced as
> "East Rodriguez"
And for this very reason the OSM map
Felix Hartmann (extremecar...@gmail.com) wrote:
[snip]
>
> --- in principal there is no speed advantage - [snip]
Maybe it's just me, but I find the polygon version of generate-sea
much faster than the multipolygon version - at least twice as fast if
not more.
around the park just fine.
Looking at your style file, your lines rules explicitly doesn't apply a
wall to any object which also has the landuse tag set, which is probably
why it isn't working for you.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 04/12/2010 09:48, garvan&maew wrote:
> When I create a map of Cambodia with the default style I get garbage in
> the boundary names (a mixture of Thai and other regional script which
> will not display correctly). Looking at the data I can see that this
> comes from the name tag so I need to sel
e multipolygon and add-pois-to-areas code. WanMil posted a
couple of days ago saying that it was going to be harder than he
initially thought to fix, as the --add-pois-to-areas works on Garmin
objects, rather than OSM objects.
--
Charlie
___
mkgma
On 18/11/2010 00:50, Chris66 wrote:
>>> Another possible reason: The MP Code splits the MP to several
>>> "normal" polygons (without holes), each getting a POI. But this
>>> is just a guess.
>
>> Can anyone confirm this? (I don't read code sorry)
>
> Hi, I created a test file with one park and one
On 15/11/2010 01:11, Adrian wrote:
> On 14/11/2010, Charlie Ferrero wrote:
>> 3. Compiled with mkgmap r1728 with your patch, using:
>> generate-sea:multipolygon,extend-sea-sectors,close-gaps=1000
>> No sea, entire map is land
>
> Have you put the drawing order of sea a
On 14/11/2010 04:40, Adrian wrote:
> On 5/11/2010, Charlie Ferrero wrote:
>> One improvement would be for the --generate-sea:mp version to imitate
>> the non-mp version in that a land polygon is generated to overwrite
>> the ugly Garmin yellow base colour.
>>
>> T
work though
>> (at least, I don't use mp version of generate-sea so I don't know
>> either way).
>
> I'm using generate-sea=extend-sea-sectors.
>
> Chris
Maybe it's no-sea-sectors then...?
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ted sea
tiles like this. I think it might be extend-sea-sectors. You might
have to use the polygons version of generate-sea for it to work though
(at least, I don't use mp version of generate-sea so I don't know
either way).
--
Charlie
___
On 04/11/2010 22:52, WanMil wrote:
> Hi all,
>
> I have started to rework the sea generation code. There have been
> several reports of problems with flooded tiles in the last weeks so I
> think it is neccessary to improve some parts of it.
>
> The first thing I've started is to implement a flooded
. Right?
>
> bye
Are you sure that the GPS won't try to route even when there is no
routing info in the map? I've got a vague memory (back when I didn't
know how to create a routable map) that my GPS still offered the
option to route to a POI even without routing info
Lambertus wrote:
> On 2010-10-14 06:10, Charlie Ferrero wrote:
>> Peter Hendricks wrote:
>>> Hi all,
>>>
>>> I would like to report what looks like a style sheet problem. I'm using
>>> Lambertus' Garmin map from http://garmin.na1400.info/r
{operator}' } [0x2f01 resolution 19 ]
Unfortunately, as I understand it Lambertus is keen to stick with the
default style.
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
in. Your spreadsheet would be even more useful if it showed
whether a Garmin type was searchable and if so, what category it appears
in. You can use my spreadsheet for this.
Finally finally finally (!) - what is column O? It looks like the zoom
level mapping for Garmin POIs. If so, then this information isn't that
useful as it's arbitrary (though carefully selected).
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
closed polygon.
If, so, then this code could be re-used and --add-pois-to-areas could
be run before the style file processing. Whilst I'm helpfully palming
off work to others more skilful than myself, could whoever does this
also add some logic to make sure the resultant POI is always place
?
Either way, the current code omits a fair number of multipolygons due
to not catching appropriate tags.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
end it
> covers teh same area).
>
> Gruss
> Torsten
OK, but in practical terms if mkgmap generated a nature reserve
polygon, a wood multipolygon and an inner water polygon, wouldn't the
visible results be undefined? In other words, you could end up with
either:
a)
> multipolygon relation: natural=wood and outer=polygon A and inner=polygon B
> (only the surrounding area)
>
> Right now polygon A seems to be missing in the resulting map.
>
But how would mkgmap know which of the two outer polygon types to use
(ie nature reserve or wood)?
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
treetmap.org/wiki/Tag:natural%3Dwater)
doesn't mention it.
Also, the multipolygon "usage" section on the wiki
(http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states:
"The direction of the ways does not matter"
--
Charlie
_
ese mps wrongly as I created them...can
someone point out my error? I'm sure it'll be a "doh" moment for me.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
transpatent \
> elev/*.osm \
> topo.TYP
>
> But map not transparent. In GMapTool i see that map not have T flag.
> I test in
> in 1673 and 1699.
> ___
Hi,
It's --transparent, not --transpatent
--
Charlie
___
ect whether something is a closed polygon or not,
which would make it much more robust in these instances.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
1 - 100 of 266 matches
Mail list logo
