[Geomoose-users] Scalebar & Measure

Brent Fraser bfraser at geoanalytic.com
Fri Dec 17 12:59:50 EST 2010


Just to follow up, for future reference:

The viewport element's parentElement.id = "mapContainer" (from the DIV 
declared in geomoose.html) and parentElement.uniqueNumber = 4, so I 
expect the viewport's elementID can be constructed from that...

Best Regards,
Brent Fraser


On 12/17/2010 10:44 AM, Brent Fraser wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> 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/1257eb12/attachment.html


More information about the Geomoose-users mailing list