- mkgmap-dev - The mkgmap lists

Multi-word street search with city
by Steve Ratcliffe 18 Dec '14

18 Dec '14

Hi Andrzej, Carlos Its OK I've got a test case for street-with-city not working on a recent version of mapsource. I'll report any progress with that on this thread. ..Steve

3 3

multi-word street search
by Michał Rogala 18 Dec '14

18 Dec '14

Hello! I've a problem regarding street search. In Poland (and I suppose few more countries also may have this issue) person-named streets can have two forms - long one: Miroslawa Dudka or short one: Dudka there is no standard for tagging such names in OSM. Problem is that Garmin/Mapsource search function is matching names from the beginning of the string, so if I enter "Dudka" it will find all streets named "Dudka" but not "Miroslawa Dutka". Do you have any idea how can I deal with such issue? best regards Michal Rogala

12 67

status addr:place evaluation
by Gerd Petermann 18 Dec '14

18 Dec '14

Hi all, up to now I've implemented a) the algo to calculate the convex hull (using the QuickHull algo) for a set of coordinates b) an algo to identify elements with addr:place tag which are probably referencing the same place. I use a combination of addr:place,addr:city,addr:postcode and the mkgmap:admin_levels8 to 10 This makes it less likely that a wrongly tagged object is blowing up the area for a hamlet, but I still see hamlets with a dense cluster of nodes and a few ones rather far away which might be copy+paste errors in the OSM data. c) an algo to the find roads without mkgmap:street which intersect with one or more of the computed convex hulls. This is all work in progress and not yet usable. Open problems: 1) The convex hulls may be overlapping. I assume I have to subtract the overlaps (from all areas) 2) Some OSM ways connect different hamlets. I think I have to split them somewhere outside of any of the convex hulls. 3) The convex hull might be (nearly) a straight line if only a few houses along the same side of the road are tagged with addr:place. I guess I have to make sure that I'll find at least one road that is close to them. 4) I am not sure if I should name all unnamed routable ways with the name of the hamlet. This could include tracks and steps etc. . I think I should check a tag like mkgmap:ignore-for-housenumbers=1 to exclude roads from this algo. Any better ideas ? Ciao, Gerd

1 0

Commit: r3383: part style function:
by svn commit 18 Dec '14

18 Dec '14

Version mkgmap-r3383 was committed by gerd on Thu, 18 Dec 2014 part style function: - make sure that arguments are valid, else throw SyntaxException Added unit tests

1 0

Commit: r3382: substring style function:
by svn commit 18 Dec '14

18 Dec '14

Version mkgmap-r3382 was committed by gerd on Thu, 18 Dec 2014 substring style function: - make sure that arguments are valid, else throw SyntaxException - make sure that string is long enough, else return null Added unit tests

1 0

Nodes with direction attributes
by Roger Calvert 17 Dec '14

17 Dec '14

I suspect I know the answer to this, but... On maps, canal lock gates are often conventionally shown as a chevron pointing upstream. On OSM, they are a node tagged as "waterway=lock_gate" on a way tagged "waterway=canal", and sometimes also tagged "lock=yes". Potlatch 2 and ID render them as a circle. JOSM has a pictorial symbol, which is always in the same orientation. Is there any way the local direction of the way representing the canal or lock could be assigned to the lock gate, so that an appropriately orientated image can be selected? There may be other such directional nodes; perhaps weirs and barriers such as cattle grids could be treated similarly. Thanks, Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------

1 0

[Patch v1] check length in substring style function
by Gerd Petermann 17 Dec '14

17 Dec '14

Hi all, the discussion about offsets in the mixed-index branch rang a bell: I forgot to answer this post from gbbickerton: "May i suggest that a test is made to check that the string is long enough before applying this filter otherwise an exception occurs .It would be unsafe to use this filter in any style without such a test. " Attached is a small patch that implements these plausibility checks. @gbbickerton: I noticed that you use substring:1:14 which removes the 1st character as counting starts with 0. If nobody complains I'll commit this on thursday. Gerd

2 3

Commit: r3374: Latest on the tutorial.
by svn commit 15 Dec '14

15 Dec '14

Version mkgmap-r3374 was committed by steve on Mon, 15 Dec 2014 Latest on the tutorial. Still not useful :(

1 0

Commit: r3372: Make the road offset shift parameter from the header available.
by svn commit 15 Dec '14

15 Dec '14

Version mkgmap-r3372 was committed by steve on Mon, 15 Dec 2014 Make the road offset shift parameter from the header available. No affect on mkgmap, used for debugging in display project.

1 0

addr:place and housenumbers
by Gerd Petermann 15 Dec '14

15 Dec '14

Hi all, I have an idea how to support the evaluation of the addr:place tag. I first thought this can all be done with a few rules in the style, but it seems that the boundaries don't contain the hamlet boundaries, so it is difficult to find the matching names for streets and nodes. Idea: Step 1: - collect all nodes with addr:housenumber=* and addr:place=* and addr:street!=* - collect all nodes with place=hamlet and name=* - collect all unnamed roads Step 2: For each hamlet, calculate the area (bbox or maybe a circle) containing the corresponding addr:place nodes (the place=hamlet nodes should help in case that there are two or more hamlets with the same name in one tile) Step 3: Find out the unnamed streets in these areas. Give them the name of the hamlet and interpret the addr:place tag in the nodes like mkgmap:street (using the normal housenumber routines) Is anybody interested in that? Gerd

3 7