Thanks to Volker Fröhlich’s efforts, a source code RPM package (SRPM) of QGIS 2.0.1 is now available for Fedora. If you are not yet F20 user (like me), you can just take the F20 package and compile it for F19 (or even F18) since there will be no backport of QGIS 2 to F19 (it comes with QGIS 1.8). But: we do want QGIS 2 on Fedora19!

Solution: compile it yourself.

1. 1. Preparations

The best way is  to use “mock” which is used to recompile SRPMS in a separate local environment (“chroot”) without cluttering the system with extra packages needed for the compilation (run as “root”):

su
yum install mock

2. 2. Get the source code

Next download the SRPM package from the Koji  server:
QGIS:  http://koji.fedoraproject.org/koji/buildinfo?buildID=467757 (–> src – download) or check here for more recent versions.

3. 3. Compile it locally as RPM package

The general compilation command (“mock”) would be:

mock -r my_fedora_version_config --rebuild my_source_rpm.src.rpm

So, check for Fedora version config name which is suitable for your system (“my_fedora_version_config“)

ls /etc/mock/

In my case of a 64bit machine, it is “fedora-19-x86_64″. Hence we can compile QGIS 2.0.1 directly from the SRPM file:

mock -r fedora-19-x86_64 --rebuild qgis-2.0.1-2.fc20.src.rpm

Note: the compilation takes 40min on my tiny core i3 laptop (ASUS X202). Use the time to donate some coins to the QGIS project

4. 4. Install and enjoy

Once the compilation job is done, i.e. the binary RPM files are available for installation. To install the freshly compiled QGIS 2.0.1 RPMs, run:

cd /var/lib/mock/fedora-19-x86_64/result/

# an existing QGIS1.8 installation will be replaced: 
yum localinstall qgis-2.0.1-2.fc19.x86_64.rpm \
qgis-grass-2.0.1-2.fc19.x86_64.rpm qgis-python-2.0.1-2.fc19.x86_64.rpm

# consider to cleanup (or keep it for the next update, it is about 1.5GB):
rm -rf /var/lib/mock/fedora-19-x86_64/
# leave the "root" shell
exit

Now we can happily use QGIS 2.0.1 on Fedora 19!

qgis

Sourcepole bietet Grundlagen- und Aufbau-Kurse für den Betrieb von Geodaten-Infrastrukturen auf der Basis von PostgreSQL/PostGIS und Quantum GIS an. Detaillierte Informationen zu den Kursen, die wieder im November 2013 stattfinden, entnehmen Sie bitte http://www.sourcepole.ch/kurse Die Anmeldung ist online möglich. Wir freuen uns darauf Sie in Zürich begüssen zu können.

Dal 10 al 11 Ottobre 2013 si terrà a Bologna presso i laboratori della Scuola di Ingegneria e Architettura (V.le del Risorgimento, 2), e le sale conferenze della Regione Emilia-Romagna (V.le della Fiera, 8), la sesta conferenza italiana sul software geografico e sui dati geografici liberi (GFOSS DAY 2013).

Lo scopo principale della conferenza è quello di coinvolgere imprese, enti pubblici, scuole, università, centri di ricerca, sviluppatori, cittadini, operatori del settore ed appassionati dei temi del software libero geografico e degli open data.

Sarà inoltre possibile seguire in diretta streaming il convegno.

Registrati:

http://www.gfoss.it/drupal/gfossday2013/registrazione

La partecipazione alla conferenza è libera e gratuita ma è richiesta una registrazione (meglio anticipata) per consentire una migliore organizzazione dell’evento e garantire la stampa di badge e attestati.
L’accesso ai workshop è garantito fino al raggiungimento numero massimo di partecipanti.

Section 1. Programma

http://www.gfoss.it/drupal/gfossday2013/programma

Section 2. Sede della conferenza

http://www.gfoss.it/drupal/gfossday2013/locations

Parteciperete a #gfoss13? Ditelo al mondo!

tl;dr

The API had to change. We don't like breaking plugins. It makes us sad. We did it now to save pain in the future. You will like the new version better. Trust me.

What happened to my cheese?

When updating to QGIS 2.0 you might have noticed two things. (Apart from all the new awesome stuff!)

1. All your settings have been set back to defaults
2. Some of your plugins are gone, or missing in the installer.

Resetting of settings is caused by QGIS now storing its 2.0 settings in a different folder then we used for 1.8. In 1.8, all your plugins, etc, were stored in the ./qgis folder in your home directory, in 2.0 these are now stored in ./qgis2. The reason will become evident later. All user settings, the UI layout, database connections, etc, are now stored in a QGIS location. In windows this in the registry key HKEY_CURRENT_USER\Software\QGIS\QGIS2. So this explains why your settings are missing when you first load QGIS 2.0.

Why did we have to move the settings location?

Good question.

