Ok, now I'm confused. How do I initialize the ArcGISCache layer with this service
http://server.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer ?? Previously I was going after http://server.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer + "/tile/" + "${z}/${y}/${x}" tiles. This goes after completely different scheme of tiles. On Mon, Jul 19, 2010 at 9:08 PM, Mike Swope <[email protected]> wrote: > You might also keep in mind, that they are using arcgis.com now. Perhaps > some more info is there? > > On Mon, Jul 19, 2010 at 9:17 PM, Vadim Bokin <[email protected]> wrote: >> >> Robert, >> >> I've made good progress with your suggestion. I created a new class >> and just extended XYZ.js with the 2 methods you provided. But I still >> have a problem. >> >> Old Code: locations where close, but kept jumping around north or >> south of the right location >> >> New code: locations are almost exactly 41.0 miles North of where they >> should be. But they are off by a fixed amount. So when I zoom in and >> out they are staying put where they are, but they are still off. So >> if I try to put a point on the beach in Santa Monica, on the map it >> looks to be between Santa Clarita and Palmdale. As soon as I change >> base maps to Google or a epsg:4326 map, all is well and points are in >> perfect location. >> >> So it's 1 step forward (locations don't jump) and 1 step back >> (locations are pretty far north). >> >> I read tileOrigin from the AGS layer spec, e.g. >> >> http://server.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer. >> And I've made sure it is correct by testing in firebug and just >> dumping out map.baseLayer.tileOrigin. >> >> Did you do anything else to modify XYZ to make this work? Does 41.0 >> miles mean anything? to me it doesn't look like 1 degree, or anything >> else. But it's a fixed distance difference between plotted and viewed >> points. Some kind of error in calculation or my setup of the layer? >> >> Thank you! >> >> -Vadim >> >> >> On Mon, Jul 19, 2010 at 6:24 PM, Robert Sanson >> <[email protected]> wrote: >> > Hi Vadim >> > >> > What layer type are you using? ArcGIS tilecaches have a tile origin in >> > the >> > top left. The standard layer.XYZ in OpenLayers is built to support a >> > lower >> > left tile origin. You need a patched XYZ.js with setMap and >> > calculateGridLayout copied from Zoomify.js: >> > >> > * APIMethod: setMap >> > * When the layer is added to a map, then we can fetch our origin >> > * (if we don't have one.) >> > * >> > * Parameters: >> > * map - {<OpenLayers.Map>} >> > */ >> > setMap: function(map) { >> > OpenLayers.Layer.Grid.prototype.setMap.apply(this, arguments); >> > if (!this.tileOrigin) { >> > this.tileOrigin = new OpenLayers.LonLat(this.maxExtent.left, >> > >> > //this.maxExtent.bottom); >> > this.map.maxExtent.top); >> > //patched to be similar to Zoomify >> > } >> > }, >> > >> > /** >> > * Method: calculateGridLayout //patched from Zoomify >> > * Generate parameters for the grid layout. This >> > * >> > * Parameters: >> > * bounds - {<OpenLayers.Bound>} >> > * extent - {<OpenLayers.Bounds>} >> > * resolution - {Number} >> > * >> > * Returns: >> > * Object containing properties tilelon, tilelat, tileoffsetlat, >> > * tileoffsetlat, tileoffsetx, tileoffsety >> > */ >> > calculateGridLayout: function(bounds, extent, resolution) { >> > var tilelon = resolution * this.tileSize.w; >> > var tilelat = resolution * this.tileSize.h; >> > >> > var offsetlon = bounds.left - extent.left; >> > var tilecol = Math.floor(offsetlon/tilelon) - this.buffer; >> > var tilecolremain = offsetlon/tilelon - tilecol; >> > var tileoffsetx = -tilecolremain * this.tileSize.w; >> > var tileoffsetlon = extent.left + tilecol * tilelon; >> > >> > var offsetlat = extent.top - bounds.top + tilelat; >> > var tilerow = Math.floor(offsetlat/tilelat) - this.buffer; >> > var tilerowremain = tilerow - offsetlat/tilelat; >> > var tileoffsety = tilerowremain * this.tileSize.h; >> > var tileoffsetlat = extent.top - tilelat*tilerow; >> > >> > return { >> > tilelon: tilelon, tilelat: tilelat, >> > tileoffsetlon: tileoffsetlon, tileoffsetlat: tileoffsetlat, >> > tileoffsetx: tileoffsetx, tileoffsety: tileoffsety >> > }; >> > }, >> > >> > Using the above works perfectly. >> > >> > regards, >> > >> > Robert Sanson >> > >> >>>> Vadim Bokin <[email protected]> 20/07/2010 11:53 a.m. >>> >> > >> > Hi, >> > >> > Does anyone have the _exact_ proj4js definition for ESRI projections >> > EPSG:102100 and the older EPSG:102113? >> > >> > My maps have a y-coordinate shift (both north and south at different >> > zooms) >> > off by many map pixels. Always close, but no cigar. X-coordinate is >> > always >> > dead on. >> > >> > I can add in ArcGIS online content as dynamic layer without any >> > problems. >> > But when adding cached tiles, there's always this shift. Has anyone >> > seen >> > this before and/or been able to resolve it? I need to be able to use >> > the >> > cached tiles. >> > >> > I've used the one from spatialreference.org, as well as set it directly >> > to >> > be equal to Google's EPSG:900913 but there's always a shift. I've tried >> > many different variations with +a and +rf and others but I feel like >> > the >> > definition is missing a +towgs84=... adjustment to properly correct for >> > the >> > shift on the map but I have no way of knowing what those parameters >> > should >> > be and whether it should be the 3-parameter adjustment or the >> > 7-parameter >> > one. >> > >> > Here's my current definition: >> > >> > Proj4js.defs["EPSG:102100"] = "+proj=merc +lon_0=0 +x_0=0 +y_0=0 >> > +a=6378137 >> > +b=6378137 +units=m +nadgri...@null"; >> > >> > +towgs84=0,0,0,0,0,0,0 doesn't help, but I feel like the right values >> > in >> > there will fix the problem. >> > >> > Thank you, >> > >> > -Vadim >> > >> > >> > -- >> > View this message in context: >> > >> > http://osgeo-org.1803224.n2.nabble.com/ArcGIS-Online-Cached-tiles-datum-shift-tp5314596p5314596.html >> > Sent from the OpenLayers Users mailing list archive at Nabble.com. >> > _______________________________________________ >> > Users mailing list >> > [email protected] >> > http://openlayers.org/mailman/listinfo/users >> > >> > >> > >> > This message has been scanned for malware by SurfControl plc. >> > www.surfcontrol.com >> _______________________________________________ >> Users mailing list >> [email protected] >> http://openlayers.org/mailman/listinfo/users > > _______________________________________________ Users mailing list [email protected] http://openlayers.org/mailman/listinfo/users
