Wierd behavior when using setExtent method

[wudgcd]

I'm using the 2.8 compact library and finding some wierd behavior when testing on IE9 and sometime Safari on the iOS. I'm using setExtent to set the extent when the map initially appears. I also have a Full Extent button that achieves this same purpose. If I set the extext (using setExtent) to show the whole city it set the extent correctly, but then the Shift Key/mouse drag used to zoom no longer works. In addition the scroll wheel seems to zoom out instead of zoom in (its like the responses are reversed temporarily) and the map shifts up after doing the zoom in or out using the wheel (rather than zooming out from the point my mouse point is located). It only does this the first I try these operations after do the setting the extent to the city wide view. This strange behavior happens no matter whether I set the extent from the intial map load or click my full extent button. When I change the extent to a particular area of the map (not city wide) when the map starts up and in my full extent button, everything works fine. Its just at full extent the Shift Key/Mouse drag and scroll wheel operations stop working right. I'm consuming these same service in my Silverlight map and never see any of this behavior. I'm thinking this is a Javascript bug or somehow an extent on a Dataframe (or layer) is overriding the Javascript setExtent method. Different layers display on my map based on extent (as defined in the MXD/MSD - we are using Server 10 with SDE 9.3.1) maybe one of the layers that only displays at the city wide extent is overriding the extent somehow? Help.

[swingley]

Please post a simple code sample that shows how you're setting extents. A full page with HTML/JS that reproduces the issue is ideal.

[wudgcd]

Please post a simple code sample that shows how you're setting extents. A full page with HTML/JS that reproduces the issue is ideal.

initExtent = new esri.geometry.Extent({
"xmin": 1444848.0341,
"ymin": 1535243.2771,
"xmax": 1581479.7741,
"ymax": 1433679.2476,
"spatialReference": {
"wkid": 2903
}
});

map.setExtent(initExtent);

[swingley]

What is the spatial reference of your map?

[wudgcd]

What is the spatial reference of your map?

New Mexico State Plain wkid = 2903 same as the extent I'm using. In my MXD this is shown as the coordinate system "NAD_1983_HARN_StatePlane_New_Mexico_Central_FIPS_3002_Feet"

[swingley]

Thanks. Looking at the extent you posted, ymin is greater than ymax which is probably why you're seeing the map do unexpected things. Do you still have issues if you construct a proper extent?

[wudgcd]

Thanks. Looking at the extent you posted, ymin is greater than ymax which is probably why you're seeing the map do unexpected things. Do you still have issues if you construct a proper extent?

Those coordinates are correct base on NM state plan

With North up, xmin and ymin is the upper left of the extent and xmax and xmax, ymax is the lower right (same way you typically draw a box to zoom).

In really it should not matter if you reverse these point or even used the lower left and upper right combo. Having said that I did reverse the coordinates for kicks so that it read:

initExtent = new esri.geometry.Extent({
"xmin": 1581479.7741,
"ymin": 1433679.2476,
"xmax": 1444848.0341,
"ymax": 1535243.2771,
"spatialReference": {
"wkid": 2903
}
});

This appeared to work initially but I soon discovered that it sometimes shifted right (remember originally it shifted up - north).

So I finally defined the extent as lower left corner to upper right which meets the rule you stated that xmax should be greater than xmin and ymax should be greater than ymin.

initExtent = new esri.geometry.Extent({
"xmin": 1444848.0341,
"ymin": 1433679.2476,
"xmax": 1581479.7741,
"ymax": 1535243.2771,
"spatialReference": {
"wkid": 2903
}
});

This works!

This is a Bug - it should work any of the ways I stated!

Note: This only failed at the city wide extent, closer extents worked using the original techique (upper left corner to lower right).

[swingley]

With North up, xmin and ymin is the upper left of the extent and xmax and xmax, ymax is the lower right (same way you typically draw a box to zoom).

Are you sure about that? I do not think that is correct. In state plane coordinate systems, xmin, ymin corresponds to lower-left and xmax, ymax correspond to upper-right. Think quadrant one of a cartesian coordinate system.

In really it should not matter if you reverse these point or even used the lower left and upper right combo. Having said that I did reverse the coordinates for kicks so that it read:

initExtent = new esri.geometry.Extent({
"xmin": 1581479.7741,
"ymin": 1433679.2476,
"xmax": 1444848.0341,
"ymax": 1535243.2771,
"spatialReference": {
"wkid": 2903
}
});

This appeared to work initially but I soon discovered that it sometimes shifted right (remember originally it shifted up - north).

So I finally defined the extent as lower left corner to upper right which meets the rule you stated that xmax should be greater than xmin and ymax should be greater than ymin.

initExtent = new esri.geometry.Extent({
"xmin": 1444848.0341,
"ymin": 1433679.2476,
"xmax": 1581479.7741,
"ymax": 1535243.2771,
"spatialReference": {
"wkid": 2903
}
});

This works!

This is a Bug - it should work any of the ways I stated!

This is not a bug and is as designed. In its current state, the API relies on the developer to construct a proper extent. The extent object does not do any checking to verify that an extent is valid and there are not plans to add that to the API.