[ka-Map-users] queryByAttributes and projection

[TC Haddad]

Hi Bob,

I have a similar drop down in our ka-map application that does a zoom
to location. And in our case, the javascript just uses a list of
spatial bookmarks, so no attribute queries are involved at all. This
seemed like it would work fastest, though I never needed to try your
way.

Anyhow, if you wanted to try that method I can send you the script.
It's fairly straightforward - just feed in a list of locations and
coordinates, and it builds the list. In your case I guess the coords
you would want to feed it are in lat/long (since that is the display
coordinates of you map now).

As to you original question - my guess is that it is failing because
when the  queryByAttributes happens it uses the extent of the found
shape as the "zoom to coords", and since your data is really still in
UTM, it is trying to zoom to UTM coords on a Lat/Long map, which won't
work.  To make this approach work you would have to reproject the
found extent on the fly, before allowing the view extent to refresh.

If your drop down list is static and not very long, I think a basic
list of spatial bookmarks will still  be quicker.

Tanya


Date: Thu, 19 Mar 2009 12:30:50 -0400

From: "Bistrais, Bob" <Bob.Bistrais at maine.gov>
Subject: [ka-Map-users] queryByAttributes and projection


(Cross-posted to the Mapserver list)...

I have a modified ka-map application with some customized search tools.
One of these tools allows the user to pick a town from a dropdown and
zoom to it.  This uses a queryByAttributes process and it was working
well.


The data for the project is projected in UTM in its native format.  The
customer asked if we could display the data in lat/long (EPSG:4326).  If
I change the projection and extent in the .Map files, the map displays
properly, but the search tools no longer function, I get a "no matching
results" error.

This seems pretty strange, as I am only querying by attributes, not
spatially.  So I wouldn't think projection would be an issue.  But
apparently it is.  Does anyone have some insight as to how I can correct
this (other than reprojecting the data)?