[mkgmap-dev] [PATCH v8] - alpha patch to support road find by name

Mon Mar 23 20:44:00 GMT 2009

On Mon, Mar 23, 2009 at 08:57:24AM +0000, Mark Burton wrote:
> > Some further observations about the incremental street name search.
> > When I search for a road with ref=1521, as I type "1", the list will
> > display both the road with ref=1 and road names starting with "1".
> > (In Finland, street numbers come after the road name.  Thus, a street
> > name can start with a number.)  When I type "15", I only see "15" on
> > the list.  Likewise for "152" and "1521".  (All these roads exist.  If
> > I type a digit after 1521, then there won't be matches.)  Also, when
> > I type "E 7", the list only displays "7" (without the E).  With "E 75",
> > it will display "E 75" as the only entry.
> > 
> > I'm beginning to think that Garmin has implemented it like this on purpose.
> 
> I think it's just plain broken!

Come to think of it, could this be a collation problem?  What happens
if you have the street names Aa, Aac, Aab, Aaa sorted in that order while
Garmin expects Aa, Aaa, Aab, Aac, and you type "AA"?  Will it only display
the "Aa"?

Do you have a copy of a map where the incremental search of street names
containing numbers does work?  If yes, can you extract the labels from
there and infer (some of) the collation?  Specifically, I'm suspecting that
one of the collations (mkgmap, Garmin) could be sorting 0-9 before A-Z and
the other could be sorting 0-9 after A-Z.

[snip]

> Haven't a clue about any of that. But when people around the world test
> this patch and report back, we will know whether it's doing the right
> thing or not. I am ready to act on reports of it not working as
> expected.

Right, with open source you can outsource the testing.  I feel that the
patch is good enough to be committed.  The small imperfections can be
ironed out later.

> > Should setIndex assert that the index must not be set twice?
> 
> The answer to that depends on how paranoid you are. I can cope with
> there not being an assert there because I know how that method is being
> invoked.

When working on complex pieces of software, I've been peppering the code
quite liberally with assertions.  They don't hurt performance on production
environments when you compile (or in the case of Java, run) with the right
flags.  And they can save a lot of trouble later.

	Marko