2.0 is very different from 1.8. There has been a lot of work to make this the best version we have ever made, new features, more bug fixes, a bigger dev team, and a even bigger community. Being the next major release we had to make some calls to remove some of the old code and features that were weighing us down. Features such as the old labelling engine, old symbol engine, the old vector API. Carrying old code and old out dated features into the future can sometimes really hurt a project and they have to be cut loose. Because of the massive amount of changes in 2.0 people needed to be able to run 2.0 and 1.8 on the same machine without causing any issues. If they both store settings in the same location this would have had bad results.

Why move the settings. Part 2

Moving the settings was also a result of having non backwards compatible plugins between 1.x and 2.x. If we kept both plugins in the same folder it just wouldn't work. You would install a 1.8 version of a plugin, I would update my plugin to 2.0, you then install the same plugin in 2.0, and now you 1.8 version is broken. Fun!. To avoid this we moved all QGIS 2.0 stuff into ./qgis2.

Why did my plugins break anyway. Why not just leave them be.

In 1.x we were using SIP v1. This meant the framework we used, PyQt, felt more like C++ then it did Python. If you are a Python developer then this isn't a very fun thing to deal with. In SIP v1 you need to tell PyQt, and our QGIS API, what to convert the type to. feature['mycolumn'].toInt() that is pretty gross. In V2 you can just do feature['mycolumn'] and SIP will auto convert the type for you. This makes our API feel more like Python and less like C++. There are other changes when using SIP V2 but you get the idea. Unfortunately SIP v1 and v2 do not work together so we couldn't make the code backwards compatible. This was also a forced change for us. Once we switch to Python 3 at some stage in the future V2 would be the default and we have to change then. The bright side of this change is most of the time you are removing code. Consider it a good time to go though your code, give it a bit of a polish, and remove anything that is no longer needed.

There was another major API change that needed to happen. Vector API update. In order to allow for multithreading in the future, and we all know everyone is looking forward to that, we needed to change how code can ask for features from a layer. The old method would never work in a multithreaded structure and had to go.

What can I do if I need a plugin?

Having a plugin missing from the plugin installer when you really need it can be a bit of a pain. Plugin authors are working hard to update there plugins. I approve about two a day into the plugin repository. While most plugins might be updated at some stage. There are some things that you can do if you need a plugin update to work with 2.0.

1. Email the author of the plugin to see where they are at with the update

2. Email the author and offer your help to update the plugin. Remember a lot of plugins are written by volunteers who just need the plugin to get their work done and wanted to share it with everyone.

3. If the author has no intention of updating the plugin, or can't be contacted. You are free to update you local copy and offer it back to the community as the updated copy. If you are going to upload it back to the plugin repository please try to contact the author and seek permission first. I will be watching for copies of plugins to make sure we don't end up with 10 versions of the same plugin. The GPL allows for you to modify and share your updated version but it's nice to keep the original author in the loop. If the author no longer wants to maintain the plugin and you are able to then contact me and I will make you the owner of the plugin. Overall be nice not evil, we are all friends here.

4. If you don't have, or know someone with, the skills to update the plugin. You can contact a developer to help update the plugin for you. Companies like mine, or Faunalia, or a whole range of other open source devs, can normally be contracted to update a plugin if needed.

Moving forward

We like the new API. It makes the Python side of QGIS much cleaner. There is still more work to do, it's never ending, but this is a good step. We don't like breaking plugins, but breaking a few now is better then breaking heaps as the popularity of QGIS continues to grow.

tl;dr

The API had to change. We don't like breaking plugins. It makes us sad. We did it now to save pain in the future. You will like the new version better. Trust me.

What happened to my cheese?

When updating to QGIS 2.0 you might have noticed two things. (Apart from all the new awesome stuff!)

1. All your settings have been set back to defaults
2. Some of your plugins are gone, or missing in the installer.

Resetting of settings is caused by QGIS now storing its 2.0 settings in a different folder then we used for 1.8. In 1.8, all your plugins, etc, were stored in the ./qgis folder in your home directory, in 2.0 these are now stored in ./qgis2. The reason will become evident later. All user settings, the UI layout, database connections, etc, are now stored in a QGIS location. In windows this in the registry key HKEY_CURRENT_USER\Software\QGIS\QGIS2. So this explains why your settings are missing when you first load QGIS 2.0.

Why did we have to move the settings location?

Good question.

2.0 is very different from 1.8. There has been a lot of work to make this the best version we have ever made, new features, more bug fixes, a bigger dev team, and a even bigger community. Being the next major release we had to make some calls to remove some of the old code and features that were weighing us down. Features such as the old labelling engine, old symbol engine, the old vector API. Carrying old code and old out dated features into the future can sometimes really hurt a project and they have to be cut loose. Because of the massive amount of changes in 2.0 people needed to be able to run 2.0 and 1.8 on the same machine without causing any issues. If they both store settings in the same location this would have had bad results.

Why move the settings. Part 2

Moving the settings was also a result of having non backwards compatible plugins between 1.x and 2.x. If we kept both plugins in the same folder it just wouldn't work. You would install a 1.8 version of a plugin, I would update my plugin to 2.0, you then install the same plugin in 2.0, and now you 1.8 version is broken. Fun!. To avoid this we moved all QGIS 2.0 stuff into ./qgis2.

