Page 2 of 111 (2218 posts)

  • talks about »


Last update:
Sat Apr 20 10:05:14 2019

A Django site.

QGIS Planet

Leaflet Day 13 - Styling with a Plugin

Today we’ll take a look at another plugin—one that allows us to interactively change they style of features on our map: Leaflet.StyleEditor. This illustrates how we can customize our map by changing styles on the fly and also serves as a starting point for even more customization. Installing and Referencing the Plugin The web page for the plugin provides information on installing it. This requires getting the css, js, and image files in the proper location, then referencing them in our HTML file:

Leaflet Day 12 - Create a Leaflet Map from QGIS

Today we’ll use the qgis2web plugin to export from QGIS to Leaflet. The QGIS project, a location map for the third (in progress) Life on the Alaska Frontier novel, looks like this: Installing qgis2web The qgis2web plugin is installed like any other. Click on the Plugins->Manage and Install Plugins... menu item, click Not installed, and then find qgis2web in the list. Click the Install plugin button to complete the install.

Leaflet Day 11 - Plugins

At its core, Leaflet is designed to be lightweight. That being said, there are hundreds of third-party plugins available to extend and enhance the functionality of your web maps. Today we’ll illustrate adding a plugin to our map from Day 6. The L.Control.ZoomBar plugin adds a custom zoom control that allows us to draw a box around the area we want to zoom to, as well as adding a Home button to return to the initial map view.

Leaflet Day 10 - Adding a Link to a Popup

In this post we’ll add a link to the towns popup that will display the satellite view on Google Maps. The API for working with Google Maps URLs can be found here: To add a link to the town name in the popup, we modify the JavaScript code that creates the towns layer: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 var towns = L.

User question of the Month – Feb’19 & answers from Jan

In January, we wanted to learn more about if and how QGIS users contribute back to the project. We received 299 responses from all over the world:


55% of responders have contributed to the project in the past:


Responders who stated that they had contributed to QGIS were asked to specify what kind of contributions they had provided. This question was multiple-choice. Time contributions are generally more common than financial contributions. 30% of responders helped by creating reproducible bug reports and 24% implemented improvements themselves. The most common financial contribution are personal donations to QGIS.ORG at 17%.

Membership in user groups, contracting developers / documentation writers / translators, or having a support contract with a QGIS support provider are less common amongst responders:


Responders who stated that they had not contributed to QGIS most commonly stated that they didn’t know how to contribute (26%), while lacking financial resources were only raised by 10% of responders:


New question

This month, we’d like to know which plugins you think should be advertised as “featured” on the official QGIS plugin repository.

The survey is available in English, Spanish, Portuguese, French, Italian, Ukrainian, Danish, and Japanese. If you want to help us translate user questions in more languages, please get in touch!

Leaflet Day 2 - Adding a Marker

I’m starting off slow, so today we’ll add a marker with some extra features. Since the map from yesterday is already centered on the big earthquake, lets add a marker there. Adding a Marker To create a marker, Leaflet uses the L.marker class: var earthquakeMarker = L.marker([61.346, -149.955]); This creates the marker, but it needs to be added to the map: earthquakeMarker.addTo(map); This gives us: Good so far, but looking at the map tells us nothing about the marker.

Leaflet Day 3 - The Trail

Background In 1902 the only way from the port of Valdez to the Fortymile gold fields was a nearly 400 mile trail through the Alaska wilderness. The Valdez-Eagle trail plays a key role in novels two and three. Adding the Trail to a Leaflet Map To add the trail to our map, we will convert it from a shapefile to GeoJSON. There is more than one way to do this—you could use ogr2ogr, but we chose to use QGIS, since it would not only convert it, but transform the coordinate system at the same time.

Leaflet Day 5 - Working with Features

Today we’ll add towns along the trail route that are mentioned in the novels. I hesitate to call them towns, because in 1902, many of them consisted of a view indigenous people and sometimes a roadhouse. The method to add these locations will be to add a GeoJSON layer and loop through each town, adding a marker and popup with some info. The Data The data for the locations is from the GNIS database for Alaska, containing over 35,000 locations.

