That’s right, but since I sent the previous mail I also noticed that the Map object’s extent is different that in GeoServer. I modified it, but still didn’t solve the problem.
Gergely
···
2014-05-27 13:17 GMT+02:00 Arne Kepp-2 [via OSGeo.org] <[hidden email]>:
Hi,
If you look at the GridSet definition (in the screenshot, attached to your email), you / GeoServer have defined the extent of the GridSet to be
[422251.0, 48437.6 ,950242.3, 368889.2]
In the Heron-configuration (which I am not familiar with, but I assume it copies the info to OpenLayers verbatim)
you configure the extent to be [420000, 40000, 950000, 370000]
That’s not going to work. Use the same extent in both cases.
-Arne
On 27/05/14 10:56 , Gergely Padányi-Gulyás wrote:
Hello Arne,
Thanks for the answer.
I tried with and without tileOrigin parameter, and there was absolutely no difference in the result.Although I won’t say I fully understand what you wrote about the “inconsistent grid definition”, I tried to make a gridset using resolutions like this: rb = ra/2. Unfortunately the result was again the same, at some zoom levels the offset is visible, at another levels it fits just fine.
This is my (modified) map object (I use GeoExt 1.1 and Heron 1.0.1):
huBox = [420000, 40000, 950000, 370000];
Heron.options.map.settings = {
projection: ‘EPSG:23700’,
displayProjection: ‘EPSG:23700’,
units: ‘m’,
maxExtent: new OpenLayers.Bounds(huBox[0], huBox[1], huBox[2], huBox[3]),
scales: [4000000, 2000000, 1000000, 500000, 250000, 125000, 62500, 31250, 15625],xy_precision: 2
};I attach the modified EPSG:23700 gridset definition where all the zoom levels, resolutions and tiles are visible (gridset.png).
I’m thinking that maybe the datum parameters are not the same that OpenLayers and GeoServer uses. OpenLayers gets it from Proj4js, here is the def:
Proj4js.defs[“EPSG:23700”] = “+proj=somerc +lat_0=47.14439372222222 +lon_0=19.04857177777778 +k_0=0.99993 +x_0=650000 +y_0=200000 +ellps=GRS67 +units=m +no_defs”;And here is the definition from GeoServer:
PROJCS["HD72 / EOV", GEOGCS["HD72", DATUM["Hungarian Datum 1972", SPHEROID["GRS 1967", <a href="tel:6378160.0" value="+3663781600" target="_blank">6378160.0, 298.247167427, AUTHORITY["EPSG","7036"]], TOWGS84[52.17, -71.82, -14.9, 0.0, 0.0, 0.0, 0.0], AUTHORITY["EPSG","6237"]], PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295], AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH], AUTHORITY["EPSG","4237"]], PROJECTION["Oblique_Mercator", AUTHORITY["EPSG","9815"]], PARAMETER["longitude_of_center", 19.048571777777784], PARAMETER["latitude_of_center", 47.14439372222222], PARAMETER["azimuth", 90.0], PARAMETER["scale_factor", 0.99993], PARAMETER["false_easting", 650000.0], PARAMETER["false_northing", 200000.0], PARAMETER["rectified_grid_angle", 90.0], UNIT["m", 1.0], AXIS["Easting", EAST], AXIS["Northing", NORTH], AUTHORITY["EPSG","23700"]]But because NOT every zoom levels produce misplacement I don’t really think that the datum definition causes it.
Gergely
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.x6.nabble.com/GeoWebCache-misplacement-tp5142563p5142697.html
To unsubscribe from GeoWebCache misplacement, click here.
NAML