Why did my plugins break anyway. Why not just leave them be.

In 1.x we were using SIP v1. This meant the framework we used, PyQt, felt more like C++ then it did Python. If you are a Python developer then this isn't a very fun thing to deal with. In SIP v1 you need to tell PyQt, and our QGIS API, what to convert the type to. feature['mycolumn'].toInt() that is pretty gross. In V2 you can just do feature['mycolumn'] and SIP will auto convert the type for you. This makes our API feel more like Python and less like C++. There are other changes when using SIP V2 but you get the idea. Unfortunately SIP v1 and v2 do not work together so we couldn't make the code backwards compatible. This was also a forced change for us. Once we switch to Python 3 at some stage in the future V2 would be the default and we have to change then. The bright side of this change is most of the time you are removing code. Consider it a good time to go though your code, give it a bit of a polish, and remove anything that is no longer needed.

There was another major API change that needed to happen. Vector API update. In order to allow for multithreading in the future, and we all know everyone is looking forward to that, we needed to change how code can ask for features from a layer. The old method would never work in a multithreaded structure and had to go.

What can I do if I need a plugin?

Having a plugin missing from the plugin installer when you really need it can be a bit of a pain. Plugin authors are working hard to update there plugins. I approve about two a day into the plugin repository. While most plugins might be updated at some stage. There are some things that you can do if you need a plugin update to work with 2.0.

1. Email the author of the plugin to see where they are at with the update

2. Email the author and offer your help to update the plugin. Remember a lot of plugins are written by volunteers who just need the plugin to get their work done and wanted to share it with everyone.

3. If the author has no intention of updating the plugin, or can't be contacted. You are free to update you local copy and offer it back to the community as the updated copy. If you are going to upload it back to the plugin repository please try to contact the author and seek permission first. I will be watching for copies of plugins to make sure we don't end up with 10 versions of the same plugin. The GPL allows for you to modify and share your updated version but it's nice to keep the original author in the loop. If the author no longer wants to maintain the plugin and you are able to then contact me and I will make you the owner of the plugin. Overall be nice not evil, we are all friends here.

4. If you don't have, or know someone with, the skills to update the plugin. You can contact a developer to help update the plugin for you. Companies like mine, or Faunalia, or a whole range of other open source devs, can normally be contracted to update a plugin if needed.

Moving forward

We like the new API. It makes the Python side of QGIS much cleaner. There is still more work to do, it's never ending, but this is a good step. We don't like breaking plugins, but breaking a few now is better then breaking heaps as the popularity of QGIS continues to grow.

tl;dr

The API had to change. We don't like breaking plugins. It makes us sad. We did it now to save pain in the future. You will like the new version better. Trust me.

What happened to my cheese?

When updating to QGIS 2.0 you might have noticed two things. (Apart from all the new awesome stuff!)

1. All your settings have been set back to defaults
2. Some of your plugins are gone, or missing in the installer.

Resetting of settings is caused by QGIS now storing its 2.0 settings in a different folder then we used for 1.8. In 1.8, all your plugins, etc, were stored in the ./qgis folder in your home directory, in 2.0 these are now stored in ./qgis2. The reason will become evident later. All user settings, the UI layout, database connections, etc, are now stored in a QGIS location. In windows this in the registry key HKEY_CURRENT_USER\Software\QGIS\QGIS2. So this explains why your settings are missing when you first load QGIS 2.0.

Why did we have to move the settings location?

Good question.

2.0 is very different from 1.8. There has been a lot of work to make this the best version we have ever made, new features, more bug fixes, a bigger dev team, and a even bigger community. Being the next major release we had to make some calls to remove some of the old code and features that were weighing us down. Features such as the old labelling engine, old symbol engine, the old vector API. Carrying old code and old out dated features into the future can sometimes really hurt a project and they have to be cut loose. Because of the massive amount of changes in 2.0 people needed to be able to run 2.0 and 1.8 on the same machine without causing any issues. If they both store settings in the same location this would have had bad results.

Why move the settings. Part 2

Moving the settings was also a result of having non backwards compatible plugins between 1.x and 2.x. If we kept both plugins in the same folder it just wouldn't work. You would install a 1.8 version of a plugin, I would update my plugin to 2.0, you then install the same plugin in 2.0, and now you 1.8 version is broken. Fun!. To avoid this we moved all QGIS 2.0 stuff into ./qgis2.

Why did my plugins break anyway. Why not just leave them be.

In 1.x we were using SIP v1. This meant the framework we used, PyQt, felt more like C++ then it did Python. If you are a Python developer then this isn't a very fun thing to deal with. In SIP v1 you need to tell PyQt, and our QGIS API, what to convert the type to. feature['mycolumn'].toInt() that is pretty gross. In V2 you can just do feature['mycolumn'] and SIP will auto convert the type for you. This makes our API feel more like Python and less like C++. There are other changes when using SIP V2 but you get the idea. Unfortunately SIP v1 and v2 do not work together so we couldn't make the code backwards compatible. This was also a forced change for us. Once we switch to Python 3 at some stage in the future V2 would be the default and we have to change then. The bright side of this change is most of the time you are removing code. Consider it a good time to go though your code, give it a bit of a polish, and remove anything that is no longer needed.