Leaflet Day 6 - GeoPackage Layers

In this post we’ll switch gears and install Leaflet locally, then add a layer from a GeoPackage file. Installing Leaflet Up until now we’ve been using a hosted version of Leaflet. In other words, each time we load the map, a request is made to fetch the Leaflet CSS and JavaScript. There are a couple of ways to install Leaflet: download it from the website or install with npm. In both cases you’ll need to move leaflet.

Leaflet Day 4 - Basemaps and Overlays

Today we’ll add some basemaps and a couple of controls to our map. So far we’ve been using OpenStreetMap as our back drop. There are a couple of tile servers that will give us a little more of a “back in the day” look. We’ll also add attribution to the map so we give credit where credit is due, as well as a scale bar. Complete code for the map can be viewed at the bottom of this post.

Leaflet Day 9 - Calculating Distance with Turf.js

Today we’re going to use Turf.js to calculate the distance between any two points along the trail. Turf.js is billed as providing “Advanced geospatial analysis for browsers and Node.js.” The distance calculated is a straight line (“as the crow flies”) distance rather than actual trail miles. Including Turf.js To calculate the distance we need to include Turf.js. Rather than install it locally, just add this line to the head of your HTML:

Leaflet Day 7 - Coordinates

In this post, we’ll do a couple of things: Clean up the display of coordinate precision in our popups Add the current coordinates to the map as the mouse moves Coordinate Precision Display The current map displays the latitude and longitude with seven decimal places. This is more than we need to see when displaying information about locations: Fixing this is easy to do using the JavaScript function toFixed.

Leaflet Day 8 - Zoom to Feature

In this post we’ll add a zoom button to pan the map to one of the towns in the trail stops layer. Adding a Dropdown Box and Button The first thing to do is add the select element and a button to the HTML: <select id='zoombox'> </select> <input type="button" id="zoomTo" value="Zoom to town"> We’ll populate the options for the select element using the town GeoJSON. Creating a Dictionary and Populating the Select Box Next we loop through the towns in the GeoJSON layer and create a dictionary that maps the town name to its data, then add each as an option to a select element:

Happy birthday OSGeo!

On February 4, 2006 OSGeo held its first meeting in Chicago, with 25 participants representing 18 groups and over 20 different Open Source GIS projects, and 39 others participating via Internet Relay Chat. During the meeting, participants made important decisions in the formation and organization of the foundation, including the name, structure and purpose. The consensus reached in Chicago opened the way for the establishment of a productive and representative foundation.

Today we are happy to announce that the we have meanwhile over 32,800 unique subscribers in the huge list of over 290 OSGeo mailing lists!

And: check out the web site of the OSGeo foundation.

1. More to come this year!

… see here for the growing list of events

The post Happy birthday OSGeo! appeared first on GFOSS Blog | GRASS GIS and OSGeo News.

Announcing our SLYR (MXD to QGIS) funding drive!

One product which North Road had the chance to develop last year, and which we are super-proud of, is our SLYR ESRI style to QGIS conversion tool. If you haven’t heard of it before, this tool allows automatic conversion of ESRI .style database files to their equivalent QGIS symbology equivalent. It works well for the most part, and now we’re keen to take this to the next stage.

The good news is that North Road have been conducting extensive research and development over the past 12 months, and we’re pleased to announce our plans for extending SLYR to support ESRI LYR and MXD documents. The LYR and MXD formats are proprietary ESRI-only formats, with no public specifications allowing their use. This is a huge issue for organisations who want to move from an ESRI environment to the open geospatial world, yet are held back by hundreds (or thousands!) of existing ESRI MXD map documents and layer styles which they currently cannot utilise outside of the ESRI software ecosystem. Furthermore, many providers of spatial data only include ESRI specific layer formatting files with their data supplies. This leaves users with no means of utilising these official, pre-defined styles in non-ESRI tools.

