May 2015 - mkgmap-dev - The mkgmap lists

problem with highways as multipolygons
by Andrzej Popowski 11 May '15

11 May '15

Hi All, I have stuck at following problem: There is relation 4764899: type=multipolygon highway=footway Line 336969927 as inner Line 336969921 as outer This is an area, probably it should include tag "area=yes", but actually it doesn't. Mkgmap creates a new polyline from multipolygon and polyline is processed according to rules in "lines" part of style. I haven't found any method to safely remove this line from my map. I have tried to added following rule to "relations" file: type=multipolygon & highway=* { set area=yes; } but this doesn't work, new tags aren't added to created polyline. This looks for me like a bug. Any ideas, how to deal with multipolygon? -- Best regards, Andrzej

2 9

r3571 in housenumber2 branch
by Gerd Petermann 10 May '15

10 May '15

Hi all, I think r3571 is stable and working good enough again for a public test. Compared to trunk there are many changes: - mkgmap tries to identify unnamed roads which lead to houses and can be named (assuming they are service roads) - mkgmap tries to find a plausible road when no street is given (mkgmap:housenumber=* & mkgmap:street!=* & addr:street=* - addr:interpolation ways are used to find the most plausible road and the interpolated addresses are found - special cases regarding addresses in different cities or zip codes along the same road are handled. This is important when a road starts in city A and has some numbers 1..20 there and later crosses city B with numbers 1..5 and finally ends in city C with numbers 1..50. - the found addresses are typically closer to the house If you want to test with your own style: Please note the new special tags mkgmap:numbers=false and mkgmap:execute_finalize_rules=true - a road with mkgmap:numbers=false is ignored in housenumber processing. The default style uses it for ferries and motorways and for bicycle-only roads. To set the city, region and country values for all elements with housenumbers, use addr:housenumber=* {set mkgmap:execute_finalize_rules=true} as a first rule in points, lines and polygons and add include 'inc/address'; to the finalize sections. Gerd

1 1

feedback for patch admin_centre-v1.patch ?
by Gerd Petermann 09 May '15

09 May '15

Hi all, not sure if anybody noticed this post: http://gis.19327.n5.nabble.com/Fw-Help-tp5843021p5843485.html I wrote that I'll commit it on sunday if I hear no complains, but I would prefer to hear some positive feedback first ;-) Gerd

2 2

help improvements
by Mike Baggaley 07 May '15

07 May '15

Hi Gerd, please find attached a patch to correct a few typos in the documentation. Please commit if you are happy with it. Note I have standardised on English, rather than US English - there was previously a mixture of the two, but more British spellings than American. Regards, Mike

3 4

Commit: r3570: style: make sure that highway=footway is accessible for pedestrian
by svn commit 07 May '15

07 May '15

Version mkgmap-r3570 was committed by gerd on Thu, 07 May 2015 style: make sure that highway=footway is accessible for pedestrian

1 0

highway=footway not accessible for pedestrian?
by Gerd Petermann 07 May '15

07 May '15

Hi all, I've just noticed that the default style treats a way with highway=footway and bicycle=yes as a bicycle-only way, e.g. http://www.openstreetmap.org/way/8564649 I think that is not intended. Reason is this rule: # Convert generic path to most specific highway=footway & snowplowing!=no & (bicycle=yes|bicycle=designated|bicycle=permissive|bicycle=official) {set highway=cycleway; set bicycle=yes} which changes a highway=footway to a highway=cycleway. In the german wiki the tag highway=footway means something like "pedestrian only". I'd like to change that rule to highway=footway & snowplowing!=no & (bicycle=designated|bicycle=permissive|bicycle=official) {set highway=cycleway; set bicycle=yes; set foot=yes} OK? Gerd

2 1

Commit: r3569: help improvements by Mike Baggaley
by svn commit 07 May '15

07 May '15

Version mkgmap-r3569 was committed by gerd on Thu, 07 May 2015 help improvements by Mike Baggaley

1 0

Fw: Help
by thundercel＠gpsinfo.com.br 06 May '15

06 May '15

Hi Gerd, Trying to help the Anor.Carlos, is there any command to be entered by the user in rendering to be removed key: place inserted boundary: relation? Unfortunately in Brazil some editors inserted a KEY place in boundary-administrative relationship there so duplicity in indexing as the key:place exists in admin_centre inserted in the relationship. []s Marcio > Date: Sun, 3 May 2015 07:56:00 -0700 > From: gpetermann_muenchen(a)hotmail.com > To: mkgmap-dev(a)lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Help > > Hi A.Carlos, > > I am sorry, I don't yet understand your problem. > Maybe you can post some screenshots to describe what you want > and what you get? > > You can use http://files.mkgmap.org.uk/ for that. > > Gerd > > > A. Carlos wrote > > help > > > > Hello, the question may seem amateurish, but I'm having problems > > compiling my maps. > > Seeing the OSM, the region that use in many places are using the place at > > the midpoint of the Administrative Liminte and also in relation to limit > > the administrative, in the case here level 8. > > > > However, when compiling the map with the styles that have both the GPS > > when the Mapsouce when looking for these cities are showing up two times > > in the list. > > > > I ask: > > Do you have any command, tip to delete one of these tags, both at the > > center (point) and in relation Administrative Limit to not duplicate > > research? > > grateful > > Anor C. A. de Souza

5 11

RFC: naming unnamed roads
by Gerd Petermann 06 May '15

06 May '15

Hi all, I see some cases where the automatic naming of "service roads" causes problems. Maybe you can help me to find better heuristics. The target is to produce data that enables Garmin software to find an address / a house when OSM data shows an address. Now, often houses have a tag addr:street=xyz, but the closest road(s) don't have the name xyz. This happens when 1) an unnamed service road or footway is connecting the house with a road named xyz 2) unnamed cylceways / footways are between the house and the named road 3) typos in the addr:street tag or the mkgmap:street tag prevent a clear match, e.g. the road is named "Alte Chausseestraße" and the houses have (probably wrong) "Alte Chaussestraße" (single e), or the addr:street tag is completely wrong, means, no street with a name like that is close. 4) a named road is close to one side of the house but an unnamed track/footway is closer on an other side. I think 1) is clear, we want that Garmin address search points us to a point on the service road. In case 2) I would prefer to find the named road, but it seems to cause no problems when mkgmap uses the closer way and gives it the name of the named road, at least as long as both roads are more or less parallel lines. Case 3) is a bit funny. The unnamed road will be used and address search will find the address as long as you type the (probably) wrong name. In trunk, these houses are ignored, which is sometimes better, sometimes not. Case 4) is causing real trouble. We don't want to be routed to the these roads, but up to now I found no rule(s) to distinguish them from 1) or 2) besides the tag mkgmap:numbers=false . Any ideas ? Gerd

4 8

assertion in mdrx2 in housenumber2 branch
by Gerd Petermann 05 May '15

05 May '15

Hi Steve, when creating the index for multiple files I see now an assertion from line 45: assert street.getMapIndex() == street.getCity().getMapIndex() : street.getMapIndex() + "/" + street.getCity().getMapIndex(); I guess the code is not yet prepared for roads with more than one city, but I don't understand it yet. Do you have a hint what to change here? Gerd

2 3