There was another major API change that needed to happen. Vector API update. In order to allow for multithreading in the future, and we all know everyone is looking forward to that, we needed to change how code can ask for features from a layer. The old method would never work in a multithreaded structure and had to go.

What can I do if I need a plugin?

Having a plugin missing from the plugin installer when you really need it can be a bit of a pain. Plugin authors are working hard to update there plugins. I approve about two a day into the plugin repository. While most plugins might be updated at some stage. There are some things that you can do if you need a plugin update to work with 2.0.

1. Email the author of the plugin to see where they are at with the update

2. Email the author and offer your help to update the plugin. Remember a lot of plugins are written by volunteers who just need the plugin to get their work done and wanted to share it with everyone.

3. If the author has no intention of updating the plugin, or can't be contacted. You are free to update you local copy and offer it back to the community as the updated copy. If you are going to upload it back to the plugin repository please try to contact the author and seek permission first. I will be watching for copies of plugins to make sure we don't end up with 10 versions of the same plugin. The GPL allows for you to modify and share your updated version but it's nice to keep the original author in the loop. If the author no longer wants to maintain the plugin and you are able to then contact me and I will make you the owner of the plugin. Overall be nice not evil, we are all friends here.

4. If you don't have, or know someone with, the skills to update the plugin. You can contact a developer to help update the plugin for you. Companies like mine, or Faunalia, or a whole range of other open source devs, can normally be contracted to update a plugin if needed.

Moving forward

We like the new API. It makes the Python side of QGIS much cleaner. There is still more work to do, it's never ending, but this is a good step. We don't like breaking plugins, but breaking a few now is better then breaking heaps as the popularity of QGIS continues to grow.

Yesterday, I received an interesting QGIS question:

is there a way to make road label font size depending on road lenght (with osm layer)?
Indeed, it could be interresting to see all roads, even the smallest, on a city map rendering.

Thanks to the data-defined labeling capabilities of the new QGIS version, we can!

Just click the slightly weird symbol right of the label text size and select Edit …

Since OSM data is in WGS84 by default, street length will be measured in degrees and therefore the values will be small. To get to a reasonable font size, I selected $length * 1000.

The second part of the question can be addressed using a setting in the Rendering section which is – very descriptively – called “Show all labels for this layer (including colliding labels)”.

While I doubt that this simple method alone will create a great road map, I think it’s still an interesting exercise with sometimes surprising results.

(reposting from here, Note to English speakers below)

Sie forschen, Sie entwickeln, Sie beschäftigen sich mit Open-Source-Geo-Software oder freien Geodaten? Sie haben neue Ideen in diesem Themenbereich oder sind bereits dabei, freie Software und freie Geodaten zu nutzen oder zu entwickeln? Dann sind Sie auf unserer Konferenz – der FOSSGIS-Konferenz 2014 - genau richtig.

WIR BIETEN: Eine Plattform für Ihre Idee, Ihr Projekt, Ihren Erfahrungsbericht auf der größten deutschsprachigen Anwenderkonferenz für freie Geoinformationssysteme und freie Geodaten. Im Jahr 2014 findet die FOSSGIS vom 19. bis 21. März auf dem Gelände der Beuth Hochschule für Technik in Berlin statt. Wir rechnen mit über 400 Teilnehmern. An der Konferenz 2013 in Rapperswil (Schweiz) nahmen über ca. 350 Besucher teil.

WIR SUCHEN: Ihre Idee. Ihr Projekt. Ihren Erfahrungsbericht. Ihr Thema. Genauer gesagt, suchen wir Vorträge für Einsteiger und Fortgeschrittene, um spannende Themen zu behandeln, Diskussionen zu entwickeln, praxisorientierte Workshops* runden unser Programm ab. Vorträge zum Thema freie Geodaten, zum Beispiel OpenStreetMap, Open Data sind ebenso möglich wie Beiträge zu beispielsweise Softwarelösungen aus dem Bereich WebGIS, Desktop GIS, Geodatenbanken oder Location-Based-Services. Bewerben Sie sich jetzt mit einem Vortrag, Lightning Talk oder Workshop* beim Call for Papers.

ABSTRACT: Die Einreichung eines Abstracts für die FOSSGIS 2014 ist ab sofort bis zum 15. November 2013 über unsere Konferenzsoftware Pentabarf möglich. Beitrags-Einreichungen ohne Abstract müssen leider abgelehnt werden, da sich das Programm-Komitee anhand des Abstracts ein Bild von Inhalt und Relevanz des Beitrags macht. Der Abstract sollte ca. 1500 Zeichen umfassen. Ob die Einreichung angenommen wurde, wird im Dezember 2013 bekanntgegeben. Es besteht die Möglichkeit einen Lightning Talk einzureichen. Ein Lightning Talk ist eine kurze, knackige Auseinandersetzung mit einem Thema, welches in 5 Minuten, gern humorvoll, Anregung zur Diskussion bietet. Weiterhin können Poster eingereicht werden.

