Re: [mkgmap-dev] New branch for default typ file
Hi Greg, On Tue, 27 Nov 2018 at 18:21, Greg Troxel wrote: > Semi-related, I am carrying a diff to render "boundary=parcel"; I > include state parcel boundary data with osm data in splitter. I have no > idea how many others want this, but given that parcel data is not in > OSM, merging while mapbuilding (or a separate transparent parcel map) > seems pretty useful. What I'm doing is not really ok, but I'm just > mentioning the concept. > I realize this is a bit off-topic on this thread but I'm curious to know your process for combing non-OSM data with splitter. I was just starting a project to add some non-OSM data to my maps but I thought the only way to do this was with osmosis, combining a generated change file with the real data. Is your process documented somewhere? If not, do you mind sharing it here? Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] TYP filename too long
Hi, A user recently reported that my maps weren't able to be installed with BaseCamp (error: "The data was not successfully sent"). It turns out that name of the TYP file was too long; the MapSetToolkit program reported an error on the OpenMapChest registry entries: openmapchest.typ - 12+3 characters. After renaming the TYP file to omc.typ in a new build, transferring worked correctly. It would be nice if mkgmap truncated TYP file names that are too long. I think the maximum length is the old DOS standard of 8+3 characters. I'm using a relatively old version of mkgmap (3909) so this might already be fixed. But in case it's not, I thought I would report it. Thanks for all your hard work on mkgmap! Regards, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] no cities found on large areas with --x-split-name-index option
On Tue, Jul 5, 2016 at 3:24 PM, Thorsten Kukuk <ku...@suse.de> wrote: > > I guess if you search for cities in the near, they are still shown? > Yeah, I can see the cities but I can't search for them by name. It might be a good idea for mkgmap to print a warning or fail when the index gets too big. But as you said, this might be device specific so it might not be possible to know exactly where the limit is. Thanks for passing along this info. Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] no cities found on large areas with --x-split-name-index option
Hi, I ran into a problem with the --x-split-name-index option. When I build the geofabrik extract for Ontario with the following options, the 'Where to -> Cities -> Spell Name' works properly. http://download.geofabrik.de/north-america/canada/ontario-latest.osm.pbf java -jar splitter/dist/splitter.jar --geonames-file=cities1000.zip --output=o5m --mapid=20244000 --max-threads=1 --status-freq=0 --max-areas=50 ontario-latest.osm.pbf java -jar mkgmap/dist/mkgmap.jar --route --add-pois-to-areas --bounds=bounds_20160628.zip --index --gmapsupp --housenumbers -c template.args --x-split-name-index --description="Ontario Test" When I build the geofabrik extract for Canada with the same options, the 'Where to -> Cities -> Spell Name' doesn't work. http://download.geofabrik.de/north-america/canada-latest.osm.pbf java -jar splitter/dist/splitter.jar --geonames-file=cities1000.zip --output=o5m --mapid=20244000 --max-threads=1 --status-freq=0 --max-areas=50 canada-latest.osm.pbf java -jar mkgmap/dist/mkgmap.jar --route --add-pois-to-areas --bounds=bounds_20160628.zip --index --gmapsupp --housenumbers -c template.args --x-split-name-index --description="Canada Test" For the map of Canada, the cities still show up in the list but they aren't found if you search for them. Removing --x-split-name-index fixes the problem. It's not a huge issue because I can just remove this option but I did want to report the problem to you. Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] hospital POI improvements
Hi Regunathan, My guess is that Ayurvedic facilities would fall under amenity=clinic. There would need to be a specific tag for Ayurvedic facilities to be able to add a new mkgmap style rule with one of the medical POIs in the range 0x4B00 - 0x4BFF. I would get in touch with the Sri Lanka OSM group to see how to best tag these facilities. https://wiki.openstreetmap.org/wiki/Sri_Lanka In the meantime, if Ayurvedic facilities are tagged amenity=clinic, this patch will ensure they are not listed in 'Where am I? -> Hospitals'. Ben On Sat, Feb 13, 2016 at 11:26 AM, Regunathan Umapathy <umapath...@gmail.com> wrote: > Hi, > I also marked amenity=doctors for the Primary Health care centers here in > Vavniya, Northern Sri Lanka. I also seen some of the openstreetmap > contributors mapped clinics (amenity=clinic) in Jaffna northern Sri Lanka. > Is there any way to distinguish them in garmin maps with the hospitals. > Also there are hospital but not practising modern medicine but traditional > ones here in Sri Lanka known as Ayurvedic (Mostly from herbs they create > medicine), Is there any way to distinguish them because they don't help > much during emergency (for example road traffic accidents) as most of them > do not have any ambulance and they generally also don't treat the > bleedings. > , > > On Sat, Feb 13, 2016 at 3:23 PM, Ben Konrath <b...@bagu.org> wrote: > >> I didn't type the correct git command. Here's the actual patch. :) >> >> >> >> On Sat, Feb 13, 2016 at 9:59 AM, Ben Konrath <b...@bagu.org> wrote: >> >>> Hi, >>> >>> I found a problem with the hospital POIs in the default style. When you >>> use the 'Where am I? -> Hospitals' functionality, all hospitals, clinics, >>> dentists and doctors show up in the list. The 'Where am I?' seems like it's >>> something I would use in an emergency so it makes sense to only add >>> hospitals with the 'emergency=yes' tag. This patch also splits out >>> hospitals without emergency departments, clinics, dentists, doctors and >>> other healthcare providers into separate POIs so people can update the TYP >>> file if they want. >>> >>> I tested this patch on my Nuvi 255w and it seems to work. Only hospitals >>> tagged with 'emergency=yes' show up in the 'Where am I? -> Hospitals' list. >>> The other POIs turn up with the same heath care plus icon. The only >>> downside I can see is that not all hospitals are correctly tagged with >>> 'emergency=yes' so these won't be in the 'Where am I? -> Hospitals' list. >>> In my mind, this a problem with the data and there's not much to do about >>> except fix it in OSM. >>> >>> Comments and suggestions are appreciated. >>> >>> Thanks, Ben >>> >>> >> >> ___ >> mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > > > -- > Regards > Regunathan Umapathy (Uma) > Visit: http://www.panoramio.com/user/69195 > > > ___ > 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] [patch] hospital POI improvements
Hi, I found a problem with the hospital POIs in the default style. When you use the 'Where am I? -> Hospitals' functionality, all hospitals, clinics, dentists and doctors show up in the list. The 'Where am I?' seems like it's something I would use in an emergency so it makes sense to only add hospitals with the 'emergency=yes' tag. This patch also splits out hospitals without emergency departments, clinics, dentists, doctors and other healthcare providers into separate POIs so people can update the TYP file if they want. I tested this patch on my Nuvi 255w and it seems to work. Only hospitals tagged with 'emergency=yes' show up in the 'Where am I? -> Hospitals' list. The other POIs turn up with the same heath care plus icon. The only downside I can see is that not all hospitals are correctly tagged with 'emergency=yes' so these won't be in the 'Where am I? -> Hospitals' list. In my mind, this a problem with the data and there's not much to do about except fix it in OSM. Comments and suggestions are appreciated. Thanks, Ben mkgmap-hospital-poi-improvements.patch Description: application/download ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Will you please include water thanks in future releases.
Hi Gerd, You're right, that is not correct. I'm actually not sure how I came up with that. I think I may have been trying to limit 0x6411 to communication towers but used landmark=chimney instead of man_made=mast. In any case, here's my proposal for an updated rule to match all towers: man_made=tower | man_made=communications_tower | man_made=mast | man_made=water_tower | landmark=chimney [0x6411 resolution 24] If somebody wants a different icon for water towers, they can remove man_made=water_tower and create a separate rule (with TYP icon). What do you think? Thanks for spotting the problem. Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Will you please include water thanks in future releases.
Hi Gerd, 0x6411 is a tower. The first 2 lines look good. It would also be ok for me if the chimney POI is not included. If it is included, you might want to use the man_made=chimney tag as it's more common like you said. man_made=tower | man_made=communications_tower | man_made=mast [0x6411 resolution 24] man_made=water_tower [0x6411 resolution 24 default_name 'Water'] man_made=chimney | landmark=chimney [0x6411 resolution 24 default_name 'Chimney'] Ben On Fri, Feb 5, 2016 at 12:01 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Ben, > > > I think you meant man_made=chimney which is far more often used. > > I did not yet check what icon 0x6411 means, but I think that it cannot > work to have > > one icon for all these objects. I think the style might add different > default names, e.g. > > man_made=tower | man_made=communications_tower | man_made=mast [0x6411 > resolution 24] > > man_made=water_tower [0x6411 resolution 24 default_name 'Water'] > > landmark=chimney [0x6411 resolution 24 default_name 'Chimney'] > > Don't know if the Garmin device knows how to translate Chimney ? > > > Gerd > > > -- > *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < > mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ben Konrath < > b...@bagu.org> > *Gesendet:* Freitag, 5. Februar 2016 11:47 > *An:* Development list for mkgmap > *Betreff:* Re: [mkgmap-dev] Will you please include water thanks in > future releases. > > Hi Gerd, > > You're right, that is not correct. I'm actually not sure how I came up > with that. I think I may have been trying to limit 0x6411 to communication > towers but used landmark=chimney instead of man_made=mast. > > In any case, here's my proposal for an updated rule to match all towers: > > man_made=tower | man_made=communications_tower | man_made=mast | > man_made=water_tower | landmark=chimney [0x6411 resolution 24] > > If somebody wants a different icon for water towers, they can remove > man_made=water_tower and create a separate rule (with TYP icon). What do > you think? > > Thanks for spotting the problem. > > Ben > > ___ > 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] Will you please include water thanks in future releases.
Here's what I'm using for towers which I've been meaning to post and contribute to mkgmap:. > man_made=tower | man_made=mast | man_made=communications_tower | > (landmark=chimney & communication:mobile_phone=yes) | (landmark=chimney & > communication:microwave=yes) [0x6411 resolution 24] > This rule includes updates for rules about communication towers. In my opinion man_made=mast fits in this rule because items with this tag should be a full tower as opposed to a GSM antenna attached to a building. https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast This is easily removed if map makers don't want it. Ben On Wed, Jan 27, 2016 at 5:40 AM, Minko <ligfiet...@online.nl> wrote: > 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) > > > > ___ > 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] [patch] Add leisure=bowling_alley to default style
Hi Gerd, Here's a patch to add leisure=bowling_alley to the default style. According to the wiki page, leisure=bowling_alley implies sport=10pin. https://wiki.openstreetmap.org/wiki/Tag%3Aleisure%3Dbowling_alley Thanks, Ben mkgmap-default-style-leisure-bowling_alley.patch Description: application/download ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Country unification in address search
Hi Thorsten, On Thu, Nov 12, 2015 at 9:25 PM, Thorsten Kukuk <ku...@suse.de> wrote: > > Hi, > > On Thu, Nov 12, Felix Hartmann wrote: > > > Well I use the bounds file - updated every month or so from here: > > http://osm.thkukuk.de/data/bounds-latest.zip > > It's updated every week, if it passes the sanity checks. > So if too many boundaries are broken, it's not updated. > I'm curious to know what sanity checks you do? Would it be possible to add these checks to mkgmap somehow so that a waning message is printed when there are problems with the bounds? Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [patch] hide abandoned highways in default style
Hi Gerd, Here's a patch to hide abandoned highways in the default style. Abandoned highways have some evidence of their former existence but are no longer used. I made a separate rule for this change to highlight that abandoned highways could be useful in topographical maps. https://wiki.openstreetmap.org/wiki/Key:abandoned: The rule also matches highway=abandoned. While not an official OSM rule, it is being used in the US an Europe: https://taginfo.openstreetmap.org/tags/highway=abandoned#map I also found a German wiki page for it but not a page in English: https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dabandoned Let me know what you think. Thanks, Ben hide-abandoned-highways-in-default-style.patch Description: application/download ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] hide abandoned highways in default style
Hi Gerd, No, that's a mistake on my part. It looks like abandoned:highway=* is for the old highway value (e.g. abandoned:highway=classified) and if the highway tag is also present, it's for the current highway value (e.g. abandoned:highway=path). Ways with abandoned:highway but without highway should be ignored. I've updated the patch. Let me know if I didn't express that correctly. Thanks, Ben On Sun, Nov 22, 2015 at 3:54 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Ben, > > > I think it is okay, but I don't yet see a need to handle abandoned:highway. > > I find > 2100 ways that with abandoned:highway=* and highway=*. > > Do you think these are not usable highways ? > > > Gerd > > > > -- > *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < > mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ben Konrath < > b...@bagu.org> > *Gesendet:* Sonntag, 22. November 2015 13:33 > *An:* Development list for mkgmap > *Betreff:* [mkgmap-dev] [patch] hide abandoned highways in default style > > Hi Gerd, > > Here's a patch to hide abandoned highways in the default style. Abandoned > highways have some evidence of their former existence but are no longer > used. I made a separate rule for this change to highlight that abandoned > highways could be useful in topographical maps. > > https://wiki.openstreetmap.org/wiki/Key:abandoned: > > The rule also matches highway=abandoned. While not an official OSM rule, > it is being used in the US an Europe: > > https://taginfo.openstreetmap.org/tags/highway=abandoned#map > > I also found a German wiki page for it but not a page in English: > > https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dabandoned > > Let me know what you think. > > Thanks, Ben > > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > hide-abandoned-highways-in-default-style-v2.patch Description: application/download ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] hide abandoned highways in default style
> if the highway tag is also present, it's for the current highway value (e.g. abandoned:highway=path). I meant: if the highway tag is also present, it's for the current highway value (e.g. highway=path). On Sun, Nov 22, 2015 at 7:31 PM, Ben Konrath <b...@bagu.org> wrote: > Hi Gerd, > > No, that's a mistake on my part. It looks like abandoned:highway=* is for > the old highway value (e.g. abandoned:highway=classified) and if the > highway tag is also present, it's for the current highway value (e.g. > abandoned:highway=path). Ways with abandoned:highway but without highway > should be ignored. I've updated the patch. Let me know if I didn't express > that correctly. > > Thanks, Ben > > > On Sun, Nov 22, 2015 at 3:54 PM, Gerd Petermann < > gpetermann_muenc...@hotmail.com> wrote: > >> Hi Ben, >> >> >> I think it is okay, but I don't yet see a need to handle >> abandoned:highway. >> >> I find > 2100 ways that with abandoned:highway=* and highway=*. >> >> Do you think these are not usable highways ? >> >> >> Gerd >> >> >> >> -- >> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < >> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ben Konrath < >> b...@bagu.org> >> *Gesendet:* Sonntag, 22. November 2015 13:33 >> *An:* Development list for mkgmap >> *Betreff:* [mkgmap-dev] [patch] hide abandoned highways in default style >> >> Hi Gerd, >> >> Here's a patch to hide abandoned highways in the default style. Abandoned >> highways have some evidence of their former existence but are no longer >> used. I made a separate rule for this change to highlight that abandoned >> highways could be useful in topographical maps. >> >> https://wiki.openstreetmap.org/wiki/Key:abandoned: >> >> The rule also matches highway=abandoned. While not an official OSM rule, >> it is being used in the US an Europe: >> >> https://taginfo.openstreetmap.org/tags/highway=abandoned#map >> >> I also found a German wiki page for it but not a page in English: >> >> https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dabandoned >> >> Let me know what you think. >> >> Thanks, Ben >> >> >> >> >> >> ___ >> 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] don't route the highway=construction ways
Hi Gerd,
Thanks for the explanation (again) and for the new patch. This approach is
probably better considering the concerns about v1. Perhaps you can add a
comment about this new rule above the highway=construction statement in the
lines file. That way people will be able to find the special handling when
reading the lines file.
Thanks, Ben
On Thu, Oct 22, 2015 at 6:54 AM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Ben,
>
>
> attached is my version of your approach. It adds the rule
>
> # Don't route through highway=construction, they are considered unusable
> highway=construction {setaccess no}
>
> at the very end of inc/access.
>
> This should work, but splits the special handling of highway=construction.
>
>
> Gerd
>
>
> --
> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk <
> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ben Konrath <
> b...@bagu.org>
> *Gesendet:* Mittwoch, 21. Oktober 2015 09:28
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] [patch v1] don't route the
> highway=construction ways
>
> For people who have issues with Gerd's implement (line is in NET but not
> in NOD): What do you think about my original suggestion of adding
> "setaccess 'no';" to highway=construction?
>
> Thanks, Ben
>
> On Tue, Oct 20, 2015 at 11:38 AM, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Chris,
>> glad to see that you did not use the mkgmap: prefix ;-)
>>
>> Gerd
>>
>>
>> Von: mkgmap-dev-boun...@lists.mkgmap.org.uk <
>> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von chris66 <
>> chris66...@gmx.de>
>> Gesendet: Dienstag, 20. Oktober 2015 10:52
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] [patch v1] don't route the
>> highway=construction ways
>>
>> Am 16.10.2015 um 20:46 schrieb Alexandre Loss:
>> > I agree also that "mkgmap:ignore-for-routing=yes" is more clear.
>>
>> I used this tag already in OSM to mark isolated ways. :-)
>>
>> https://www.openstreetmap.org/way/111674198#map=18/54.3354/8.5915
>>
>> Chris
>>
>>
>>
>> ___
>> 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 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] don't route the highway=construction ways
For people who have issues with Gerd's implement (line is in NET but not in NOD): What do you think about my original suggestion of adding "setaccess 'no';" to highway=construction? Thanks, Ben On Tue, Oct 20, 2015 at 11:38 AM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Chris, > glad to see that you did not use the mkgmap: prefix ;-) > > Gerd > > > Von: mkgmap-dev-boun...@lists.mkgmap.org.uk < > mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von chris66 < > chris66...@gmx.de> > Gesendet: Dienstag, 20. Oktober 2015 10:52 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] [patch v1] don't route the highway=construction > ways > > Am 16.10.2015 um 20:46 schrieb Alexandre Loss: > > I agree also that "mkgmap:ignore-for-routing=yes" is more clear. > > I used this tag already in OSM to mark isolated ways. :-) > > https://www.openstreetmap.org/way/111674198#map=18/54.3354/8.5915 > > Chris > > > > ___ > 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch v1] don't route the highway=construction ways
Hi Gerd, Thanks for creating this patch. I ran a build with the patch and everything seemed work fine. I installed the map into BaseCamp without problems. I didn't specifically test a highway=construction way though. As for the option name, using something like 'mkgmap:ignore-for-routing=yes' would be better because it makes the option easier to understand at a glance for people, such as myself, who don't know the nomenclature of the Garmin map format. Thanks, Ben On Wed, Oct 14, 2015 at 12:04 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > sorry, forgot to mention that GPSMapEdit seems to have a problem with > these roads. It shows the road as routable with more or less unpredictable > attributes. But Garmin software seems to work fine. > > Gerd > > -- > From: gpetermann_muenc...@hotmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Date: Wed, 14 Oct 2015 12:02:23 +0200 > Subject: [mkgmap-dev] [patch v1] don't route the highway=construction ways > > > Hi all, > > attached patch implements the new internal tag > mkgmap:add-to-NOD=false > to handle the issue discussed here: > > http://gis.19327.n5.nabble.com/don-t-route-through-highway-construction-tt5856734.html > > It shows how to use it in the default style. > I've also added a rule to ignore highway=planned like highway=proposed > > If you don't like the rather technical name mkgmap:add-to-NOD, please let > me know it, > here are my ideas for alternatives: > mkgmap:ignore-for-routing=yes > mkgmap:routable=no > mkgmap:address-search-only=yes > > Gerd > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] don't route through highway=construction
Thanks for the suggestion Nick. I may end up doing this all thought I'm trying to keep my style as close to the mkgmap default as possible so that I can contribute fixes and updates as I find them. Ben On Sun, Oct 11, 2015 at 7:34 PM, nwillink <o...@pinns.co.uk> wrote: > I would personally assign highway=construction a non routable type, ie > 0x10100 > This works for me > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/don-t-route-through-highway-construction-tp5856734p5856776.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] don't route through highway=construction
Hi Gerd, According to the OSM wiki, highway=construction means that the road is closed. construction=minor with the other highway tags unchanged means that the road is still open. https://wiki.openstreetmap.org/wiki/Key:construction > For minor road-works (where the road in question remains open), use construction=minor (and don't use highway=construction, but leave it at its default value). So I still think that disabling routing or making access=destination would be the best option. Do you have any further thoughts? It's ok if you disagree, I can always change it my style. :) Thanks, Ben On Sun, Oct 11, 2015 at 12:00 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Ben, > > quite difficult. My understanding is that a road should have something > like access=no if the > construction work means that the road is closed. If the road is open for > traffic it probably > means something like surface=unpaved and descreased maxspeed, but not > access=no . > So, I'd rather add "set upaved=yes" to the rule. > > Gerd > > -- > Date: Sat, 10 Oct 2015 19:29:05 +0200 > From: b...@bagu.org > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] don't route through highway=construction > > > Hi, > > A while ago a user reported that they were being routed through a closed > highway. The highway in question was marked as highway=construction. What's > the best way to ensure that you don't get routed through the path that's > created in the default style when a way is marked as highway=construction? > I'm not able to test this easily because the highway is now back in service. > > I've attached a patch that adds access=no to the highway=construction > rule. Is this a good way to prevent routing through highway=construction > roads? > > Thanks, Ben > > ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] don't route through highway=construction
Hi,
A while ago a user reported that they were being routed through a closed
highway. The highway in question was marked as highway=construction. What's
the best way to ensure that you don't get routed through the path that's
created in the default style when a way is marked as highway=construction?
I'm not able to test this easily because the highway is now back in service.
I've attached a patch that adds access=no to the highway=construction rule.
Is this a good way to prevent routing through highway=construction roads?
Thanks, Ben
diff --git a/resources/styles/default/lines b/resources/styles/default/lines
index ab89b5a..a36970d 100644
--- a/resources/styles/default/lines
+++ b/resources/styles/default/lines
@@ -107,7 +107,7 @@ junction=roundabout [0x0c road_class=0 road_speed=1 resolution 22]
# Ways that may or may not be useable
# Treat ways under construction almost as highway=path
-highway=construction { add mkgmap:dead-end-check = false; }
+highway=construction { add mkgmap:dead-end-check = false; setaccess 'no'; }
[0x16 road_class=0 road_speed=0 resolution 23]
# Lower the road speed of ways under some construction.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] add support for information=guidepost POI in default style
Hi Gerd, Sorry about the late reply. Your response ended up in my spam box and I just found it now. I did in fact make the patch again the wrong branch. Sorry about that - clearly I need to contribute more of my tweaks. :) Anyway, I see you've committed the patch already so thanks for that. Ben On Thu, Sep 17, 2015 at 9:43 AM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Ben, > > sorry for the delay, I was biking for a few days. > I had small problems with your patch because it seems not to be based on > the svn > version, so please double check the changes. > > Gerd > > -- > Date: Tue, 8 Sep 2015 16:25:46 +0200 > From: b...@bagu.org > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] [patch] add support for information=guidepost > POI in default style > > > Hi Gerd, > > I've attached a new patch with the previously mentioned change. I've also > changed the other POI using 0x2f0c to 'amenity=toilets & highway=rest_area' > which seems to match the POI type better. > > Thanks, Ben > > On Tue, Sep 8, 2015 at 3:49 PM, Ben Konrath <b...@bagu.org> wrote: > > Hi Gerd, > > I didn't spend too much time digging into this but I agree that it makes > sense to solve this correctly. > > According to this XLS file with Garmin POIs, 0x2f0c is for Toilets and > will be listed in the the Auto Services -> Rest Area / Tourist Info > category. > > http://www.cferrero.net/maps/downloads/garmin_feature_list.xls > > > 0x2F0CToiletBlue, smallAuto ServicesRest Area / Tourist > Info YesRestroom > > According to the osm tag page, tourism=information is for information > sources, not toilets. > > https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dinformation > > I propose that we just change tourism=information to 0x4c00 regardless of > the the information=* refinement and ignore the previous patch. > > tourism=information [0x4c00 resolution 24] > > What do you think? > > Thanks, Ben > > On Tue, Sep 8, 2015 at 2:48 PM, GerdP <gpetermann_muenc...@hotmail.com> > wrote: > > Hi Ben, > > the node in your example has the tag tourism=information > and the default style contains the rule. > tourism=information [0x2f0c resolution 24] > > Your patch adds the rule > information=guidepost [0x4c00 resolution 24] > > I'd prefer to modify the existing rule, > but I don't know which of the types is more > likely to show the wanted icon. > > Gerd > > > > Ben Konrath wrote > > Hi, > > > > The default style currently has information=guidepost POIs set as a > toilet > > icon. This patch changes information=guidepost to be an 'i' in a circle. > > For reference, here's an example of a POI with this tag: > > > > https://www.openstreetmap.org/node/2883638464 > > > > Thanks, Ben > > > > ___ > > mkgmap-dev mailing list > > > mkgmap-dev@.org > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > mkgmap-add-support-for-information-guidepost.patch (746 bytes) > > < > http://gis.19327.n5.nabble.com/attachment/5854217/0/mkgmap-add-support-for-information-guidepost.patch > > > > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/patch-add-support-for-information-guidepost-POI-in-default-style-tp5854217p5854227.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 > > ___ > 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] [patch] add support for information=guidepost POI in default style
Hi, The default style currently has information=guidepost POIs set as a toilet icon. This patch changes information=guidepost to be an 'i' in a circle. For reference, here's an example of a POI with this tag: https://www.openstreetmap.org/node/2883638464 Thanks, Ben diff --git a/resources/styles/default/points b/resources/styles/default/points index 797e2f4..9c90fd9 100644 --- a/resources/styles/default/points +++ b/resources/styles/default/points @@ -211,6 +211,8 @@ historic=museum [0x2c02 resolution 24] historic=archaeological_site | historic=ruins [0x2c02 resolution 24] historic=memorial [0x2c02 resolution 24] +information=guidepost [0x4c00 resolution 24] + leisure=common & name=* [0x2c06 resolution 24] leisure=garden & name=* [0x2c06 resolution 24] leisure=golf_course [0x2d05 resolution 24] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] add support for information=guidepost POI in default style
Hi Gerd, I've attached a new patch with the previously mentioned change. I've also changed the other POI using 0x2f0c to 'amenity=toilets & highway=rest_area' which seems to match the POI type better. Thanks, Ben On Tue, Sep 8, 2015 at 3:49 PM, Ben Konrath <b...@bagu.org> wrote: > Hi Gerd, > > I didn't spend too much time digging into this but I agree that it makes > sense to solve this correctly. > > According to this XLS file with Garmin POIs, 0x2f0c is for Toilets and > will be listed in the the Auto Services -> Rest Area / Tourist Info > category. > > http://www.cferrero.net/maps/downloads/garmin_feature_list.xls > > > 0x2F0CToiletBlue, smallAuto ServicesRest Area / Tourist > Info YesRestroom > > According to the osm tag page, tourism=information is for information > sources, not toilets. > > https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dinformation > > I propose that we just change tourism=information to 0x4c00 regardless of > the the information=* refinement and ignore the previous patch. > > tourism=information [0x4c00 resolution 24] > > What do you think? > > Thanks, Ben > > On Tue, Sep 8, 2015 at 2:48 PM, GerdP <gpetermann_muenc...@hotmail.com> > wrote: > >> Hi Ben, >> >> the node in your example has the tag tourism=information >> and the default style contains the rule. >> tourism=information [0x2f0c resolution 24] >> >> Your patch adds the rule >> information=guidepost [0x4c00 resolution 24] >> >> I'd prefer to modify the existing rule, >> but I don't know which of the types is more >> likely to show the wanted icon. >> >> Gerd >> >> >> >> Ben Konrath wrote >> > Hi, >> > >> > The default style currently has information=guidepost POIs set as a >> toilet >> > icon. This patch changes information=guidepost to be an 'i' in a circle. >> > For reference, here's an example of a POI with this tag: >> > >> > https://www.openstreetmap.org/node/2883638464 >> > >> > Thanks, Ben >> > >> > ___ >> > mkgmap-dev mailing list >> >> > mkgmap-dev@.org >> >> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > >> > mkgmap-add-support-for-information-guidepost.patch (746 bytes) >> > < >> http://gis.19327.n5.nabble.com/attachment/5854217/0/mkgmap-add-support-for-information-guidepost.patch >> > >> >> >> >> >> >> -- >> View this message in context: >> http://gis.19327.n5.nabble.com/patch-add-support-for-information-guidepost-POI-in-default-style-tp5854217p5854227.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 >> > > diff --git a/resources/styles/default/points b/resources/styles/default/points index 797e2f4..defe00d 100644 --- a/resources/styles/default/points +++ b/resources/styles/default/points @@ -189,7 +189,7 @@ amenity=supermarket [0x2e02 resolution 24] amenity=taxi [0x2f17 resolution 24] amenity=telephone [0x2f12 resolution 24 default_name 'Telephone'] amenity=theatre [0x2d01 resolution 24] -amenity=toilets & tourism=information [0x2f0c resolution 24] +amenity=toilets & highway=rest_area [0x2f0c resolution 24] highway=rest_area [0x2000 resolution 24 default_name 'Rest Area'] amenity=toilets [0x4e00 resolution 24 default_name 'Toilets' ] amenity=townhall [0x3003 resolution 24] @@ -304,7 +304,7 @@ tourism=chalet [0x2b02 resolution 24] tourism=guest_house [0x2b02 resolution 24] tourism=hostel [0x2b02 resolution 24] tourism=hotel | tourism=motel [0x2b01 resolution 24] -tourism=information [0x2f0c resolution 24] +tourism=information [0x4c00 resolution 24] # tourism=lean_to replaces some uses of amenity=shelter tourism=lean_to [0x2b05 resolution 24 default_name 'lean-to'] tourism=wilderness_hut [0x2b07 resolution 24 default_name 'wilderness hut'] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] add support for information=guidepost POI in default style
Hi Gerd, I didn't spend too much time digging into this but I agree that it makes sense to solve this correctly. According to this XLS file with Garmin POIs, 0x2f0c is for Toilets and will be listed in the the Auto Services -> Rest Area / Tourist Info category. http://www.cferrero.net/maps/downloads/garmin_feature_list.xls > 0x2F0CToiletBlue, smallAuto ServicesRest Area / Tourist Info YesRestroom According to the osm tag page, tourism=information is for information sources, not toilets. https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dinformation I propose that we just change tourism=information to 0x4c00 regardless of the the information=* refinement and ignore the previous patch. tourism=information [0x4c00 resolution 24] What do you think? Thanks, Ben On Tue, Sep 8, 2015 at 2:48 PM, GerdP <gpetermann_muenc...@hotmail.com> wrote: > Hi Ben, > > the node in your example has the tag tourism=information > and the default style contains the rule. > tourism=information [0x2f0c resolution 24] > > Your patch adds the rule > information=guidepost [0x4c00 resolution 24] > > I'd prefer to modify the existing rule, > but I don't know which of the types is more > likely to show the wanted icon. > > Gerd > > > > Ben Konrath wrote > > Hi, > > > > The default style currently has information=guidepost POIs set as a > toilet > > icon. This patch changes information=guidepost to be an 'i' in a circle. > > For reference, here's an example of a POI with this tag: > > > > https://www.openstreetmap.org/node/2883638464 > > > > Thanks, Ben > > > > ___ > > mkgmap-dev mailing list > > > mkgmap-dev@.org > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > mkgmap-add-support-for-information-guidepost.patch (746 bytes) > > < > http://gis.19327.n5.nabble.com/attachment/5854217/0/mkgmap-add-support-for-information-guidepost.patch > > > > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/patch-add-support-for-information-guidepost-POI-in-default-style-tp5854217p5854227.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] question about ignored no_u_turn restriction
Hi Gerd, I'm just back from my vacation. I just wanted to say thanks for taking the time figure this out. Ben On Sun, Aug 2, 2015 at 11:03 AM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, it seems the tests were even more complicated than I thought, but in the end, today I found that I was wrong. The no_u_turn restriction has an effect, the warning makes no sense. This is what I tested: Switch to car routing with shortest distance (shorter time seems to avoid u-turns), and enable automatic recalculation of routes. Enter a target which just requires a left turn after 100m. Ignore the left turn, after a few seconds the device tells me to make a u-turn at the next crossing. (tried this two or three times with the same result) I've then used JOSM to add a no_u_turn restriction for this crossing , created a new map (with a different id) and tried again. And, ta-ta, the device shows different hints for the same situation (no u-turn at this crossing). I thought I tried the same last time, but I must have made an error somewhere, maybe some kind of caching in my Oregon 600. So I've removed the check with r3626, the restriction is no longer ignored. Gerd -- Date: Sat, 1 Aug 2015 22:11:58 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Gerd, For point 2, what makes you think that the restriction has no effect on Garmin routing? You said that it wasn't easy to test but did you mean that it's not possible to test this? If we don't know for sure or if it's too hard to test, changing the warning message to an informational would be good. You can always add a link to this thread in a comment in case we discover more information about the effect on the Garmin routing. Thanks again for your help. Ben On Wed, Jul 29, 2015 at 11:09 AM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, my results so far: 1) The img format allows to store this kind of no-u-turn, mkgmap also doesn't seem to have a problem with it, I just have to comment the check. 2) I still think that the restriction has no effect on Garmin routing I think I should change the message to ... no_u_turn with equal 'from' and 'to' way and via node has no effect, is ignored and make it informational. OK? Gerd -- Date: Tue, 28 Jul 2015 17:38:34 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Gerd, I guess I was a little to 'quick' with that example. ;-) Thanks for looking into this. Ben On Tue, Jul 28, 2015 at 5:22 PM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, okay, I did not yet think about the case that the device knows in which direction you are currently driving when it re-calculates a route. I did only consider the case that you are planning while standing still. If I remember correctly, this case will produce a message like please make a u-turn, I never saw that it tells me to make a u-turn at a specific place. It's not easy to test if Garmin uses this restriction (when written by mkgmap), I have to think about it. @Steve: Do you see these restrictions in Garmin maps? Gerd PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but that shouldn't matter here ;-) -- Date: Tue, 28 Jul 2015 16:50:30 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Gerd, In this example, if you're travelling southbound on North Harlem Avenue and you miss your right turn onto Quick Avenue, the GPS might suggest that you make a u-turn at the North Harlem Avenue / Ontario Street intersection so that you can double back get back to your original route. The traffic rule is saying that you're not allowed to make a u-turn at this intersection and the OSM data is capturing the traffic rule correctly. I've never been to this area so I can't actually test to see if the Garmin routing algorithm would try to do this u-turn. This is just an example that I'm using to try to figure if why the restriction is being ignored. I don't actually know the details Garmin routing algorithm but I have been routed on such u-turns in the past when I've missed a turn. Given that this is a legitimate type of 'no u-turn' restriction, if the Garmin map format or routing algorithm can't deal with it, there should be a message that says so in the warning. In this case, maybe an info message makes more sense - but you should probably decide how you want to present it since you wrote it. :-) The other side of this is that the Garmin map format or routing algorithm can actually handle this specific type of 'no u-turn' restriction, in which case it would be nice to have
Re: [mkgmap-dev] question about ignored no_u_turn restriction
Hi Chris, many Garmin devices do have an option avoid u-turns / Ausschluss Kehrtwenden. So I guess this kind of turn restriction is for the Garmin routing algorithm a complete other thing as normal turn-restrictions. I think the 'avoid u-turns' option tells the device to only do u-turns when it's the only choice - effectively a 'no u-turn' restriction at every intersection. I assume that the routing algorithm follows the actual turn restrictions when the 'avoid u-turns' option is disabled. But as Gerd pointed out, he's not sure if the no u-turn restriction in my example actually has an effect so my assumption could be wrong. Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] question about ignored no_u_turn restriction
Hi Gerd, For point 2, what makes you think that the restriction has no effect on Garmin routing? You said that it wasn't easy to test but did you mean that it's not possible to test this? If we don't know for sure or if it's too hard to test, changing the warning message to an informational would be good. You can always add a link to this thread in a comment in case we discover more information about the effect on the Garmin routing. Thanks again for your help. Ben On Wed, Jul 29, 2015 at 11:09 AM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, my results so far: 1) The img format allows to store this kind of no-u-turn, mkgmap also doesn't seem to have a problem with it, I just have to comment the check. 2) I still think that the restriction has no effect on Garmin routing I think I should change the message to ... no_u_turn with equal 'from' and 'to' way and via node has no effect, is ignored and make it informational. OK? Gerd -- Date: Tue, 28 Jul 2015 17:38:34 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Gerd, I guess I was a little to 'quick' with that example. ;-) Thanks for looking into this. Ben On Tue, Jul 28, 2015 at 5:22 PM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, okay, I did not yet think about the case that the device knows in which direction you are currently driving when it re-calculates a route. I did only consider the case that you are planning while standing still. If I remember correctly, this case will produce a message like please make a u-turn, I never saw that it tells me to make a u-turn at a specific place. It's not easy to test if Garmin uses this restriction (when written by mkgmap), I have to think about it. @Steve: Do you see these restrictions in Garmin maps? Gerd PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but that shouldn't matter here ;-) -- Date: Tue, 28 Jul 2015 16:50:30 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Gerd, In this example, if you're travelling southbound on North Harlem Avenue and you miss your right turn onto Quick Avenue, the GPS might suggest that you make a u-turn at the North Harlem Avenue / Ontario Street intersection so that you can double back get back to your original route. The traffic rule is saying that you're not allowed to make a u-turn at this intersection and the OSM data is capturing the traffic rule correctly. I've never been to this area so I can't actually test to see if the Garmin routing algorithm would try to do this u-turn. This is just an example that I'm using to try to figure if why the restriction is being ignored. I don't actually know the details Garmin routing algorithm but I have been routed on such u-turns in the past when I've missed a turn. Given that this is a legitimate type of 'no u-turn' restriction, if the Garmin map format or routing algorithm can't deal with it, there should be a message that says so in the warning. In this case, maybe an info message makes more sense - but you should probably decide how you want to present it since you wrote it. :-) The other side of this is that the Garmin map format or routing algorithm can actually handle this specific type of 'no u-turn' restriction, in which case it would be nice to have the restriction included in the maps. Thanks for your help and all your hard work on mkgmap! Ben On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, unfortunately I did not add a comment to that part of the source which would explain why I coded it, but I think the reason is that the restriction has no effect on route calculation. I can't think of any case where the Garmin algo would route you along that u-turn. Do you have an example that proves this assumption to be wrong? If not, I can change the msg to say something like has no effect, or please suggest a better text. Gerd -- Date: Mon, 6 Jul 2015 13:34:12 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Just to follow up ... Does anybody know concretely that the Garmin format cannot handle and u-turn restriction with the same from and two way? Thanks, Ben On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote: Hi Anor, Thanks for the tip but it seems that your suggestion breaks the OSM rule of manipulating the map for specific renderers (the renderer here being mkgmap). If the Garmin format truly doesn't support the u-turn restriction with the same to and from way at an intersection, we should come up with another solution. Ben On Sun, Jul 5, 2015
Re: [mkgmap-dev] question about ignored no_u_turn restriction
Hi Gerd, I guess I was a little to 'quick' with that example. ;-) Thanks for looking into this. Ben On Tue, Jul 28, 2015 at 5:22 PM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, okay, I did not yet think about the case that the device knows in which direction you are currently driving when it re-calculates a route. I did only consider the case that you are planning while standing still. If I remember correctly, this case will produce a message like please make a u-turn, I never saw that it tells me to make a u-turn at a specific place. It's not easy to test if Garmin uses this restriction (when written by mkgmap), I have to think about it. @Steve: Do you see these restrictions in Garmin maps? Gerd PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but that shouldn't matter here ;-) -- Date: Tue, 28 Jul 2015 16:50:30 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Gerd, In this example, if you're travelling southbound on North Harlem Avenue and you miss your right turn onto Quick Avenue, the GPS might suggest that you make a u-turn at the North Harlem Avenue / Ontario Street intersection so that you can double back get back to your original route. The traffic rule is saying that you're not allowed to make a u-turn at this intersection and the OSM data is capturing the traffic rule correctly. I've never been to this area so I can't actually test to see if the Garmin routing algorithm would try to do this u-turn. This is just an example that I'm using to try to figure if why the restriction is being ignored. I don't actually know the details Garmin routing algorithm but I have been routed on such u-turns in the past when I've missed a turn. Given that this is a legitimate type of 'no u-turn' restriction, if the Garmin map format or routing algorithm can't deal with it, there should be a message that says so in the warning. In this case, maybe an info message makes more sense - but you should probably decide how you want to present it since you wrote it. :-) The other side of this is that the Garmin map format or routing algorithm can actually handle this specific type of 'no u-turn' restriction, in which case it would be nice to have the restriction included in the maps. Thanks for your help and all your hard work on mkgmap! Ben On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, unfortunately I did not add a comment to that part of the source which would explain why I coded it, but I think the reason is that the restriction has no effect on route calculation. I can't think of any case where the Garmin algo would route you along that u-turn. Do you have an example that proves this assumption to be wrong? If not, I can change the msg to say something like has no effect, or please suggest a better text. Gerd -- Date: Mon, 6 Jul 2015 13:34:12 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Just to follow up ... Does anybody know concretely that the Garmin format cannot handle and u-turn restriction with the same from and two way? Thanks, Ben On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote: Hi Anor, Thanks for the tip but it seems that your suggestion breaks the OSM rule of manipulating the map for specific renderers (the renderer here being mkgmap). If the Garmin format truly doesn't support the u-turn restriction with the same to and from way at an intersection, we should come up with another solution. Ben On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote: Ben There I draw two routes, one in each direction, since there is a false median, then with 2-way, it's easy for a restriction *___* *Anor Co* *ncórdia SC * -- Date: Sun, 5 Jul 2015 15:53:50 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Thorsten, Thanks for your reply. This type of restriction is probably a country specific thing. In Ontario Canada, you can make u-turns at intersections (regardless of the road is separation) if there is no sign indicating that you can't make the u-turn. Here's the information directly from the Ontario Ministry of Transportation: http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml I realize that the link I sent previously is in the US but I suspect that it's the same policy there which is why the restriction is tagged like it is. Since
Re: [mkgmap-dev] question about ignored no_u_turn restriction
Hi Gerd, In this example, if you're travelling southbound on North Harlem Avenue and you miss your right turn onto Quick Avenue, the GPS might suggest that you make a u-turn at the North Harlem Avenue / Ontario Street intersection so that you can double back get back to your original route. The traffic rule is saying that you're not allowed to make a u-turn at this intersection and the OSM data is capturing the traffic rule correctly. I've never been to this area so I can't actually test to see if the Garmin routing algorithm would try to do this u-turn. This is just an example that I'm using to try to figure if why the restriction is being ignored. I don't actually know the details Garmin routing algorithm but I have been routed on such u-turns in the past when I've missed a turn. Given that this is a legitimate type of 'no u-turn' restriction, if the Garmin map format or routing algorithm can't deal with it, there should be a message that says so in the warning. In this case, maybe an info message makes more sense - but you should probably decide how you want to present it since you wrote it. :-) The other side of this is that the Garmin map format or routing algorithm can actually handle this specific type of 'no u-turn' restriction, in which case it would be nice to have the restriction included in the maps. Thanks for your help and all your hard work on mkgmap! Ben On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, unfortunately I did not add a comment to that part of the source which would explain why I coded it, but I think the reason is that the restriction has no effect on route calculation. I can't think of any case where the Garmin algo would route you along that u-turn. Do you have an example that proves this assumption to be wrong? If not, I can change the msg to say something like has no effect, or please suggest a better text. Gerd -- Date: Mon, 6 Jul 2015 13:34:12 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Just to follow up ... Does anybody know concretely that the Garmin format cannot handle and u-turn restriction with the same from and two way? Thanks, Ben On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote: Hi Anor, Thanks for the tip but it seems that your suggestion breaks the OSM rule of manipulating the map for specific renderers (the renderer here being mkgmap). If the Garmin format truly doesn't support the u-turn restriction with the same to and from way at an intersection, we should come up with another solution. Ben On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote: Ben There I draw two routes, one in each direction, since there is a false median, then with 2-way, it's easy for a restriction *___* *Anor Co* *ncórdia SC * -- Date: Sun, 5 Jul 2015 15:53:50 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Thorsten, Thanks for your reply. This type of restriction is probably a country specific thing. In Ontario Canada, you can make u-turns at intersections (regardless of the road is separation) if there is no sign indicating that you can't make the u-turn. Here's the information directly from the Ontario Ministry of Transportation: http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml I realize that the link I sent previously is in the US but I suspect that it's the same policy there which is why the restriction is tagged like it is. Since the tagging seems to be valid, does the Garmin format support this type of restriction? If not then it's probably a good idea to indicate this in the warning message. Maybe the message should also be changed to an info message if there's no problem with the data. Does anybody have other insights? Thanks, Ben On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote: On Sun, Jul 05, Ben Konrath wrote: Does anybody know why this particular restriction is being ignored? Beside that this particular type of restrictions doesn't make any sense to me, I would guess the GARMIN format does not support it. If the to and from ways are the same, I have never seen a sign forbidding u-turns. Only, if you have two ways, structural seperated. But then I should tag the street that way and the restriction will not be ignored. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg
Re: [mkgmap-dev] question about ignored no_u_turn restriction
Just to follow up ... Does anybody know concretely that the Garmin format cannot handle and u-turn restriction with the same from and two way? Thanks, Ben On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote: Hi Anor, Thanks for the tip but it seems that your suggestion breaks the OSM rule of manipulating the map for specific renderers (the renderer here being mkgmap). If the Garmin format truly doesn't support the u-turn restriction with the same to and from way at an intersection, we should come up with another solution. Ben On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote: Ben There I draw two routes, one in each direction, since there is a false median, then with 2-way, it's easy for a restriction *___* *Anor Co* *ncórdia SC * -- Date: Sun, 5 Jul 2015 15:53:50 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Thorsten, Thanks for your reply. This type of restriction is probably a country specific thing. In Ontario Canada, you can make u-turns at intersections (regardless of the road is separation) if there is no sign indicating that you can't make the u-turn. Here's the information directly from the Ontario Ministry of Transportation: http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml I realize that the link I sent previously is in the US but I suspect that it's the same policy there which is why the restriction is tagged like it is. Since the tagging seems to be valid, does the Garmin format support this type of restriction? If not then it's probably a good idea to indicate this in the warning message. Maybe the message should also be changed to an info message if there's no problem with the data. Does anybody have other insights? Thanks, Ben On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote: On Sun, Jul 05, Ben Konrath wrote: Does anybody know why this particular restriction is being ignored? Beside that this particular type of restrictions doesn't make any sense to me, I would guess the GARMIN format does not support it. If the to and from ways are the same, I have never seen a sign forbidding u-turns. Only, if you have two ways, structural seperated. But then I should tag the street that way and the restriction will not be ignored. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ 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 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] question about ignored no_u_turn restriction
Hi Thorsten, Thanks for your reply. This type of restriction is probably a country specific thing. In Ontario Canada, you can make u-turns at intersections (regardless of the road is separation) if there is no sign indicating that you can't make the u-turn. Here's the information directly from the Ontario Ministry of Transportation: http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml I realize that the link I sent previously is in the US but I suspect that it's the same policy there which is why the restriction is tagged like it is. Since the tagging seems to be valid, does the Garmin format support this type of restriction? If not then it's probably a good idea to indicate this in the warning message. Maybe the message should also be changed to an info message if there's no problem with the data. Does anybody have other insights? Thanks, Ben On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote: On Sun, Jul 05, Ben Konrath wrote: Does anybody know why this particular restriction is being ignored? Beside that this particular type of restrictions doesn't make any sense to me, I would guess the GARMIN format does not support it. If the to and from ways are the same, I have never seen a sign forbidding u-turns. Only, if you have two ways, structural seperated. But then I should tag the street that way and the restriction will not be ignored. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ 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] question about ignored no_u_turn restriction
Hi everybody, I recently noticed a bunch of warning messages about ignored no_u_turn restrictions. Here's an example: 2015/07/04 18:12:50 WARNING (RestrictionRelation): 17244023.o5m: Turn restriction (no_u_turn) http://www.openstreetmap.org/relation/4630872 (at http://www.openstreetmap.org/?mlat=41.890540mlon=-87.805101zoom=17) no_u_turn with equal 'from' and 'to' way and via node is ignored Looking at the rules for restrictions and the relation itself, I can't see what the problem is. https://wiki.openstreetmap.org/wiki/Relation:restriction http://www.openstreetmap.org/relation/4630872 Does anybody know why this particular restriction is being ignored? Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] question about ignored no_u_turn restriction
Hi Anor, Thanks for the tip but it seems that your suggestion breaks the OSM rule of manipulating the map for specific renderers (the renderer here being mkgmap). If the Garmin format truly doesn't support the u-turn restriction with the same to and from way at an intersection, we should come up with another solution. Ben On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote: Ben There I draw two routes, one in each direction, since there is a false median, then with 2-way, it's easy for a restriction *___* *Anor Co* *ncórdia SC * -- Date: Sun, 5 Jul 2015 15:53:50 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction Hi Thorsten, Thanks for your reply. This type of restriction is probably a country specific thing. In Ontario Canada, you can make u-turns at intersections (regardless of the road is separation) if there is no sign indicating that you can't make the u-turn. Here's the information directly from the Ontario Ministry of Transportation: http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml I realize that the link I sent previously is in the US but I suspect that it's the same policy there which is why the restriction is tagged like it is. Since the tagging seems to be valid, does the Garmin format support this type of restriction? If not then it's probably a good idea to indicate this in the warning message. Maybe the message should also be changed to an info message if there's no problem with the data. Does anybody have other insights? Thanks, Ben On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote: On Sun, Jul 05, Ben Konrath wrote: Does anybody know why this particular restriction is being ignored? Beside that this particular type of restrictions doesn't make any sense to me, I would guess the GARMIN format does not support it. If the to and from ways are the same, I have never seen a sign forbidding u-turns. Only, if you have two ways, structural seperated. But then I should tag the street that way and the restriction will not be ignored. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ 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 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] IndexOutOfBoundsException in US map with mkgmap 3605
Hi Gerd, Thanks for the quick fix - r3606 worked! Ben On Thu, Jun 4, 2015 at 5:10 PM, GerdP gpetermann_muenc...@hotmail.com wrote: Hi Ben, please try again with r3606. It should either report errors with the tile name or run without problems. Gerd Ben Konrath wrote Hi, I have a IndexOutOfBoundsException while generating a map of the United States with mkgmap 3605. I think this is related to the recent house number merge because 3598 worked fine and the problem seems to come from house number related code. java.lang.IndexOutOfBoundsException: bitIndex 0: -1 at java.util.BitSet.get(BitSet.java:615) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator$RoadSegmentIndex.createHousenumberMatch(HousenumberGenerator.java:2055) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.findClosestRoadsToHouse(HousenumberGenerator.java:794) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:621) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:619) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:255) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:251) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Here's how I'm calling mkgamp: java -Xmx14000M -jar -Dlog.config=/home/ben/osm/confs/logging.properties /home/ben/osm/mkgmap/dist/mkgmap.jar --latin1 --gmapsupp --index --route --min-size-polygon --series-name=United States 2015.06.03 --family-name=United States 2015.06.03 --location-autofill=bounds,is_in,nearest --remove-ovm-work-files --bounds=/home/ben/osm/data/bounds --precomp-sea=/home/ben/osm/data/sea_20150602.zip --generate-sea --add-pois-to-areas --process-destination --process-exits --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance --check-roundabout-flares --remove-short-arcs --family-id=14244 --product-id=1 --make-opposite-cycleways --drive-on=detect,right --check-roundabouts --housenumbers -c template.args --description=United States 2015.06.03 /home/ben/osm/confs/typ.txt Obviously a full US map is big so I don't know exactly where the problem is. What's the best way to help narrow done the problem? Let me know what I can do. Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/IndexOutOfBoundsException-in-US-map-with-mkgmap-3605-tp5847079p5847116.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
[mkgmap-dev] IndexOutOfBoundsException in US map with mkgmap 3605
Hi, I have a IndexOutOfBoundsException while generating a map of the United States with mkgmap 3605. I think this is related to the recent house number merge because 3598 worked fine and the problem seems to come from house number related code. java.lang.IndexOutOfBoundsException: bitIndex 0: -1 at java.util.BitSet.get(BitSet.java:615) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator$RoadSegmentIndex.createHousenumberMatch(HousenumberGenerator.java:2055) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.findClosestRoadsToHouse(HousenumberGenerator.java:794) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:621) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:619) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:255) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:251) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Here's how I'm calling mkgamp: java -Xmx14000M -jar -Dlog.config=/home/ben/osm/confs/logging.properties /home/ben/osm/mkgmap/dist/mkgmap.jar --latin1 --gmapsupp --index --route --min-size-polygon --series-name=United States 2015.06.03 --family-name=United States 2015.06.03 --location-autofill=bounds,is_in,nearest --remove-ovm-work-files --bounds=/home/ben/osm/data/bounds --precomp-sea=/home/ben/osm/data/sea_20150602.zip --generate-sea --add-pois-to-areas --process-destination --process-exits --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance --check-roundabout-flares --remove-short-arcs --family-id=14244 --product-id=1 --make-opposite-cycleways --drive-on=detect,right --check-roundabouts --housenumbers -c template.args --description=United States 2015.06.03 /home/ben/osm/confs/typ.txt Obviously a full US map is big so I don't know exactly where the problem is. What's the best way to help narrow done the problem? Let me know what I can do. Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] multiple US highway shields on one highway
Hi everyone,
I recently added the US highway shields to my maps. My solution works
pretty well and I'll happily make a patch for the default style if people
are interested. Here's what I'm currently doing:
# Highway shields for the United States.
# All highways in the US that aren't link roads and have a reference in the
expected format.
mkgmap:admin_level2=USA highway=* highway~'^(?!.*_link).*$'
ref~'^[A-Z]+(-| )*\d+$'
{ set usa_hwy_ref_numbers='${ref|subst:^([A-Z]+)(-| )*(\d+)~$3}'; set
usa_hwy_ref_letters='${ref|subst:^([A-Z]+)(-| )*(\d+)~$1}' }
usa_hwy_ref_letters=I
{ name '${usa_hwy_ref_numbers|highway-symbol:interstate} ${name}' |
'${usa_hwy_ref_numbers|highway-symbol:interstate}'; addlabel '${name}' }
usa_hwy_ref_letters=US
{ name '${usa_hwy_ref_numbers|highway-symbol:shield} ${name}' |
'${usa_hwy_ref_numbers|highway-symbol:shield}'; addlabel '${name}' }
# State highways are prefixed in OSM with SR or the state code.
usa_hwy_ref_letters~'SR|AL|AK|AZ|AR|CA|CO|CT|DE|FL|GA|HI|ID|IL|IN|IA|KS|KY|LA|ME|MD|MA|M|MI|MN|MS|MO|MT|NE|NV|NH|NJ|NM|NY|NC|ND|OH|OK|OR|PA|RI|SC|SD|TN|TX|UT|VT|VA|WA|WV|WI|WY'
{ name '${usa_hwy_ref_numbers|highway-symbol:round} ${name}' |
'${usa_hwy_ref_numbers|highway-symbol:round}'; addlabel '${name}' }
One issue I have is that I haven't figured out a way to support multiple
highway shields for roads that have multiple interstate, us highway or
state highway references. For example, this section of highway has the ref
tag set to I 275;I 96 meaning that it's both interstate I275 and
interstate I96.
http://www.openstreetmap.org/way/124433753
I tried setting the highway-symbol filter twice on one highway but it
didn't work. It this expected work or does the garmin format only allow one
shield per highway? Does anybody have any ideas on how I could get multiple
highway shields to display when a highway is part of multiple highway
references?
Thanks, Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Add man_made=mast to the default style
Hi,
Here's a small improvement to the tower entry of the default style.
man_made=mast is a valid OSM tag and it is used a bit so I think we should
include it.
https://taginfo.openstreetmap.org/tags/man_made=mast
Thanks, Ben
diff --git a/resources/styles/default/points b/resources/styles/default/points
index edfd825..4ee4993 100644
--- a/resources/styles/default/points
+++ b/resources/styles/default/points
@@ -213,7 +222,7 @@ leisure=stadium { name '${name} (${sport})' | '${name}' } [0x2c08 resolution 24]
leisure=track { name '${name} (${sport})' | '${name}' } [0x2c08 resolution 24]
leisure=water_park [0x2d09 resolution 24]
-man_made=tower|landmark=chimney [0x6411 resolution 24]
+man_made=tower|man_made=mast|landmark=chimney [0x6411 resolution 24]
# Edge 705 displays 0x650a,0x6511,0x6512,0x6513,0x6603,0x6614 as hollow white circles, no menu
natural=cave_entrance [0x6601 resolution 24]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap:city empty in large cities
Hi Gerd,
I was a bit wrong with my analysis of Ottawa and Toronto. Toronto and
Ottawa should be admin level 8 and the 'cities' within Toronto and Ottawa
should be admin level 9 (as Orleans was already tagged). I've corrected the
labelling issues in OSM but I didn't add the missing 'city' boundaries
inside Ottawa.
I've attached a patch that corrects address search for Toronto and Ottawa.
You'll need updated bounds data for this to work but I have confirmed that
it's working. It would be nice to get this included in mkgamp.
Thanks, Ben
diff --git a/resources/styles/default/inc/address b/resources/styles/default/inc/address
index f01b26e..4a85973 100644
--- a/resources/styles/default/inc/address
+++ b/resources/styles/default/inc/address
@@ -59,6 +59,8 @@ mkgmap:country=CHE mkgmap:city!=* mkgmap:admin_level8=* { set mkgmap:city='$
# Canada
mkgmap:country=CAN mkgmap:region!=* mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' }
+mkgmap:country=CAN mkgmap:city!=* mkgmap:admin_level8=Toronto mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
+mkgmap:country=CAN mkgmap:city!=* mkgmap:admin_level8=Ottawa mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=CAN mkgmap:city!=* mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8|subst:City of }' }
# United States
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap:city empty in large cities
Hi Gerd, Yes, that's correct. The patch will have no effect until the bounds are updated to OSM data that's newer than 27 April 2015. Thanks, Ben On Tue, Apr 28, 2015 at 10:04 AM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Ben, thanks for the patch. Just to make sure: The additional rules have no effect until one has updated bounds, so I can commit that without causing trouble, right? Gerd -- Date: Tue, 28 Apr 2015 09:43:03 +0200 From: b...@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] mkgmap:city empty in large cities Hi Gerd, I was a bit wrong with my analysis of Ottawa and Toronto. Toronto and Ottawa should be admin level 8 and the 'cities' within Toronto and Ottawa should be admin level 9 (as Orleans was already tagged). I've corrected the labelling issues in OSM but I didn't add the missing 'city' boundaries inside Ottawa. I've attached a patch that corrects address search for Toronto and Ottawa. You'll need updated bounds data for this to work but I have confirmed that it's working. It would be nice to get this included in mkgamp. Thanks, Ben ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap:city empty in large cities
Hi Gerd,
I think the problem with Ottawa is a problem with the data. The current
Ottawa boundary describes a municipal level entity composed of the a bunch
of former small cities (including the city of Ottawa which is now downtown
area of Ottawa).
Looking at Canada in the administrative boundary list and using Toronto as
an example, the current Ottawa boundary should be admin level 8.
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
The National Capital Region should be admin level 6 but I can't find a
boundary for it.
https://en.wikipedia.org/wiki/National_Capital_Region_%28Canada%29
The suburbs within Ottawa (the former full cities) should be admin level
10. Again there are no boundaries but these suburbs are used officially for
addresses. For instance, you can find Kanata listed in the Canada Post
postal code lookup app.
https://www.canadapost.ca/cpo/mc/personal/postalcode/fpc.jsf
It looks like the address setup in mkgmap is incorrect for this setup
because admin level 10 is what people use for addresses in the big cities
in Canada. I can fix this and send a patch.
As for your original question, I think adding the safety catch at the end
would be a good idea just in case there are other areas that have broken
data.
or should we add a one to this block:
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
e.g. a further line with
mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
Nice catch! Thanks, Ben
On Thu, Apr 23, 2015 at 10:13 AM, Gerd Petermann
gpetermann_muenc...@hotmail.com wrote:
Hi all,
I noticed that our rules in inc/address do not set
mkgmap:city in Ottawa/Ontario.
Adding an additional line like the 2nd below solves the problem:
# Canada
mkgmap:country=CAN mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:country=CAN mkgmap:city!=* mkgmap:admin_level6=Ottawa { set
mkgmap:city='${mkgmap:admin_level6}' }
mkgmap:country=CAN mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8|subst:City of }' }
or should we add a one to this block:
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
e.g. a further line with
mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
I assume that there are more large cities with this problem.
Does anybody know how to find them without mkgmap ?
Gerd
___
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] patches
Hi Brian,
Thanks for the feedback.
On Thu, Nov 6, 2014 at 3:13 AM, Brian Egge briane...@gmail.com wrote:
snip
The NYC addresses are working well. I have a minor correction as follows:
Index: resources/styles/default/inc/address
===
--- resources/styles/default/inc/address (revision 3342)
+++ resources/styles/default/inc/address (working copy)
@@ -66,8 +66,11 @@
# New York City has different admin levels than the rest of the US.
# https://wiki.openstreetmap.org/wiki/United_States_admin_level
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='New York County' { set mkgmap:city='New York' }
-mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Bronx County' { set mkgmap:city='The Bronx' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Bronx County' { set mkgmap:city='Bronx' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Kings County' { set mkgmap:city='Brooklyn' }
+# Queens uses neighborhoods for city in postal addresses
+# http://en.wikipedia.org/wiki/List_of_Queens_neighborhoods
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Queens County' mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Queens County' { set mkgmap:city='Queens' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Richmond County' { set mkgmap:city='Staten Island' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8|subst:City of }’ }
One always says ‘The Bronx’, but in addresses is it’s simply Bronx. For
Queens, the neighborhood is used in mailing addresses, though sometimes
people will use ‘Queens’ instead. If you look up 40-01 43 AVENUE”
www.usps.com, it says the standardized address is:
4001 43RD AVE
SUNNYSIDE NY 11104-3205
But, the school board
http://schools.nyc.gov/SchoolPortals/30/Q150/default.htm lists it’s
address as:
40-01 43 AVENUE
QUEENS, NY11104
While the school itself https://sites.google.com/site/ps150queens/ says
it’s address is:
40-01 43 Avenue Sunnyside, NY 11104
If I’m given an address, most likely it will have the neighborhood in it,
and not ‘Queens’.
I briefly looked into this as well and you are correct. Good catch, thanks.
@Gerd (or other mkgmap developers): Can you update the address rules for
NYC with Brian's patch. Thanks.
Here’s an alternative patch to pick up place_name:
Index: src/uk/me/parabola/mkgmap/build/LocatorUtil.java
===
--- src/uk/me/parabola/mkgmap/build/LocatorUtil.java (revision 3342)
+++ src/uk/me/parabola/mkgmap/build/LocatorUtil.java (working copy)
@@ -28,7 +28,7 @@
.compile([,\\s]+);
public static ListString getNameTags(Properties props) {
- String nameTagProp = props.getProperty(name-tag-list, name);
+ String nameTagProp = props.getProperty(name-tag-list,
name,place_name);
return Arrays.asList(COMMA_OR_SPACE_PATTERN.split(nameTagProp));
}
I think it makes sense to have this in mkgmap. Personally I prefer the
patch which displays a warning message so that I can include it in the list
of warnings to fix on my website. But I guess the mkgmap developers are in
the best position to decide which is best. If this solution is chosen, a
comment would be useful - maybe just indicate that 'place_name' is only
included for compatibility with an old tag. Perhaps place_name would be
removed in the future when it's no longer in OSM.
Your other patches seem ok to me but I'm probably not the best person to
review them. :)
Thanks again for this work.
Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: mkgmap in NYC
On Sat, Nov 1, 2014 at 6:03 PM, Brian Egge briane...@gmail.com wrote:
Hi Ben,
The latest maps you've created are working well - I can find addresses in
NYC.
The address search isn't quite as fluid as the Garmin maps, but perhaps
this is related to how the map file is created. For 311 W 51st St, I must
enter in W 51 in order to find the street. With a Garmin map, I can input
'50', and it will show me a list of streets and avenues.
Interesting. I don't know the details of the implementation of the address
search in mkgmap so I don't know what the Garmin maps are more flexible.
Does anybody have any ideas?
I'm not sure how streets names are shortened. In OSM, we have 'West 51st
Street' and that becomes 'W 50st St'. However, when it's part of a route,
it doesn't get shortened. Hence 'West 178th Street
http://www.openstreetmap.org/way/44763890' is listed as 'West 178th
Street (US 9)'. Since not all West's becomes W, one can't guess correctly
which one to use.
I have some rules in my style file to shorten the names
highway=* { name '${name|subst: Street= St|subst: Avenue= Ave| ...
|subst:Ouest =O }' }
I can give you the whole list I use if you're interested. This rule is in
resources/styles/default/lines but I'm not sure why the street name doesn't
get shortened when it's part of a route.
Sometimes names are shortened too much, as in 'West Lane' becomes 'W Ln',
but I can't find any code which is doing this either.
This is a bug in my implementation of the shortening. Fixing this issue is
on my TODO list.
I've also been compiling my own map of the northeast, but with less success
than when I use your weekly map. The main issue I'm having right now is I
can only find cities by searching in all-caps. This is quite odd because
the cities are shown in mixed case. If I search for NEW YORK, I'm able to
find addresses, just like I can on your map. However, searching for 'New
york', 'New York', or 'Ne' yields no results. I've tried including /
excluding the --lower-case flag, but it makes no difference on my Nuvi
1450. Any idea what is causing the issue with the case while searching?
I've never seen this. Here are the options that I'm using for splitter /
mkgmap.
java -Xmx7500M -jar ~/osm/splitter/dist/splitter.jar
--geonames-file=~/osm/data/cities1000.zip
--precomp-sea=~/osm/data/sea_20141027.zip --output=o5m --mapid=24244000
--max-threads=1 --status-freq=0 --max-areas=50 united-states-141029.o5m
java -Xmx7500M -jar -Dlog.config=~/osm/confs/logging.properties
~/osm/mkgmap/dist/mkgmap.jar --latin1 --gmapsupp --index --route
--min-size-polygon --series-name=OSM United States 2014.10.29
--family-name=OpenStreetMap United States 2014.10.29
--location-autofill=bounds,is_in,nearest --remove-ovm-work-files
--bounds=~/osm/data/bounds_20141027.zip
--precomp-sea=~/osm/data/sea_20141027.zip --generate-sea
--add-pois-to-areas --process-destination --process-exits
--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance
--check-roundabout-flares --remove-short-arcs --family-id=24244
--product-id=1 --make-opposite-cycleways --drive-on-right
--check-roundabouts --housenumbers -c template.args --description=OSM
United States 2014.10.29
Hopefully this will help you out. You should definitely be able to get a
usable map for a smaller region of the US.
Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: mkgmap in NYC
Brian: Address search in the US map from 2014.10.23 should now works for
New York. I've tested it in simulation mode but it would be great if you
could test it out to confirm it's working as well. Thanks for pointing out
the issue.
Gerd: I've attached a patch that I'm using to fix the New York address
search. I've also included a small change in Canada and the US which
removes the 'City of' in front of city names when it's there. Nobody uses
the official 'City of' form of city names so it doesn't make sense to have
it in the default style. Let me know if there are any issues.
Thanks, Ben
On Tue, Oct 21, 2014 at 11:39 AM, Gerd Petermann
gpetermann_muenc...@hotmail.com wrote:
Just noticed that I sent this to Greg only...
Gerd
--
From: gpetermann_muenc...@hotmail.com
To: g...@ir.bbn.com
Subject: RE: [mkgmap-dev] mkgmap in NYC
Date: Tue, 21 Oct 2014 09:25:45 +0200
Hi Greg,
I thought about this. The precompiled bounds contain the needed info,
it is the LocationHook that fills the tags like mkgmap:admin_level6.
The LocationHook uses the --name-tag-list option to decide which
value is used.
It would be possible to fill an additional set of tags like
mkgmap:admin_level-alt-2 .. mkgmap:admin_level-alt-11,
but I don't see much use in this.
If I got it right, all we need for New York are a five rules like this:
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5=New York City
mkgmap:admin_level6=New York County { set mkgmap:city=Manhattan }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5=New York City
mkgmap:admin_level6=Kings County { set mkgmap:city=Brooklyn }
...
With the additional alt_name values it would be one rule like this:
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5=New York City
{set mkgmap:city='${mkgmap:admin_level-alt-6}' }
(note that the rule doesn't check if the alt-name is filled)
Are there more places where this could be used?
Gerd
From: g...@ir.bbn.com
To: gpetermann_muenc...@hotmail.com
CC: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] mkgmap in NYC
Date: Mon, 20 Oct 2014 08:37:36 -0400
Gerd Petermann gpetermann_muenc...@hotmail.com writes:
[1] This is because we use so called precompiled boundaries, and
changing them like that would
require hard coded rules in the source.
That might be the right place to fix this. Unfortunately New York
really is a weird case (I don't know of any other such case in the US),
but arguably it's important because a lot of people live there :-)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
diff --git a/resources/styles/default/inc/address b/resources/styles/default/inc/address
index 7c2b3bc..a1f504d 100644
--- a/resources/styles/default/inc/address
+++ b/resources/styles/default/inc/address
@@ -59,7 +59,18 @@ mkgmap:country=CHE mkgmap:city!=* mkgmap:admin_level8=* { set mkgmap:city='$
# Canada
mkgmap:country=CAN mkgmap:region!=* mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' }
-mkgmap:country=CAN mkgmap:city!=* mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
+mkgmap:country=CAN mkgmap:city!=* mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8|subst:City of }' }
+
+# United States
+mkgmap:country=USA mkgmap:region!=* mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' }
+# New York City has different admin levels than the rest of the US.
+# https://wiki.openstreetmap.org/wiki/United_States_admin_level
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City' mkgmap:admin_level6='New York County' { set mkgmap:city='New York' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City' mkgmap:admin_level6='Bronx County' { set mkgmap:city='The Bronx' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City' mkgmap:admin_level6='Kings County' { set mkgmap:city='Brooklyn' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City' mkgmap:admin_level6='Queens County' { set mkgmap:city='Queens' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City' mkgmap:admin_level6='Richmond County' { set mkgmap:city='Staten Island' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8|subst:City of }' }
# Ecuador = ECU
mkgmap:country=ECU mkgmap:region!=* mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap in NYC
Hi everybody,
Thanks for helping out with this issue. @Brian you can also just send me a
message direct about issues related to the maps I make. I have some changes
in the style file so the people on this list won't always be able to help
out. But now that we're talking on this list, I hope other don't mind if we
continue.
I do actually have some changes for the US and NYC that I have been meaning
to contribute to mkgmap. Now's probably a good time to see if this it makes
sense.
Here are my rules for the US:
# United States
mkgmap:country=USA mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
# New York City has different admin levels than the rest of the US.
# https://wiki.openstreetmap.org/wiki/United_States_admin_level
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level6=*
(name='Manhattan' | alt_name='Manhattan') { set mkgmap:city='New York' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level6=* (name='The
Bronx' | alt_name='The Bronx') { set mkgmap:city='The Bronx' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level6=*
(name='Brooklyn'| alt_name='Brooklyn') { set mkgmap:city='Brooklyn' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level6=*
(name='Queens' | alt_name='Queens') { set mkgmap:city='Queens' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level6=* (name='Staten
Island' | alt_name='Staten Island') { set mkgmap:city='Staten Island' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8|subst:City of }' }
I just tried to find 311 W 51 St. in New York but it didn't work as Brian
pointed out. Can anybody see an obvious problem with my rules? Do I need to
compile the bounds myself for this rule to work?
Once I get this working properly, I can make a proper patch.
Thanks, Ben
On Mon, Oct 20, 2014 at 2:37 PM, Greg Troxel g...@ir.bbn.com wrote:
Gerd Petermann gpetermann_muenc...@hotmail.com writes:
[1] This is because we use so called precompiled boundaries, and
changing them like that would
require hard coded rules in the source.
That might be the right place to fix this. Unfortunately New York
really is a weird case (I don't know of any other such case in the US),
but arguably it's important because a lot of people live there :-)
___
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] Address boundary rules for South Africa
On Tue, Jul 1, 2014 at 6:44 PM, Steve Ratcliffe st...@parabola.me.uk wrote: On 01/07/14 17:11, Ben Konrath wrote: Just wondering if somebody can commit this so that other people can benefit from having the address search setup correctly in South Africa. OK done. Thanks for the patch. Thanks. I just re-read my message and it feels a little more pushy than I intended - sorry about that. Thanks to you and the other mkgmap devs for all your hard work! Cheers, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address boundary rules for South Africa
Hey guys, Just wondering if somebody can commit this so that other people can benefit from having the address search setup correctly in South Africa. Thanks, Ben On Tue, Jun 24, 2014 at 2:39 PM, Ben Konrath b...@bagu.org wrote: Hi, Here's a patch to add address boundary rules for South Africa. Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Address boundary rules for South Africa
Hi,
Here's a patch to add address boundary rules for South Africa.
Thanks, Ben
From 7599c827900d6c176439b1323607dea47c8a1cbb Mon Sep 17 00:00:00 2001
From: Ben Konrath b...@bagu.org
Date: Tue, 24 Jun 2014 14:37:15 +0200
Subject: [PATCH] Add address boundary rules for South Africa.
---
resources/styles/default/inc/address | 6 ++
1 file changed, 6 insertions(+)
diff --git a/resources/styles/default/inc/address b/resources/styles/default/inc/address
index 8cbb8df..1a7d0b4 100644
--- a/resources/styles/default/inc/address
+++ b/resources/styles/default/inc/address
@@ -67,6 +67,12 @@ mkgmap:country=ECU mkgmap:city!=* mkgmap:admin_level6=* { set mkgmap:city='$
mkgmap:country=ECU mkgmap:city!=* mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=ECU mkgmap:city!=* mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
+# South Africa = ZAF
+mkgmap:country=ZAF mkgmap:region!=* mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' }
+mkgmap:country=ZAF mkgmap:city!=* mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
+mkgmap:country=ZAF mkgmap:city!=* mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' }
+mkgmap:country=ZAF mkgmap:city!=* mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
+
# common rules for all the rest of countries
mkgmap:region!=* mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' }
mkgmap:region!=* mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' }
--
1.8.2.1
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] 'ant dist' doesn't work for splitter
Hi Gerd,
'ant dist' doesn't work for splitter since this commit:
commit 3f2d290ab9df68cb32128951686fb7853e59f82c
Author: gerd gerd@838fabe5-b1a8-4b81-9896-7a84386980e9
Date: Thu May 22 06:24:27 2014 +
change build to (hopefully) make --version work again
git-svn-id:
http://svn.mkgmap.org.uk/splitter/trunk@389838fabe5-b1a8-4b81-9896-7a84386980e9
I'm not sure if this problem is caused by my use of git (through the
openstreetmap github mirror of splitter). In any case, I've attached a
patch that seems to fix the problem but I'm not exactly sure if it's the
right fix. Any thoughts?
Thanks, Ben
From a9c09f61d46deb3a187a452da2999bf8f7357528 Mon Sep 17 00:00:00 2001
From: Ben Konrath b...@bagu.org
Date: Wed, 28 May 2014 15:45:15 +0200
Subject: [PATCH] Fix build issue with ant dist.
---
build.xml | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/build.xml b/build.xml
index 6aa7dd3..debb970 100644
--- a/build.xml
+++ b/build.xml
@@ -303,13 +303,7 @@
/target
!-- Main --
- target name=build depends=compile,compile.tests,run.tests
-copy todir=${build.classes}
- fileset dir=${resources}
-include name=*.properties/
- /fileset
-/copy
- /target
+ target name=build depends=compile,compile.tests,run.tests/
target name=rebuild depends=clean, build/
/project
--
1.8.2.1
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [splitter patch] check for mapids with less than 9 digits
Hi guys,
I ran into a problem where my map failed to generate properly with mkgmap
when the mapid used with splitter had more than 9 digits. I've attached a
patch for splitter to check for a mapid with more than 9 digits.
Thanks, Ben
diff --git a/src/uk/me/parabola/splitter/Main.java b/src/uk/me/parabola/splitter/Main.java
index 8b1284d..b7923e9 100644
--- a/src/uk/me/parabola/splitter/Main.java
+++ b/src/uk/me/parabola/splitter/Main.java
@@ -323,6 +323,9 @@ public class Main {
}
}
mapId = params.getMapid();
+ if (mapId ) {
+ System.err.println(The --mapid parameter must less than 9 digits. Resetting to 63240001.);
+ }
maxNodes = params.getMaxNodes();
description = params.getDescription();
geoNamesFile = params.getGeonamesFile();
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] add ability to have unlimited ValueFilter chains
On Fri, May 25, 2012 at 10:56 PM, Steve Ratcliffe st...@parabola.me.uk wrote: On 22/05/12 19:46, Ben Konrath wrote: Hi, Here's a patch to add ability to have unlimited ValueFilter chains. I'm using this with the SubstitutionFilter to normalize the road types with a rule like this: Looks good to me. It was always intended that it should do that. Ah ok. I thought that it might have been an oversight, but I wasn't exactly sure. I'll apply it, thanks! Great, thanks! :-) Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2280: Add location rules for Canada -- Ben Konrath
Hi WanMil, Thanks for committing this. I noticed a small typo in the comment - '# Canda' should be '# Canada'. I realize it's a comment and doesn't really affect anything, but I still thought you might want to know. Thanks again, Ben On Thu, May 24, 2012 at 8:56 PM, svn commit s...@mkgmap.org.uk wrote: Version 2280 was commited by wanmil on 2012-05-24 19:56:36 +0100 (Thu, 24 May 2012) Add location rules for Canada -- Ben Konrath ___ 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] how to make address search aware of the Canadian provinces?
Hi WanMil, On Thu, May 24, 2012 at 8:52 PM, WanMil wmgc...@web.de wrote: your approach is correct. But I don't know which field are used by the builtin map. So maybe it is not possible to have the same functionality with mkgmap generated maps. Ok, good to know. Thanks. Can you please what information/address is displayed if you select a POI on your mkgmap generated map. Is the province name displayed? If not then you should check the log file if mkgmap really finds your bounds directory. On the mkgmap generated map of Canada, POIs have the city and province name displayed. If the POI has full address information in OSM, then the full address is displayed. I think the bounds are being set correctly. One thing I noticed is that the built-in map of Canada uses the province abbreviation whereas the mkgmap generated map uses the full province name. For instance, the built-in map uses ON for the province while the map generated with mkmap uses Ontario. Could this somehow be causing the problem? In any case, I would like to use the province abbreviations instead of the full province names. Is there a setting that I can use in mkgmap to get this behaviour? Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [patch] ignore unnamed generated POIs
Hi, I whipped up a patch to ignore unnamed POIs generated with the --add-pois-to-areas option. The patch adds the option to delete all tags with the 'delete' action using '*'. What do people think; is this a good approach? Thanks, Ben mkgmap-ignore-unnamed-generated-pois.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [patch] add ability to have unlimited ValueFilter chains
Hi,
Here's a patch to add ability to have unlimited ValueFilter chains.
I'm using this with the SubstitutionFilter to normalize the road types
with a rule like this:
highway=* { name '${name|subst: Street= St|subst: Avenue= Ave|subst:
Road= Rd}' }
Any thoughts on this? I'd be happy to hear about a better way to
accomplish the same task if this isn't good.
Thanks, Ben
mkgmap-unlimited-value-filter-chain.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [splitter patch] limit description length to 50 characters
I use this patch when building maps of Canada using the --geonames-file=CA.zip option. Sometimes the length of the description will be longer than 50 characters and mkgmap complains. - Ben -- http://www.linkedin.com/in/benkonrath splitter-description-length-50.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmapsupp visible in Basecamp
Hi Minko, I've seen a similar result in Basecamp where the basemap highways were visible along with the OSM map. This was for a map with no TYP file (or the default TYP file I'm not sure what mkgmap is doing these days). This didn't happen with a commercial map so there's definitely something missing from the mkgmap generated maps to tell the Basecamp software to disable or override the basemap. On my unit I've have seen a problem where the routing would use the basemap if a road from the basemap was closer than any road from in my map. It's a weird problem because the routing highlight appears over non-existent roads. I assume this is caused by the same problem as we're seeing in Basecamp. I've also deleted the basemap from my Nuvi but it's not possible to delete the basemap on my etrex vista so the problem still happens occasionally. Is there a bug report database for mkgmap where we can collect information about this problem? - Ben On Sat, Oct 22, 2011 at 9:54 AM, Minko ligfiet...@online.nl wrote: Hi Klaus, I was curious if and how it worked, because Garmin is (probably) going to deliver all its maps this way in the near future. With some products it's already the case, like the official Garmin Benelux cycling map, no installer, no DVD, just a map on muicro SD card. On the Dutch GPS forum there are already people complaining why the other maps are not working in Basecamp while they plug their GPS into the computer! So for convenience, it should be an option to look at, no need to install any maps on the computer anymore. Problem now is, how to get rid of the transparency of the OSM maps when we set the MS flag to zero (to make it visible in Basecamp while you have your OSM map on your GPS (or MicroSD card) and it is plugged into your computer. Op the GPS.nl forum someone already found a workaround by making the (imho worthless basemap) emtpy, but this is for a user with not much computer knowledge already one step too far (it is easier to install the maps on the computer). ___ 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] problem with highway=cycleway in default style
Hi Marko / everybody,
On Wed, Jul 6, 2011 at 1:18 PM, Ben Konrath b...@bagu.org wrote:
[snip]
On Wed, Jul 6, 2011 at 9:15 AM, Marko Mäkelä marko.mak...@iki.fi wrote:
[snip]
Isn't it a bit redundant to add access=yes to ways? Usually, you would
add access restrictions. I would say that this is a problem in the map
data.
This is a good point. Looking at the taginfo:
http://taginfo.openstreetmap.org/keys/?key=access#values
'access = yes' is definitely being and it seems to be a valid
tag/value pair according the wiki. I think it would be a good idea to
remove the 'access = yes' from the OSM data. Perhaps we could remove
this tag/value pair when mkgmap is reading in the data? That way all
of the ways will be normalized to mean 'access = yes' if no access
tag is present. And then we could keep 'add access = no' for the
cycleways which would give the correct behaviour. I can see that my
'set access = no' with overwrite other types of access like 'access =
destination' so it's not a good way forward. Thoughts? I'd be happy to
make the patch.
A proposed patch to solve this issue is attached. Comments are appreciated.
Thanks, Ben
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java b/src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java
index 8627f26..9859807 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java
@@ -167,6 +167,14 @@ public class HighwayHooks extends OsmReadingHooksAdaptor {
}
public void onAddWay(Way way) {
+ // always ignore 'access = yes' because no access tag has this meaning
+ // see this thread for more info:
+ // http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/011884.html
+ String access = way.getTag(access);
+ if (access != null yes.equals(access)) {
+ way.deleteTag(access);
+ }
+
String highway = way.getTag(highway);
if (highway != null || ferry.equals(way.getTag(route))) {
boolean oneway = way.isBoolTag(oneway);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with highway=cycleway in default style
On Wed, Jul 6, 2011 at 3:31 PM, Marko Mäkelä marko.mak...@iki.fi wrote:
On Wed, Jul 06, 2011 at 02:52:59PM +0200, Ben Konrath wrote:
'access = yes' is definitely being and it seems to be a valid
tag/value pair according the wiki. I think it would be a good idea to
remove the 'access = yes' from the OSM data. Perhaps we could remove
this tag/value pair when mkgmap is reading in the data? That way all
of the ways will be normalized to mean 'access = yes' if no access
tag is present. And then we could keep 'add access = no' for the
cycleways which would give the correct behaviour.
With this scheme, we would still get the proper behaviour with cycleways
that have been tagged as access=destination (implying motor vehicle
routing).
Yep.
I can see that my 'set access = no' with overwrite other types of
access like 'access = destination' so it's not a good way forward.
Thoughts?
Would something like this work at the top of the style file?
highway=* access = yes { delete access }
I didn't know you could that with the style rules. I just tried this
but it actually removed the whole way in the resulting map. Maybe
there's a bug in mkgmap with this type of rule??
I would prefer to do such tweaks in the style language, if possible. For
example, the --make-opposite-cycleways (or whatever it is called) would
be easier to understand and maintain if it made use of the
continue_with_actions that was introduced after the feature was
implemented.
Yeah, I agree. Using the style rules for things like this makes it
more maintainable.
It could be a good idea to treat motor_vehicle the same as motorcar and
motorcycle, and warn if there is a conflict (such as motorcar=yes,
motorcycle=no).
That seems good. Do you know how to represent that in the style file?
Thanks, Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problem with highway=cycleway in default style
Hi everybody,
I've found a problem with the highway=cycleway in the default style.
The current setting from the default lines file is this:
highway=cycleway {add access = no; add bicycle = yes; add foot = yes}
[0x07 road_class=0 road_speed=1 resolution 23]
One small problem is that the cycleway should probably be listed as a
path or trail (0x16) instead of alley (0x07).
The bigger issue, however, is that the extra tags which are added to
highway=cycleway makes cycleways routable by car under certain
circumstances. The problem comes from the way that the access tag is
used in the style file. The access tag in OSM describes legal access
to a given highway:
http://wiki.openstreetmap.org/wiki/Key:access
A tag with 'access = no' means that the general public is not allowed
to go on that particular highway. Likewise, 'access = yes' means that
the general public is allowed to use that highway. And then there's
specific types of access in between yes and no for specific types of
traffic as listed on tag's wiki page.
In the default style of mkgmap, it seems that the access tag is used
to represent whether or not a particular highway type is routable by
motor vehicle. If you have have cycyleway that is tagged with 'access
= yes' - meaning the public is allowed use that cycleway - the 'add
access = no' rule will not overwrite the access rule in the OSM data
and the cycleway will be routable by motor vehicle. An example of this
can be found in Red Deer, Alberta, Canada on the Bob Johnson Trail:
http://www.openstreetmap.org/?lat=52.276167lon=-113.804459zoom=18layers=MOn
To solve this problem, I've changed 'add access = no' to 'set access =
no' so that the access tag will be overwritten and cycleways will not
be routable. But this seems to be a hack because it's not really
describing the OSM data correctly. I think it would be better to use
the motor_vehicle tag to determine if a cycleway is routable by car.
The motor_vehicle tag is described on the 'access' tag's osm wiki page
above. Here's the proposed style for cycleways:
highway=cycleway {add motor_vehicle = no; set bicycle = yes; add foot
= yes} [0x16 road_class=0 road_speed=1 resolution 23]
This would prohibit motor_vehicle routing on cycleways by default if
the cycleway if the cycleway doesn't have a motor_vehicle tag. This
would also allow motor vehicle routing on cycleways that allow it as
described in this thread from last month:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011771.html
We'd still have to support the OSM access tag somehow. I did a quick
grep through the mkgmap source and it seems that there isn't support
of the motor_vehicle tag. I would like to make a patch to address this
issue but I have a couple of questions first. Is the access tag used
to describe motor vehicle access in mkgmap? Does the garmin format
support the idea of public / private access separately from motor
vehicle access?
For now, I'm using the attached patch prohibit . I've change 'add
bicycle = yes' to 'set bicycle = yes' because anything tagged a
cycleway must allow bicycles by definition.
Thanks, Ben
diff --git a/resources/styles/default/lines b/resources/styles/default/lines
index b335c7b..d4ae91b 100644
--- a/resources/styles/default/lines
+++ b/resources/styles/default/lines
@@ -119,7 +119,7 @@ highway=service (service=alley|service=driveway)
[0x07 road_class=0 road_speed=0 resolution 23]
highway=service [0x07 road_class=0 road_speed=2 resolution 22]
-highway=cycleway {add access = no; add bicycle = yes; add foot = yes} [0x07 road_class=0 road_speed=1 resolution 23]
+highway=cycleway {set access = no; set bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=1 resolution 23]
highway=footway|highway=path|highway=steps {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
highway=track [0x0a road_class=0 road_speed=1 resolution 22]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with highway=cycleway in default style
HI Felix,
On Tue, Jul 5, 2011 at 12:37 PM, Felix Hartmann extremecar...@gmail.com wrote:
[snip]
highway=cycleway {add motor_vehicle = no; set bicycle = yes; add foot
= yes} [0x16 road_class=0 road_speed=1 resolution 23]
That wouldn't change anything. 0x16 is routable by motorcars too. Add is
correct, as in some places people seem to think that cycleways are usable
for cars (for short distances and so on). Else use set access=no; set
bicycle=yes; add foot=yes.
According to the OSM tag rules, if a cycleway is allowed to used by
cars, the motor_vehicle should be set to yes in which case the 'add
motor_vehicle = no' wouldn't do anything which is correct.
Let me try to clarify things a bit. The OSM data separates who's
allowed to access a given way and what type of traffic is allowed on a
given way. I think that mkgmap should properly support this. The
garmin format may not support these distinctions in which case we'll
need to tweak the style file to combine them as best as we can. There
are problems with the way that is currently being done in the default
style of mkgmap.
By the way, 'set bicycle = yes' is actually wrong in the patch that I
attached because it could overwrite other information in the bicycle
tag. I've attached a corrected patch which keeps the 'add bicycle =
yes'.
Cheers, Ben
diff --git a/resources/styles/default/lines b/resources/styles/default/lines
index b335c7b..802dd7b 100644
--- a/resources/styles/default/lines
+++ b/resources/styles/default/lines
@@ -119,7 +119,7 @@ highway=service (service=alley|service=driveway)
[0x07 road_class=0 road_speed=0 resolution 23]
highway=service [0x07 road_class=0 road_speed=2 resolution 22]
-highway=cycleway {add access = no; add bicycle = yes; add foot = yes} [0x07 road_class=0 road_speed=1 resolution 23]
+highway=cycleway {set access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=1 resolution 23]
highway=footway|highway=path|highway=steps {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
highway=track [0x0a road_class=0 road_speed=1 resolution 22]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with highway=cycleway in default style
On Tue, Jul 5, 2011 at 1:04 PM, Felix Hartmann extremecar...@gmail.com wrote: [snip] But there is no difference in routing between 0x07 and 0x16! (else my maps wouldn't work...) There are only very few types that have very special attributes and they only differ in the routing instructions but not the access rights like the ones for junctions and roundabouts (well and then there are the ferry types that are super special) Ah ok, I understand what you were getting at now. Changing 0x07 to 0x16 make my GPS draw a trail or path, not an alley. With 0x07, hovering above the way pops up 'Alley' while 0x16 pops up the path name. I just think 0x16 is more correct for cycleway. Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
On Tue, Feb 1, 2011 at 4:20 PM, Torsten Leistikow de_m...@gmx.de wrote: Moin, Henning Scholland schrieb am 31.01.2011 21:41: Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon? In OSM some objets can be mapped in OSM as a node or as an area, depending on the availability of the source data. If they are mapped as a node, I want them to be displayed as a symbol in my map. If they are mapped as an area, I want them to be displayed as a polygon. With the pois-to-area function the latter ones are displayed in a map twice, as a polygon AND as a symbol. That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out. Cheers, Ben ___ 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
Hi Charlie, Like Marko, I would much much prefer an add_poi style action than the univeral --add-pois-to-areas. Yeah. 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. That's a sore spot for me too. I started a patch to calculate the value based on the shape's centroid but the centroid is not always going to be inside the shape for extremely concave polygons. For example, I suspect the centroid of Museo Nacional de Costa Rica is not inside the shape: http://www.openstreetmap.org/?lat=9.932377lon=-84.070927zoom=18layers=M There's a trick I could use to nudge the POI into the shape for cases like this so I might code that up when I can find some time. There's another problem that needs to be sorted out when using the driving directions to the POIs. When I'm driving to the big box store in the suburbs, I don't actually want directions to the building, but rather directions to the parking lot (car park in the UK terms) of the building. To solve this I think a new relation type will be needed where you can relate a parking lot to a building. And then of course we'll need to support this in mkgmap. Cheers, Ben ___ 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
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) Cheers, Ben ___ 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
On Sun, Jan 30, 2011 at 9:42 PM, Marko Mäkelä marko.mak...@iki.fi wrote: On Sun, Jan 30, 2011 at 08:53:09PM +0100, Ben Konrath wrote: 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 You seem to have have a vertical band of inverted land/sea west from Oakville. I would guess that the NW or NE corner of the inverted box is at a tile border. I would suspect some error at the spot where one of the vertical lines intersects with the real coastline. Hmm, I was almost going to believe that the ocean starts right south of Canada, but then I remembered that there is some piece of land called the United States in between. :-) You can't really see the U.S. across the lake from Toronto it's easy to pretend it's not there :-). I would guess two possible causes for your problem. Either your tile boundaries are chosen badly, so that some multipolygons are severed by them, or the input data is bad. splitter.jar will leave some 'safety margin' around the tiles, but it may not be enough. When the Lake Päijänne in Finland was defined in a single multipolygon (it used to be natural=coastline), I got some errors that I fixed by moving my tile boundaries so that the entire lake fits in a single tile. The actual coastline seem fine around where the problem flooded land hits the lake. I think it probably has something to do with the multipolygon that makes up the North shore of Lake Ontario. I'm using my own Canada polygon cut from the planet so I might be cutting off the parts of the multipolygon. I'll look into this when I have some time. If you want generate-sea to work on a non-rectangular map extract (and if the Great Lakes have been defined as natural=coastline), you may have to apply some black magic when choosing the tile borders. For my Finland map, I extracted the natural=coastline from the Geofabrik finland.osm.pbf with Osmosis, and loaded the result in JOSM. Then I figured out how to choose the tile borders so that the missing sections of natural=coastline would be outside the tile borders. Only in the north, I had to use extend-sea-sectors to augment a missing bit, because I did not want to create lots of tiny tiles near the Swedish/Finnish land border. Thanks, this is really useful information. I'm using mkgmap version r1783 with these options: java -Xmx400M -Dlog.config=/home/ben/osm/mkgmap/resources/logging.properties 400M could be a bit scarce, but probably not causing this. I run with -Xmx1024m. If your logging.properties is like the one I have at http://www.polkupyoraily.net/osm/, you should have some mkgmap.log.* files. The most recent one should be mkgmap.log.0. Does anybody know what's going on? What's the best way to debug a problem like this? Search mkgmap.log.0 for 'MultiPolygon' or 'coastline'. Or, if you are ambitious, take and adapt my logging.ignore, and grep -vf logging.ignore mkgmap.log.0, and fix all errors. That is doable for a small country, such as Finland. I update my public map only when there are no serious errors (such as multipolygon issues or dead-end oneways other than some driveway). Again, great information. Thanks! I'll check how Canada is doing on the error front. For now I'm relying on people who download my map to let me know if something's broken but it's would be better to add some error checking like you do. Cheers, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problem with --generate-sea near Toronto, Canada
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 Does anybody know what's going on? What's the best way to debug a problem like this? Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] --generate-sea for Australia?
Hi folks, I got quite excited when generate-sea was introduced, and tried several combinations of parameters in the last weeks to render some Aussie sea - to no avail. There is just no sea polygon generated. - Did someone manage to generate some sea for (parts of) Australia and is so kind to share his parameters? - Is the data probably not sufficient, and I am contributing to global warming by rendering again and again? Cheers, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap-latest direct-link?
http://wiki.openstreetmap.org/wiki/Mkgmap/dev and http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz Great, thanks Chris! How could I miss that? http://www.mkgmap.org.uk/snapshots/mkgmap-latest.zip works as well! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem seeing OSM maps on nuvi 255w
Hi Clinton, On Tue, Dec 22, 2009 at 11:20 AM, Clinton Gladstone clinton.gladst...@googlemail.com wrote: On Dec 22, 2009, at 17:08, Ben Konrath wrote: I added '--draw-priority=30' to all three commands and the resulting map is visible but the roads appear behind the roads from the Garmin North American maps even though they are turned off. I *could* just plug the GPS unit into my computer and delete the Garmin basemaps and North American maps but I thought I'd ask here first before I do that. I have had various maps on my Nuvi (including several layers of Ontario), but have never needed to delete the basemap, etc. I would suggest that this is not a good option. ;-) Have you even seen a conflict between the included maps (not the basemaps) and the OSM maps? Do you have a North American (Canada and US) Nuvi? Do the img files which you generate for Ontario and Quebec have exclusive names, or do they do they have overlapping names? If some of the img files are identically named (even though they are in separate directories), this could be the source of some problems. Yeah, the img files have different names - so that's not the problem. Thanks for the suggestion though :-). Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem seeing OSM maps on nuvi 255w
Hi Charlie, On Tue, Dec 22, 2009 at 11:27 AM, Charlie Ferrero char...@cferrero.net wrote: Can you have multiple gmapsupp files on a Nuvi? I guess you must be able to, if you've got both North American maps and OSM maps at the same time. I don't know if Nuvis are the same, but on a GPSMap you can't remove the basemap (though you can turn it off). The Nuvi 255w appears as a 2Gb USB drive when you plug it into a computer. This USB drive appears to have all the firmware and maps files. The Garmin directory has the basemaps - gmapbmap.img (50Mb) and the map files for the region you bought the GPS unit - gmapprom.img (1.1Gb) - in my case Canada and USA. To load external maps, you can either put the gmapsupp file in the Garmin directory of the USB drive or you can put it in the Garmin directory of an SD card. The nuvi will only load one gmapsupp file giving preference to the file on the unit itself. To remove the basemap or included maps, all you have to do is rename or delete the appropriate file. Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem seeing OSM maps on nuvi 255w
Hi Clinton, On Tue, Dec 22, 2009 at 1:55 PM, Clinton Gladstone clinton.gladst...@googlemail.com wrote: No, I have a European Nuvi; I believe it has a worldwide base map and the City Navigator (or whatever it's called) for Europe. I have not yet have any conflicts with the maps. I do load all my OSM maps onto an SD card though. When I was in Costa Rica I was able to load the OSM maps without a problem because the included Garmin city maps didn't cover the same area. That might be the same when you were in Ontario - you were able to see the Ontario OSM map fine because it didn't cover the same area as the included Garmin City maps. What happens when you load an mkgmap generated map for an area in Europe that overlaps the included Garmin city maps for Europe? Does this work for you? FWIW, I have the same problem if I load the maps on an SD card or on the unit itself. Cheers, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POIs not visible in 3d mode
Hi Maning, With my Nuvi 255w I don't see POIs in 3D mode with the mkgmap generated maps or the included garmin maps. I think that might be how it's supposed to work. HTH, Ben On Mon, Dec 7, 2009 at 8:54 AM, maning sambale emmanuel.samb...@gmail.com wrote: Hi, I saw my garmin map (compiled with mkgmap) loaded on a Nuvi 1310 and notice that POIs are not visible in 3d mode. A while back, I also saw this behaviour in nuvi200. Other users reported that they can see POIs in 3d mode. Is this a confirmed issue with other units? -- 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] --add-poi-to-areas customization?
Hi guys, whilst its a great feature for some areas such as shops, its rather useless for others, such as natural=rock, where there might be areas and POIs tagged with. Is there a way to have POIs generated from the areas for certain polygons only? Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] suppress street labels / set name=nil
LABEL= That does the trick perfectly! (And it should even keep the name for routing etc. Didnt test that though) Thanks, Felix! Felix Hartmann wrote: If you use a typfile, you can surpress labels by type. On 02.12.2009 08:33, Marko Mäkelä wrote: Hi Ben, On Wed, Dec 02, 2009 at 05:14:08PM +1100, Ben wrote: Is there a smart way to have mkgmap explicitly setting an empty name for lines? - when I use [default_name ''] the name is filled with some odd content, in my case Castle Hill Police... - when I use [default_name ' '] the name is filled with the expected space, but this causes a black rectangle to appear instead of a label When the name is missing, my Edge 705 usually says Jälki (the Finnish for Trace or Track) for cycleways, footways and highway=service. I do not know of a way to assign a null name in mkgmap, other than omitting the name or default_name action. background: the setting on Garmin devices (I am testing on a 60CSx) Max Zoom: Street Label doesnt seem to work properly fro some ways: even if set to off, some street labels are still shown, e.g. steps and cycleways. This clutters up the map, so I want to suppress names for those types of ways. This is another example of it being impossible to satisfy everyone's needs with a single map. As a bicyclist, I very much appreciate having street names on cycleways that are running next to a highway. In that way, the turn directions become more meaningful. Would it be possible to hide names in a map overlay? Say, have several overlays on the base layer: * contour lines * highlighting of paths that are not for (motor) vehicle use: * hiking * mountain biking * horse riding * routes and stops for public transportation * motor vehicle overlay (hiding some names and the like) If the Garmin routing subsystem could utilize data from map overlays (can it?), the motor_vehicle=no stuff could be omitted from the base layer and the desired overlays enabled by the user on a case-by-case basis. For example, mountain bikers and normal bicyclists would prefer different routes and select different map overlays. Best regards, Marko ___ 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 mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] suppress street labels / set name=nil
Hi all, Is there a smart way to have mkgmap explicitly setting an empty name for lines? - when I use [default_name ''] the name is filled with some odd content, in my case Castle Hill Police... - when I use [default_name ' '] the name is filled with the expected space, but this causes a black rectangle to appear instead of a label background: the setting on Garmin devices (I am testing on a 60CSx) Max Zoom: Street Label doesnt seem to work properly fro some ways: even if set to off, some street labels are still shown, e.g. steps and cycleways. This clutters up the map, so I want to suppress names for those types of ways. Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] tag test start with
Hi mkgmap gurus,
Im currently trying to convert some POI lists into img format with mkgmap.
Depending on the first character of the POI name, different actions
should be performed.
I tried the following:
name=T* {name '${name}'} [0x0101 level 4]
name=M* {name '${name}'} [0x0102 level 4]
name=E* {name '${name}'} [0x0103 level 4]
what results in the error message
Error in style: Error: (points:1): Stack size is 2
Could not open style null
As far as I understand the syntax, I can only test tags for equality,
not if they contain certain strings.
Does anyone have a good idea idea for how to achieve the desired
differentiation?
Thanks,
Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tag test start with
Thanks, Thilo!
that worked (almost) straight away.
I just needed to add an equation to start with:
name=* name ~ 'T.*' {name '${name}'} [0x6501 level 4]
Happy mapping,
-Ben
Thilo Hannemann wrote:
Hi Ben,
perhaps it is not really obvious from the documentation, but you can use
regular expressions. The syntax would be
name ~ 'T.*'
for example. Note the .* instead of a single *, this is a proper regexp and
not the simplified version. For reference I would suggest something like
http://java.sun.com/docs/books/tutorial/essential/regex/, but I'm not sure if
everything works in mkgmap that is described there.
Regards
Thilo
Am 25.11.2009 um 13:21 schrieb Ben:
Hi mkgmap gurus,
Im currently trying to convert some POI lists into img format with mkgmap.
Depending on the first character of the POI name, different actions
should be performed.
I tried the following:
name=T* {name '${name}'} [0x0101 level 4]
name=M* {name '${name}'} [0x0102 level 4]
name=E* {name '${name}'} [0x0103 level 4]
what results in the error message
Error in style: Error: (points:1): Stack size is 2
Could not open style null
As far as I understand the syntax, I can only test tags for equality,
not if they contain certain strings.
Does anyone have a good idea idea for how to achieve the desired
differentiation?
Thanks,
Ben
___
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] change bus_stop to Transit Service category and add name / operator
Hi Marko, On Sat, Jul 18, 2009 at 2:49 PM, Marko Mäkelämarko.mak...@iki.fi wrote: snip I would prefer to have only the major things (bus stations and train stops) in one menu and all the others (bus stops, tram stops) in the other menu. In this way, it should be easier to plan long journeys when travelling by train or long-haul bus. And for getting around inside a city, you'd look for the nearest bus or tram stop. I assume that this was Ben's reasoning too. Yes, that's exactly what I was thinking. I like your updated rules, thanks for making them. It would be nice to see them committed. About the TYP file, are there any plans to have one included for use with the default style? I don't actually know much about these files yet so my question might be a bit naive. Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] some natural points
Hi Marko, On Sat, Jul 11, 2009 at 1:41 AM, Marko Mäkelämarko.mak...@iki.fi wrote: Hi Ben, I compared your patch to mine. I only noticed two differences: First, in my patch, truck stops have precedence over manned fuel stations (to make the map more useful to truck drivers): +amenity=fuel fuel:HGV_diesel=yes [ 0x2f16 resolution 19 ] amenity=fuel shop=convenience [ 0x2e06 resolution 19 ] I may have posted an initial version of the patch where this was not the case. Second, in my patch, natural=rock is added before natural=spring, not after it. It is a cosmetic thing (maintaining alphabetical order). Did you perhaps post the wrong patch? I may have made a mistake here. Thanks for looking at the patch and catching the error. Cheers, Ben ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
