Re: [mkgmap-dev] Commit r3728: treat waterway=drain like waterway=stream, not like waterway=river

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

[mkgmap-dev] rendering waterway=drain as stream

Hi, On the osm forum someone noticed that waterway=drain is rendered as river (0x1f), better is to use the same line as stream (0x18). Improvement for styles/default/inc/water_lines: waterway=stream | waterway=drain [0x18 resolution 22] Example OSM

Re: [mkgmap-dev] Adding the gmapi format.

I distribute my gmaps only with a gmap folder and my Mac OS X users never complain. I normally use family-name for the gmap folder name, I haven't tested the patch yet, can you configure this gmap folder name somehow (osmmap.gmapi by default)? ___

Re: [mkgmap-dev] Include "landuse=grass" in default style

gt; I see no problem with that change. I looked at other public styles and many > of them do exactly this. > I found one special case: Minkos openfietsmap style uses > (landuse=grass & source!=3dShapes) > > @Minko: Do you think this should also be used in the default style? U

Re: [mkgmap-dev] Lake Geneva

I have had the same problem with the Germany extract from Geofabrik (the Bodensee and part of the Rhine was empty). Caused by incomplete multipolygons at the border regions due to the cutting. I download those complete relations with overpass and add them to the germany-latest.osm.pbf with

Re: [mkgmap-dev] [Patch v2] improve roundabout checks

> BTW: The styles which add multiple routable ways for one OSM way will > probably never use > --check-roundabouts, and I assume that Garmin software will never show > reasonable exit counts for those styles > @Minko: Maybe this could explain the crashes when routing near roundabo

Re: [mkgmap-dev] render landuse=orchard

. and it looks just like a usable track > > If there is a track following the old line it will have its own > definition. > > Thanks > Ticker > > On Thu, 2016-07-28 at 16:26 +, Gerd Petermann wrote: > > Hi Minko, > > > > thanks, I agree and will commit t

[mkgmap-dev] render landuse=orchard

landuse=orchard is missing in styles/default/inc/landuse_polygons they can be rendered the same as farms, vineyards etc: landuse=orchard [0x4e resolution 20] Reported on http://forum.openstreetmap.org/viewtopic.php?pid=602085#p602085 ___ mkgmap-dev

Re: [mkgmap-dev] Roundabouts causes crashing devices

scratch... Henning wrote: > Hi Minko, > > I#m not completly sure, but I remember, there were long time ago > problems with 2 routable lines on same position. So in my map I changed > all routeable lines to transparent and used for showing highways etc. > non-routabl

Re: [mkgmap-dev] Roundabouts causes crashing devices

Thanks Bernd, I think your method of "every routable ways is an invisible line with overlay" will prevent those crashes. With my style I have used in case of roundabouts two routable lines on top of each other that might have caused those occasional crashes. The same with bike routes on top of

Re: [mkgmap-dev] Roundabouts causes crashing devices

Thanks Gerd, I can't open your track but both roundabouts don't look too complicated with too many nodes and I don't render bus routes, so I think it could be caused with the two routable lines on top of each other in my styles. In the NL's many roundabouts have cycle routes on them I thought

Re: [mkgmap-dev] Roundabouts causes crashing devices

Hi Gerd, Interesting to hear because on Sicily there are hardly any cycle routes, if any, on OSM, so it could be also associated with something else. Can you give just the location of that particular roundabout on the osm.org map so I can see if there are similarities with other roundabouts?

[mkgmap-dev] Roundabouts causes crashing devices

Hi list, Many users of my Openfietsmap are reporting crashes when approaching roundabouts. Some notice it before they enter the roundabout, others report that the device dies on the roundabout itself. In many cases those roundabouts are with cycle routes, so I have removed the bicycle routes

Re: [mkgmap-dev] make the gmapsupp visible/invisible in Basecamp

With a few external tools you can set this, http://www.gmaptool.eu/en/content/map-visible-basecamp or http://www.javawa.nl/jdm_en.html Don't know if such option could be implemented in mkgmap? > Hi developers, > is there an option to make the gmapsupp visible/invisible in Basecamp? > At the

Re: [mkgmap-dev] Has anyone added a USA TIMEZONE overlay ontop of their custom maps?