*Workshops: Bitte berücksichtigen Sie bei der Planung, dass für die Workshops nur 90 Minuten vorgesehen sind und die Teilnehmer ein Mix aus Theorie und vor allem Praxis erwarten. Die Beschreibung des Workshops soll erreichbare Lernziele und die notwendigen Vorkenntnisse der Teilnehmer enthalten. Ein Workshop findet ab einer Teilnehmerzahl von 5 statt.

WER WIR SIND: Veranstaltet wird die Konferenz vom FOSSGIS e.V., von der OSGeo Foundation und der Beuth Hochschule für Technik Berlin.

Unsere Konferenz lebt von Ihren Beiträgen und Ihrem Besuch. Werden Sie Teil der Konferenz – wir freuen uns auf Sie!

Noch Fragen? Wir haben versucht, in unseren FAQs alle wichtigen Fragen zu beantworten. Falls weitere Fragen bestehen, zögern Sie nicht uns eine E-Mail zu schreiben.

Note to English speakers

The FOSSGIS-conference is the largest German-language conference for Free and Open Source Software for GIS and Free Geodata hosting about 400 participants.

Today, the Conference Committee announced the “Call for papers” for 2014. Because the conference-language is German, the CfP is either.

The program committee will, however, also consider applications for talks or workshops held in English if they are deeemed to add to the quality of the conference. So if you don’t speak German, but are a FOSS/Open Data celebrity, or have a story that only you can tell, please do submit your talk. We are unlikely to be able to provide interpreters, but we’ll make sure you don’t get lost in Berlin. Please be aware that you can submit paper until November, 15. 2013. You can submit your abstract using our Conference Software.

We are looking forward to see you in Berlin March 19-21, 2014!

The Open Source Geospatial Foundation (OSGeo) is pleased to announce that the U.S. Internal Revenue Service (IRS) has accepted their application (PDF) for non-profit status under section 501(c)(4) of the tax code. Our 501(c)(4) status declares that OSGeo is a Social Welfare Organization. This determination affirms OSGeo’s role in serving the public through their mission, focused around Open Source Geospatial software.

This determination helps ensure that the organization will not have to pay US federal taxes on money accumulated toward the fulfilment of their mission. Unfortunately, unlike a 501(c)(3) (Charitable) status, this does not allow financial contributors to OSGeo to treat the contributions as a charitable contribution which can have a tax benefit for US tax payers. There should still be no problem with commercial organizations treating contributions to OSGeo as a business expense.

OSGeo owes a special debt to past Executive Director Tyler Mitchell, and current Treasurer Daniel Morissette who have carried this process to a successful conclusion after several years of work. Current OSGeo President, Jeff McKenna, says “Both Daniel and Tyler should be thanked by the entire community for their dedication to such a challenging task. Our future foundation events, and OSGeo in general, will benefit from their hard work for years to come.”

About the Open Source Geospatial Foundation

The Open Source Geospatial Foundation, or OSGeo, is a not-for-profit organization founded in 2006 whose mission is to support and promote the collaborative development of open geospatial technologies and data.  The Foundation provides financial, organizational and legal support to the broader open source geospatial community. It also serves as an independent legal entity to which community members can contribute code, funding and other resources, secure in the knowledge that their contributions will be maintained for public benefit.

We liked this article http://www.cio.com/article/728794/6_Reasons_to_Pay_for_Open_Source_Software about why it is good to invest in Open Source software, so we would like to share the key points with you ——————————— Companies such as Red Hat make a lot of money selling products based on open source projects. But if the underlying software is free, what exactly are […]

Lutra Consulting and the University of Sussex are proud to host the 10^th developer conference (or Hackfest) on the 12^th to 16^th of September. QGIS is a powerful and user-friendly Free and Open Source GIS capable of viewing, analysing and mapping Geographic Information.

The adoption of QGIS is accelerating globally in public, private and academic organisations. Developers from around the globe will meet in person to discuss, plan and implement various aspects of the QGIS project.

All university staff and students are welcome to join the Hackfest and meet the people behind QGIS! See the wiki page for more information.

Ongoing news and updates will be posted to this page during the hackfest.

Day 1

Live streaming can be viewed here

Find us here

</p>

You may also like...

Mergin Maps, a field data collection app based on QGIS. Mergin Maps makes field work easy with its simple interface and cloud-based sync. Available on Android, iOS and Windows.

While it’s really exciting that the release of QGIS 2.0 is just around the corner, I’m finding it just as exciting that work is already under way on version 2.1! Some great new features have already landed and I can’t wait to see what else is planned. Personally, I’ve got plans for a raft of improvements relating to print composers with the goal of making the print composer behave as much like a full-blown DTP package as possible. In the meantime, here’s a quick teaser of a feature I’ve been working on that will hopefully be landing in master soon:

