<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Len seems to have answered this question in this thread earlier in
May. Basically, OpenLayers 2.9 contains a fix for the ScaleLine
issue. And while 2.9 doesn't work with GeoMoose trunk, 2.9.1 seems
to work better with the exception of the cursor handling at line 850
in main.js:<br>
<br>
// Add cursors<br>
var olDiv =
document.getElementById('mapContainer_OpenLayers_ViewPort');<br>
<br>
where olDiv gets set to null.<br>
<br>
Replacing the line with <br>
<br>
var olDiv =
document.getElementById('OpenLayers.Map_4_OpenLayers_ViewPort');<br>
<br>
makes it work. I got the element id by using Firebug's Inspection
tool, but I'm not sure how (or where) this element gets
constructed. The "Map_4" portion looks suspicious; I expect we'll
need a more robust way of determining the element's id....<br>
<pre class="moz-signature" cols="72">Best Regards,
Brent Fraser</pre>
<br>
On 12/17/2010 9:00 AM, Brent Fraser wrote:
<blockquote cite="mid:4D0B8938.3000202@geoanalytic.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Johan,<br>
<br>
Interesting stuff.<br>
<br>
Looking at my experimental source from a few months back, I had
added a property to main.js around line 98:<br>
<br>
if(CONFIGURATION.scale_line.enabled) {<br>
Map.addControl(new OpenLayers.Control.ScaleLine({<br>
bottomOutUnits: CONFIGURATION.scale_line.bottom_units,<br>
topOutUnits: CONFIGURATION.scale_line.top_units,<br>
geodesic: true, /* bfraser */<br>
maxWidth: CONFIGURATION.scale_line.width<br>
}));<br>
}<br>
<br>
but testing today it seems to have no effect in "correcting" the
scalebar length. I'll have to do more investigation. Note from
the OpenLayers doc:<br>
<br>
<h3 class="CTitle">geodesic</h3>
<div class="CBody">
<p>{Boolean} Use geodesic measurement. Default is false. The
recommended setting for maps in EPSG:4326 is false, and true
EPSG:900913. If set to true, the scale will be calculated
based on the horizontal size of the pixel in the center of the
map viewport.</p>
</div>
<br>
<br>
Your point 2 is a tough one. The search radius is a map
projection distance and would have to be corrected by the map
projection point scale factor, or adjusted to be a geodesic
distance. I don't know if OpenLayers has a function to do either
of those. <br>
<br>
<pre class="moz-signature" cols="72">Best Regards,
Brent Fraser</pre>
<br>
On 12/17/2010 8:04 AM, Johan Forsman wrote:
<blockquote
cite="mid:D697C50705266B4B826C7322C809F00D6D7CC8AE@MAILMBX09.MAIL.LA.GOV"
type="cite">
<pre wrap="">All:
I just discovered this issue. After applying Brent's fix below the measure tool appears to return the correct values, but there are other remaining issues.
I am using the 900913 projection for all data.
1. The scale bar is off. 500 meters on the scale bar measures to 431 meters, or a factor of ~0.86. This is not a critical issue, but it would be "nice" if it measured the same.
2. The select feature, using By Point, is a very clever way to get all features within a certain radius of a point location. However this function will return a radius that is shorter by about the same amount as the scale bar. This is an important issue. I have attached 3 screenshots illustrating the problem.
The GM shot shows what is supposed to be a 1-mile radius, plus the new measurement (post-fix) to the most distant feature of interest.
The GE-EC shot shows the measured distance using an all-Google application.
The ArcGIS shot shows the actual size of a circle with an (presumably ArcGIS is authoritative) 1-mile radius in the same location. These data are in NAD83 UTM 15N.
I measured the scale factors on a 200 meter scale bar (1:6771) for my state (Louisiana) and found them to be about 0.86 at the northern extreme and 0.89 at the southern extreme.
Is there any way I can implement some type of automatic correction to the select tool, and any other tool that may be affected by this behavior? Certainly I can inform the users that they need to add x % to their chosen buffer, but I am not prepared to trust the users to really do that.
Thanks!
/Johan.
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Brent Fraser [<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:bfraser@geoanalytic.com">mailto:bfraser@geoanalytic.com</a>]
Sent: Wednesday, May 26, 2010 1:53 PM
To: Len Kne
Cc: '<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:geomoose-users@lists.sourceforge.net">geomoose-users@lists.sourceforge.net</a>'
Subject: Re: [Geomoose-users] Scalebar & Measure
Len(and others interested in measuring),
Here's my solution to the measure problem:
In main.js somewhere around line 138 add the two lines below marked with a
"//BWF":
Tools['measure'] = new
OpenLayers.Control.GeoMooseMeasure(OpenLayers.Handler.MeasurePath,
measureToolOptions);
Tools['measure'].geodesic = true; //BWF
Tools['measurearea'] = new
OpenLayers.Control.GeoMooseMeasure(OpenLayers.Handler.MeasurePolygon,
measureToolOptions);
Tools['measurearea'].geodesic = true; //BWF
Thoughts?
Brent
Brent Fraser wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Paul, Len,
Our scale problem is a (mostly) map projection issue. All map
</pre>
</blockquote>
<pre wrap="">projections
</pre>
<blockquote type="cite">
<pre wrap="">introduce distortions in trying to represent a round(ish) Earth on a
</pre>
</blockquote>
<pre wrap="">flat plane.
</pre>
<blockquote type="cite">
<pre wrap=""> Mercator is no different: it is like wrapping an up-right cylinder
</pre>
</blockquote>
<pre wrap="">around the
</pre>
<blockquote type="cite">
<pre wrap="">Earth, projecting light from the center onto the cylinder
(<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Mercator_projection">http://en.wikipedia.org/wiki/Mercator_projection</a>). As you can imagine
</pre>
</blockquote>
<pre wrap="">the
</pre>
<blockquote type="cite">
<pre wrap="">distortions get "worse" the further from the equator. The distortions
</pre>
</blockquote>
<pre wrap="">can be
</pre>
<blockquote type="cite">
<pre wrap="">modeled as a Point Scale Factor. At the equator the Point Scale Factor
</pre>
</blockquote>
<pre wrap="">is 1.0,
</pre>
<blockquote type="cite">
<pre wrap="">at latitude 60 degrees North (or South), the scale factor is 0.5!
So what's the solution? Here's mine:
1. Enhance Proj4 (and Proj4js) to return the Point Scale factor
</pre>
</blockquote>
<pre wrap="">(given the
</pre>
<blockquote type="cite">
<pre wrap="">projection and a location)
2. Enhance MapServer and Openlayers to use the Point Scale Factor in
calculating distances and scale.
I'm trying to drum up interest, but so no takers....
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://osgeo-org.1803224.n2.nabble.com/Point-Scale-factor-service">http://osgeo-org.1803224.n2.nabble.com/Point-Scale-factor-service</a>-
</pre>
</blockquote>
<pre wrap="">td4938743.html
</pre>
<blockquote type="cite">
<pre wrap=""><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://osgeo-org.1803224.n2.nabble.com/Re-3265-Scale-dependent-layer">http://osgeo-org.1803224.n2.nabble.com/Re-3265-Scale-dependent-layer</a>-
</pre>
</blockquote>
<pre wrap="">switching-error-with-Mercator-td4966902.html
</pre>
<blockquote type="cite">
<pre wrap="">Best Regards,
Brent Fraser
Len Kne wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The scale bar issue with the web Mercator projection is a limitation of
OpenLayers, the application GeoMOOSE 2.x uses to render the map frame.
There has been discussion on the OpenLayers site about providing a
patch (this link offers a patch <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://trac.openlayers.org/ticket/1890">http://trac.openlayers.org/ticket/1890</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">in the next version 2.9. I'm sure GM will upgrade to OL 2.9, but not
sure there is any schedule in place to do this.
The cursor issue is also kind of fun because it seems each browser
handles the custom icons differently. Here's the attribute in the
mapbook which defines the query for the Identify service:
cursor="url('cursors/identify2.cur') 9
</pre>
</blockquote>
</blockquote>
<pre wrap="">9,url('cursors/identify2.cur'),auto"
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
This makes three attempts to draw the cursor, the first offsets the
mouse click 9 pixels from the top and the left. Firefox can use this
value and seems to line the mouse click up pretty good with the
crosshair. However, IE cannot handle the offset adjustment, so it
</pre>
</blockquote>
</blockquote>
<pre wrap="">reads
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">the second cursor definition. There are tools like AT File Mole which
can be used to edit the hotspot of a cursor. Attached is the latest
version I have been using for Identify service, again this seems to
</pre>
</blockquote>
</blockquote>
<pre wrap="">line
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">the crosshair up pretty well with the mouse click. If you are using
Safari or Chrome, these setting don't seem to work at all and I would
recommend not using customer cursors with those browsers.
Len
*From:* Wirth, Paul [<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:Paul.Wirth@kniferiver.com">mailto:Paul.Wirth@kniferiver.com</a>]
*Sent:* Saturday, May 01, 2010 9:03 PM
*To:* '<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:geomoose-users@lists.sourceforge.net">geomoose-users@lists.sourceforge.net</a>'
*Subject:* [Geomoose-users] Scalebar & Measure
Two questions:
1. I have a web Mercator application, and I noticed that the
scalebar does not display the correct distance. For instance, when the
scalebar shows a distance of 20 miles, it measures only 13.8 miles. I
know the measure tools are working correctly, so I assume this is a
scalebar issue. Any thoughts on how to fix this?
2. I think this question was asked before, but I can't seem to
find it on the e-mail list. With the measure tools, the cursor does
</pre>
</blockquote>
</blockquote>
<pre wrap="">not
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">start measuring at the "crosshairs" when the user clicks, but rather in
the NW quadrant of the crosshairs. Is there a way to change it so the
measure start point will be on the crosshairs?
-----------------------------------------------------------------------
</pre>
</blockquote>
</blockquote>
<pre wrap="">-
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">-----------------------------------------------------------------------
</pre>
</blockquote>
</blockquote>
<pre wrap="">-------
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
-----------------------------------------------------------------------
</pre>
</blockquote>
</blockquote>
<pre wrap="">-
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">_______________________________________________
Geomoose-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Geomoose-users@lists.sourceforge.net">Geomoose-users@lists.sourceforge.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/geomoose-users">https://lists.sourceforge.net/lists/listinfo/geomoose-users</a>
</pre>
</blockquote>
<pre wrap="">
------------------------------------------------------------------------
</pre>
</blockquote>
<pre wrap="">------
</pre>
<blockquote type="cite">
<pre wrap="">_______________________________________________
Geomoose-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Geomoose-users@lists.sourceforge.net">Geomoose-users@lists.sourceforge.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/geomoose-users">https://lists.sourceforge.net/lists/listinfo/geomoose-users</a>
</pre>
</blockquote>
<pre wrap="">
--------------------------------------------------------------------------
----
_______________________________________________
Geomoose-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Geomoose-users@lists.sourceforge.net">Geomoose-users@lists.sourceforge.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/geomoose-users">https://lists.sourceforge.net/lists/listinfo/geomoose-users</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/lotusphere-d2d">http://p.sf.net/sfu/lotusphere-d2d</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Geomoose-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Geomoose-users@lists.sourceforge.net">Geomoose-users@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/geomoose-users">https://lists.sourceforge.net/lists/listinfo/geomoose-users</a>
</pre>
</blockquote>
</body>
</html>