Re: [mkgmap-dev] Routing and tunnels
The type you've picked for tunnels (0x11501) is not routable. On 11 Dec 2012, at 21:24, Geoff Sherlock geoffrey_sherl...@btinternet.com 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 are tunnels: highway=* tunnel=yes [0x11501 road_class=0 road_speed=1 resolution 23] Or specifically for each type of highway e.g.: highway=cycleway tunnel!=yes [0x10 road_class=0 road_speed=1 resolution 23] . . . . . . highway=cycleway tunnel=yes [0x11501 road_class=0 road_speed=1 resolution 23] The visual results are what I expect: you see the cycleway, then the tunnel, and then the cycleway again. But routing is broken and you are unable to route through the tunnel for any type of highway. If however I do the following: highway=* tunnel=yes [0x11501 resolution 23 continue] . . . . . . highway=cycleway [0x10 road_class=0 road_speed=1 resolution 23] I see both the tunnel and the cycleway, rather than just the tunnel, but at least I can route through the tunnel. So it seems if you have the test tunnel=yes it breaks routing. Is this expected behaviour? I am using R2328. Cheers, Geoff. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Options
On 10 Dec 2012, at 15:32, Steve Ratcliffe st...@parabola.me.uk 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,extend-sea-sectors,close-gaps=1000,land-tag=natural=background Never had flooding in this part of the world (Middle East) ... but maybe that's because it never rains. ;) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] render closed waterway polygons?
On 27 Oct 2012, at 09:26, Minko ligfiet...@online.nl 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 waterway=canal. There are dozens of mappers who are making this mistake and I'm tired of writing them or correcting them all. In general maybe it would also help to add the way-id to problematic_polygons list. So mkgmap has the hole way and there is no need to autoclose a way. That is not the point. The point is that correct waterway=canals which are single lines are being closed too if I render it as polygons. I can think of other forms of lines that could either be polygons or lines. Think of highway=pedestrian or man_made=pier so I think this patch can help. Isn't the area=yes tag designed to help differentiate in these cases? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mp/hh / km/h m or other units in maxspeed or distance keys
On 28 Aug 2012, at 11:36, Felix Hartmann extremecar...@gmail.com 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: Remove any non numeric keys (and not . or , ) and place them into a new key called mkgmap:unit= Do this for maxspeed, distance, height, width (propose other keys I may have missed). As I'm sure this would take quite some time, it should be an option, and there should be a style-file called units_removed where you can specify the keys for which mkgmap should do this. Of course an implementation of automatically translating mp/h to km/h and other things would be great to have too, but the above is IMHO first of main importance. The problem is simply that commands like maxspeed50 or distance10 don't work otherwise. -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org Isn't this a problem with the OSM data entry that would be better solved by a bot working on the data? Or are you just looking for a pragmatic solution through mkgmap? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Distributing TYP file sources with mkgmap
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š mira.mi...@seznam.cz wrote:
Od: Marko Mäkelä marko.mak...@iki.fi
Hi Marko,
Marko, is somewhere some kind of chart which shows symbols used by
mkgmap default style?
Uh, isn't that the default style? In the mkgmap source code, it is in
resources/styles/default/{points,lines,polygons}
Of course ;)
I started splitting the default style into sub-styles, but did not
complete the task yet. Currently there are a few sub-styles:
contours_ft
landuse
waters
As I said before I am mainly interested in hiking do you thinking to make
dedicated style fo that too?
Would be great.
Meanwhile I am working on TYP file ( which is also hiking oriented) I found
few troubles for me:
POIS
tourism=attraction and tourism=viewpoint ... both same symbol 2c04
Can get different?
tourism=alpine_hut tourism=hostel ... both same symbol 2d02
Can get different?
tourism=campsite tourism=caravan_site ...both 2b03
Can get different?
tourism=basic_hut missing
man_made=cairn
LINES
natural=cliff missing
POLYGONS
natural=beach | natural=sand ... missing
natural=scree missing
landuse=meadow | natural=fell ... missing
wood=mixed
wood=deciduos | wood=deciduous
wood=coniferous
Would be also great to have possibility recognize vegetation.
Do you it is possible to add this to mkgmap styles?
One question about copyright field in TYP file ...
Few commented-out lines in top of typ.txt file is fine way how to do it?
best regards
mira
___
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
Re: [mkgmap-dev] generate-sea:polygons broken between mkgmap r2160 and r2168
toc-rox (easyclassp...@googlemail.com) wrote: I have experimented with polygons in the past but this was unsuccessful. May be due to the problem you have found yet. Could you explain the basic difference between multipolygon and polygons ? And what is the advantage of polygons ? Thanks - Klaus The advantage is quite specific, but for older GPS units where you cannot change the background polygon colour, --generate-sea:multipolygon creates maps which display land as Garmin yellow. --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
Re: [mkgmap-dev] generate-sea:polygons broken between mkgmap r2160 and r2168
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 of your tile so that I or someone else can do some debugging to find the problem. WanMil Can you send a link to r2163? http://www.mkgmap.org.uk/snapshots/ only goes back to r2168 The original OSM files are here: http://cferrero.net/maps/downloads/63251501.osm.pbf http://cferrero.net/maps/downloads/63251502.osm.pbf -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] generate-sea:polygons broken between mkgmap r2160 and r2168
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 polygon version. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] BaseCamp 3.3 and Routing
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 easyclassp...@googlemail.com wrote: BaseCamp 3.3 offers some new features concerning routing: http://gis.19327.n5.nabble.com/file/n5474741/Routing-BC33-1.png http://gis.19327.n5.nabble.com/file/n5474741/Routing-BC33-2.png http://gis.19327.n5.nabble.com/file/n5474741/Routing-BC33-3.png How is it possible to take advantage from this features ? Klaus -- View this message in context: http://gis.19327.n5.nabble.com/BaseCamp-3-3-and-Routing-tp5474741p5474741.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ 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
Re: [mkgmap-dev] mkgmap command-line argument parsing bugs
On 14 Jan 2012, at 03:03, Richard Hansen rhan...@bbn.com 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. Ah, that's good to know. So the bug is that this behavior is not documented in '--help=options'. :) Does that mean that it does not 'return' after reading a -c, so that only one -c can be used? If I understand Steve correctly, multiple -c arguments should work. I've never tried it so I don't have any first-hand experience. -Richard According to a recent post on the OSM forum, multiple -c do work and thus offer a convenient way of calling both a relatively unchanging options file and a potentially frequently changing file list in the template.args. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter
On 11 Dec 2011, at 04:43, steve sgalowski steve.sgalow...@gmail.com 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 major failure in the main section . any ideas appreciated Stephen __ You can split PBF files in splitter. Have you tried that? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Load custom polygons to Garmin GPS using ogr2osm and mkgmap
On 17 Nov 2011, at 15:50, Adrien ANDRE adrien.andr...@gmail.com 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 : python ogr2osm/ogr2osm.py polygons-4326.mif bzip2 -k -f polygons-4326.osm # wget http://download.geofabrik.de/osm/europe/france/guyane.osm.bz2 python pyMkgmapGarmin/pyMkgmapGarmin.py \ polygons-4326.osm.bz2 guyane.osm.bz2 Does anybody know why ? Thanks in advance, Regards Adrien ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev What style are you using and what type codes are these custom polygons being assigned to? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Load custom polygons to Garmin GPS using ogr2osm and mkgmap
On 17 Nov 2011, at 17:10, Adrien ANDRE adrien.andr...@gmail.com wrote: Le 17/11/2011 08:58, Charlie Ferrero a écrit : On 17 Nov 2011, at 15:50, Adrien ANDREadrien.andr...@gmail.com 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 : python ogr2osm/ogr2osm.py polygons-4326.mif bzip2 -k -f polygons-4326.osm # wget http://download.geofabrik.de/osm/europe/france/guyane.osm.bz2 python pyMkgmapGarmin/pyMkgmapGarmin.py \ polygons-4326.osm.bz2 guyane.osm.bz2 Does anybody know why ? Thanks in advance, Regards Adrien ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev What style are you using and what type codes are these custom polygons being assigned to? __ None, i thought the mkgmap default style would be OK... ___ Well it's hard to say. How are these custom polygons tagged? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Short mkgmap HowTo
On 16 Nov 2011, at 14:42, Steve Hosgood st...@stoneship.org.uk 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 in details of how to get MapSource to install at all! I tried to install 6.16.3 on my Vista box, but all I got was a message Previous MapSource not found! Setup will terminate. Which it did! Leaving me with no MapSource. I'm eager to have a play with it in order to get the address-search stuff working (and maybe to find out how to do that independently) but obviously I need a usable MapSource in the first place. Any ideas please? Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev I just reinstalled windows from scratch and had the same problem. The solution is to install the version of mapsource or trip and waypoint manager that came on a cd with your gps, then update mapsource to the newest version. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Cutting down the default style
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 that are reasonable to edit with free tools and store in version control systems (and be diffable, etc.). Fixing this would let us bring a TYP file into the mkgmap source sanely, and then have a style that matches it. Style files get edited for multiple reasons; one is to match TYP files, and another is catching up with tag usage. I'm not suren if Charlie's style files are be a bit out of date (not complaining; what I have to use for free is awesome), but structurally it would be hard to keep them in sync; I think what's needed is a merger of those and the modern mkgmap style, but I haven't spent the time to really dig in (which is a clue that just using what Charlie publishes is very good - I think my big issue is town boundaries being missing, but even that I'm not sure of). I'm not sure my style files are *that* out of date. ;) The only thing I haven't incorporated is the tweaks necessary to make use of --location-autofill=bounds as there are no usable bounds in my part of the world. So, besides the Free textTYP converter, one path forward could be (and I'm really curious what Charlie thinks here): Check in a TYP file that is intended to provide lots of drawing primitives, and Charlie's TYP is probably a good choice (or at least starting place). Hold our noses while editing it (with the web tools). Have a text file that documents what the codes do alongside it. Have a style file that is aimed at this checked-in TYP, and use the various perl programs (or probably easy to redo in java) to poke the family id into the TYP. I would revive the suggestion made a few months (years?) ago that mkgmap ship with a variety of styles and (if necessary) TYP files donated and maintained by individual style maintainers. Then a given mkgmap user can choose which style is applied at compile-time. To make this more foolproof, you could add a tag to the options part of the style file that told mkgmap that an associated TYP file is required, or else to abort the compilation of the map. But I would leave the default style TYP-free, for simplicity. The default style should, insofar as possible, just work and so avoiding TYPs by default is imho a better idea. In terms of TYP-Text, both TYPViewer and TYPWiz can convert from one format to the other, so the style maintainers can submit a text version and a binary version of the TYP to the codebase. I guess in an ideal world the text version would be the master, and a binary version could be compiled either by the user using mkgmap as needed, or by the toolchain on the mkgmap server for subsequent distribution in the mkgmap.zip. Nick Willink: would you be willing to contribute your code from TYPWiz to make that happen? As you say, a TYP goes hand in hand with a style file and both have to be maintained in synchrony for the system to work. I would be happy to donate my style and TYP (or text equivalent) to the mkgmap trunk and then maintain it, but would first need to remove some POIs that I adapted from Garmin originals (I had no idea anyone used my TYP so never bothered to clear them up). It's by no means the best or most complete TYP/style though: Minko/Liegfietser has also been developing a separate TYP and style and Felix is the master here. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Further reduction of the builtin-tag-list
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 o...@aighes.de wrote: Hi WanMil, could you explain, what mkgmap do with maxspeed-tagg? I haven't care about this and removed maxspeed from all ways in my style-file. Henning ___ 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
Re: [mkgmap-dev] Commit: r2048: This patch lets you set --code-page=932; with it, mkgmap outputs maps with proper Japanese characters
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 ki...@deepskymarines.org 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, mkgmap outputs maps with proper Japanese characters for my Oregon 300. It disables transliteration. I have created a testmap with this option. Please test it on your GPS device. http://openstreetmap.teddynetz.de/latest/new/japan_gmapsupp.img.gz (Probably this file will be not be there for a longer time) It worked for me. I posted a screenshot at http://yfrog.com/kjcg98p. Is your style file available? I was searching for symbols for traffic lights, and could not find them using the test map. Kimon ___ 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
Re: [mkgmap-dev] [PATCH v1] Reimplementation of add-pois-to-areas option
On 05/10/2011 00:48, WanMil wrote: ... and will also tell you where it is uploaded to... ;-) http://files.mkgmap.org.uk/detail/34 (my send button finger is too fast...) WanMil Looking good to me: http://cferrero.net/maps/img/patch.html In the second example you 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
Re: [mkgmap-dev] Too many pois on multipolygon areas
Minko (ligfiet...@online.nl) wrote: I have enabled the add-pois-to-areas option, because this way I can search for a certain tag that is placed on an area like landuse=*, tourism=* or building=yes. But sometimes those pois are cluttering the map, especially if this area is a type=multipoygon relation. Take for example this multipolygon relation: http://www.openstreetmap.org/browse/relation/949481 tourism=zoo is tagged only once on the outer way: http://www.openstreetmap.org/browse/way/61046378 However, the multipolygon function of mkgmap splits this area up in several parts (to render the inner islands, which is fine) but it also creates too many pois by the add-pois-to-areas for this one tourism=zoo area: http://img546.imageshack.us/img546/5763/zoow.jpg I'd like to see just one elephant icon instead of several. Is it possible to execute the add-pois-to-areas action before the multipolygon action takes place? Or is it possible to set some rules in the style file to make some exceptions for areas with type=multipolygon? This is a known issue (http://wiki.openstreetmap.org/wiki/Mkgmap/known_issues#Too_many_POIs_for_a_given_area_that_has_been_split_using_multipolygon_code). WanMil had a look at it a few months back and concluded that there wasn't a quick fix (http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07431.html). 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
Re: [mkgmap-dev] Further possible removals from builtin-tag-list
WanMil (wmgc...@web.de) wrote:
Hi,
I want to remove a long list of tags from the builtin-tag-list by
different actions. The advantage is that specialised styles that do not
need these tags are faster and do consume less memory.
== Tags that are no longer used ==
Tag: osm:id
There are only two references in mkgmap source code: HighwayHook sets
this tag and StyleConverter that reads this tag. I think this is not an
OSM tag but a tag set internally by mkgmap.
If so we should rename it to mkgmap:osmid. Any objections?
Tag: openGeoDB:postal_codes
I haven't found any references in the source code. openGeoDB workout
have been removed with locator branch merge.
== Tags that can be moved to style handling ==
I am thinking about moving some static coded rules (e.g. name of a POI
street is taken from tag addr:street) to the style system as it has
been done with other location items:
mkgmap:street!=* addr:street=* { set mkgmap:street='${addr:street}' }
This has two advantages:
1. Speed improvement for styles that don't use this information. (Marko:
this should help you with your need for speed improvements for special
styles)
2. More flexiblity: If someone likes to use different tags for a POI
street name it is easy to configure that.
Possible downside:
* Little more memory requirement for styles that use address information
The tags to be changed are:
addr:street
addr:housename
addr:housenumber
addr:phone (is currently not used in mkgmap)
phone
is_in
== Tags that are used only if --route is set ==
I am not sure if that's correct. Can someone please confirm that?
access
bicycle
carpool
delivery
emergency
except
exception
foot
goods
hgv
motorcar
motorcycle
psv
restriction
route
taxi
toll
I would 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
phone=* is used to fill the telephone field in the address form?
Just my two fils,
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Resolution/level range, rendering parallel routes
On 19/07/2011 21:46, Jiri Klement wrote: Hi, [1] says that resolution or level range is not supported but in fact it works (tested on gpsmap 62s). It only needs to be written in opposite order (ie 3-1 instead of 1-3). Can you please change it so it works in both ways? It's really a minor issue but it should make it a bit easier for beginners :-) I'll fix the wiki, but I wouldn't know how to re-code mkgmap so that the level or resolution-ranges can be defined in the opposite way. I need resolution range to render parallel hiking routes, like in [2] or in josm plugin routes. Lines for different routes needs to be offset by the same number of pixels in every zoom level so I'm going to generate osm file, that will for every zoom level contain all routes (with different offset that will translate to the same pixel distance). Before I start, is there any easier way to do this in mkgmap? If not, do you think it's useful enough to get it integrated into mkgmap? So I'll try to make mkgmap patch instead of osm file generator... I guess it depends on how those 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 in his openmtbmap, if you want to see a working example of how to do this. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Using exit refs in routing directions
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 can do? -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Using exit refs in routing directions
Using the default style, I get the same thing: Exit right onto ramp. If I changed the OSM data so that the ramp was named Exit 32 then of course the directions would say Exit right onto Exit 32, but I was hoping that the ref=32 from the highway=motorway_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 A). On 14.07.2011 12:05, Charlie Ferrero wrote: 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 can do? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1516/3763 - Release Date: 07/13/11 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index and equally named cities
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 not how do you tell them apart? Out of curiosity, are you using --location-autofill? I've noticed that mkgmap isn't handling region, city and country names properly when location-autofill is used, but haven't quite got to the bottom of it yet. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem Displaying Polygons with Extended Type codes
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 using the 'default' style with r1979 together with a very simple TYP defining only 'leisure=playground [0x24 resolution 24]' (at draw level 7). This displayed correctly. Then I simply edited the 'polygons' file line to read 'leisure=playground [0x10103 resolution 24]' and suitably changed the TYP. In this case the polygon was NOT displayed. In both cases I used only the minimal arguments in the mkgmap compile command line. I will try to put a small GMAPSUPP.IMG online somewhere for others to confirm. Conversely, it would be good if I could test a build that someone else has made using an extended polygon code. Bill. You can download a gmapsupp.img from http://www.cferrero.net/maps/gcc_downloads.html that includes lots of extended type polygons (land background, archeological sites, woods, gardens etc). You can get the TYP that is used 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
[mkgmap-dev] Mysterious capitalisation (or not) of labels
mkgmap, or Mapsource, or Garmin in general, seems to have inconsistent capitalisation of labels. Take the following two buildings: Building 1 (http://www.openstreetmap.org/browse/way/99899451) name=Khalidiya Palace Tower A building=yes Building 2 (http://www.openstreetmap.org/browse/way/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 attachment: khal_pal.png___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem Displaying Polygons with Extended Type codes
On 29/06/2011 01:57, Bill Lancashire wrote: I have recently noticed that polygons assigned codes of the type 0x101xx are not displayed on my Garmin 62s. However, if I open the compiled maps in a package such as GPSMapEdit I can see that the features are indeed compiled correctly in the maps. I am using version r1973 The polygons are correctly defined in a TYP file If I redefine the polygons to alternative unused codes of type 0x2x or 0x3x and also change the code in the TYP file then the polygons are displayed correctly. It does not seem to matter what the Drawing Level is in the TYP file. Non of the 0x101xx types are ever displayed. In the case of Polylines, I have used several codes of the types 0x100xx, 0x101xx and 0x105xx and they are displayed correctly. I am really puzzled by this and would really appreciate any insight into what is happening. At the lower drawing levels in the TYP file I have the following defined: Type *0x4b* [*Background (coverage)*], Drawing order: *1 *Type *0x32* [*Sea*], Drawing order: *2 (Placeholder only) *Type *0x27* [*?*], 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 is a feature of the GPSMap62s, or if there's something else wrong in your compile. Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] display of place names on lower zoom levels
On 27/06/2011 13:12, Minko wrote: On http://forum.openstreetmap.org/viewtopic.php?id=12817 someone reported that the name labels of places disappear too quickly. When I look at the default style, I notice there are some points for improvements: place=city [0x0400 resolution 20] place=hamlet [0x1100 resolution 23] place=suburb [0x0a00 resolution 23] place=town [0x0800 resolution 22] place=village [0x0b00 resolution 24] place=island [0x650c resolution 22] - villages are only shown at level 24 where hamlets are shown one level lower - resolution 23 is mentioned here, although it is not set in the options file: levels = 0:24, 1:22, 2:20, 3:18, 4:16 - all place names are only shown at the highest zoom levels. In my opinion cities should also be visible at levels 18 or even 16? Towns can better be set to 20, villages/suburbs 22 and hamlets 24? Maybe Marko can have a look at this? Cheers, Minko FWIW, I use the following rules for places: # # PLACES # place=capitol | place=capital | capital=yes [0x0100 resolution 16] place=city [0x0200 resolution 16] place=town [0x0800 resolution 18] place=village [0x0b00 resolution 20] place=hamlet [0x0d00 resolution 23] place=country [0x1400 resolution 12] place=region population 100 [0x1400 resolution 16] 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index with Arabic names
The airport POI is http://www.openstreetmap.org/browse/node/26608948 and the name is given as مطار دمشق الدولي Which is how it should be written. Marko Mäkelä (marko.mak...@iki.fi) wrote: On Sun, Jun 05, 2011 at 11:56:40PM +0300, Hosam Arnous wrote: For example, the Arabic name of Damascus International Airport is: مطار دمشق الدولي but it is written in the file osmmap_mdr.img as: أطار دأشق اءدئءح Do you have the OpenStreetMap node or way ID of the airport? Or the map coordinates (lat/lon)? Is the name written correctly in the map data? Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] What's next?
WanMil (wmgc...@web.de) wrote: Hi all, it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk. So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws? WanMil ___ Bear with me, because I haven't tried the locator branch for the reasons I'm about to explain, so my comments may be off the mark... From my perspective, the locator branch as I understand it will not be much use because the area I live in (in the Middle East) has no useful boundary relations that the locator branch could use. It's not necessarily that people haven't got around to adding this information to the OSM database, but often that this information is not publicly available at all. In the UAE, for instance, there is no formal, systematic address system *whatsoever* (it is completely normal here to give your home location relative to local landmarks such as parks, mosques and malls, rather than giving an address. Makes getting home deliveries a nightmare, but that's another story) so we couldn't add data to the database even if we wanted to. Secondly, the need to pre-process OSM data for boundaries using osmosis strikes me as unwieldy and difficult to maintain. I would much prefer if everything could be self-contained in one executable. Thus, in my opinion any merge back into trunk should still preserve the branch algorithms for retrieving address information. In particular, as Felix said a few weeks ago, I would encourage that address info for POIs is gathered from the addr: tags in those OSM objects (which will encourage people to tag POIs with address info) and the locator algorithms are only: a) offered as an alternative or supplementary option to --location-autofill to get address information for POIs; and b) offered as an option to get address information for streets that are typically never tagged with addr: info. Incidentally, one very quick improvement to the branch handling of addr: tags for POIs would be to fix the bug I pointed out a few weeks ago and the 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
Re: [mkgmap-dev] [locator] What's next?
Johann Gail (johann.g...@gmx.de) wrote: available at all. In the UAE, for instance, there is no formal, systematic address system *whatsoever* (it is completely normal here to give your home location relative to local landmarks such as parks, mosques and malls, rather than giving an address. Makes getting home deliveries a nightmare, but that's another story) so we couldn't add data to the database even if we wanted to. Thanks for delivering some background information. Just out of curiosity: How are the adresses mapped in commercial databases and commercial navigation systems? Are the ususal fields like region, city, street not used in UAE maps? How do you enter an address relative to landmarks into a gpsr? I have absolutely no idea. But there is no domestic postal service (whether this is a cause, or a consequence, of the lack of addresses I don't know). If you want to receive mail, you receive it to a central PO Box and go to pick it up. When we bought a bed (in person at the shop) we had to draw a map of our location for the delivery man (using major streets and landmarks), because the house we live in has no formal address. In Abu Dhabi (and I suspect also in the other Emirates), a major problem is that most residential streets are just numbered, rather than named, so you have hundreds of 1st Streets, hundreds of 3rd Streets etc (compare http://www.openstreetmap.org/?lat=24.47457lon=54.37276zoom=16layers=M with http://www.openstreetmap.org/?lat=24.45496lon=54.37316zoom=17layers=M - different location, but same street names). There is no postal code to help differentiate them. Maps over here are still a novel concept. If a business gives a map, it will quite often be handdrawn, and they sometimes just give you the GPS coordinates directly, see for example the German Vet clinic: http://www.germanvet.ae/contact.html. IKEA recently distributed their 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
Re: [mkgmap-dev] [locator] What's next?
WanMil (wmgc...@web.de) wrote: Hi all, it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk. So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws? WanMil ___ Bear with me, because I haven't tried the locator branch for the reasons I'm about to explain, so my comments may be off the mark... From my perspective, the locator branch as I understand it will not be much use because the area I live in (in the Middle East) has no useful boundary relations that the locator branch could use. It's not necessarily that people haven't got around to adding this information to the OSM database, but often that this information is not publicly available at all. In the UAE, for instance, there is no formal, systematic address system *whatsoever* (it is completely normal here to give your home location relative to local landmarks such as parks, mosques and malls, rather than giving an address. Makes getting home deliveries a nightmare, but that's another story) so we couldn't add data to the database even if we wanted to. Ok, I really wasn't aware of such things... Secondly, the need to pre-process OSM data for boundaries using osmosis strikes me as unwieldy and difficult to maintain. I would much prefer if everything could be self-contained in one executable. You've never done that? In case the branch is merged I hope we will be able to provide a download for the precompiled boundaries. So you don't have to do it yourself. By the way: You are using splitter to create tiles? I think that's a quite similar step. The osmosis call is not nice but maybe we get an easier way to filter the boundaries. Yes, I agree splitter is an extra step, but on my computer splitter takes 18s to split the whole of the GCC countries (into precisely one tile, natch), whereas from what I've read on the mailing list, osmosis takes much longer to produce the bounds. I understand that if the bounds files are provided for download, that avoids the processing time but unless the bounds are mature (e.g. as they are in Europe), you will have to constantly regenerate it. Thus, in my opinion any merge back into trunk should still preserve the branch algorithms for retrieving address information. In particular, as Felix said a few weeks ago, I would encourage that address info for POIs is gathered from the addr: tags in those OSM objects (which will encourage people to tag POIs with address info) Using the locator branch you can use the style file to decide yourself which tags are used to assign the address information. So you can configure to use the addr:* tags. OK, that's great. and the locator algorithms are only: a) offered as an alternative or supplementary option to --location-autofill to get address information for POIs; and In general: we need an algorithm that helps in regions without boundary information. And maybe some parts of the current location-autofill can be used for this. Agreed b) offered as an option to get address information for streets that are typically never tagged with addr: info. You can already do this with the style file. But an additional parameter would have some advantages for processing time. So that sounds useful. Incidentally, one very quick improvement to the branch handling of addr: tags for POIs would be to fix the bug I pointed out a few weeks ago Can you give me a link to your post? I don't remember... http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011267.html and the addition of processing of the addr:full tag if that is present as an alternative 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
Re: [mkgmap-dev] [Talk-de] continue statement and order of drawn ways?
Minko (ligfiet...@online.nl) wrote: Maybe the word 'transparent' is a bit confusing. With transparent I don't mean to omit line type 0x01 from the typ files at all. Like Henning said, you have to use a bitmap pattern without colours (=transparent) in the TYP file. On top of this, you use another bitmap with an arrow in the middle, for highways with oneway. This has to be a non routable line to avoid problems. For highways without oneway, you use another line type with a solid colour. This isn't stupid, it works, only if you know what you are doing. The only thing to watch out for is what your GPS uses when it pops up a routing instruction. On mine, it shows the routeable lines. When I set routeable lines as transparent in the TYP file, then the GPS ignores the transparency and used a 1px grey line instead, which was a bit confusing. It would be even worse if it just displayed the roads transparently as the routing instruction would just show a routing arrow, and no roads. In the end, I set the routeable way as a thinner version of the display road, using the same colouring. 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Non way element X in multipolygon Y
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? Actually this is depending on the type of the relation. With type=multipolygon there shouldn't be any non-way member in the relation, with type=boundary the role admin_centre is defined. There is no such thing as a boundary multipolygon, you have either one or the other. You're right - I wrote boundary multipolygon but I meant boundary relation. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Non way element X in multipolygon Y
On 26/04/2011 10:19, Carlos Dávila wrote: El 25/04/11 18:57, WanMil escribió: I get a lot of warnings of the form Non way element X in multipolygon Y (e.g. Non way element 247735163 in multipolygon 339577) in which X is a correct admin_centre node of a boundary multipolygon relation. Would it be possible to detect admin_centre tag when the MP is processed to avoid this warnings in the log? Of course it is possible. Would it be ok (for you and other) if I lower the log level to info? I don't want to start hardcoding a list of complex exceptions in which cases it is ok to have non way elements in a multipolygon. As in other cases the warning is correct you can leave it as it is now. I will just add them to my logging.ignore 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
Re: [mkgmap-dev] Tile splitter and merged maps?
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-bounds, but I wasn't aware that you could do the same thing in splitter. Perhaps doing it in mkgmap is enough. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Separate boundary files
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 the processing times. The osmosis step took a lot of time, I'm now trying a bigger bounding box (with whole germany, france and the benelux) but after two hours it isn't still finished. It's not a bad idea that someone can put the europe-boundaries.osm somewhere so everybody can use it. I could upload the data for whole europe. Does anyone has a server where we can put it? WanMil ___ 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] mkgmap address processing question
How does mkgmap process the addr: tags in POIs? For instance, take the following POI (http://www.openstreetmap.org/browse/node/918409138) addr:city=Abu Dhabi addr:country=AE addr:housename=Fairmont Bab al Bahr phone:+971 2 654 3238 In Mapsource or on the GPS, the restaurant is given the address: 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, -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile splitter and merged maps?
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 this maps contains three different countries which do not necessarily have any overlap or connections, and bounding rectangles far apart from each other. Now I try to create one single gmapsup.img out of it using the tile splitter and mkgmap: $ java -Xmx5000M -jar ../splitter.jar --mapid=63240345 --max-nodes=100 ../DE_FI_USW.osm after this step I get a list of tiles which is suspiciously small, about 165M. $ java -Xmx4000M -jar ../../mkgmap.jar --max-jobs --style-file=../../aiostyles/basemap_style/ --description='DeFiUs' --country-name=world --country-abbr=W --family-id=4 --product-id=45 --series-name='basemap' --family-name=OSM --area-name=W --latin1 --mapname=63240345 --draw-priority=10 --add-pois-to-areas --make-all-cycleways --link-pois-to-ways --remove-short-arcs --net --route --gmapsupp ../*.osm.gz ../../aiostyles/basemap.TYP When I install the map, I only get map data for Finland, nothing shown for Germany nor US West. So looks like the tile splitter took into account only the first part of the merged .osm map. Am I doing something wrong here? Or is this an incompatibility or a possible problem with the tile splitter? Would you use to use the --mixed option to splitter or does osmosis automatically sort files when it merges them? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Omitting ref from named minor roads
Marko Mäkelä (marko.mak...@iki.fi) wrote:
A fellow mapper complained that some highways carry a 5-digit ref on the
mkgmap-produced map, even though the ref is nowhere to be seen on street
signs. OK, mkgmap cannot possibly know that, but I was wondering if we
could split this rule in the default style:
highway=* {name '${ref} ${name}' | '${ref}' | '${name}' }
so that we would assign '${ref} ${name}' only to highway=tertiary, and
assign either $name or $ref to lesser roads:
highway=tertiary {name '${ref} ${name}' | '${ref}' | '${name}' }
highway=* {name '${name}' | '${ref}' }
For example, a railway=platform that is also tagged as highway=footway
would continue to carry the platform $ref, provided that the way is not
named.
Would anyone object to this change? Does anyone need to see both $name
and $ref on highways lesser than tertiary?
Best regards,
Marko
Sounds fine to me: in my style I only use ref for down to the
secondary classification...these things are, to an extent, 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
Re: [mkgmap-dev] [PATCH v1] Prefer multiples of 2048 as cut coordinates in multipolygons
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 the cut lines of the multipolygons. The patch contains also a fix for the bug found by Nakor (Some inner areas are ignored in mulitpolygon processing). Please test it soon. I plan to commit that within the next 2 days if noone complains about it. I tested this patch, and it does not seem to break anything for me. I have not paid attention to the number of multipolygon cut lines in the past, so I cannot say if this patch reduces them considerably. Marko If someone can compile a jar file for me I'd like to test this. I recently built a map of Thailand and Malaysia and with all the islands the multipolygon artefacts in Mapsource are quite extreme. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] via ways (rather than nodes) in restrictions
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sensible resolutions - (or patch 5)
On 26/03/2011 15:50, Johann Gail wrote: Actually, we do have a mean: if there are multiple parallel tracks (each drawn as a separate way with railway=*), it is a major railway. It should be doable to merge adjacent ways at lower resolutions and sum the weights of the ways, to decide what to draw. A style file extension could be useful, to specify e.g., the following: * draw individual railways at resolution 24 * merge parallel tracks to one and draw them at resolution 22..23 * merge parallel tracks to one and draw if count1 at resolution 21 * merge parallel tracks to one and draw if count3 at resolution 20 For polygons, it could be useful to specify the minimum size that qualifies for inclusion in a given resolution. Of course, small adjacent polygons would have to be merged together first. I am beginning to think that it could be useful to have low-resolution versions of the OpenStreetMap data, generated by an experimental algorithm that attempts to merge polygons and lines as suggested above. If it is not too CPU intensive to merge adjacent areas and lines, perhaps it could be implemented inside mkgmap after all. I'm thinking since some time about an algorithm for merging small polygons. Up to now I have not found an suitable algorithm. In another case I have thought about merging parallel lines, especially the both tracks of highways. While reading your mail I got the insight, that this are possibly two similar problems. In both cases there should be two objects with a small space between it be replaced by a merged single one. 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. Regards, Johann. I thought the --merge-lines option did part of what you're saying? i.e. merge lines at low zoom levels. If it doesn't do that, then what does --merge-lines do? -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] share your outdoor/mtb/hiking styles and typ
On 19/02/2011 07:23, maning sambale wrote: Hi, I am planning to create an outdoor garmin map useful for hikers, MTB, mountaineers. Care to share your typs and style code? Hi, I've completed the revamp to my styles. There are two: 1) CF_GPS is designed to work with old GPS units (such as mine, the GPSMap76csx) which do not display roads with borders properly http://www.cferrero.net/maps/downloads/CF_GPS.zip 2) CF_Mapsource is much prettier and I use it in Mapsource. People with more modern GPS units may find it looks good on those too http://www.cferrero.net/maps/downloads/CF_Mapsource.zip Both styles are identical except for the lines file. 3) Both styles work with the same TYP file (but use different parts of it): http://www.cferrero.net/maps/downloads/CFMaster.TYP Obviously the family ID of the TYP file must be altered to match that of 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing sea in northern Italy
On 19/03/2011 20:33, Thorsten Kukuk wrote: On Sat, Mar 19, Daniela Duerbeck wrote: If you have some spare time could you perhaps create a map from Italy (geofabrik)and look whether it looks good in mapsource? Ok, using the data from geofrabrik I created a map for you: http://osm.thkukuk.de The page is in german, but I think you will find the map for italy ;) The archive contains a installer for MapSource, but you should make sure that neither mapsource nor basecamp are running if you install the map. I only see a rectangle in the upper right corner which is not ok. Don't know why that is, else on a quick view it looked ok for me. Thorsten Ich auch...something odd's going on in the Gulf of Venice: http://www.cferrero.net/maps/img/italy.png There's also strange things 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] UK Contours
Stuart Poulton (webw...@gmail.com) wrote: Hi, Has anyone got a quick recipe for STRM contours to garmin for the UK, preferably on Linux ? Cheers Stuart ___ mkgmap-dev mailing list mkgmap-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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mkgmap.log.0 warning messages in triplicate
Hi, I use the -Dlog.config=logging.properties java option in combination with the following mkgmap switches: --check-roundabouts --drive-on-right --check-roundabout-flares --report-dead-ends --max-flare-length-ratio:5 I've noticed that in the mkgmap.log.0 file, I'm now seeing every 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 accident? -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overlays issue
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 0x0c just to see if the two lines are really there. They are, I can see the 0x04 on top of the 0x0c as expected. BUT: The roundabout is never used for routing now. It is treated as if it was a non-routable line. Do I do something wrong or is the routing info not created properly? If I remember correctly, the overlay file does not guarantee, which line is displayed on top. So if not one of the lines is transparent, the display of such a structure will vary. If you are using a transparent code for the roundabout, you could also add a second non-routable line for the display, without using the overlays file, e.g.: Lines file: junction=roundabout highway=secondary [0x0c road_class=2 road_speed=3 level 4 continue] junction=roundabout highway=secondary [0x04 level 4] Gruss Torsten This is what I do - I've got rid of the overlays file completely now that I understand how continue works. The only thing to bear in mind: - When my GPS flicks up a navigation prompt (e.g. turn left in 300 metres) it shows the routeable line (0x0c), not the other line (0x04). So if 0x0c is invisible, then the navigation prompt doesn't look too good. Other GPS may behave differently. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
Marko Mäkelä (marko.mak...@iki.fi) wrote:
On Sun, Feb 27, 2011 at 11:06:22AM +0200, Marko Mäkelä wrote:
I am now testing the patch on Finland.
I got 2386 additional warnings. Some are for thin man_made=pier that
have been drawn as lines. There is man_made=* in the polygons style
file. Could we suppress the warnings for certain minor unclosed
polygons? E.g., something like this:
building=* | man_made=* | amenity=* | tourism=*
{ add mkgmap:polygon-check=false } [0x13 resolution 24]
In my custom style I have adjusted the polygons style rule 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Contour lines in Mapsource (was Improved street search in index branch)
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: [snip] Note that I don't put the line mapname: 10010101.img in the line above with description: contourmap because this causes that the contours dont show up in Mapsource. If I leave mapname etc out, it shows the 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 workaround of the year so far if this works. ;) Highly off topic: 1. Check: Countourlines have to have exactly the same resolution as normal maps (if normal maps 24,22,20,18 countourline maps have to be 24,22,20 (you can skip the 18) - if normal maps are 24,23,22,21,20 then well, your contourline maps need to be also 24,23,22,21,20 - as soon as you leave out a resolution they won't be displayed anymore) 2. Contourline maps have to have higher mapname. --- both is irrelevant if you use basecamp or on GPS, which always shows contourlines if inside same tdb. Problem is 1, in general contourlines work better if you have 23,21,20 as levels on GPS or for Qlandkarte GT. DEM3 data, is not good enough resolution to justify the 2x space / render requirements of res 23.) Hmmm - tried this and it still doesn't work. My contour style has exactly the same levels as the base style, and the mapnames are higher. All I can see is the contour labels, but not the contours themselves (see http://cferrero.net/maps/img/mkgmapdev_contourissue.png). If I just display the contour maps and not the basemap, it works as expected (see http://cferrero.net/maps/img/mkgmapdev_contourissue2.png) I'm 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 Where did I write you are supposed to use --transparent. Drop that it causes only problems. You beauty - thanks Felix. Dropping transparent counterintuitively fixed things. All working now. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Contour lines in Mapsource (was Improved street search in index branch)
On 21/01/2011 18:17, Felix Hartmann wrote: On 21.01.2011 15:12, char...@cferrero.net wrote: Minko (ligfiet...@online.nl) wrote: [snip] Note that I don't put the line mapname: 10010101.img in the line above with description: contourmap because this causes that the contours dont show up in Mapsource. If I leave mapname etc out, it shows the 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 workaround of the year so far if this works. ;) Highly off topic: 1. Check: Countourlines have to have exactly the same resolution as normal maps (if normal maps 24,22,20,18 countourline maps have to be 24,22,20 (you can skip the 18) - if normal maps are 24,23,22,21,20 then well, your contourline maps need to be also 24,23,22,21,20 - as soon as you leave out a resolution they won't be displayed anymore) 2. Contourline maps have to have higher mapname. --- both is irrelevant if you use basecamp or on GPS, which always shows contourlines if inside same tdb. Problem is 1, in general contourlines work better if you have 23,21,20 as levels on GPS or for Qlandkarte GT. DEM3 data, is not good enough resolution to justify the 2x space / render requirements of res 23.) Hmmm - tried this and it still doesn't work. My contour style has exactly the same levels as the base style, and the mapnames are higher. All I can see is the contour labels, but not the contours themselves (see http://cferrero.net/maps/img/mkgmapdev_contourissue.png). If I just display the contour maps and not the basemap, it works as expected (see http://cferrero.net/maps/img/mkgmapdev_contourissue2.png) I'm 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
Re: [mkgmap-dev] objects with line and polygon
On 20/02/2011 03:51, Thorsten Kukuk wrote: Hi, I have some problems to create a style with draws objects correct, which have a line and polygon tag. For example http://www.openstreetmap.org/browse/way/37712194 On my maps, only barrier = fence is drawn, but the landuse tag is ignored. On www.streetmap.org, it is mapped correct. How can I modify the style file, so that the line and landuse are drawn? Thanks, Thorsten Use a continue statement in the lines definitions, e.g. barrier=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). -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Ben Konrath (b...@bagu.org) wrote: Hi Charlie, On Mon, Jan 31, 2011 at 8:35 AM, char...@cferrero.net 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 patch I include with the version of mkmap that I use. It doesn't add a POI for areas that don't have a name. I'd be happy to share the patch if you're interested. I haven't posted it because it's kind of a hack but it works. I guess a better solution would be to make it an option to --add-poi-to-area but, as a bunch of people have pointed out, that functionality really needs to be reworked. I've thought doing it a couple of times but sadly I don't have a lot of extra time these days. I did, however, post a couple of updates to the original patch a while ago but I'm not sure if those were integrated. (I think anyway, it was a while ago) I thought as much. My solution to the same issue has been via the style file: i.e. leisure=park name=* [0xbla resolution bla] This means that a POI is only created when the area has a name (that can be used in a POI search) Like Marko, I would much much prefer an add_poi style action than the univeral --add-pois-to-areas. And finally, and apologies for bleating on about this, I would love it if the POI that was added was *always* placed inside the area bounds, rather than in the area's centre-of-mass as currently happens. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How to fix amenity=shelter in the default style?
Marko Mäkelä (marko.mak...@iki.fi) wrote: Last week, I changed the POI type for amenity=shelter in the default style from 0x2b05 (bed icon) to 0x6402 (an icon of a building block). Even though I later changed the resolution to 24, this symbol (along with grave yard symbols) seems to be visible from much greater distance than shops or anything else. I tried with two different map detail levels on my Edge 705. So, it looks like the 0x6402 is meant for skyscrapers and the like. Next try is with 0x6412. Same problem: at normal detail level, it shows at 120m zoom while shops and the like start to appear at 50m. At the highest detail level, shops appear at 120m and 0x6412 appears at 500m. Can anyone suggest a more suitable symbol for amenity=shelter? It does not need to be searchable, and it should not be any more 'visible' than, say, 0x2f17 (transit service; used by highway=bus_stop). The 'problem' at hand are two shelters on a railway station platform. I do not want them to be more visible on the map than the shops and other features in the town centre. Here are the nodes: http://www.openstreetmap.org/browse/node/439195020 http://www.openstreetmap.org/browse/node/439195021 If nobody can suggest a better symbol for amenity=shelter, I would remove amenity=shelter altogether from the default style. There seems to be some agreement that amenity=shelter may be too inaccurate tagging for the tourism or hiking related shelters. Side note: the unsearchable 0x6412 'hiker symbol' could be a good choice for some minor hiking feature. I think that sites where overnighting is possible do require a searchable symbol. Best regards, Marko Hi Marko, The mysteries of the zoom-behaviour of default Garmin objects is a scary subject. :) The 0x64 series are man made geographical POIs. I think Garmin intends this series to be used for navigational purposes (i.e. there's a huge building/dam/oil field over there, I'll use it to triangulate my location). This is probably why they appear even when zoomed out. I think you're starting to push the limits of what is practical using the default Garmin objects (i.e. without the use of a TYP file) and 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
Re: [mkgmap-dev] problem with --generate-sea near Toronto, Canada
Ben Konrath (b...@bagu.org) wrote: Hi, I've run into a strange problem with --generate-sea while generating a map of Canada. Here's a screenshot of the problem I'm seeing: http://bagu.org/scratch/generate-sea-problem-lake-ontario.bmp I'm using mkgmap version r1783 with these options: java -Xmx400M -Dlog.config=/home/ben/osm/mkgmap/resources/logging.properties -jar \ /home/ben/osm/mkgmap/dist/mkgmap.jar --tdbfile --latin1 --gmapsupp \ --country-name=Canada --country-abbr=CAN '--series-name=OSM Canada' \ '--family-name=Open Street Map Canada 12 Jan 2011' --location-autofill=1 \ --add-pois-to-areas --ignore-unnamed-areas --road-name-pois --check-roundabout-flares \ --route --remove-short-arcs --drive-on-right --check-roundabouts --family-id=34244 \ --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. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] looking for set-typ.pl script
Steve Ratcliffe (st...@parabola.me.uk) wrote: Hi I already looked into the archive and I can't find this script. The links are dead, or the attachment was removed from the mails. So could somebody provide me this script? This would be great. The links are downloadable from the on-line archive of the emails at least, not tried the downloaded archive: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007067.html Attachment link is: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/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
Re: [mkgmap-dev] Improved street search in index branch
Minko (ligfiet...@online.nl) wrote: [snip] Note that I don't put the line mapname: 10010101.img in the line above with description: contourmap because this causes that the contours dont show up in Mapsource. If I leave mapname etc out, it shows the 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 workaround of the year so far if this works. ;) -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Multipolygon problem
Hello all,
I have the following rule in my polygons style:
surface=sand [0x1b resolution 20]
The problem is the following multipolygon:
http://www.openstreetmap.org/browse/relation/1221199
This is a complex multipolygon which, in certain sections, uses the
coastline to define the outer. Parts of the coastline (and therefore
parts of the multipolygon) have the key/tag pair surface=sand
The result is that mkgmap attempts to build a multipolygon for Port
Philip Bay and fill it with sand, which is not ideal:
http://www.cferrero.net/maps/img/1.png
What I can't figure out is how to adjust my polygon style rules to avoid
this happening. Or tell mkgmap not to process multipolygons of type
natural=bay
Neither of the following two variations of the rule makes any difference:
surface=sand natural!=coastline [0x1b resolution 20]
surface=sand type=!multipolygon [0x1b 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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Multipolygon problem
On 08/01/2011 13:02, Torsten Leistikow wrote: Moin, I think the problem is not the multipolygon, but that some of the outer ways are tagged with surface=sand. These tags are not considered for the multipolygon, but for these ways mkgmap creates single surface=sand polygons. But if you change your polygon style from surface=sand [0x1b resolution 20] to surface=sand natural!=coastline [0x1b resolution 20] this shouldn't happen any more. Just for a try: What happens, if you remove the surface=sand lines from your polygon styles completely? And one other thing: There was once a patch, which limited the polygon creation to closed ways. Does anybody know, what happened to this patch? I really liked it. Gruss Torsten Hi Torsten, You may be right - it might just be that the polygon rule makes mkgmap create a surface=sand polygon for coastline ways tagged with surface=sand. Unfortunately it is legitimate to tag a way as surface=sand so I cannot correct the OSM data. I need some way of telling mkgmap not to create a surface=sand polygon when it is associated with a coastline. Unfortunately surface=sand natural!=coastline [0x1b resolution 20] does not solve the problem. I think this may be because the natural=coastline tag is being removed during the --generate-sea processing, so it is no longer there when the 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
Re: [mkgmap-dev] announced streets are wrong for abbreviated street names on nuvi
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 GPSr - if I saw a street labelled E Rodriguez I would also assume that the street was called East Rodriguez! -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in generation gmapsupp map (overflow?)
Maks Vasilev (m...@stranger-team.ru) wrote: Hi! I generate every week map from osm data in single file and elevation contour from 133 .osm files. Osm data increase in each time, elevation data in osm files is permanent. Yesterday i have error in generation gmapsupp map: --cut-- Exception in thread main java.lang.IllegalArgumentException at java.nio.ByteBuffer.allocate(Unknown Source) at uk.me.parabola.imgfmt.sys.Directory.sync(Directory.java:176) at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:230) at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:240) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:119) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:127) --cut-- mkgmap commandline: http://code.google.com/p/velo100mapper/source/browse/trunk/makemap.elev where: chepetsk.org.ru.osm - osm data (124M), 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. Wild guess, but perhaps you need to split your chepetsk.org.ru.osm file into smaller tiles. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] announced streets are wrong for abbreviated street names on nuvi
maning sambale (emmanuel.samb...@gmail.com) wrote: Not exactly an mkgmap issue, but I would like to point this out when mapping for OSM. Using nuvi text-to-speech feature, some abbreviated street names are announced with some kind of default words. i. e., - 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 mapping guidelines state that no abbreviations should be used in names. :) -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
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. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] style polygon+line on one input object
On 09/12/2010 17:06, Maks Vasilev wrote: Hi! http://www.openstreetmap.org/browse/way/87336026 barrier = wall + landuse = industrial http://www.openstreetmap.org/browse/way/86381931 amenity = parking + barrier = fence I have description for line barrier= in line style file and for way landuse= in polygon style file, but mkgmap generete only 1 object (polygone) without using line style barrier=. Key countinue work only in 1 style file (line or polygon). What way to generate 2 objects in output file - line for barrier and polygone for content? my mkgmap style: http://code.google.com/p/velo100mapper/source/browse/trunk/stranger/ my TYP: http://velo100mapper.googlecode.com/svn/trunk/stranger.typ --- wbr Maks Hi, I have no problem processing such objects when assigning the continue statement to the lines rules. The continue statement crosses style files. Take a look at the park in the lower left of this screenshot: http://www.cferrero.net/maps/shot_AD_detail2.html You can see that the wall renders 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
Re: [mkgmap-dev] What is ${mkgmap:boundary_name}
On 04/12/2010 09:48, garvanmaew 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 select name:en and only use name
where no name:en exists.
I first tried using the option --name-tag-list=name:en, name
expecting that the boundaries would now use the name:en tag, but this
had no effect that I could see. Next I tried editing the line style, and
I got the tags to display in English by commenting out this line:
boundary=administrative { name '${mkgmap:boundary_name}' }
This appears to be setting the name of administrative boundaries to
mkgmap:boundary_name, so I was wondering where mkgmap:boundary_name gets
its value?
Garvan
Most likely from the relations style file.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 2 pois for a single polygon/multipolygon
On 11/23/2010 05:20 AM, maning sambale wrote: FYI, I already moved the tags to the multipolygon relation but the 2 poi icons still exist: http://www.openstreetmap.org/browse/relation/452620 I would expect them to, seeing as this is an unwanted outcome of combining the 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sea generation
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.
This is the only issue stopping me from switching to --generate-sea:mp
I have produced a modification for mkgmap. It creates a land polygon
covering each tile, when you are using the option
--generate-sea=multipolygon. The tag of the land polygon is set in the
same way as for the no-mp option. Note: Felix has reported that doing
this, slows down redrawing of the screen. For that reason, he recommends
against this approach. I was not sure whether you wanted a land polygon
over the whole tile, or only over the actual land area. The latter would
be more difficult, and I'm not a Java programmer. Perhaps my
modification will do as a temporary fix. If you do not specify a land
polygon type in the style file, the modification should have no effect.
I will go into more detail than you may need, in the hope that it will
be helpful to less expert readers.
Download the source, e.g. mkgmap-r1728.src.tar.gz
Unpack the file, to produce the directory, e.g. mkgmap-r1728
Use a text editor to open the file
mkgmap-r1728/src/uk/me/parabola/mkgmap/reader/osm/SeaGenerator.java
After line 148, [Coord se = new Coord(maxLat, maxLong);] insert
if (generateSeaUsingMP) {
/*
* Add a land polygon covering the tile
*/
long landId = FakeIdGenerator.makeFakeId();
Way land = new Way(landId);
land.addPoint(nw);
land.addPoint(sw);
land.addPoint(se);
land.addPoint(ne);
land.addPoint(nw);
land.addTag(landTag[0], landTag[1]);
saver.addWay(land);
}
I have seen strange things happen to text in e-mails, such as tabs being
converted to spaces, and leading blanks being suppressed. Each of the
lines above starts with either two tabs or three tabs. So I have also
attached a file containing the same block of code. (But the last time I
sent a text attachment, it appeared on the mailing list web site with a
.pl extension and with all the line-endings removed!) If your text
editor cannot handle Unix line-endings, you may need to use unix2dos and
dos2unix.
Having saved the file, change to the directory mkgmap-r1728, and compile
mkgmap by entering
ant dist
at the command line.
(Note for Mac OS 10.5 Leopard. You need 64-bit Intel hardware to run
Apple's Java v1.6. To get ant to use Java v1.6, change the symbolic link
CurrentJDK in /System/Library/Frameworks/JavaVM.framework/Versions to
point to 1.6 instead of 1.5. Changing the preferred version of Java in
the Java Preferences utility will not do the trick. You may need to redo
the change to the symbolic link after a Java update.)
If you need to rerun the compilation after fixing a problem, sometimes
it will not succeed unless you first issue the command
ant clean
The directory mkgmap-r1728/dist will contain what you would normally
download as mkgmap-r1728.zip or mkgmap-r1728.tar.gz. The jar file will
be at mkgmap-r1728/dist/mkgmap.jar
I discovered while testing, that the restriction on short option names
in the configuration (.args) file, also applies to input files. If you
just put a file name in the .args file, it will be silently ignored. You
have to put e.g. input-file:white.TYP
I would have liked to make this work also when you are not using
--generate-sea, but I could not see how, because method end() of class
SeaGenerator is not invoked when you are not using --generate-sea. If
you try to insert similar code into method init(...), which *is* always
invoked, you find that saver.getBoundingBox returns default values - it
has not yet been set up to correspond to the map. As a workaround for a
land-only map, you could use my modified version of mkgmap, with
--generate-sea=multipolygon, and use a custom style with the line
natural=sea [0x32 resolution 10]
removed from the polygons file, in order to avoid any possible problems
with flooding. For a map with a coastline, this workaround will not give
you a coastline way drawn on a white background.
To get a white background, you need to use a custom style and a custom
.TYP file. The style needs to contain a line such as
natural=land [0x010100 resolution 16]
in the polygons file. The .TYP file needs to specify the colour of
polygon type 0x010100 (or whatever you have chosen). There is a good
description of how to construct a .TYP file in the cGPSmapper manual
http://cgpsmapper.com/download/cGPSmapper-UsrMan-v02.5.pdf
There is a good online .TYP file creator/editor at
http://ati.land.cz/gps/typdecomp/editor.cgi
You will not need this for making a white background, but details of the
Garmin colour palette are here
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007419.html
Details of what you need to do for certain, particularly recalcitrant
GPS receivers, are here
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1
Re: [mkgmap-dev] Sea generation
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 after land in your .TYP file? Otherwise the land polygon will cover the sea. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev You were right, I had the draw order wrong. That was the problem. However now I see what the patch is doing, maybe I'm missing the point. The problem with the polygons version of generate-sea is that it underlays the entire tile with a sea polygon, then plots land polygons on top as required. This results in quite a slow map to pan around on. Your patch does the reverse (draws a land polygon everywhere, then plots sea on top as required) but has the same problematic effect of slow panning. Is there some other improvement in the multipolygons version of generate-sea that makes it preferable to use it over the simpler (and quicker to compile) polygons version? I don't mean to sound ungrateful - I'm just trying to understand the difference in the two ways of generating sea. In my mind, the best solution would be a multipolygon one where sea and land polygons do not overlap at all - thus you should get much less redraw slowness on panning. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sea Detection
Chris66 (chris66...@gmx.de) wrote: Hi, I created a map of a cutout of the europe geofabrik extract including generate sea option. All is OK, but one tile is white instead of blue because it's completely in the sea and contains no coastline. How to detect such tiles? I think this is easy: It contains no or very few data (only some ferry lines). An option for detecting such sea tiles and filling with a sea polygon would be nice. Christian I'm sure there is an sub-option to --generate-sea that created 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sea Detection
Chris66 (chris66...@gmx.de) wrote: Am 09.11.2010 09:56, schrieb char...@cferrero.net: I created a map of a cutout of the europe geofabrik extract including generate sea option. All is OK, but one tile is white instead of blue because it's completely in the sea and contains no coastline. How to detect such tiles? I think this is easy: It contains no or very few data (only some ferry lines). An option for detecting such sea tiles and filling with a sea polygon would be nice. I'm sure there is an sub-option to --generate-sea that created 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). 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
Re: [mkgmap-dev] Sea generation
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 tile blocker. The algorithm has been discussed a while ago on this list. It uses a quadtree implementation which is able to return all points contained by a polygon. The quadtree is filled with all highway points. If a sea polygon contains too many points that belong to highways something is wrong and the sea polygon is discarded. That's the idea... Let's see how it works. The quadtree might also be used to correct wrong sea polygons. But that's one of the further steps. Do you have any other ideas how to improve the sea generation and how to make it more failsafe? Then please let me know. 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. This is the only issue stopping me from switching to --generate-sea:mp ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Strange request with later versions of mkgmap
NopMap (ekkeh...@gmx.de) wrote: Johann Gail wrote: I do not know, what causes this message. But I assume it is the question if the device should route over streets (with routing information) or if it should show only the straight line to the destination. This is was I understand with 'beeline'. The line which flies a bee in the air. Yes. The terms are clear. The device ask for street routing or a straight line. Which is strange as the map should not contain route information without --route. 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. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fuel POI label corrupted
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/routable.php. This node http://www.openstreetmap.org/browse/node/418611927 shows up on the Garmin map with label ptth: Ptt. The default style sheet is used, so I am told. Yes, I'm using the default stylesheet. It looks like the POI is being labelled operator: name:en where operator is being transliterated from the Thai (?) script. This is expected behaviour from mkgmap if Lambertus is using the default style combined with mkgmap's --name-tag-list option (i.e. --name-tag-list=name:en, name). I'm using the follow Mkgmap option: --name-tag-list=name:en,int_name,name:zh_py,name:engels,name Where name:engels is the transliterated name. I had no idea that the name-tag option interacts with the stylesheet. Yes: name-tag-list defines the precise name tag to use for a given object and so interacts with any style rules that match that object and also use the name tag for labelling purposes. Does this mean that I need to have an adapted stylesheet because of the name-tag-list? Any other options? There's no easy answer if you're making a global map that has to have some sort of consistency. This is the first time that I've seen an operator:en tag and there's no way to account for it using --name-tag-list. The only way to fix it is to use a modified style rule that uses operator:en in preference for operator. This could be a change to the mkgmap default style, but if you do it for fuel you'd really have to do it for all rules to avoid a special case. Preferable would be for the --name-tag-list code to be made more generic so that it applies to any tags, not just name. Unfortunately, as I understand it Lambertus is keen to stick with the default style. Correct, it seems to me that maintaining a stylesheet takes quite some time, time which is a scarce commodity. Creating my own stylesheet is just very low on my priority list. That said, if anyone knows of a good public *generic* stylesheet that is maintained or actively developed and is better then the default stylesheet then I will consider to switch. I think the default one is probably the best generic stylesheet out there that doesn't require a TYP file. I know there are some specialist stylesheets around (e.g. for MTB of cycling) but I'm not aware of a generic stylesheet other then the Mkgmap default. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fuel POI label corrupted
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/routable.php. This
node http://www.openstreetmap.org/browse/node/418611927 shows up on the
Garmin map with label ptth: Ptt. The default style sheet is used, so I
am told.
Regars,
Peter.
Hi Peter,
It looks like the POI is being labelled operator: name:en where
operator is being transliterated from the Thai (?) script. This is
expected behaviour from mkgmap if Lambertus is using the default style
combined with mkgmap's --name-tag-list option (i.e.
--name-tag-list=name:en, name).
The only way to fix it would be to change the default style to use
amenity=fuel { name '${operator:en}: ${name}' | '${name}' |
'${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
Re: [mkgmap-dev] Latest List of OSM to GarminIDs
Sam Vekemans wrote: Hi all, I'm hoping that im being of some help here :) For those who might not know, im taking on the challenge of trying to organize all of the Map Features into a universal system. I'm calling it 'SchemaTroll 2.01' http://wiki.openstreetmap.org/wiki/SchemaTroll_2.01 I have now completed an analysis of the Garmin Map Features, and created a spreadsheet which lists it all. I used http://freegeographytools.com/2008/garmin-gps-unit-waypoint-icons-table - for the icons and feature categories the mkgmap .csv file from the 'mkgmap-r1709-src' and cross-referenced the big list of Map features, with the smaller list of OSM tags that it supports. http://www.geopainting.com/en/ - GPSMapEdit provides a nice detailed category listing for each map feature. .. and in it's 0x form. So it was easy to match-up the GarminID's with the mkgmap ID's ... as some where switched around. http://www8.garmin.com/cartography/mapSource/mapLegend.html - has a detailed list of all the map features that gets supported (for MapSource) I also included 2 columns for 'SchemaTroll KEY' and SchemaTroll Value' these are where i simply went through it and guessed as to what the tags could possibly be in the future. For the OSM Map Features, there are a few (a whole lot) of Tag Proposals that need to be made. So i'm leaving that upto the Wikians to fix up the wiki. I'm just trying to help it along. Ideally, it would be great to see an OSM tag for each of the Garmin Map Features, as the map can actually support the customized map, of upto 700 or so features. I noticed that many features are duplicated across different Garmin ID's and Many Garmin ID's support multiple OSM tags. So basically, im trying to get the whole chart filled in, with the best known map features, and using the Wiki as the primary source. And over on my version of the Spreadsheet, im keeping a list of Features that need to be proposed, and updating my own spreadsheet. Which i hope to make available in the next month or so. (it's going through so many changes) :) For those who know how to use Gitorious I just converted the file to .csv and Pushed the latest changes http://gitorious.org/wikimap-books/wikimap-books-legend and here's the GoogleDocs Chart https://spreadsheets.google.com/ccc?key=0Am70fsptsPF2dGdSaEwwTUx5eGtzSFdPbmZPQlpBTEEhl=en Hopefully someone will find some use for it :) Cheers, Sam P.S How often does the osm map features .csv file get updated? --- Across Canada Trails - Beyond 2017 - The National Trails Network Victoria, BC Canada Hi Sam, For mkgmap purposes, the map_features.csv file is deprecated. As I understand it (this was before I started using mkgmap) it was initially a reference for helping mkgmap to convert OSM objects to Garmin types. But now this conversion is done via the style rule system, so you will find that many more OSM objects are mapped to Garmin types than is apparent just from the map_features.csv file. To understand the current mapping of OSM features, have a read through the various style files in the default directory of the SVN: http://www.mkgmap.org.uk/svn/wsvn/mkgmap/resources/styles/default/ You'll probably be most interested in the lines, points, polygons and relations files. Taking an example 0x6612 which you say is not supported by mkgmap. If you open the points style file you'll see that there is in fact a rule to use this type: leisure=nature_reserve name=* [0x6612 resolution 18] Another thing to look at if you're interested in Garmin POI types is the spreadsheet I put together a while back: http://www.cferrero.net/maps/downloads/garmin_feature_list.xls This is a work in progress and it's still not entirely complete. Finally, beware that http://www8.garmin.com/cartography/mapSource/mapLegend.html is not entirely complete nor correct as I don't think they have updated this for a while and the POIs supported by MapSource seem to change with every new version. Finally finally, of great importance to Garmin GPS users is the ability to search for particular POI types. Not all the Garmin type codes are searchable - it is important when considering the conversion of OSM objects to Garmin types whether you want the resulting POI to be searchable on the GPS unit, and if so, what category you want it to appear 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
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Torsten Leistikow (de_m...@gmx.de) wrote: WanMil schrieb am 24.09.2010 19:29: My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area. You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know. I tried your patch today, and I think it looks quite promising. Implementing such a strict scheme will certainly show some faulty multipolygon (e.g. Aussenalster in Hamburg), but perhaps this will encourage a cleaner tagging of such relations. I think the patch has still one problem: If the tags of the outerpolygon are not used for the multipolygon area, they must still be used as a stand-alone polygon. As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) 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
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
Torsten Leistikow (de_m...@gmx.de) wrote: char...@cferrero.net schrieb am 27.09.2010 15:20: As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) 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)? It should use both: The nature reserve should cover the complete area. The wood should cover only the area defined by the multipolygon. This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be: 1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B 2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B 3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B 4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the 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) Wood multipolygon water polygon hidden underneath a nature reserve polygon, or b) A nature reserve polygon hidden underneath the wood mp and water polygon depending on draw order of the polygons (which afaik you can't control). -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
On 24/09/2010 10:42, Markus wrote: The other relations seem to have water reversed also. For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter. Markus_g For the Markus, Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --transpatent not work
Maks Vasilev (m...@stranger-team.ru) wrote: Hi! I create map (contour) with: mkgmap --gmapsupp --tdbfile \ --family-name=NASA-SRTM-Topo \ --product-id=9 \ --family-id=99 \ --series-name=Vyatka-topo \ --description=Centae \ --country-name=RUSSIA --country-abbr=RU \ --charset=cp1251 --lower-case \ --style-file=stranger/ \ --output-dir=elev/ \ --draw-priority=31 \ --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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] line features are converted to a closed way
maning sambale (emmanuel.samb...@gmail.com) wrote: This way is a line tagged as man_made = breakwater: http://www.openstreetmap.org/browse/way/55131773 I have in my style polygons file a generic assignment for man_made=* [0x13 resolution 24] The compiled map tried to close the line to form a polygon: http://www.flickr.com/photos/esambale/5006580843/ Any idea how to fix this? -- cheers, maning mkgmap assumes that any OSM object that matches a rule in the polygons style file must be a polygon (it has no other way of telling). The only current way to fix this is to edit your polygons rule so that it no longer matches such OSM objects, perhaps man_made=* (area=yes | area=true) [0x13 resolution 24] In the past I've had a similar problem with man_made=pier, which sometimes in the OSM data is a closed polygon, sometimes not. A rule which matches the closed polygons results in nasty artefacts when the OSM data is not closed, whereas a rule that only matches lines misses all the closed polygons. Personally, I would love it if some logic could be added to mkgmap for it to be able to detect 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
Re: [mkgmap-dev] [mkgmap-svn] Commit: r1671: output dir
Steve Ratcliffe (st...@parabola.me.uk) wrote: Hi I still have the same problem with r1671 or later. The problem is caused by the --index option. Maps generated without --index work fine on MapSource. Nobody else has this problem? OK Thanks for the information. I assume you are not using --output-dir? I'll try building an index before and after r1671 there should be no difference. Perhaps the file is being created in the wrong place/wrong name. ..Steve ___ I've noticed the same problem. Maps don't have index included when generated with --index using r1675 (the only recent version I've tried) but they do have index included when generated with r1625. In Mapsource, the Find button is greyed out with maps created using r1675. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Proposal: Multipolygon handling and line based multipolygons
WanMil (wmgc...@web.de) wrote: The latest question about the boundary handling of multipolygons encouraged me to start another try to fix the problem in mkgmap (please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q3/008976.html). Now I have another idea. The problem is: The resulting multipolygons usually are used as polygons. But some should only be used for the line processing (country borders). The multipolygon algorithm creates artificial polygons which are annoying if you want to use them as lines: you get artificial borders inside your country. My solution: The mp algorithm adds a tag mkgmap:styleusage=polygon to all artificially created polygons. Additionally it duplicates all input ways of the multipolygon, tag them with the mp tags and add mkgmap:styleusage=line. The style handling now applies line rules only if the tag mkgmap:styleusage=line is set or if it is completely unset. The same with polygons. With this solution the style writer can decide on its own if he wants to use the polygon information or the line information of the multipolygon. 2nd advantage: the style writer need not to change any existing styles as this new feature is handled internally in mkgmap. 3rd advantage: the line information of properly tagged multipolygons could also be used if the multipolygon is not completely contained in the tile. This if often the case for country boundaries. The --process-boundary-relations option of mkgmap would become needless. I am not an expert in styles so maybe I have missed something?!? What do you think about my idea? WanMil ___ That sounds like a good proposal. Another, possibly conceptually-related problem with the mp code is as follows: Consider a multipolygon with one outer way having the tags barrier=fence landuse=farm and one inner way having the tag natural=water The mp splits this into two outer polygons with landuse=farm and barrier=fence and one inner polygon with natural=water. The problem is that now the fence no longer follows the (outer) ways it was originally designed to follow, but also follows the synthetic orthogonal ways created by the mp code. If the style rules process both landuse=farm (in the polygon ruleset) and barrier=fence (in the lines ruleset) then you get an unwanted, synthetic fence being created where none really exists. Having the mp code add a new tag to synthetic ways created as part of multipolygon splitting would be one way of tackling this problem (by subsequent re-writing of the style rules). The other would be to avoid adding barrier=fence (or other such linear tags) to synthetic ways created as part of polygon splitting. Hope that made sense, -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tag values of relations and tag values of its members
Marko Mäkelä (marko.mak...@iki.fi) wrote: On Fri, Sep 10, 2010 at 07:01:55PM +0200, Torsten Leistikow wrote: I think this wouldn't solve my problem. What I want to achieve is, that multiple relations can add information to a single way. [snip] Do we have a bug tracking system or a wiki page for tracking this kind of long-term, hard-to-implement feature requests? There's this: http://wiki.openstreetmap.org/wiki/Mkgmap#Known_issues -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon wih leisure=park does not render
Markus (marku...@bigpond.com) wrote: Hi Chris, Are you sure? I just removed the --process-boundary-relations from my mgkmap bat file and the multipolygons I have added to osm no longer show up in mapsource. Regards, Markus_g --process-boundary-relations is definitely not needed in order for (most) multipolygons to work properly. Using this switch simply enables better processing of boundary relations so that they form complete polygons. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Known issues wiki page
Hello list, I have taken the liberty of updating the known issues section of mkgmap's wiki page (http://wiki.openstreetmap.org/wiki/Mkgmap#Known_issues) I make no claim to authority here, so if I've made a mistake or mis-stated something please shout (or better, edit!). Whilst I would love to be able to contribute code to fix these problems, I'm not a java programmer (barely a programmer at all, to be honest). So at best, I can help by outlining the problems as clearly as I can. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map
Steve Ratcliffe (st...@parabola.me.uk) wrote: Hi I have started to implement adding features into the overview map. You can find ready built jar files on the download page and in the 'overview' branch in subversion. It creates the overview map from the .img (as before) and so it is very quick to try out even on a set of tiles covering a whole country. There is no configuration yet, it just takes everything (lines and polygons) that is in the least detailed layer of the detailed maps and adds it into the overview. You will immediately notice a big problem in that the overview map shows up even when the detailed maps are being displayed, so you get ugly jagged lines across the top of the map. I remember this happening the last time we has an overview map and I wonder if anyone can remember if there was a solution then? I'm going to start by trying the (so-called) POI flags, as one of those has been noted to be set differently on detail and base maps before. ..Steve Sounds intriguing. What precisely is the overview map for? -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Suugestion for default style: 660c for island instead of 650c
Marko Mäkelä (marko.mak...@iki.fi) wrote: On Tue, Jul 20, 2010 at 06:53:09PM +0200, Daniela Duerbeck wrote: Hi! In the german translation in the Oregon water features is translated with Gewässerarten, i.e. water types. I do not know whether this is the correct translation for water features but if, island should IMHO be a land feature not a water feature. Can you suggest a patch to resources/garmin_feature_list.csv then? It describes 0x660c as follows: point|0x10|0x66|0x0c|natural-land|gut|Gut Not being a native English speaker, I have no idea what this is supposed to mean. A small hill perhaps? I would say to leave it at 0x650c: there are other items in the 0x65-- series that are not obviously made of water (e.g. sand bar), but which are located in or near water. 0x650c is listed as island by cGPSmapper, but falls in the water based category in Mapsource / GPS. I guess it kind of makes sense as an island is in the water. 0x660x is listed by cGPSmapper as gut and is adjacent to other land features like gap, isthmus etc so I assume it means either some sort of cut-away in the land by the coast, or a promontory into the sea. As a native English speaker I can't say I've ever heard the term used in this way, but perhaps it's a specific geographical usage. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file and custom style
Frédéric Bonifas (fredericboni...@gmail.com) wrote: Hi, I am trying to use a custom TYP file with mkgmap. To learn, I am for now just trying to display toilets. So I did : * a TYP file, available here : http://ati.land.cz/gps/typdecomp/editor.cgi?_h=2678aeac15f92afa813cefcc5bb2b1d10f07b23c There is just a definition for toilets, and I use the type 0x4e00 * a style file, availbale here : http://fredericbonifas.free.fr/watsan.zip I just define a rule for amenity=toilets using the type 0x4e00 * Then I run mkgmap with : java -jar mkgmap.jar --family-id=4242 --style-file=resources/styles --style=watsan --gmapsupp bilbao.osm watsan.TYP I got no error generating the map, and the produced gmapsupp file is : But nothing appears on my GPS (Vista CX) Am I doing something wrong ? Use --style-file=resources/styles/watsan (--style=X is just for internal styles, not custom styles). I would also suggest you set the product ID of the TYP file to 1, though that may not be anything to do with it. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file and custom style
Frédéric Bonifas (fredericboni...@gmail.com) wrote: From charlie at cferrero.net charlie at cferrero.net on Tue Jul 20 11:22:48 BST 2010 Use --style-file=resources/styles/watsan (--style=X is just for internal styles, not custom styles). I would also suggest you set the product ID of the TYP file to 1, though that may not be anything to do with it. -- Charlie Thanks Charlie, I tried what you said but I still have nothing displayed. What POIs do you see in your map? You should see no POIs (except toilets). If you're seeing any other POIs, then mkgmap is not using your custom style. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing
Per Laustsen (p...@brugergruppen.dk) wrote: Neither Garmin Nüvi 205 or Etrex Legend HCx is stable searching address - sometimes it works but most times it does not. My GPSMap 76CSx will find a road (or multiple roads if they have the same name) and list the cities they are in, as long as I fill in a street number (I just use number 1). Some weird things happen, though. For instance if I search for streets beginning with S, I get two listings*: S S?? If I click on the S option, it takes me to a road called Sadaf If I click on the S?? option, it takes me to a road called Sayadan I compile maps with the --name-tag-list: name:en, int_name, name switch *This is in a map covering the GCC countries of the Middle East -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Online typ editor down, TYPViewer with trojan
Daniela Duerbeck (daniela.duerb...@gmx.de) wrote: Hi! The Online typ editor is down and the setup program of TYPViewer has a trojan: TR/Crypt.XPACK.Gen (Says Antivir) Is there another editor? One which allows to exchange icon images? Thanks a lot in advance, Dani Where are you downloading TYPViewer from? The version on opheliat.free.fr is (apparently) unchanged since 12th Feb 2010 and when I installed it a few months ago got no virus warnings (though that may be the fault of my anti-virus software). -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] leisure=recreation_ground
Daniela Duerbeck (daniela.duerb...@gmx.de) wrote: Hi! leisure=recreation_ground should be given 0x17 and not 0x19 because a recreation_ground is more similar to a village_green than to a stadium: http://wiki.openstreetmap.org/wiki/Tag:landuse%3Drecreation_ground Dani In the UK at least, a recreation ground is often used to play sport (cricket, football etc). The wiki definition An open green space for general recreation, which may include pitches, nets and so on, usually municipal but possibly also private to colleges or companies implies that sports activities take place on it, so in my view it makes sense for 0x19 to be used. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How to create POI detail information
NopMap (ekkeh...@gmx.de) wrote:
Hi!
aighes wrote:
you can add address-informaton and phonenumber by setting --index. Usefull
combination would be --location-autofill=1.
Yes, I found the hint that I can activate something with --index.
But what gets added to the details? How can I control what is added? And how
would I add some custom information like opening hours or a website for a
shop or elevation for landmarks?
bye
Nop
By default I think that for POI types that can accept address
information (0x2a00-0x32ff, afair), mkgmap looks for any addr: tags
and uses them to populate the address fields, plus it looks for a
phone tag and adds this too.
You can hack this behaviour by adjusting the style rules to use
different tags and get mkgmap to populate the POI address field with
these instead. For instance,
tourism=attraction {add addr:street='${note}'; add
addr:city='${description}'; name '${name} (${operator})' | '${name}'}
[0x2c04 resolution 23]
Sets the addr:street tag to contain whatever is in the note tag (if
there is one) and sets the addr:city tag to contain whatever is in the
description tag (again, if there is one). This means that if I look
at the POI details for tourism attractions, I see the note and
description, rather than an address.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error with overlays stylefile
On 20/06/2010 23:04, aighes wrote: Hello, I have a problem with overlays style file. I want to show an overlay for raods with cobblestones. In lines file I wrote: highway=primary surface=cobblestone [0x104 road_class=1 road_speed=1 resolution 16] highway=secondary surface=cobblestone [0x105 road_class=1 road_speed=1 resolution 18] highway=tertiary surface=cobblestone [0x106 road_class=1 road_speed=1 resolution 18] highway=unclassified surface=cobblestone [0x107 road_class=2 road_speed=4 resolution 19] highway=minor surface=cobblestone [0x107 road_class=2 road_speed=4 resolution 22] highway=residential surface=cobblestone [0x108 road_class=2 road_speed=4 resolution 20] highway=living_street surface=cobblestone [0x108 road_class=2 road_speed=4 resolution 22] and in the overlays file: 0x104: 0x04, 0x1A 0x105: 0x05, 0x1A 0x106: 0x06, 0x1A 0x107: 0x07, 0x1A 0x108: 0x08, 0x1A On 0x1A is the symbol, which should be show as an overlay and on 0x04 - 0x08 are the symbols of the normal roads. mkgmap throws out the Error: List of numbers expected in overlays file. Could someone tell me what I am doig wrong? Try adding an empty line to the end of your overlays file (just a carriage return should do it). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Display problem with Mapsource 6.16.1
On 14/06/2010 13:16, Peter Hendricks wrote: Thanks for your comment, Charlie. I will pass this back to the people who make the maps. I also have MapSource 6.16.1 and I don't get this problem, so it's not universal. When I have been messing around with self-generated maps in the past, I have seen this problem occur (with older versions of Mapsource) but that was due to the bounding box of my data not being converted to Garmin coordinates properly so the map border was offset from the actual map data. FWIW, I was able to recreate this problem by using the multipolygon version of generate-sea in mkgmap. I normally use the no multipolygon version of generate-sea because this creates a nice land polygon that covers the default Garmin yellow on my GPS (my GPS ignores any attempt to change the 0x4b polygon using a typ file). With generate-sea:no-mp, I have no problems. But with generate-sea multipolygon version, and MapSource 6.16.1, I get similar problems to those shown above, with blurry images when zooming in and out that are only resolved by refreshing the cache. To summarise. 1) No problems with blurry images, compiled using: generate-sea:no-mp,no-sea-sectors,extend-sea-sectors,close-gaps=1000 2) Blurry images when zooming in out, only solved by refreshing tile cache: generate-sea:extend-sea-sectors,close-gaps=1000 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Display problem with Mapsource 6.16.1
Peter Hendricks (beddh...@gmail.com) wrote: Hi, Sorry if this has been discussed before, but I did search the list and couldn't find any reference. I'm using maps from OSM, downloaded from here: http://garmin.na1400.info/routable.php Ever since I upgraded Mapsource to the latest I'm getting the screen corrupted when zooming in. Details are currently discussed here: http://forum.openstreetmap.org/viewtopic.php?pid=83694#p83694 I would have thought that the developers would be aware of this problem, but can't find any reference to it. Cheers, Peter. I also have MapSource 6.16.1 and I don't get this problem, so it's not universal. When I have been messing around with self-generated maps in the past, I have seen this problem occur (with older versions of Mapsource) but that was due to the bounding box of my data not being converted to Garmin coordinates properly so the map border was offset from the actual map data. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] append is_in tags to places
maning sambale (emmanuel.samb...@gmail.com) wrote:
Any style magic that can combine is_in tags to place/cities search like:
name= x town
place=town
is_in:state = y state
would be: x town, y state
place=town {name '${name}, ${is_in:state}' | name '${name}'} [0x...
name=z village
place=village
is_in:town: x town
is_in:state = y state
would be:
z village, x town, y state
place=village {name '${name}, ${is_in:town}, ${is_in:state}' | name
'${name}'} [0x...
Is that what you mean?
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] append is_in tags to places
Sorry, my mistake. Try
place=town {name '${name}, ${is_in:state}' | '${name}'} [0x...
and
place=village {name '${name}, ${is_in:town}, ${is_in:state}' |
'${name}'} [0x...
You could make the latter more sophisticated using
place=village {name '${name}, ${is_in:town}, ${is_in:state}' |
'${name}, ${is_in:town}' | '${name}, ${is_in:state}' | '${name}'} [0x...
This uses the town tag if the state tag is missing, or the state tag
if the town tag is missing, or if both town and state are missing it
just uses the name tag.
Yes this works, but,
place=town {name '${name}, ${is_in:state}' | name '${name}'} [0x...
if there are no is_in:state tags it defaults to Name
see here:
http://farm5.static.flickr.com/4048/4677736137_454b62bf62.jpg
name=z village
place=village
is_in:town: x town
is_in:state = y state
would be:
z village, x town, y state
place=village {name '${name}, ${is_in:town}, ${is_in:state}' | name
'${name}'} [0x...
same problem as above
--
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
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maintaining generated sea polygons
aighes (h.scholl...@googlemail.com) wrote: Yesterday germany had no coastline-problems ;) An easy way for correcting the errors would be the possibility to open the splitted osm-Files. Then you can fix the error direct (and afterwards in osm-database). There is no waiting for next planetfile. Now I draw in Mapsource rectangles of the flooded areas and generate an polygonfile via josm and osm2poly.pl. Then I separate the coastlines and split this file with the generated polygon-files. This file I can open in josm and search and fix the error. cu, aighes I don't suppose you fancy fixing Scotland do you? ;-) Someone broke the coastline somewhere near Edinburgh about a week ago and I'm damned if I can find the error. T'would be great if someone could write a methodology for fixing broken coastlines. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maintaining generated sea polygons
On 21/05/2010 07:14, Marko Mäkelä wrote: On Thu, May 20, 2010 at 10:57:54PM -0700, NopMap wrote: Therefore my question: Would it be possible to save the generated sea polygons to disk in osm format so an intact set of polygons can be re-used with future osm data? That way it could be ensured that future updates will have the same, correct sea polygons and not be randomly broken by temporary inconsistencies in the osm data. I've found this command useful: osmosis --rx finland.osm.bz2 --tf accept-ways natural=coastline --used-node --wx finland-coastline.osm The resulting file is small enough to be loaded to JOSM. I have also done something similar with boundary=administrative. Marko - how long should this take to run? I'm a newbie to osmosis but trying to fix some flooding in Scotland and this looks like the best method. However, osmosis doesn't really give any feedback on its progress and at the moment, I just have an empty output file and the process has been running for 10 minutes. -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