You can import a shp file into JOSM. Edit those polygons by splitting them into lines (I suppose you dont need to see 0x19 lines along the coast line). Give those lines an appropriate tag (e.g. timezone=yes, name="GMT +2") Save it as osm file, DO NOT upload it to OSM! Run splitter/mkgmap on

Re: [mkgmap-dev] Create Test map

Hi Dave, I make a small map in JOSM with all the features I want to test and save it as *.osm file (without uploading it!). You can then execute mkgmap on this osm test file. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] "mirror" problem with GPS

It's a bug. I complained several times at Garmin but they have never solved it, seems they don't care. - demon.box schreef: > Hi, excuse me, do you think there is a reason why this line (0x10505) it's ok > in MapSource and BaseCamp: > >

Re: [mkgmap-dev] osm combiner error

Thanks Steve, It seemed the user had both versions installed... > > What does Unsupported major.minor version 51.0 mean? > > This happens when you try to run with Java 6 or lower. I realise that he says > he on the latest version of Java and the previous version of osm combiner > was running OK,

[mkgmap-dev] osm combiner error

Hi, On the osm forum someone reported this error with OSM combiner (http://www.openfietsmap.nl/news/osmcombiner) (mkgmap r.3654) http://forum.openstreetmap.org/viewtopic.php?id=30632 What does Unsupported major.minor version 51.0 mean? -- Unfortunately the new OSM Combiner 1.8

Re: [mkgmap-dev] intermittent waterways

Yes, here is an example of Mapsource and Oregon 600, in Basecamp/Mapsource the intermittent stream is rendered as dashed blue line, on my Oregon a solid blue line, but with a label showing "intermittent" (without typ file): https://www.dropbox.com/s/mrf74mgmvhhq1km/intermittent.jpg?dl=0 > Did

[mkgmap-dev] intermittent waterways

Hi On the osm forum a request was made to render intermittent waterways, see http://forum.openstreetmap.org/viewtopic.php?id=53986 We can add this code before the waterway lines in the default style (default/inc/water_lines): (waterway=river | waterway=canal) & intermittent=yes [0x26 resolution

Re: [mkgmap-dev] Routes being overwritten

I think you mean track instead of route? Tracks are displayed on top. - Gary Bamford schreef: > Thanks for the prompt reply. > > Mmm. I am pretty sure when I use a walking route ( as opposed to a > autogenerated "Take me to" ) , it is on top of everything, I am

Re: [mkgmap-dev] Routes being overwritten

You didnt do anything wrong, the route line of those older units are always under the road. Newer units will display it on top of the roads. - Gary Bamford schreef: > I am producing maps using Mkgmap and Openstreetmap data. the maps I am happy > with, lovelly

Re: [mkgmap-dev] Oneway arrows

3=0x02,Hauptverbindungsstraße ExtendedLabels=Y FontStyle=SmallFont CustomColor=No [end] - Oorspronkelijk bericht - Dave wrote: @Minko - But Greg says he gets the results I want with the rules he's using. So how to explain that? ___ mkgmap

Re: [mkgmap-dev] Oneway arrows

The problem is that most Garmins don't display a bitmap on top of a vector line (esp. the major highway types like 0x01, 0x02 etc will be put on top of other lines). So you have to place the arrow on one side of the underlying highway, instead of in the center. See the typ file of the new

Re: [mkgmap-dev] Splitter: Assertion on very large node id

Problem is corrupt data in the Vlaanderen set: lon min: 2.3066895 lon max: 200.000 lat min: -120.4967296 lat max: 103.000 I have fixed it with osmconvert (bbox around Belgium) https://github.com/ligfietser/mkgmap-style-sheets/commit/bd945183cdfc704d0ff6dc8190e463f31b9ee0ce

Re: [mkgmap-dev] Anyone determine which linetypes are NOT visable in BaseCamp?

h hex code 0x1007 that is then > assigned via a style rule to an OSM way? > If I do not then I agree; I don't understand anything about TYP files. > Can you explain in a little more detail what you are trying to tell me? > On Sat, Feb 27, 2016 at 4:45 PM, Minko < ligfiet...@online.nl

Re: [mkgmap-dev] Anyone determine which linetypes are NOT visable in BaseCamp?

See also http://www.openfietsmap.nl/tips-tricks/customize - Oorspronkelijk bericht - > Hi Dave, > it seems you don't understand the meaning of TYP file. > It is used to define how POI / lines / areas are displayed (in Basecamp and > the device). > Such a file is not part of the

Re: [mkgmap-dev] POI (point) resolution problem

In Mapsource this won't be an issue, only in Basecamp many POIs cannot be controlled by mgkmap anymore. Also on modern devices like the Oregon 6xx setting the POI levels on automatic will lead to cluttered maps. See for instance this example of noexit=yes [0x5800 resolution 24] in Basecamp:

Re: [mkgmap-dev] TYPViewer

You can probably find the latest versions and contact the developer here: http://www.gpspower.net/creating-maps/218482-typ-viewer.html > > I decided to download TYPViewer. Following the link in the wiki took me to > > sites.google.com/site/sherco40/ . This page states the latest version is > >

Re: [mkgmap-dev] Will you please include water thanks in future releases.

I think in the default mkgmap style water towers can be added the same as man_made=tower: man_made=tower|man_made=mast|landmark=chimney|man_made=water_tower [0x6411 resolution 24] (IMHO man_made=mast could be removed in this rule, all those gsm antennas will clutter the map)

Re: [mkgmap-dev] [Patch v1] reduce line distortion

Thanks for the fix Gerd! For an example of this fixed issue, see http://www.dropbox.com/s/ny2c769np3zq40k/bug_fixed.jpg?raw=1 Gerd wrote: > I think a distance of less than 0.4 m is not visible, and nearly all > calculated points are > now closer than that. > A binary based on r3658 is here: >

Re: [mkgmap-dev] landuse=farmland

; <f...@zz.de> > Aan: "Minko" <ligfiet...@online.nl> > Cc: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> > Verzonden: Vrijdag 4 december 2015 09:41:01 > Onderwerp: Re: [mkgmap-dev] landuse=farmland > > On Fri, Dec 04, 2015 at 0

[mkgmap-dev] landuse=farmland

Please add landuse=farmland, it has replaced landuse=farm some time ago: http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dfarmland /styles/default/inc/landuse_polygons landuse=farm | landuse=farmland [0x4e resolution 20] ___ mkgmap-dev mailing list

Re: [mkgmap-dev] landuse=farmland

Sounds good to me Gerd, I already do this for my Openfietsmap > OK, will do that. I wonder why we have > landuse=farmyard [0x4e resolution 22] > > Wouldn't it be better to use a different type, maybe 0x10 (residential) ? > > Gerd ___ mkgmap-dev

Re: [mkgmap-dev] feedback on sharp-angles-v4.patch?

Hi Gerd, I have tested it a bit and noticed some improvements in routing at sharp corners. Haven't seen any major differences or issues yet, i think it's a good improvement. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] feedback on sharp-angles-v4.patch?