Un’occasione speciale: due corsi avanzati, tenuti da uno dei massimi esperti nazionali del settore. A Pontedera (PI), vedi http://www.faunalia.it/calendario per dettagli logistici. Costo per ciascun corso: 350 € (+ IVA per aziende/partite IVA). Sconto 10% per l’iscrizione simultanea ad entrambi i corsi. Scrivete a [email protected] per dettagli. GDAL/OGR avanzato 18-19-20 Novembre 2013 Primo giorno: lavorare […]

On 7th Sep 2013 the final results from the 2013 elections for the open seats of the OSGeo Board of Directors have been published. There were four seats open and they have been filled by (in no particular order):

• Jáchym Čepický
• Jorge Sanz
• Bart van den Eijnden
• Gérald Fenoy

Thanks to all candidates for going through the elections and exposing themselves. All six candidates received excellent support with more then 60 votes each. Overall voting participation was 72% (129 out of 180) and there were no tie scores to arbitrate. Thanks to all Charter Members who voted!

The complete resulting OSGeo Board is:

• Anne Ghisla
• Bart van den Eijnden
• Gérald Fenoy
• Cameron Shorter
• Daniel Morissette
• Frank Warmerdam
• Gérald Fenoy
• Jáchym Čepický
• Jeff McKenna
• Jorge Sanz

With the election results published the new board of directors becomes immediately effective.

OSGeo wishes to thank the outgoing directors for their continued support of OSGeo and for helping to run a fantastic organizations with a great membership and lots of energy. We thank all candidates who stood in this election and all OSGeo Charter Members for their contribution and votes.

It’s almost here, the biggest open source GIS event of the year: the FOSS4G 2013 in Nottingham. It’s going to be my first visit to FOSS4G and I’m looking forward to present a project I did together with two colleagues at AIT where we compared OpenStreetMap to the official Austrian street network using tools developed in QGIS 1.8 Sextante. The presentation is scheduled for the first day and it would be great to meet you there:

• An Open Source Analysis Toolbox For Street Network Comparison: How OSM Compares To The Official Austrian Reference Graph

I also have the honor to present Victor Olaya’s Sextante/Processing in a workshop together with Paolo Cavallini on the 20th:

• W21: Spatial Analysis With QGIS And SEXTANTE

I guess I owe Victor a geobeer or two ;-)

See you in Nottingham! And for those who can’t make it to the UK: I’ll try to keep you posted if the conference wifi allows it.

The OSGeo-Live geospatial software collection version 7.0 has been released, featuring more than sixty open source, standards compliant geospatial desktop applications, web applications and frameworks. A complete installation kit and high-quality sample data in multiple industry standard formats are included. The OSGeo Live will be officially launched at FOSS4G 2013 in Nottingham, UK, 17-21 September, 2013.

Release Highlights

Projects new to this release include:

• GeoNode — a web-based application and platform for developing geospatial information systems (GIS) and for deploying spatial data infrastructures (SDI)
• Leaflet — a modern, open source JavaScript library for mobile-friendly interactive maps
• ncWMS — a Web Map Service (WMS) for geospatial data stored in CF-compliant NetCDF files
• netCDF dataset — daily maximum temperature and rainfall, worldwide

All geospatial applications on the disc have been updated to their latest stable releases.

About OSGeo-Live

OSGeo-Live is a self-contained bootable DVD, USB flash drive and Virtual Machine based upon Ubuntu Linux (version 12.04 LTS). OSGeo-Live is pre-configured with a wide variety of robust open source geospatial software. All applications can be trialled without installing anything on your computer, simply by booting the computer from a DVD or USB drive, or running in a Virtual Machine environment. Each featured package is accompanied by both a publication quality one page descriptive summary and a short tutorial on how to get started using it.

http://live.osgeo.org

OSGeo-Live includes:

• Over sixty quality geospatial Open Source applications installed and pre-configured
• Free world maps and geodata
• One page overview and quick start guide for every application
• Overviews of key OGC standards
• Translations to multiple languages

Credits

Over 160 people have directly helped with OSGeo-Live packaging, documenting and translating, and thousands have been involved in building the packaged software.

Packagers, documenters and translators include:

