April 2015 - mkgmap-dev - The mkgmap lists

Commit: r3522: correct files with mixed unix/windows eol styles
by svn commit 05 Apr '15

05 Apr '15

Version mkgmap-r3522 was committed by gerd on Sun, 05 Apr 2015 correct files with mixed unix/windows eol styles no effect on img output

3 2

Commit: r3523: Make pre-commit check match mixed CRLF and LF line endings.
by svn commit 05 Apr '15

05 Apr '15

Version mkgmap-r3523 was committed by steve on Sun, 05 Apr 2015 Make pre-commit check match mixed CRLF and LF line endings. Previously the match only worked for files that were completely in CRLF format.

1 0

Commit: r3519: write NET file when either --route or --net is given
by svn commit 05 Apr '15

05 Apr '15

Version mkgmap-r3519 was committed by gerd on Sun, 05 Apr 2015 write NET file when either --route or --net is given

1 0

mkgmap & 2 TYP files?
by nwillink 04 Apr '15

04 Apr '15

Perhaps I'm the only person who uses 2 typ files for the same map: one for Basecamp/Mapsource ,another for my gps device I always seem to be compromising my colour palette and line widths to accommodate my device and yet I'm always creating my routes on Basecamp. So, at present, I'm having to compile the osm twice, once for Basecamp and once for my Oregon. I wonder if it were possible to include a new option, ie --gmapsupp_typ= I've tried replacing the TYP file within the gmapsupp but there are so many entries to alter. Any thoughts? Nick -- View this message in context: http://gis.19327.n5.nabble.com/mkgmap-2-TYP-files-tp5839762.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 6

Re: [mkgmap-dev] address search and mixed index
by Bernd Weigelt 04 Apr '15

04 Apr '15

I didn't test the new function against the default style, so you can ignore this special case Bernd Hier sollte eigentlich eine Signatur stehen. -----Original Message----- From: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> To: "mkgmap-dev(a)lists.mkgmap.org.uk" <mkgmap-dev(a)lists.mkgmap.org.uk> Sent: Sa., 04 Apr. 2015 15:46 Subject: Re: [mkgmap-dev] address search and mixed index Hi Bernd, can't reproduce a problem with Bergstraße 116-118 with the default style. They are all found at this node: http://www.openstreetmap.org/node/279052767 and that's what I think is the best possible place. The algo "assumes" that a service road is connected to this node. Gerd > From: weigelt.bernd(a)web.de > To: mkgmap-dev(a)lists.mkgmap.org.uk > Date: Sat, 4 Apr 2015 15:13:50 +0200 > Subject: Re: [mkgmap-dev] address search and mixed index > > Am Freitag, 3. April 2015, 17:05:08 schrieb Gerd Petermann: > > Please try it and let me know how it works for you. If possible I'd like > > to change the option so that it is done by default and may be switched off. > > Looks really good for me, found 9 of 10 addresses along the nearest renamed > service roads > > here https://www.openstreetmap.org/#map=19/50.65044/7.23882 was a little > problem, didn't found Bergstraße 116-118, only Bergstraße 120 or Bergstraße > 115. Maybe it is possible, to find Bergstraße 118 at a short part of the > street, but i think there is also a missing part of the service road in front > of these buildings in the database. > > > Bernd > > > -- > amarok2 now playing: > > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

1 0

address search and mixed index
by Gerd Petermann 04 Apr '15

04 Apr '15

Hi all, maybe you can help me with an open problem. I am not sure sure if this is a case of "garbage-in -> garbage-out" or not. I see a lot of houses with plausible tags addr:housenumber and addr:street which are close to a road that has no name or a different name. A typical example is a village like Stühren: http://www.openstreetmap.org/node/378300184#map=17/52.89235/8.71508 Almost all buildings are all tagged with addr:street="Stühren", but the main road through the village is the L340: http://www.openstreetmap.org/way/26701165 which has no name and many buildings are close to it. I think the postal address for these buildings is really something like "Stühren 28, 27211 Bassum,Germany" With trunk and r3477 in the housenumber2 branch I see rather bad results for this because the housenumbers are only added to those roads that have the name "Stühren". I wonder if the housenumber option should add the name "Stühren" to (a part of) L340 ? Or should we try to handle this with bounds containing villages and some style rules? Gerd

4 8

patch Interface Locatable and Kd-tree
by Gerd Petermann 02 Apr '15

02 Apr '15

Hi Steve, I plan to use a KD tree in the house number code. I noticed that the existing Kd-tree implementation in MapPointKdTtree is only usable with MapPoint instances, although it only uses the getLocation() method . I think this should be replaced using general interface Locatable() with method getLocation() and and general Kd-Tree implementaion for classes that implement the Locatable interface. The attached patch shows what I mean. What do you think about it? Do you see better names or packages for this? Gerd

3 5

Splitter - missing area, trim not working
by Andrzej Popowski 01 Apr '15

01 Apr '15

Hi, I'm trying to create contour map of Europe. I have created a rectangle area with contours using phyghtmap and then clipped it to europe.poly using osmosis. I'm working with splitter 421. My first split of data went wrong, some parts of north Scandinavia was missing. After some trying, I have found that adding option --polygon-file=europe.poly helps and map contains all data. But at the same time trimming of tiles stopped working and I'm getting some big empty tiles. I have attached a picture, showing all examples of splits. You can see, that without bounding polygon trim works but some data is missing. And with polygon trim doesn't work. My map will be transparent, without background polygon. I prefer to get tile area covering only existing data, which require trim to work. And I don't like empty tiles. I'm not sure what could help to debug this problem. Source data is about 1.3GB, I can upload it. -- Best regards, Andrzej

4 5