[Qgis-developer] qgis2google, OTB plugins, enhanced measurements

[Maxim Dubinin]

Hi all,

We missed hackfest again :( But we were busy working on several
things, that might be of interest, we:

1. fixed qgis2google, working again ;)
2. created a win-build with OTB plugins based on r14713m
3. modified all three measurement tools to work with
unprojected data in lat-long and automagically give numbers in meters etc
(angles are spherical), calculations are using QgsDistanceArea
and WGS84 based. Handy for those who have rasters in latlong, but
still want to get measurements in meters/km2

All three things are available for testing as a package, details on
installation can be found here:
http://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fgis-lab.info%2Fblog%2F2010-11%2Fotb-plugin-qgis%2F

New measurements patch is in trac, can please someone
have a look and commit or just review, Alex can commit.
http://trac.osgeo.org/qgis/ticket/3240

Thanks to stopa85 and alexbruy for awesome work,

Maxim

Вы писали 19 ноября 2010 г., 19:24:46:

AM> On 11/19/2010 04:43 PM, Martin Dobias wrote:
>> Hi Alex
>> 
>> On Sat, Nov 20, 2010 at 12:44 AM, Alex Mandel
>> <tech_dev at wildintellect.com> wrote:
>>>
>>> I feel that a central option would help new plugin authors and authors
>>> who want collaborate on plugins. I've created a sourceforge site for my
>>> plugins in the past and attracted zero developers and only had a handful
>>> of bugs put into my trac. Aside from that, a central place lets us
>>> easily adopt abandoned plugins, and to give 1 place for reporting bugs
>>> which in theory would improve the reporting and tracking of fixes.
>>>
>>> I don't think we have to host it, but if we don't I would like to see us
>>> pick one of the 3rd party hosting services and create a collaborative
>>> collective under which people list their plugins(a qgis group).
>> 
>> Picking a 3rd party hosting service seems like an option. Anyway there
>> were such motions before, but did not really succeed:
>> http://sourceforge.net/projects/qgiscommunitypl/
>> 

AM> The biggest con is that we can't use osgeo logins if it's 3rd party.
AM> This to me is a big barrier to getting people using it. So picking a
AM> place a bunch of us already use would be good. We could speculate more
AM> about why that one didn't pan out (had forgotten about it) but I think
AM> the important parts are that there needs to be some buy-in (which I feel
AM> we have now that we've discussed the options), some ability for qgis
AM> core devs to admin over it (for rescue purposes), and more visibility
AM> like obvious linkage from qgis.org and in this case the new plugin site
AM> that's being built.

AM> My guess is a survey amongst current plugin and core devs would have
AM> them pick github 1st and maybe googlecode next with
AM> bitbucket/launchpad/sourceforge on the least favorite end.

AM> I also think Paolo is really excited about a central place to report and
AM> track issues. His team seems to do most of it right now and I see how
AM> other users searching the internet could really benefit from knowing
AM> where to look/getting them in search results. Then it just becomes a
AM> cultural thing to convince devs to pay attention to it.

>> 
>>> A large number of plugins right now aren't even under version control
>>> and even fewer of them have public tickets systems. So when I go to hack
>>> on a plugin(that isn't mine) I never know if I have the latest code or
>>> if it's been fixed and I don't expect an update to the release for every
>>> little fix. I also have no idea if it's still under development, or
>>> abandoned in favor of something else, merged into another plugin, etc.
>> 
>> I just have the impression that the plugin developers mostly will not
>> use that service. As you say, lots of plugins don't have any
>> versioning system (or just a private one) and maybe that's because the
>> authors do not need it for their work - more than 90% of the plugins
>> are one-man shows.
>> 

AM> I actually see this as a potential issue going forward as more and more
AM> people rely on plugins to get stuff done and there is potential to
AM> incorporate some plugins that offer central functionality into the core.
AM> A Bus number of 1 is kinda scary and while they may be one man shows
AM> that might be because it too much effort to solicit help (I've heard
AM> this from some developers out there over the years, 'I didn't open up
AM> the code or ask for collaboration because it was too much extra work').

AM> Lack of version control is a little frightening too (Carson lost all his
AM> original work on ftools at one point because he wasn't using version
AM> control, I think he recovered from the already released code). My goal
AM> is to better enable collaboration and encourage good open source
AM> programming practices.

>> In the new plugin repository we would like to keep track of plugin
>> updates - so determining whether the plugin is dead should be simple.
>> 
>> Regards
>> Martin

AM> Example, someone files a ticket with a patch to fix a major bug(feature)
AM> in a plugin. Said plugin appears to be dead. So someone else grabs the
AM> patch, forks the code, applies the patch and releases the plugin update.

AM> I'm open to trying github right now before we go and install stuff if we
AM> can figure out how to group stuff. I get the feeling the issue tracking
AM> won't be super central but it's really easy to try it 1st before we
AM> start installing stuff on the servers.

AM> Thanks,
AM> Alex
AM> _______________________________________________
AM> Qgis-developer mailing list
AM> Qgis-developer at lists.osgeo.org
AM> http://lists.osgeo.org/mailman/listinfo/qgis-developer