Activity Workshop, Agustín Dí­ez, Aikaterini Kapsampeli, Alan Beccati, Alan Boudreault, Alessandro Furieri, Alexander Bruy, Alexander Kleshnin, Alexander Muriy, Alexandre Dube, Alexey Ardyakov, Alex Mandel, Amy Gao, Andrea Antonello, Andrea Yanza, Andrey Syrokomskiy, Andry Rustanto, Angelos Tzotsos, Anna Muñoz, Antonio Falciano, Anton Novichikhin, Anton Patrushev, Argyros Argyridis, Ariel Núñez, Assumpció Termens, Astrid Emde, Barry Rowlingson, Benjamin Pross, Brian Hamlin, Bruno Binet, Cameron Shorter, Christophe Tufféry, Christos Iossifidis, Cristhian Pin, Damian Wojsław, Dane Springmeyer, Daniel Kastl, Daria Svidzinska, David Mateos, Denis Rykov, Diego González, Diego Migliavacca, Dimitar Misev, Dmitry Baryshnikov, Dominik Helle, Edgar Soldin, Eike Hinderk Jürrens, Elena Mezzini, Eric Lemoine, Estela Llorente, Etienne Delay, Etienne Dube, Evgeny Nikulin, Fran Boon, François Prunayre, Frank Gasdorf, Frank Warmerdam, Friedjoff Trautwein, Gavin Treadgold, Giuseppe Calamita, Gerald Fenoy, Grigory Rozhentsov, Guy Griffiths, Hamish Bowman, Haruyuki Seki, Henry Addo, Hernan Olivera, Howard Butler, Hyeyeong Choe, Ian Edwards, Ian Turton, Ilya Filippov, Jackie Ng, Jan Drewnak, Jane Lewis, Javier Rodrigo, Javier Sánchez, Jesús Gómez, Jim Klassen, Jing Wang, Jinsongdi Yu, Jody Garnett, Johan Van de Wauw, John Bryant, Jorge Arévalo, Jorge Sanz, José Antonio Canalejo, José Vicente Higón, Judit Mays, Klokan Petr Pridal, Kristof Lange, kuzkok, Lance McKee, Lars Lingner, Luca Delucchi, Lucía Sanjaime, Mage Whopper, Manuel Grizonnet, Marc-André Barbeau, Marco Curreli, Marco Puppin, Marc Torres, Margherita Di Leo, Maria Vakalopoulou, Mario Andino, Mark Leslie, Massimo Di Stefano, Mauricio Miranda, Mauricio Pazos, Maxim Dubinin, Michaël Michaud, Michael Owonibi, Micha Silver, Mike Adair, Milena Nowotarska, M Iqnaul Haq Siregar, Nacho Varela, Nadiia Gorash, Nathaniel V. Kelso, Ned Horning, Nobusuke Iwasaki, Oliver Tonnhofer, Òscar Fonts, Otto Dassau, Pasquale Di Donato, Patric Hafner, Paul Meems, Pavel, Pedro-Juan Ferrer, Pirmin Kalberer, Raf Roset, Ricardo Pinho, Roald de Wit, Roberta Fagandini, Roberto Antolin, Roberto Antolí­n, Roger Veciana, Ruth Schoenbuchner, Samuel Mesa, Scott Penrose, Sergey Grachev, Sergio Baños, Simon Cropper, Simon Pigot, Stefan A. Tzeggai, Stefan Hansen, Stefan Steiniger, Stephan Meissl, Steve Lime, Thierry Badard, Thomas Baschetti, Thomas Gratier, Tom Kralidis, Toshikazu Seto, Trevor Wekel, Valenty González, Vera, Xianfeng Song, Yoichi Kayama, Zhengfan Lin

Sponsoring organisations

• The Open Source Geospatial Foundation OSGeo provides the primary development & hosting infrastructure and personnel for the OSGeo-Live project, and infrastructure for many of the software projects themselves. http://www.osgeo.org/
• LISAsoft provides sustaining resources and staff toward the management and packaging of software onto the Live DVD. http://www.lisasoft.com
• Information Center for the Environment (ICE) at the University of California, Davis provides hardware resources and development support to the OSGeo Live project. http://ice.ucdavis.edu
• Remote Sensing Laboratory at the National Technical University of Athens, provides hardware resources and development support to the OSGeo-Live project. http://www.ntua.gr
• The DebianGIS and UbuntuGIS teams provide and quality-assure many of the core packages. http://wiki.debian.org/DebianGis and https://wiki.ubuntu.com/UbuntuGIS

faunaliagis

Nothing in life ever comes free. Each time you make a desision there can sometimes be long a lasting effect. This is exectly the case with the new QGIS 2.0 pyqgis API. Changing to the new api was a big step in order make the API clear and more Pythonic. But there was a small detail to fix.

In QGIS 2.0 we can now just do this to read the attribute value for a field:

>>> feature['yourcolumn']
"Hello World"

What would you expect to get if the value was NULL (not empty string). Would you expect to see None? You would think so. Right? However lets just check that.

>>> feature['yourcolumn']
NULL

NULL? What the heck? That isn't None! What is NULL?

>>> type(NULL)
<class 'PyQt4.QtCore.QPyNullVariant'>

QPyNullVariant WA! WHAAAT! Why didn't we get None? Turns out by removing QVariant from PyQt it had some impact on methods that expected a NULL QVariant - A QVariant with no value. Passing None didn't work because those methods needed the type information that QVariant holds, even when NULL.

When using SIP V2, which is what QGIS 2.0 is using, PyQt will auto convert any Null QVariants to QPyNullVariant.

The NULL you see is a variable masking the QPyNullVariant so that the output is nicer and it's easier to work with. We have also added a bunch of methods to QPyNullVariant in order to make it act as much like None as we can.

If you see a NULL this is how you can deal with it:

>>> feature['yourcolumn']
NULL

>>> if not feature['nullcolumn']:
>>>     print "Was null"
Was null

>>> if feature['nullcolumn'] == NULL:
>>> print "Was null"
Was null

NULL will also return False if boolean checked:

>>> value = NULL
>>> if value:
...  print "This value wasn't null"
... else:
...  print 'This value was null' 
This value was null

