Tom Hughes wrote: > Milo van der Linden wrote: > >> I strongly suggest that you read the postgresql text search[1] >> chapter in depth. You will find that a lot of textual and >> multilingual confusions can be solved with that function set. the >> name "text search" is by far too simple for what it covers... > > I have read it, and it's not at all clear it can be made to work right. > > The basic problem is that it assumes that all text in a given field is > in the same language - you can give it a set of language specific > rules to use when parsing a the record data and when parsing the query > but you can't vary that on a record by record basis. That is indeed a thing. It also shows that it might be a good option to extend the column remapping that for instance osm2pgsql uses to create new columns per language.
In the end, a well structured gazetteer that works on a steady system of internationalization http://wiki.openstreetmap.org/wiki/Key:name might give people a stimulance to not only create name:yourlanguageisocode tags, but actually see them in action.. > > Though even if you could you wouldn't know what language the query was > in anyway, so you wouldn't know how to parse it... Being it from a browser: You might know the browser language, or give the user a language selection option And as a webservice: set a directive to a language iso code in the post or get variables. > > I have actually been playing with using Postgres for this, using > osm2pgsql to load planet data into a gazetteer with Postgres text > search for name matching and a spatial index for location matching. I > wound up sticking to using the "simple" text parsing ruleset in the end. Could you be more specific on the "Why" for that? Because the two sentences above sound a bit like: "I walked by the restaurant yesterday but ended up eating with my parents." ;-) > > Tom > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
