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

Mon Mar 23 21:47:25 GMT 2009

Hi Marko,

On Mon, 23 Mar 2009 22:44:00 +0200
Marko Mäkelä <marko.makela at iki.fi> wrote:

> 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.

I have checked maps created by cgpsmapper and the sorting appears
similar (digits before letters).

> 
> [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.

Actually, I do test most of the code I write before I push it to the
list but as we're making maps here and not building moon rockets, it's
probably not too serious if it doesn't quite work right first time for
some poor alpha tester who uses a different locale/charset. They'll
soon say if it doesn't work and it can get fixed up.

> > > 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.

No doubt, but I'm comfortable with the piece of code in question not
having an assertion to check if the index has been set twice because:

1 - that method is only called from one place.

2 - the code that calls that method is trivial and unlikely to suffer
weird errors.

3 - I prefer to use assertions only in those places where I believe
there is some doubt as to the correctness of the code (or the
data being manipulated by the code). I generally don't use them as a
general backstop to catch sloppy programming or conceptual screwups -
after all, that's what exceptions are for (discuss).

Cheers,

Mark