It will also be equal to any other NULL aka QPyNullVariant variable

>>> value = NULL
>>> value2 = NULL
>>> value == value2
True
>>> value = 100
>>> value2 = NULL
>>> value == value2
False

Does None is NULL work? No.

One way to check if something is Null in Python is to use value is None however this will not work with our NULL type. Overloading the is operator in Python is not supported and there is no way we can support this - trust me I have tried. is is really doing id(object) == id(object) under the hood:

DO NOT do the following if you are checking for null values in pyqgis unless you know the return type is None:

>>> value = NULL
>>> value is None
false

Nothing in life ever comes free. Each time you make a desision there can sometimes be long a lasting effect. This is exectly the case with the new QGIS 2.0 pyqgis API. Changing to the new api was a big step in order make the API clear and more Pythonic. But there was a small detail to fix.

In QGIS 2.0 we can now just do this to read the attribute value for a field:

>>> feature['yourcolumn']
"Hello World"

What would you expect to get if the value was NULL (not empty string). Would you expect to see None? You would think so. Right? However lets just check that.

>>> feature['yourcolumn']
NULL

NULL? What the heck? That isn't None! What is NULL?

>>> type(NULL)
<class 'PyQt4.QtCore.QPyNullVariant'>

QPyNullVariant WA! WHAAAT! Why didn't we get None? Turns out by removing QVariant from PyQt it had some impact on methods that expected a NULL QVariant - A QVariant with no value. Passing None didn't work because those methods needed the type information that QVariant holds, even when NULL.

When using SIP V2, which is what QGIS 2.0 is using, PyQt will auto convert any Null QVariants to QPyNullVariant.

The NULL you see is a variable masking the QPyNullVariant so that the output is nicer and it's easier to work with. We have also added a bunch of methods to QPyNullVariant in order to make it act as much like None as we can.

If you see a NULL this is how you can deal with it:

>>> feature['yourcolumn']
NULL

>>> if not feature['nullcolumn']:
>>>     print "Was null"
Was null

>>> if feature['nullcolumn'] == NULL:
>>> print "Was null"
Was null 

NULL will also return False if boolean checked:

>>> value = NULL
>>> if value:
... print "This value wasn't null"
... else:
...     print 'This value was null' 
This value was null

It will also be equal to any other NULL aka QPyNullVariant variable

>>> value = NULL
>>> value2 = NULL
>>> value == value2
True
>>> value = 100
>>> value2 = NULL
>>> value == value2
False 

Does None is NULL work? No.

One way to check if something is Null in Python is to use value is None however this will not work with our NULL type. Overloading the is operator in Python is not supported and there is no way we can support this - trust me I have tried. is is really doing id(object) == id(object) under the hood:

DO NOT do the following if you are checking for null values in pyqgis unless you know the return type is None:

>>> value = NULL
>>> value is None
false

Nothing in life ever comes free. Each time you make a desision there can sometimes be long a lasting effect. This is exectly the case with the new QGIS 2.0 pyqgis API. Changing to the new api was a big step in order make the API clear and more Pythonic. But there was a small detail to fix.

In QGIS 2.0 we can now just do this to read the attribute value for a field:

>>> feature['yourcolumn']
"Hello World"

What would you expect to get if the value was NULL (not empty string). Would you expect to see None? You would think so. Right? However lets just check that.

>>> feature['yourcolumn']
NULL

NULL? What the heck? That isn't None! What is NULL?

>>> type(NULL)
<class 'PyQt4.QtCore.QPyNullVariant'>

QPyNullVariant WA! WHAAAT! Why didn't we get None? Turns out by removing QVariant from PyQt it had some impact on methods that expected a NULL QVariant - A QVariant with no value. Passing None didn't work because those methods needed the type information that QVariant holds, even when NULL.

When using SIP V2, which is what QGIS 2.0 is using, PyQt will auto convert any Null QVariants to QPyNullVariant.

The NULL you see is a variable masking the QPyNullVariant so that the output is nicer and it's easier to work with. We have also added a bunch of methods to QPyNullVariant in order to make it act as much like None as we can.

If you see a NULL this is how you can deal with it:

>>> feature['yourcolumn']
NULL

>>> if not feature['nullcolumn']:
>>>     print "Was null"
Was null

>>> if feature['nullcolumn'] == NULL:
>>> print "Was null"
Was null 

NULL will also return False if boolean checked:

>>> value = NULL
>>> if value:
... print "This value wasn't null"
... else:
...     print 'This value was null' 
This value was null

It will also be equal to any other NULL aka QPyNullVariant variable

>>> value = NULL
>>> value2 = NULL
>>> value == value2
True
>>> value = 100
>>> value2 = NULL
>>> value == value2
False 

Does None is NULL work? No.

One way to check if something is Null in Python is to use value is None however this will not work with our NULL type. Overloading the is operator in Python is not supported and there is no way we can support this - trust me I have tried. is is really doing id(object) == id(object) under the hood:

DO NOT do the following if you are checking for null values in pyqgis unless you know the return type is None:

>>> value = NULL
>>> value is None
false