- mkgmap-dev - The mkgmap lists

Assigning a street to more than one city
by Carlos Dávila 07 Jun '15

07 Jun '15

I've seen City Navigator maps are able to find the same street in two cities. I find this quite useful for the case of big municipalities with a main city and several minor villages belonging to that municipality or big cities with also big suburbs . I these cases you may not be sure what to enter in the "City" field when searching for a given street and finding it in both places eases search. Is it possible to accomplish the same with mkgmp?

2 4

Commit: r3615: test-map:all-elements :
by svn commit 07 Jun '15

07 Jun '15

Version mkgmap-r3615 was committed by gerd on Sun, 07 Jun 2015 test-map:all-elements : - add distance between POI and lines - now really generate polygons between 0x00 and 0x7f - evaluate option --verbose to produce a log about what was generated and where - evaluate options --x-base-lat and --x-base-long when environment variables BASE_LAT / BASE_LONG are not set

1 0

Commit: r3614: update result of test-map:all-elements
by svn commit 07 Jun '15

07 Jun '15

Version mkgmap-r3614 was committed by gerd on Sun, 07 Jun 2015 update result of test-map:all-elements - POI types from 0x00 0x7f, subtypes from to 0x00 to 0x1f, names as in style file, e.g. 0x201b - Line types from 0x00 to 0x3f - Polygons types from 0x00 to 0x7f

1 0

POIs without POI-search
by Arndt 07 Jun '15

07 Jun '15

Hello experts, there are many POIs like barrier, traffic lights, trees an so on. Is it possible to show them in the map, but without a hit in the poi-search? Best regards Arndt

6 8

Commit: r3613: test-map:all-elements: generate shapes which have identical, not just equal closing points
by svn commit 07 Jun '15

07 Jun '15

Version mkgmap-r3613 was committed by gerd on Sun, 07 Jun 2015 test-map:all-elements: generate shapes which have identical, not just equal closing points

1 0

Re: [mkgmap-dev] GUI for POI Search TYPES
by Bernd Weigelt 07 Jun '15

07 Jun '15

Francos and my POIs are more or less in the right categories, but we had to get it in the hard way. The original AIO has more unsorted kinds, we change them after a lot of tests oder weeks Bernd Hier sollte eigentlich eine Signatur stehen. -----Original Message----- From: nwillink <osm(a)pinns.co.uk> To: mkgmap-dev(a)lists.mkgmap.org.uk Sent: So., 07 Juni 2015 10:05 Subject: Re: [mkgmap-dev] GUI for POI Search TYPES Hi Bernd Thanks for that Because of this tool I realised my doctors are under Other --> Personal services NUVI CN NAV maps have 11014 (2f14) as social and medical services Nick On 07/06/2015 08:24, Bernd Weigelt [via GIS] wrote: > Hi Nick > > > Thank you for long time missed tools. > > It's very interessting to see. how much hidden POI groups are > implemented on > the different devices. Five kind of bar/nightclub on a Oregon 650, but no > special category for dentists or other doctors ;-) > > > Bernd > > > > Am Samstag, 6. Juni 2015, 22:26:43 schrieb nwillink: > > > Hi Gerd > > > > I realised I used 3602 not 3612 so now its working ; many thanks for > > burning the midnight oil! > > Have rewritten webpage as well. > > > > best regards > > > > Nick > > > > > > --- > > This email has been checked for viruses by Avast antivirus software. > > https://www.avast.com/antivirus > > > > > > > > > > > > -- > > View this message in context: > > > http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847407.h > > tml Sent from the Mkgmap Development mailing list archive at > Nabble.com. > > -- > amarok2 now playing: > > > > > _______________________________________________ > mkgmap-dev mailing list > [hidden email] </user/SendEmail.jtp?type=node&node=5847411&i=0> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847411.h… > > To unsubscribe from GUI for POI Search TYPES, click here > <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_b…>. > NAML > <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&…> > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- View this message in context: http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847417.h… Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

FW: Should we exclued bridges from housenumber processing?
by Gerd Petermann 07 Jun '15

07 Jun '15

From: gpetermann_muenchen(a)hotmail.com To: gdt(a)ir.bbn.com Subject: RE: [mkgmap-dev] Should we exclued bridges from housenumber processing? Date: Sun, 7 Jun 2015 05:31:42 +0200 Hi Greg, > I don't see why an address shouldn't be valid just because it's on a > road that happens to be a bridge. It would be good to get pointers to > the situations where people think this proposed rule makes sense, and we > can then see if we think there are tagging errors. you are right, I should have mentioned the reason. The new housenumber code is much slower than the old one, the major reason is that it has to find matching roads without using the name. In the default style, I've added some rules to exclude roads which probably never should be used for adresses, e.g. motorways, ferries and ways created by the --make-opposite-cycleways option. Marios idea was that bridges and tunnels are like those, but it turned out that we have valid addresses on bridges and in level -1 areas. So, I think the short answer is "no, we should not exclude bridges" thanks for the feedback to all others too Gerd

1 0

Should we exclued bridges from housenumber processing?
by Gerd Petermann 07 Jun '15

07 Jun '15

Hi all, Mario Batschke suggested in a private mail to use highway=* & bridge=yes {set mkgmap:numbers=false} in the finalize section for lines so that addresses are not assigned to bridges. I think this is a good idea. He also suggested to exclude tunnels, but I see quite a lot cases where this doesn't improve the address search, e.g. for shops in underground stations. Any comments? Gerd

4 3

Commit: r3612: use high precision when calculating the boundaries
by svn commit 06 Jun '15

06 Jun '15

Version mkgmap-r3612 was committed by gerd on Sat, 06 Jun 2015 use high precision when calculating the boundaries of a file that has no bounds, e.g. polish format (*.mp) input

1 0

[Patch v1] simplify address rules
by Gerd Petermann 06 Jun '15

06 Jun '15

Hi all, attached is a patch that removes all rules which I think are superfluous. I've also attached the modified inc/address file. My understanding is that country specific rules should only be used when the general rules don't work. It makes no sense to have a specific rule mkgmap:country=BEL & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } when the next possible match is the general rule mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } Or is this meant as some kind of documentation (meaning we have verified these rules for Belgium) ? Gerd

2 5