What you describe is how things are supposed to work. There are alternatives:
- case insensitivity, by default string and regular expressions are case insensitive. You can get around that by including an i at the end of the qstring. For a case-insensitive string search you'd need to delimit the string with quotes and then append the i. qstring=/Praha/i qstring='Praha'i - substrings, you need to use regular expressions to do substring matches - limited by extents, again this is the default behaviour. You often deal with it through application design. For example, if you have your search by keyword form element inside the main mapserver form then it will take on the displayed extent. Alternatively you could use a seperate form altogether. You can also use a bit of javascript to construct a query URL with the correct global extent and then submit. You'll probably need to do that anyway to format your qstring appropriately. Remember that if no extent is supplied then the search uses the default extent set in the mapfile. Steve >>> karpi <[EMAIL PROTECTED]> 11/07/06 9:02 AM >>> Hello.. There is one mapserver application, which im some time ago working on: http://localhost/cgi-bin/mapserv?map=/var/www/localhost/htdocs/newmap/czrep.map (MapServer version 4.8.3) If user enters a search string "Praha" result is ok, but unfortunatelly: - Serarching works only if entered qstring is exactly identical with database item (which is "Praha"). No case insensitiving. So -> qstring "praha" fails. - Searching fails on substrings, so searching "aha" fails on "Praha", and searching "Kralupy" fails on "Kralupy nad Vltavou" - Searching is limited on displayed map extents. If im zoomed out, even correct string "Praha" fails Do you solved someone some of this points before? Any expiriences? (second post - the first one disappeard somewere..) -- karpi from http://gismaster.liberix.cz