I have tested it with --cycle-map What is the difference vs without this option? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] feedback on sharp-angles-v4.patch?

Hi Gerd, My highest road_speed value is 3. Maybe this is why this option doesn't make very little difference, if any at all? > Hi Minko, > > if you can't find any, that is also telling me that the option is rather > useless. > > With --cycle-map mkgmap might produce l

Re: [mkgmap-dev] feedback on sharp-angles-v4.patch?

Hi Gerd I've tried to run it but cycle-map is not a valid option? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] feedback on sharp-angles-v4.patch?

Sorry my fault, I have used the wrong/older mkgmap jar file, now it is running... > Hi Gerd > I've tried to run it but cycle-map is not a valid option? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] [Patch v0] fix sharp angles to optimise bicycle routing

Thanks Gerd, I have tested only a small bit but it looks promising. It now routes via very sharp corners like this link: https://graphhopper.com/maps/?point=52.194495%2C5.432616point=52.191588%2C5.43437point=52.192893%2C5.434665vehicle=bikelocale=nlelevation=truelayer=OpenStreetMap With the

Re: [mkgmap-dev] bicycle=use_sidepath

For the Netherlands bicycle=use_sidepath should definitely be set to no; Unconnected or not drawn cycleways in combination with bicycle=use_sidepath on the main highway are mapping errors on OSM and should corrected in the database. ___ mkgmap-dev

