[Geomoose-users] Scalebar & Measure
Brent Fraser
bfraser at geoanalytic.com
Fri Dec 17 12:44:07 EST 2010
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:
// Add cursors
var olDiv =
document.getElementById('mapContainer_OpenLayers_ViewPort');
where olDiv gets set to null.
Replacing the line with
var olDiv =
document.getElementById('OpenLayers.Map_4_OpenLayers_ViewPort');
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....
Best Regards,
Brent Fraser
On 12/17/2010 9:00 AM, Brent Fraser wrote:
> Johan,
>
> Interesting stuff.
>
> Looking at my experimental source from a few months back, I had
> added a property to main.js around line 98:
>
> if(CONFIGURATION.scale_line.enabled) {
> Map.addControl(new OpenLayers.Control.ScaleLine({
> bottomOutUnits: CONFIGURATION.scale_line.bottom_units,
> topOutUnits: CONFIGURATION.scale_line.top_units,
> geodesic: true, /* bfraser */
> maxWidth: CONFIGURATION.scale_line.width
> }));
> }
>
> 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:
>
>
> geodesic
>
> {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.
>
>
>
> 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.
>
> Best Regards,
> Brent Fraser
>
> On 12/17/2010 8:04 AM, Johan Forsman wrote:
>> 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.
>>
>>> -----Original Message-----
>>> From: Brent Fraser [mailto:bfraser at geoanalytic.com]
>>> Sent: Wednesday, May 26, 2010 1:53 PM
>>> To: Len Kne
>>> Cc: 'geomoose-users at lists.sourceforge.net'
>>> 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:
>>>> Paul, Len,
>>>>
>>>> Our scale problem is a (mostly) map projection issue. All map
>>> projections
>>>> introduce distortions in trying to represent a round(ish) Earth on a
>>> flat plane.
>>>> Mercator is no different: it is like wrapping an up-right cylinder
>>> around the
>>>> Earth, projecting light from the center onto the cylinder
>>>> (http://en.wikipedia.org/wiki/Mercator_projection). As you can imagine
>>> the
>>>> distortions get "worse" the further from the equator. The distortions
>>> can be
>>>> modeled as a Point Scale Factor. At the equator the Point Scale Factor
>>> is 1.0,
>>>> 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
>>> (given the
>>>> 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....
>>>> http://osgeo-org.1803224.n2.nabble.com/Point-Scale-factor-service-
>>> td4938743.html
>>>> http://osgeo-org.1803224.n2.nabble.com/Re-3265-Scale-dependent-layer-
>>> switching-error-with-Mercator-td4966902.html
>>>> Best Regards,
>>>> Brent Fraser
>>>>
>>>> Len Kne wrote:
>>>>> 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 patchhttp://trac.openlayers.org/ticket/1890
>>> )
>>>>> 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
>>> 9,url('cursors/identify2.cur'),auto"
>>>>>
>>>>> 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
>>> reads
>>>>> 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
>>> line
>>>>> 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 [mailto:Paul.Wirth at kniferiver.com]
>>>>> *Sent:* Saturday, May 01, 2010 9:03 PM
>>>>> *To:* 'geomoose-users at lists.sourceforge.net'
>>>>> *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
>>> not
>>>>> 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?
>>>>>
>>>>>
>>>>> -----------------------------------------------------------------------
>>> -
>>>>> -----------------------------------------------------------------------
>>> -------
>>>>> -----------------------------------------------------------------------
>>> -
>>>>> _______________________________________________
>>>>> Geomoose-users mailing list
>>>>> Geomoose-users at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/geomoose-users
>>>> ------------------------------------------------------------------------
>>> ------
>>>> _______________________________________________
>>>> Geomoose-users mailing list
>>>> Geomoose-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geomoose-users
>>>>
>>> --------------------------------------------------------------------------
>>> ----
>>>
>>> _______________________________________________
>>> Geomoose-users mailing list
>>> Geomoose-users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geomoose-users
>
>
> ------------------------------------------------------------------------------
> 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.
> http://p.sf.net/sfu/lotusphere-d2d
>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geomoose-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geomoose-users/attachments/20101217/da268159/attachment.html
More information about the Geomoose-users
mailing list