In order for us to continue development of the SLYR tool and unlock use of LYR and MXD formats outside of ESRI tools, we are conducting a funding campaign. Sponsors of the campaign will receive access to the tools as they are developed and gain access to official support channels covering their use. At the conclusion of this drive we’ll be releasing all the tools and specifications under a free, open-source license.

You can read the full details of the campaign here, including pricing to become a project sponsor and gain access to the tools as they develop. As a campaign launch promo, we’re offering the first 10 sponsors a super-special discounted rate (as a reward for jumping on the development early).

The mockup below shows what the end goal is: seamless, fully integrated, automatic conversion of MXD and LYR files directly within the QGIS desktop application!

Movement data in GIS #20: Trajectools v1 released!

In previous posts, I already wrote about Trajectools and some of the functionality it provides to QGIS Processing including:

There are also tools to compute heading and speed which I only talked about on Twitter.

Trajectools is now available from the QGIS plugin repository.

The plugin includes sample data from MarineCadastre downloads and the Geolife project.

Under the hood, Trajectools depends on GeoPandas!

If you are on Windows, here’s how to install GeoPandas for OSGeo4W:

  1. OSGeo4W installer: install python3-pip
  2. Environment variables: add GDAL_VERSION = 2.3.2 (or whichever version your OSGeo4W installation currently includes)
  3. OSGeo4W shell: call C:\OSGeo4W64\bin\py3_env.bat
  4. OSGeo4W shell: pip3 install geopandas (this will error at fiona)
  5. From download Fiona-1.7.13-cp37-cp37m-win_amd64.whl
  6. OSGeo4W shell: pip3 install path-to-download\Fiona-1.7.13-cp37-cp37m-win_amd64.whl
  7. OSGeo4W shell: pip3 install geopandas
  8. (optionally) From download Rtree-0.8.3-cp37-cp37m-win_amd64.whl and pip3 install it

If you want to use this functionality outside of QGIS, head over to my movingpandas project!

You gave us feedback – we give you QField 1.0 RC3

We are really happy to announce the release a new great milestone in QField’s history, QField 1.0 Release Candidate 3! (Yes, you might have got a glimpse of the broken RC2 if you where very attentive)

Thanks to the great feedback we received since releasing RC1 we were able to fix plenty of issues and add some more goodies.

We would like to invite everybody to install this Release Candidate and help us test it as much as possible so that we can iron out as many bugs as possible before the final release of QField 1.0.