Re: [mkgmap-dev] routing bug after r3602

Thanks for the quick fix Gerd! - Oorspronkelijk bericht - Hi Minko, this one was hard to find, as the error was not in the housenumber code itself. See svn comments for r3625: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmaprev=3625 Gerd

[mkgmap-dev] routing bug after r3602

Hi, On the Dutch osm forum a routing bug was reported, http://forum.openstreetmap.org/viewtopic.php?id=31714 It is this route in Amsterdam: http://osrm.at/dR7 I have traced it down and found out that this bug is introduced between mkgmap-r3602 and r3616, the car routing now makes a detour via

Re: [mkgmap-dev] Object labels and zoom levels

Hi Carlos, For my Openfietsmap I use different lines for highways at different zoom levels. The lines you see when you zoom out have invisible street name labels. Only the highway lines with visible (small font) streetnames are in the highest zoomlewvels (22-23-24) You can set the names of the

Re: [mkgmap-dev] Rendering of islands

Albrecht, You can use the osm generic (default) type file from garmin.openstreetmap.nl: https://github.com/ligfietser/mkgmap-style-sheets/tree/master/typ/osm%20generic Not sure if the Island polygon (0x53) from this typ file is wrong, too. Am 07.06.15 21:07 schrieb(en) Gerd Petermann: AKAIK

Re: [mkgmap-dev] [Patch v1] simplify address rules

Correction: admin_level9 must be placed before admin_level8 Hi Gerd, I think admin_level9 must be placed before admin_level9 for Belgium: mkgmap:country=BEL mkgmap:city!=* mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } ___

Re: [mkgmap-dev] [Patch v1] simplify address rules

