[Talk-ca] script for changing existing CA postcodes?

[john whelan]

Currently we don't have a working solution for searching on postcodes in
Canada.

Whilst I realise the interests of many don't include postcodes condensing
them down to six characters would give us a working solution today even if
the script had to be run say once a month.

Once we have a permanent solution running a second script that inserted a
space would put things back to normal.

The script logic would be if country=ca and postcode data is 7 characters
long postcode data becomes chars1-3+5-7.  Allowing a walkthrough should
catch any software errors.

This is probably one of those occasions when its worth while asking the
question is the client people entering data or people using the map?
Condensing the postcode in this way would at least make it searchable.

Thanks

Cheerio John

>>
Comment:

 > For GB postcodes either a search of "en3 6rg,gb" or "en36rg,gb" works
 fine.
 The current GB version only works through a hideous hack which can't
 easily be extended because it uses a separate table of postcodes and
 knowledge of how the uk postcode system works to guess them.

 > For CA "k4a 1m7,ca" does not work, "k1e3p6,ca" does.  Unfortunately
 k1e3p6 was entered in the wrong format.  It should have been "ANA NAN" not
 "ANANAN" note the space.

 I'm currently working on space sensitivity issue for the next version but
 this is unlikely to be fixed quickly.

 --
 Brian



On 26 March 2010 17:02, Richard Weait <richard at weait.com> wrote:

> On Fri, Mar 26, 2010 at 4:20 PM, john whelan <jwhelan0112 at gmail.com>
> wrote:
> > Would it be possible for someone to write a script and execute it that
> went
> > through the OSM database and where country=CA change the format for the
> > existing post codes to remove the space to make them searchable?
> >
> > If some one could point me at a bit of sample code I could probably write
> > the script.
>
> Let's give the nominatim developers a couple of days to react to your
> bug report first.  No point in deliberately butchering the correct
> postcode data.
>
> Deliberately making the data incorrect to fix a bug seems suboptimal.
> The risk of a mis-behaving script, not once, but twice, seems
> contra-indicated as well.
>
> What's your rush?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20100326/c6beaa37/attachment.html>