List of fixes since RC1:
• fixed bad synchronization / geopackage files not written) (PR #455)
• fix glitches in portrait mode (PR #423 and #439)
• fix highlighting of points (search and feature selection) (PR #443)
• fix GPS info window overlapping search icon (PR #438)
• redesign of scale bar (PR #438)
• fix crash in feature form (with invalid relations) (PR #440)
• fix date/time field editing (PR #421 and #458)
• fix project not loading the correct map theme (fix #459)
• fix QGS or QGZ does not exist (PR #453)

Unfortunately, due to necessary updates in the SDK we target, we had to drop support for Android 4.4. The minimum Android requirement as of this RC is Android 5.0 (SDK version 21).

In case playstore does not suggest an update to QField Lucendro 0.11.90, the last working version for Android 4.4, we suggest all Android 4.4 users to uninstall QField 1.0 RC 1 (which was broken on android 4.4) and reinstall QField from the store. This way you should get If you don’t use play store, you can find all QField releases under

You can easily install QField using the playstore (, find out more on the documentation site ( and report problems to our issues tracking system (

QField, like QGIS, is an open source project. Everyone is welcome to contribute to make the product even better – whether it is with financial support, enthusiastic programming, translation and documentation work or visionary ideas.

If you want to help us build a better QField or QGIS, or need any services related to the whole QGIS stack don’t hesitate to contact us.

Call for testing: GRASS GIS with Python 3

Please help us testing the Python3 support in the yet unreleased GRASS GIS trunk (i.e., version “grass77” which will be released as “grass78” in the near future).

1. Why Python 3?

Python 2 is end-of-life (EOL); the current Python 2.7 will retire in 11 months from today (see We want to follow the “Moving to require Python 3” and complete the change to Python 3. And we need a broader community testing.

2. Download and test!

Packages are available at time:

3. Instructions for testing

4. Problems found? Please report them to us

Problems and bugs can be reported in the GRASS GIS trac. Code changes are welcome!

Thanks for testing grass77!

The post Call for testing: GRASS GIS with Python 3 appeared first on GFOSS Blog | GRASS GIS and OSGeo News.

Dealing with delayed measurements in (Geo)Pandas

Yesterday, I learned about a cool use case in data-driven agriculture that requires dealing with delayed measurements. As Bert mentions, for example, potatoes end up in the machines and are counted a few seconds after they’re actually taken out of the ground:

Therefore, in order to accurately map yield, we need to take this temporal offset into account.

We need to make sure that time and location stay untouched, but need to shift the potato count value. To support this use case, I’ve implemented apply_offset_seconds() for trajectories in movingpandas:

    def apply_offset_seconds(self, column, offset):
        self.df[column] = self.df[column].shift(offset, freq='1s')

The following test illustrates its use: you can see how the value column is shifted by 120 second. Geometry and time remain unchanged but the value column is shifted accordingly. In this test, we look at the row with index 2 which we access using iloc[2]:

    def test_offset_seconds(self):
        df = pd.DataFrame([
            {'geometry': Point(0, 0), 't': datetime(2018, 1, 1, 12, 0, 0), 'value': 1},
            {'geometry': Point(-6, 10), 't': datetime(2018, 1, 1, 12, 1, 0), 'value': 2},
            {'geometry': Point(6, 6), 't': datetime(2018, 1, 1, 12, 2, 0), 'value': 3},
            {'geometry': Point(6, 12), 't': datetime(2018, 1, 1, 12, 3, 0), 'value':4},
            {'geometry': Point(6, 18), 't': datetime(2018, 1, 1, 12, 4, 0), 'value':5}
        geo_df = GeoDataFrame(df, crs={'init': '31256'})
        traj = Trajectory(1, geo_df)
        traj.apply_offset_seconds('value', -120)
        self.assertEqual(traj.df.iloc[2].value, 5)
        self.assertEqual(traj.df.iloc[2].geometry, Point(6, 6))

Movement data in GIS #19: splitting trajectories by date

Many current movement data sources provide more or less continuous streams of object locations. For example, the AIS system provides continuous locations of vessels (mostly ships). This continuous stream of locations – let’s call it track – starts when we first record the vessel and ends with the last record. This start and end does not necessarily coincide with the start or end of a vessel voyage from one port to another. The stream start and end do not have any particular meaning. Instead, if we want to see what’s going on, we need to split the track into meaningful segments. One such segmentation – albeit a simple one – is to split tracks by day. This segmentation assumes that day/night changes affect the movement of our observed object. For many types of objects – those who mostly stay still during the night – this will work reasonably well.

For example, the following screenshot shows raw data of one particular vessel in the Boston region. By default, QGIS provides a Points to Path to convert points to lines. This tool takes one “group by” and one “order by” field. Therefore, if we want one trajectory per ship per day, we’d first have to create a new field that combines ship ID and day so that we can use this combination as a “group by” field. Additionally, the resulting lines loose all temporal information.

To simplify this workflow, Trajectools now provides a new algorithm that creates day trajectories and outputs LinestringM features. Using the Day trajectories from point layer tool, we can immediately see that our vessel of interest has been active for three consecutive days: entering our observation area on Nov 5th, moving to Boston where it stayed over night, then moving south to Weymouth on the next day, and leaving on the 7th.

Since the resulting trajectories are LinestringM features with time information stored in the M value, we can also visualize the speed of movement (as discussed in part #2 of this series):

  • <<
  • Page 2 of 111 ( 2218 posts )
  • >>

Back to Top