Hi Gerd, I think admin_level9 must be placed before admin_level9 for Belgium: mkgmap:country=BEL mkgmap:city!=* mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } It makes no sense to have a specific rule mkgmap:country=BEL mkgmap:city!=* mkgmap:admin_level8=* { set

Re: [mkgmap-dev] [Patch v1] simplify address rules

://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data/The_AGIV_Crab_Import_Website Hi Minko, I analysed your proposal with some tiles. It seems that your version is better, but I still see many objects where addr:city is set to a different value than mkgmap:city. Your

Re: [mkgmap-dev] OT: tool to split gpx file ?

Gerd, try this tool http://antocuc.github.io/GpxSplitter.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] index problem camp_site

I found out that type 0x2b03 is not indexed on many devices, 0x2b05 is listed and rendered as campground too. So if this is not a mkgmap bug, it should be an easy fix to change this in the default style. may be there are different codes for oregon and others for the caravan site and camp

Re: [mkgmap-dev] index problem camp_site

If I search on google with 0x2b05 Garmin it seems this issue appeared elsewhere too. It seems there is another alternative for campgrounds, poi range 4800 to 0x48ff, dont know how this is handled on the devices. 0x2b05 is already in use as tourism=lean_to [0x2b05 resolution 24 default_name

[mkgmap-dev] index problem camp_site

Hi, On the OSM forum someone found out that on some Garmin devices tourism=camp_site and tourism=caravan_site [0x2b03] cannot be found. See http://forum.openstreetmap.org/viewtopic.php?id=31093 http://forums.gpsreview.net/discussion/29752/campsite-pois-do-not-show-on-gpsmap-64s On the device's

Re: [mkgmap-dev] EU map too big?

...@hotmail.com Aan: mkgmap-dev@lists.mkgmap.org.uk Verzonden: Donderdag 14 mei 2015 10:41:13 Onderwerp: Re: [mkgmap-dev] EU map too big? Hi Minko, seems we first have to find out which file is causing the problem. I try to add some code so that a name is reported when the error occurs

Re: [mkgmap-dev] EU map too big?

Aan: mkgmap-dev@lists.mkgmap.org.uk Verzonden: Donderdag 14 mei 2015 10:03:28 Onderwerp: Re: [mkgmap-dev] EU map too big? Hi Minko, hmm, there is no need to create the ovm_* files again. Maybe the problem is not the overview map? Please double check that you use r3595. The limit

Re: [mkgmap-dev] EU map too big?

Hi Gerd, Probably something went wrong the first time. I now managed to produce a full map with all the tiles and mkgmap-r3595. Thanks again for the quick fixes! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI

Hi Gerd, There is something weird happening with this version r3573, maybe a bug or maybe a fault in my styles? The name of London disappears and becomes England, http://www.openstreetmap.org/relation/58447 I see the same for Edinburgh which becomes Scotland. Any idea what went wrong here?

Re: [mkgmap-dev] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI

Yep, I see with GPSMapedit those two points at the same place. In Mapsource it seems random at which zoomlevel which placename is shown, either London (which I prefer) or England. I notice the same for Scotland but I guess in many other countries or regions this will be an issue too. Thanks for

Re: [mkgmap-dev] Commit: r3590: ignore position of role=admin_centre node when name of

Working as expected, thanks for the quick fix Gerd! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] EU map too big?

Hi Gerd, There was no problem when I skipped about 200 tiles (~1,5 Gb), the index was created. So the limit seems to be around 2000 tiles / 10 Gb of data. I will try to skip split-name-index, lets see if that will work... ___ mkgmap-dev mailing list

Re: [mkgmap-dev] --make-opposite-cycleways option

- Oorspronkelijk bericht - Van: Gerd Petermann gpetermann_muenc...@hotmail.com Aan: mkgmap-dev@lists.mkgmap.org.uk Verzonden: Dinsdag 3 maart 2015 09:26:00 Onderwerp: Re: [mkgmap-dev] --make-opposite-cycleways option Hi Mike, I think you are right regarding the access tags. The

Re: [mkgmap-dev] --make-opposite-cycleways option

Yes Gerd, you are right. I didnt find any workaround to solve this. But at least there is a workaround to delete those artificial cycleway names, should be set in the default style rules too imho (if anyone likes to see those names, just put a # before that line).

Re: [mkgmap-dev] Adresssearch with new bounds 20.0.15

Hi, I informed the maintainer (Lambertus from garmin.openstreetmap.nl) about this buggy version of the bounds file. Thanks for reporting the issue. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] difference between addlabel and poi-address

Gerd wrote: I see that mkgmap fills the address info, and it also seems to write it, but MapSource seems to ignore it. I have no experience with this. Maybe this happens because of the big number of POIs? Yes, not all pois are capable of showing address data, please check this extensive

Re: [mkgmap-dev] minxed-index branch ready for trunk?

I have tested a gmapsupp.img created by mkgmap on my Oregon. It can't find any street when skipping the place name, so it seems you need to specify the place name, otherwise it wont work. This does not happen with the trunk version, it can also find streets if no place name is entered. With a

Re: [mkgmap-dev] How to show land and see

The land polygon is defined as 0x4b and it is the only polygon with draw-prio = 1. The sea polygon is defined as 0x32 and it has draw-prio = 2. I have the opposite, sea prio 1 and land 2, maybe that helps? You could also try another polygon for land, 0x27 or an extended one like 0x10100

Re: [mkgmap-dev] multi-word street search

Andrzej, I hope this will be committed soon, would be a great improvement for mkgmap search. Even better if it also works for address search. Hi, I have decided to try simple solution for this problem. I have modified addStreet() procedure in file imgfmt\app\mdr\MDRFile.java. While I

Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers

Problem here is that mkgmap:bicycle=no is overruled by bicycle=yes later in the access rules, imho there is an issue in the styles. So I have to add set bicycle=no motorcar=no etc if I use set access no which I find a bit unlogical. ___ mkgmap-dev

Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers

Gerd wrote: I tried route=ferry (motorcar=no | motor_vehicle=no | foot=yes access=no | foot=yes vehicle=no) {add mkgmap:ferry=1} [0x1b road_class=0 road_speed=0 resolution 23] route=ferry {add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 19] but this still doesn't catch

Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers

route=ferry foot!=no {set foot_ferry=yes; set foot=no; add mkgmap:ferry=1 } [0x1b road_class=3 road_speed=0 resolution 19 continue with_actions] route=ferry foot_ferry=yes {setaccess=no; set foot=yes} [0x1b road_class=0 road_speed=0 resolution 23] Oops, I forgot something. Above rules

Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers

More improvements: It seems setaccess=no is not the correct command (?), so I changed it into setaccess no Then it turns out that in the finalize section mkgmap notice the tag bicycle=yes and converts it into mkgmap:bicycle=yes, so it somehow switches the bicycle access flag back off (means

Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers

Thanks Gerd, I forgot a few other combinations: access=no foot=yes vehicle=no foot=yes Of course if cars AND pedestrians are allowed, routing will still be problematic in hiking mode, but with these rules we can eliminate the problems on foot/bike ferries. Also note that in bicycle mode this

[mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers

In the Belgium OSM forum someone reported that in the hiking profile ferry connections are avoided. http://forum.openstreetmap.org/viewtopic.php?id=26980 I noticed in Basecamp that the road_class=3 might be the reason for this (=main highways). In the internal routing routines of the Garmin

Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers

Oops. I forgot it was set in the water_lines ;-) https://github.com/openstreetmap/mkgmap/blob/master/resources/styles/default/inc/water_lines So I suggest to add route=ferry (motorcar=no | motor_vehicle=no) {add mkgmap:ferry=1} [0x1b road_class=0 road_speed=0 resolution 19] before this

Re: [mkgmap-dev] Incorrect runabout exit indication

Johan, Did you experience this issue also in the Generic Routable (old style) or only in the new style? BTW Lambertus produces his maps with mkgmap, r3336 is the version he also used in the latest release. ___ mkgmap-dev mailing list

Re: [mkgmap-dev] Incorrect runabout exit indication

Gerd, The new styles for Lambertus you can find here: https://code.google.com/p/mkgmap-style-sheets/source/browse/#svn%2Ftrunk%2Fstyles%2Fworld The issue could be that there are two lines used for roundabouts: https://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/styles/world/lines

Re: [mkgmap-dev] building catch all

Thanks Steve, These should be added to the polygon style file: man_made=* area!=no (man_made!=door man_made!=embankment man_made!=breakwater man_made!=cable_line man_made!=cutline man_made!=cutting man_made!=levee man_made!=trench man_made!=groyne

Re: [mkgmap-dev] building catch all

Can someone commit this to the styles, tourism areas and grave yards are still rendered as buildings. In the polygons file, I would suggest to change these lines: - (building=* | amenity=*) area!=no [0x13 resolution 24] - tourism=* area!=no waterway!=* [0x13 resolution 24] +

[mkgmap-dev] AssertionError on turn restriction

When I enable assertions (-ea) in my java command, mkgmap-r3300 is not able to produce one tile and gives an java.lang.AssertionError. I found out that the problem was this turn restriction relation, with type=restriction:motorcar restriction=only_straight_on

Re: [mkgmap-dev] building catch all

In the polygons file, I would suggest to change these lines: - (building=* | amenity=*) area!=no [0x13 resolution 24] - tourism=* area!=no waterway!=* [0x13 resolution 24] + (building=* | amenity=*) area!=no amenity!=grave_yard [0x13 resolution 24] + tourism=* area!=no waterway!=* [0x1f

Re: [mkgmap-dev] route=ferry not working

I use route=ferry seasonal!=* route=ferry {add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 24] without any problems. There are a lot of people complaining about non seasonal ferries so I've added this tag to make those ferries that do not go during winter times not routable.

Re: [mkgmap-dev] route=ferry not working

PS I made a small mistake with copy/paste, it should be route=ferry seasonal!=* {add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 24] A few reasons that ferries are not routable: - Bad connections on OSM - Ferry lines are only connected by footways where you get/on off the

Re: [mkgmap-dev] route=ferry not working

I think the main problem on this german forum topic, there are two routable lines used on top of each other. This might leading to conflicts. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] building catch all

Chris wrote Hi, at the end of polygons we have some catch all rule: (building=* | amenity=*) area!=no [0x13 resolution 24] tourism=* area!=no waterway!=* [0x13 resolution 24] # man_made can be used on areas or lines man_made=* area!=no (man_made!=door man_made!=embankment

Re: [mkgmap-dev] building catch all

I wrote: 0x1a is indeed the common Garmin tag for graveyards, I wonder why this isnt listed anymore? I noticed it is rendered AFTER (building=* | amenity=*) area!=no [0x13 resolution 24] in the landuse_polygons, so this line should be corrected too (move before the processing of

Re: [mkgmap-dev] Nursing in the waterpark

ok, alternatively we could map nursing_home to hospital (0x3002), but I'm fine with your suggestion. Chris I dont think hospital is a good one. What if there is an emergency and they are navigating to a nursery home? ;-) Can somebody commit these changes to the default style?

Re: [mkgmap-dev] Nursing in the waterpark

Because 0x3002 is for hospitals, it's logical to put a nursing home in the same category for medical care. But if you use the map in search for emergency this would lead you to the wrong place. So thats why I think it's better to put it under community center: a nursing home often facilitates

Re: [mkgmap-dev] Nursing in the waterpark

in my area, most nursing homes are driven private (profit oriented) , so I don't like the idea to put them under community. My Oregon 450t shows a category Others - Social Service I think this would be a good place for nursing homes, but I don't know the Garmin code for it. I can live

Re: [mkgmap-dev] Nursing in the waterpark

Good question Chris. That doesn't make any sense to me either ;-) Suggestion: amenity=nursing_home [0x3005 resolution 24] (can be found under community) leisure=water_park [0x2b04 resolution 24] (same as swimming pool) Hi, why do we map amenity=nursing_home and leisure=water_park to the

Re: [mkgmap-dev] Nursing in the waterpark

Suggestion: amenity=nursing_home [0x3005 resolution 24] (can be found under community) leisure=water_park [0x2b04 resolution 24] (same as swimming pool) Correction: leisure=water_park [0x2d09 resolution 24] ___ mkgmap-dev mailing list

Re: [mkgmap-dev] new bicycle access rules

A few days later the tag is used 2 140x already I guess it could be implemented in the default style now? Minko wrote: Maybe none in the UK, but according to this site, 882 values (mainly in Germany) https://taginfo.openstreetmap.org/tags/?key=bicyclevalue=use_sidepath http://overpass

[mkgmap-dev] how to replace false tracktype keys in style file?

I've noticed there are a lot of tagging mistakes have been made on OSM regarding tracktype={number} instead of tracktype=grade{number} Is there a simple formula (with regedit?) to replace this, like tracktype=1-5 tracktype=grade(1-5) in the styles? At the moment I ignore those false keys but I

[mkgmap-dev] new bicycle access rules

This week a new tag has been approved, bicycle=use_sidepath https://wiki.openstreetmap.org/wiki/Proposed_features/use_sidepath This tag will be used on main highways with compulsory adjacent cycleways. There were a lot of objections to tag these with bicycle=no because there are also other ways

Re: [mkgmap-dev] how to replace false tracktype keys in style file?

Hi Henning, Can you give an example for such rule in the style file, my knowledge of regexp is very limited ;-) How can you check if the tags are valid, like grade[1-5] is ok, and the rest is not ok? And can you automatically convert 1 to grade1 etc in one line, without having to type all the

Re: [mkgmap-dev] new bicycle access rules

Andy wrote Surely the standard mkgmap settings should ignore wikifiddled values such as this until they're actually in wodespread use? Currently it doesn't seem to be used at all: http://taginfo.openstreetmap.org.uk/search?q=use_sidepath#keys Maybe none in the UK, but according to this

Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

I think these pages could be a good start, but they need to be updated: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types http://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Polyline_Types

Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

Hi Gerd If I got that right, we should 1) warn when the style file lines uses types 0x02 - 0x09 without road class/speed if -check-styles is used 2) warn if a line is added multiple times, once with type between 0x01 and 0x3f and road class/speed, once with type 0x02 - 0x09 and without

Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

that sounds like the original list was not so bad: //return type = 0x01 type = 0x13 || type == 0x1a || type == 0x1b || type == 0x16; what about 0x16, 0x1a and 0x1b ? 0xa is in the range 0x01 - 0x13. Is this really an exception? And is it the only one? Hi Gerd 0x16: routing error 0x1a:

Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

what about 0xa ? Or was that meant to be 0x1a ? Hi Gerd 0x0a gives also a routing error, so everything in the range 0x01-0x13, 0x16 and 0x1b ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

Hi Gerd I found out that the routing errors still exist when you have two routable lines on top of each other, one with and one without road speed/class parameters. If the GPS finds an address on such road, routing goes mad. In my style I use type 0x02 for all cycleroutes. I need to use 0x02

  1   2   3   4   5   6   7   8   9   >