Hi Eric, our basic process is outlined here:
http://trac.osgeo.org/openlayers/wiki/HowToContribute Since we moved to github recently, some of the information is outdated unfortunately. Even though it's a one line patch, are you able to send a contributor agreement as outlined on the above page? Best regards, Bart -- Bart van den Eijnden OpenGeo - http://opengeo.org Expert service straight from the developers. On Apr 10, 2012, at 1:46 PM, Eric Blasenheim wrote: > Thanks, Bart. > > What is the process for reviewing and/or checking in the fix? > > Eric > > From: Bart van den Eijnden [mailto:[email protected]] > Sent: Tuesday, April 10, 2012 3:34 AM > To: Eric Blasenheim > Cc: [email protected] > Subject: Re: [OpenLayers-Dev] Bug in OpenLayers Bing support for data > attribution > > Thanks for your detailed report Eric. > > I've opened up: > > https://github.com/openlayers/openlayers/issues/398 > > so that we don't forget about this issue. > > Best regards, > Bart > > -- > Bart van den Eijnden > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > > > On Apr 9, 2012, at 4:25 PM, Eric Blasenheim wrote: > > > > I am brand new to this list and the site so I was hoping for some suggestions > in getting a bug in the Bing Maps data Attribution checked in. > > The bug that I found was that when your entire map is west of -90 or east of > +90, no text attribution shows up. I have attached a picture but this is > easily reproducible athttp://openlayers.org/dev/examples/bing-tiles.html . > (It’s also probably not a good idea to leave out attribution when you view > the providers home location of Seattle.) > > The fix seems to be a very simple change that forces the code to handle the > fact that the JSON response from the Imagery Metadata call for the bounding > boxes is lat/lon and not Lon/lat. > For example: > bbox=27, -179.99, 87, -126.5 is clearly two lat/lon rather than lon/lat > pairs. > > I discovered that the existing code was not passing the “reverseOrder” flag > to “OpenLayers.Bounds.fromArray”. Just adding missing second parameter of > “true” allows the code to generate bounding boxes consistent with the rest of > Open Layers and the bug is fixed. The line below with the added parameter is > from Bing.js. > > bbox = OpenLayers.Bounds.fromArray(coverage.bbox, true); > > Normally, I do not like hard coding “true” or any constants if there is a > different way but in this case, I see no way expressing that the JSON data > order returned from the Microsoft call is what it is. > > Of course, this also means that the attribution was not correct in many > places even when it did show up. > > As I am not familiar with the processes used for validation or testing but I > hope I will hear from someone soon. > > Thanks in advance, > Eric Blasenheim > > _______________________________________________ > Dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/openlayers-dev >
_______________________________________________ Dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/openlayers-dev
