OSGeo Planet

Tyler Mitchell: Amazon Dash Button – Concept and Article re: IoT use

OSGeo Planet - Tue, 2015-03-31 20:30

I like this concept: “Just press and never run out”.   It’s the Amazon Dash Button: http://amazon.com/… – intended to be…

The post Amazon Dash Button – Concept and Article re: IoT use appeared first on spatialguru.com.

Categories: OSGeo Planet

Slashgeo (FOSS Articles): Batch Geonews: Landsat-live and on AWS, OpenStreetMap Reaches 2M Contributors, Vector Tiles, and much more

OSGeo Planet - Tue, 2015-03-31 19:07

Here’s the recent geonews in batch mode. Slashgeo has recently been a victim of a hack and was hosting some ‘commercial’ links on a hidden sub-site — nothing users would have found out unless they were directed to this parallel site by a third-party. We addressed the issue and, while it never directly impacted the Slashgeo.org you’re used to, I’m happy this bump is behind us.

From the open source / open data front:

From the Esri front:

From the Google front:

Discussed over Slashdot:

In the everything else category:

In the maps category:

The post Batch Geonews: Landsat-live and on AWS, OpenStreetMap Reaches 2M Contributors, Vector Tiles, and much more appeared first on Slashgeo.org.

Categories: OSGeo Planet

Jackie Ng: MapGuide 3.0 feature showcase: Tile Service Enhancements

OSGeo Planet - Tue, 2015-03-31 12:46
If I were to pick the most compelling feature of MapGuide Open Source 3.0, it would be the one I am about to show you in this post.

Do you bemoan the fact that tiled maps are tied to a given Map Definition preventing their re-use with other Map Definitions?

There are ways to work around this problem, by using the "hack" of stacking multiple Map Definitions in a Fusion Application Definition. In this case, you would have a purely tiled Map Definition and you combine this with a purely dynamic Map Definition in your Application Definition and provided both maps are in the same coordinate system, both tiled and dynamic layers will line up.

You can then reuse this tiled map definition with other Fusion applications by mixing and matching tiled and dynamic Map Definitions together. However as already mentioned, this is a hack because it exploits an esoteric feature of Fusion: The ability to have more than one Map Definition specified in a Fusion MapGroup. This technique doesn't work with the AJAX viewer.

For the 3.0 release, we have solved this problem by introducing a new resource type to define shareable tile sets: The TileSetDefintion.

For a cliff notes summary: A TileSetDefinition is a re-usable tile cache that is effectively the BaseMapDefinition element of the Map Definition Schema separated out into its own resource. A TileSetDefinition lets you:
  • Define one or more base layer groups, each with 0 or more layers
  • Define a finite set of scales
  • Define the coordinate system of this tile set
  • Define the bounds of this tile set
Basically the same tiled layer settings you would've previously defined in a Map Definition. In addition a TileSetDefinition also lets you define additional settings that are specific to that tile set:
  • Tile size
  • Tile image format
  • Tile storage location
No longer are your tile sets constrained by global tile settings in serverconfig.ini and no longer are your rendered tiles always stored in a global defined tile cache directory. Each tile set can have their own tile size, format, storage location.
Here's an example of such a Tile Set Definition, notice the structural similarity to the Base Map section of the Map Definition
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99<?xml version="1.0" encoding="utf-8"?>
<TileSetDefinition xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:noNamespaceSchemaLocation="TileSetDefinition-3.0.0.xsd">
<TileStoreParameters>
<TileProvider>Default</TileProvider>
<Parameter>
<Name>TilePath</Name>
<Value>%MG_TILE_CACHE_PATH%</Value>
</Parameter>
<Parameter>
<Name>TileWidth</Name>
<Value>256</Value>
</Parameter>
<Parameter>
<Name>TileHeight</Name>
<Value>256</Value>
</Parameter>
<Parameter>
<Name>TileFormat</Name>
<Value>PNG</Value>
</Parameter>
<Parameter>
<Name>FiniteScaleList</Name>
<Value>200000,100000,50000,25000,12500,6250,3125,1562.5,781.25,390.625</Value>
</Parameter>
<Parameter>
<Name>CoordinateSystem</Name>
<Value>GEOGCS["LL84",DATUM["WGS84",SPHEROID["WGS84",6378137.000,298.25722293]],PRIMEM["Greenwich",0],UNIT["Degree",0.01745329251994]]</Value>
</Parameter>
</TileStoreParameters>
<Extents>
<MinX>-87.764986990962839</MinX>
<MaxX>-87.695521510899724</MaxX>
<MinY>43.691398128787782</MinY>
<MaxY>43.797520000480347</MaxY>
</Extents>
<BaseMapLayerGroup>
<Name>Base Layer Group</Name>
<Visible>true</Visible>
<ShowInLegend>true</ShowInLegend>
<ExpandInLegend>true</ExpandInLegend>
<LegendLabel>Tiled Layers</LegendLabel>
<BaseMapLayer>
<Name>Roads</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Roads.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Roads</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Districts</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Districts.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Districts</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Buildings</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Buildings.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Buildings</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Parcels</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Parcels.LayerDefinition</ResourceId>
<Selectable>true</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Parcels</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Islands</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Islands.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Islands</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Hydrography</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Hydrography.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Hydrography</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>CityLimits</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/CityLimits.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>CityLimits</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
</BaseMapLayerGroup>
</TileSetDefinition>

Finally, there's the re-usability aspect. Once a TileSetDefinition has been created, you can link to it from any Map Definition. Tile caches are now bound to the TileSetDefinition instead of the Map Definition. When a Map Definition links to a TileSetDefinition, it will override the following settings from the Map Definition:
  • Coordinate System
  • Map Extents
The reason we do this is because dynamic map layers can be re-projected, but tiles cannot. So in the event that the Map Definition has a different coordinate system from the one in the linked tile set, the linked tile set "wins" and all the dynamic layers in the Map Definition will be re-projected to the coordinate system of the tile set, ensuring that both dynamic and tiled layers will line up properly.
And the best thing about this is that both AJAX and Fusion viewers support shareable tile sets*. The above multiple map hack is no longer needed.

* For this release, this will only work with shareable tile sets using the "Default" tile provider. Why? Read on below.
XYZ Tile Support
The TileSetDefinition schema allows tile set settings to be defined in a key/value fashion like you would in a Feature Source. This schema design is intentional as it allows us to define a FDO-style provider model behind the scenes for tile access. Through this provider model, we are able to add support for different tile access schemes, one of which is XYZ tiles. This means you no longer need mapguide-rest to serve XYZ tiles. MapGuide 3.0 will have this support natively.
Here's an example of a Tile Set Definition using the XYZ tile provider
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83<?xml version="1.0" encoding="utf-8"?>
<TileSetDefinition xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:noNamespaceSchemaLocation="TileSetDefinition-3.0.0.xsd">
<TileStoreParameters>
<TileProvider>XYZ</TileProvider>
<Parameter>
<Name>TilePath</Name>
<Value>%MG_TILE_CACHE_PATH%</Value>
</Parameter>
<Parameter>
<Name>TileFormat</Name>
<Value>PNG</Value>
</Parameter>
</TileStoreParameters>
<Extents>
<MinX>-9770571.93250815</MinX>
<MaxX>-9755615.48593707</MaxX>
<MinY>5416573.69002144</MinY>
<MaxY>5436091.17493748</MaxY>
</Extents>
<BaseMapLayerGroup>
<Name>Base Layer Group</Name>
<Visible>true</Visible>
<ShowInLegend>true</ShowInLegend>
<ExpandInLegend>true</ExpandInLegend>
<LegendLabel>Tiled Layers</LegendLabel>
<BaseMapLayer>
<Name>Roads</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Roads.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Roads</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Districts</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Districts.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Districts</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Buildings</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Buildings.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Buildings</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Parcels</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Parcels.LayerDefinition</ResourceId>
<Selectable>true</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Parcels</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Islands</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Islands.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Islands</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>Hydrography</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/Hydrography.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>Hydrography</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
<BaseMapLayer>
<Name>CityLimits</Name>
<ResourceId>Library://Samples/Sheboygan/Layers/CityLimits.LayerDefinition</ResourceId>
<Selectable>false</Selectable>
<ShowInLegend>true</ShowInLegend>
<LegendLabel>CityLimits</LegendLabel>
<ExpandInLegend>true</ExpandInLegend>
</BaseMapLayer>
</BaseMapLayerGroup>
</TileSetDefinition>

Notice that the XYZ tile set definition does not specify a coordinate system. This is because XYZ tile sets are always in WGS84.PseudoMercator (aka. EPSG:3857), so there is no need to specify this. The extents describe the bounds of this tile set in EPSG:3857 coordinates.

You'll notice in both examples, that we have the concept of a tile provider along with a set of key/value pairs to describe settings applicable for that provider, which is similar to the how a Feature Source specifies a FDO provider and a set of key/value pairs that form the set of FDO connection properties.

And what is this %MG_TILE_CACHE_PATH%? It is a placeholder for the global server tile cache path, and just like %MG_DATA_FILE_PATH% for feature sources, you can replace this with actual physical paths or MapGuide aliases. That's right, your Tile Set Definitions can have their own defined tile storage location instead of being all under a globally defined path in serverconfig.ini

As you can see, the similarity between tile providers and FDO was quite intentional :)

This provider model is currently hard-coded for these 2 providers. There is no formal plugin model/API yet that allows for external third-party tile providers to be defined. Whether we will add such support in a future release is a discussion for another time.
The best thing about this XYZ support: No API changes required! You still use the same GETTILE requests to the mapagent, only now you pass in the actual X, Y and Z for the ROW, COL and SCALE parameters.

Now there is one limitation of the XYZ support for this release. You cannot create MgMap instances from a Map Definition that links to an XYZ tile set, and as a result you cannot load such Map Definitions in the AJAX and Fusion viewers. The main use case for XYZ tile support in this release is to enable easy consumption of XYZ tile sets in MapGuide by external clients like OpenLayers, Leaflet, etc. We'll correct this limitation for the next major release after 3.0.

With this release, there's a new sample you can check out that demonstrate how to consume XYZ tiles from OpenLayers.


When you look at the code, you'll find consuming XYZ tile sets from MapGuide is as simple as consuming OpenStreetMap and friends in your JS mapping library of choice, be it OpenLayers, Leaflet or any other library that can consume XYZ tile sets.

Now that our tile storage and access has been abstracted behind a Tile Set Definition resource, it paves the way for us to easily enhance the tiling capabilities in the future with:

  • Support for additional storage backends (eg. MBTiles)
  • Support for additional tile formats (eg. Vector tiles, UTFGrid)
  • Standardizing tile access (eg. WMTS)

That's not to say such items are definitely on our current roadmap, but it will make implementing such features a more realistic and feasible possibility now that the groundwork has been laid in this release.

For more information about these new Tile Service Enhancements, you can consult MapGuide RFC 140
Categories: OSGeo Planet

gvSIG Team: Primer curso online de gvSIG para usuarios sobre la última versión, gvSIG 2.1

OSGeo Planet - Tue, 2015-03-31 12:23

Tras la publicación de la última versión de gvSIG, está ya disponible el primer curso online en la plataforma gvsig-training.com sobre dicha versión, gvSIG 2.1.

En este curso se incluyen tanto las funcionalidades de las versiones anteriores como las nuevas herramientas incluidas en gvSIG.

Entre las novedades más importantes de esta versión se incluye la creación de librerías de símbolos propias, a partir de símbolos creados con cualquier programa de dibujo. Una funcionalidad muy interesante también es que una vez creada la librería, se puede generar un paquete de instalación que puede ponerse a disposición de los distintos usuarios de una organización. También se han incluido una gran cantidad de librerías disponibles para descargar desde la propia aplicación, relativas a emergencias, medio ambiente, criminología, etc.

En este curso el usuario aprenderá a crear vistas con cartografía, tanto local como remota, tanto ráster como vectorial, a crear capas nuevas, a realizar análisis básico (áreas de influencia…), y a crear sus propios mapas con su leyenda, escala, norte…, entre otras cosas.

El curso comenzará a partir del día 7 de abril, y las inscripciones siguen abiertas en el portal gvsig-training.com. Para realizar la inscripción se debe acceder a http://web.gvsig-training.com/index.php/es/cursos/online/actuales/product/42-curso-de-gvsig-para-usuarios-idioma-espanol-internacional-10a-edicion

Completando el curso se obtiene el Certificado Usuario Básico de la Asociación gvSIG, y permite acceder al Certificado Experto, a través de los otros cursos disponibles.

¡Os esperamos!

 


Filed under: community, gvSIG Desktop, spanish, training
Categories: OSGeo Planet

BostonGIS: PostgreSQL 9.5 features of interest to PostGIS Users

OSGeo Planet - Tue, 2015-03-31 05:14

We got back from PostgreSQL Conf 2015 which was in New York City. It's probably the most educational conference we've been to in a while and mostly because we stayed thru the whole conference. One of the key take aways from the conference was Magnus Hagander's 9.5 showcase of features slides at http://www.hagander.net/talks/postgresql95.pdf. There are 2 things I am looking for which are along the lines of parallelization and the 3rd I'm not sure about is of much benefit but could be.

Inheritance support for Foreign Tables (aka sharding with FDWs)

The thing I was most excited about was Foreign Table inheritance (and BTW you can add check constraints to Foreign tables) which means you can use the constraint exclusion feature of PostgreSQL to query across federated PostgreSQL servers. The thing that excited me about this, is I had a perfect use case I was itching to try -- which I have on my list. The PostGIS Tiger geocoder utilizes an inheritance hierarchy to partition tables. When I took on maintainance of the geocoder and changed it to use a table inheritance instead of single table structure, I was not so much concerned about speed as much as being able to easily spit out a backup of a set of states to create a smaller database I could hand-off to a user or specific client. Since it is already naturally sharded and has that built-in its query logic, it would seem a perfect fit to test if parallelization could work in this fashion and improve speed for similar setups. Michael Paquier has a simple example of this feature in PostgreSQL 9.5 feature highlight: Scale-out with Foreign Tables now part of Inheritance Trees

Parallel sequential scans

This one isn't quite in yet, but is in the queue of likely candidates. So we don't have parallalization for all query methods, but this is the first step to getting there and one that doesn't require any changes on your part to take advantage of.

GiST index only scan

Big gotcha here is that it is only currently supported for built in PostgreSQL box and point classes. The bigger question is, is it really worthwhile to implement in PostGIS 2.2 for PostGIS types. I have to say this was a bit of a yawn for me, but I point it out because it was the only time Magnus mentioned PostGIS - "PostGIS folks in crowd, can PostGIS use this?". I doubt it will provide much benefit since the GisT we have just contains the box and requires a RECHECK anyway. Conceivably it could be useful for counting points or as a very fuzzy estimate of count of objects in a window, but that's all I can think it could be useful for. How much effort to build in the logic in PostGIS 2.2 I don't know. I leave that as an excercise for someone smarter than me.

Categories: OSGeo Planet

Antonio Santiago: The mystery of no flash session variables in Express + Passport auth

OSGeo Planet - Mon, 2015-03-30 19:09

Someday I started an application using NodeJS with ExpressJS framework and decided to use passport for authenticate the users. As many other times I wanted to use flash messages so, when user authentication fails, the application shows a message informing about bad credentials. Nothing new on the horizon until…. OMG !!! I can’t see the flash messages !!!

Disclaimer: This is a really stupid history with me as starring.

I like to learn from my errors and because of this I decide to write this post both as a punishment and to ensure I don’t forget it again.

The crime scene

I was working implementing a sign up process, where the user writes its credentials and system creates as a new user or returns an error message like “Sorry, but a username with that email exists” or similar.

Before introduce any code, the flow is as follows:

  • User access the /signup page via GET method.
  • Data is sent to /signup resource via POST method, which is responsible to:
    • Check if data is fine, create a new user and redirected to the /profile page.
    • If a user with the same email exists we redirect again to the /signup page (that is, using the GET method) with a flash message related to bad credentials.

Note: A flash message is a variable stored within a session that is only available once, for the next request. That is if we put a flash variable and renders a page, the flash variable is available but if we render the same (or other) page again the flash variable is not present (it is destroyed).

The approximate code for the previous flow is as follows. First, the next code is responsible to receive the post data and register the user:

// process the signup form router.post('/signup', passport.authenticate('local-signup', { successRedirect : '/profile', // redirect to the secure profile section failureRedirect : '/signup', // redirect back to the signup page if there is an error failureFlash : true // allow flash messages }));

The authentication is delegated to passport, which is implemented as:

passport.use('local-signup', new LocalStrategy({ // by default, local strategy uses username and password, we will override with email usernameField : 'email', passwordField : 'password', passReqToCallback : true // allows us to pass back the entire request to the callback }, function(req, email, password, done) { process.nextTick(function() { // find a user whose email is the same as the forms email // we are checking to see if the user trying to login already exists User.findOne({ 'email' : email }, function(err, user) { // if there are any errors, return the error if (err) { return done(err); } // check to see if theres already a user with that email if (user) { return done(null, false, req.flash('signupMessage', 'That email is already taken.')); } else { // if there is no user with that email // create the user var user = new User(); user.local.email = email; user.local.password = user.generateHash(password); user.save(function(err) { if (err) { throw err; } return done(null, user); }); } }); }); }));

As you can see, if the user exists we add a flash session message with: 

req.flash('signupMessage', 'That email is already taken.'));

On the other side, we show the signup form each time user access to the /signup resource via GET method:

router.get('/signup', function(req, res) { res.render('signup', { message: req.flash('signupMessage') }); });

Here we are rendering the signup template passing a message with the value of the signupMessage message. This way if user is redirected to the form, because the signup process fails (that is, the access to the /signup resource via POST), then the error message is shown.

The mystery

The problem was I never get a value for the flash variable. What? Yes, I never get a value for the flash variable.

There was no error, I can’t set and (in the same method) get the flash value, but I can’t get value any value among different resources, that is, between GET /signup and POST /signup.

The solution

After too much time (too many to be recognised publicly) I found my problem was with the way I initialise my sessions. What ? Yes, I said it was my fault due the way I initialise the session. This I did it:

app.use(session({ secret: config.sessionSecret, resave: false, saveUninitialized: true, cookie: { secure: true } }));

Can you see the problem? Here goes a clue, think I was working with a dev profile, that is, in my local machine accessing resources without HTTPS.

Yes, the problem was to set the 

secure: true  and does not access resources via HTTPS.

The express-session middleware documentation says (yes, go to the cookie section):

Please note that secure: true is a recommended option. However, it requires an https-enabled website, i.e., HTTPS is necessary for secure cookies. If secure is set, and you access your site over HTTP, the cookie will not be set. If you have your node.js behind a proxy and are using secure: true, you need to set “trust proxy” in express.

Conclusions

I’m happy to found the problem. Right now, while I write this lines, I’m at a tattoo shop waiting to be tattooed with the previous beautiful sentence.

Categories: OSGeo Planet

gvSIG Team: Create labels by scale (new extension)

OSGeo Planet - Mon, 2015-03-30 15:08

We have already seen how to create legends by scale with the new extension “Complex Legend”. Having this new extension installed in our gvSIG, we also will be able to create labels depending on the scale of our View.

Let´s refresh how it works

As always, the first step is to go to labelling options: we open the properties window of the layer on which the label will be applied (right click on the layer name in the Table of Contents) and select the “Labelling” tab.

Z1_gvsig

The definition of a sensitive scale label is located inside the panel “User defined labels“.

01_label

Regarding to the associated panel, its structure has not changed a lot, so it can be handled as usual; only it will be taken into account that the operation “Define classes of features and label each differently” and the new option “Multiple label by scale must be selected from he drop-down menu.

02_label

Once this option is selected, a new entry can be added defining the label to show, clicking on the field “Label expression” which has been added in the table.

The window shown is very similar to the one already known, unless a new tab at the top to bring up a form where the range of the scale on which the label will be visible will be indicated.

03_label

 A functionality really interesting, don´t you think?


Filed under: english, gvSIG Desktop, gvSIG development Tagged: gvSIG 2.2, labelling, labels, scale
Categories: OSGeo Planet

Boundless Blog: Pinpointing Disasters with OpenGeo Suite

OSGeo Planet - Mon, 2015-03-30 13:41

Boundless’ Victoria, British Columbia office sits at the southern tip of Vancouver Island, a region in which is used to mild earthquake activity. So when a colleague back east asked if we’d felt “the earthquake near Port Hardy”, we weren’t particularly surprised that there had been one or that it had gone unnoticed locally.

We were a little surprised, however, when we saw that the epicentre was well off the west coast of the island, while Port Hardy sits on the east coast. Looking more closely at the USGS map showing the location of the earthquake, one wonders why Port Hardy was chosen as a reference point in news reports and not say, Tofino, which is roughly due east of the epicentre.
Picture1
Like many OpenGeo Suite users, PostGIS is my go-to tool for doing some quick spatial analysis, so I loaded up the Natural Earth populated places data set in to a fresh database and whipped up a quick query to see what was happening within 250 kilometres of the quake.

$ shp2pgsql -W LATIN1 -I -s 4326 ne_10m_populated_places.shp | psql earthquakes

WITH constants AS (SELECT ST_SetSRID(ST_MakePoint(-128.15, 49.42), 4326)::geography AS quake) ( SELECT name, pop_max, ST_Distance(geom::geography, quake) / 1000 AS distance FROM ne_10m_populated_places, constants WHERE ST_DWithin(quake, geom::geography, 250*1000) ORDER BY DISTANCE );

And sure enough:

name      | pop_max |     distance ----------------+---------+------------------ Port Hardy     |    2295 | 151.591959991648 Tofino         |    1655 | 170.322296453086 Campbell River |   33430 | 219.404018781354 Courtenay      |   32793 | 229.792897985687

Port Hardy just edges out Tofino as the closest settlement in my data set. So do the USGS and other organisations simply use a naive algorithm to find a reference point for earthquakes? It sure looks like it!

[Note: if you’re wondering about the WITH clause above, that’s just an easy way to effectively define a constant that can be referenced throughout the main part of the query. Remember this syntax because we’ll be using it again below.]

Google went with Port Hardy, based on USGS data (although they calculate the distance differently that their source):
Picture2

Natural Resources Canada’s website on the other hand referenced the small village of Port Alice, which is closer to the action but wouldn’t make the population threshold in most data sets:
Picture3

Writing a better algorithm

If we agree that Port Hardy probably isn’t the best reference point for an event in the Pacific Ocean, then we are left with the question: can we design a better algorithm? A simple, but effective improvement would be to calculate the distance between nearby settlements but double the distance for the bits that cross over land.

So from Port Hardy to the epicentre is about 150 kilometres, but we’ll need to add about 75 km extra because about half of that is overland. From Tofino, however, it’s 170 km from point to point and only a smidgen extra for crossing Vargas Island on the way out to sea. That’s 225 km to 175: Tofino wins!

Picture4

We’re going to build up our query in three parts, something which isn’t strictly necessary but it does make things a little easier to read and maintain.

The first step is to get a list of populated places that are within a reasonable range of the earthquake (we’ll use 250 km again) and which have more than 1000 inhabitants. Additionally, we’ll use PostGIS to create a line from that point out to the quake and pass up all this information to the next step in our query.

SELECT name, pop_max, ST_MakeLine(geom, quake) AS line FROM constants, ne_10m_populated_places WHERE pop_max > 1000 AND ST_DWithin(quake::geography, geom::geography, 250*1000)

The sub-query above will be referenced as the places table in the query below, which is where most of the hard work actually happens.

We take the results from the places query and join them to another Natural Earth data set which contains states, provinces and other subdivisions of countries around the world (you can load it with the same shp2pgsql command I used above). Basically, this new table tells us what parts of the world are covered by land and what parts are not. By finding the intersection between our line and any land polygons, we can calculate a new land_line geometry for each of the places we found above.

SELECT places.name, places.pop_max, places.line, ST_Collect(ST_Intersection(places.line, land.geom)) AS line_land, ST_Length(line::geography) / 1000 AS distance FROM ne_10m_admin_1_states_provinces_shp AS land, places WHERE ST_Intersects(places.line, land.geom) GROUP BY places.name, places.pop_max, places.line

We’ll add this new geometry and its length to the data we’ve collected about each place and pass them all up to final part of our query, referring to this as the places_land table.

SELECT name, pop_max, distance, distance + ST_Length(line_land::geography) / 1000 AS weighted_distance FROM places_land ORDER BY weighted_distance

This is where we wrap everything up by calculating the weighted_distance, which is just the regular distance plus the distance of the part that crossed over land (dividing by 1000 since the length of the PostGIS geography data type is measured in meters).

Pulling these together we get this final, three-step query:

WITH constants AS (SELECT ST_SetSRID(ST_MakePoint(-128.15, 49.42), 4326) AS quake) ( SELECT name, pop_max, distance, distance + ST_Length(line_land::geography) / 1000 AS weighted_distance FROM ( SELECT places.name, places.pop_max, places.line, ST_Collect(ST_Intersection(places.line, land.geom)) AS line_land, ST_Length(line::geography) / 1000 AS distance FROM ne_10m_admin_1_states_provinces_shp AS land, ( SELECT name, pop_max, ST_MakeLine(geom, quake) AS line FROM constants, ne_10m_populated_places WHERE pop_max > 1000 AND ST_DWithin(quake::geography, geom::geography, 250*1000) ) AS places WHERE ST_Intersects(places.line, land.geom) GROUP BY places.name, places.pop_max, places.line ) AS places_land ORDER BY weighted_distance );

All that’s left is to run the query and see what we get:

name      | pop_max |     distance     | weighted_distance ----------------+---------+------------------+------------------- Tofino         |    1655 | 170.322296453086 |  170.996532624216 Port Hardy     |    2295 | 151.591959991648 |  213.424215448539 Campbell River |   33430 | 219.404018781354 |  336.005258086551 Courtenay      |   32793 | 229.792897985687 |  344.417265701763

It works: this earthquake is best described as being 170 km from Tofino by our reckoning!

The query above is only really suitable for points at sea, but you can adapt this code for cases where points are on land as well … and of course the exercise is not limited to earthquakes, but can be applied for any kind of disaster or event. With some additional creativity, we could  also tune our algorithm to prefer places with more inhabitants over those with fewer. And of course, you can always change the search radius of 250 km or the population threshold of 1000 inhabitants.

Finally, if you want to pack this all up and create an application with OpenGeo Suite, I suggest checking out our recent blog post on publishing SQL queries like this in GeoServer and passing parameters to make an interactive and dynamic layer to show on a map!

 

The post Pinpointing Disasters with OpenGeo Suite appeared first on Boundless.

Categories: OSGeo Planet

Jackie Ng: Announcing: MapGuide Open Source 3.0 Beta 1

OSGeo Planet - Mon, 2015-03-30 01:01
After a month or two lost due to mucking around with packer and vagrant to get the perfect repeatable and disposable build environment for both Windows and Linux builds of MapGuide/FDO, I'm now happy to announce the availability of MapGuide Open Source 3.0 Beta 1.

Who knew debugging build infrastructure would be such a PITA? And who also knew that vagrant and windows is like oil and water? Ugh! I gave up on that part, so as it stands our current build infrastructure for putting out releases of MapGuide is still Jenkins for windows and (slightly improved) vagrant for Linux.

Stay tuned for the (promised) series of posts talking about what's new in MapGuide Open Source 3.0

Download
Categories: OSGeo Planet

Tyler Mitchell: IoT Day 3: Viewing data on the Eagle Energy Monitor

OSGeo Planet - Sun, 2015-03-29 18:05

The Eagle energy monitor from Rainforest Automation is a very handy device.  It reads the wireless signal from my…

The post IoT Day 3: Viewing data on the Eagle Energy Monitor appeared first on spatialguru.com.

Categories: OSGeo Planet

Tyler Mitchell: Plug-In Solar: Moveable Solar Power For Renters and Do-It-Yourselfers

OSGeo Planet - Sun, 2015-03-29 02:00

via Green Building Elements | From brick and mortar shops to city planning, we cover sustainable trends in construction,…

The post Plug-In Solar: Moveable Solar Power For Renters and Do-It-Yourselfers appeared first on spatialguru.com.

Categories: OSGeo Planet

From GIS to Remote Sensing: Unleash the Landsat archive: SCP 4.3 allows for downloading from the entire archive of Landsat 4, 5, 7 and 8.

OSGeo Planet - Sat, 2015-03-28 19:17



This post is about a major update for the Semi-Automatic Classification Plugin for QGIS, version 4.3.0.

Following the changelog:-added support for image download of Landsat 4,5, 7 and 8
-improvements to the interface
In version 4.2 of SCP I have added the function to search and download Landsat 8 images from Amazon Web Services.





Categories: OSGeo Planet

Tyler Mitchell: IoT Day 2: Cloud Services for Energy Monitoring

OSGeo Planet - Sat, 2015-03-28 13:00

Energy monitoring isn’t only about knowing what’s happening right now, but also understanding what happened historically.  Often that includes…

The post IoT Day 2: Cloud Services for Energy Monitoring appeared first on spatialguru.com.

Categories: OSGeo Planet

GeoTools Team: CodeHaus Migration Schedule

OSGeo Planet - Fri, 2015-03-27 23:19
As per earlier blog post CodeHaus is shutting down and the GeoTools project is taking steps to migrate our issue tracker and wiki to a new home.

First up I need to thank the Open Source Geospatial Foundation for responding quickly in a productive fashion. The board and Alex Mandel were in position to respond quickly and hire a contractor to work with the system admin committee to capture this content while it is still available.

I should also thank Boundless for providing me time coordinate CodeHaus migration and Andrea for arranging cloud hosting.
Confluence MigrationIs scheduled for ... now! I have taken a copy of the CodeHaus wiki and will be migrating proposals and project history. A html dump of the wiki is published at old.geotools.org so we have a record.

The new wiki is available here: https://github.com/geotools/geotools/wikiGitHub Wiki
Jira MigrationJira migration is scheduled for 00:00 UTC Saturday March 28th.

On Saturday all issues will be migrated to their new home (and CodeHaus issue creation will be disabled). If you wish to lend a hand testing please drop by the #osgeo IRC channel on Saturday. Harrison Grundy will be coordinating the proceedings.

We have set up a new JIRA available at osgeo-org.atlassian.net for the migration. If you need access to the new issue tracker please contact Andrea or Jody.

OSGeo JiraAs shown above a few friendly CodeHaus refugees have also been sheltered for the storm (uDig and GeoAPI).

Categories: OSGeo Planet

GeoTools Team: FOSS4GNA Code Sprint Replacing Vecmath

OSGeo Planet - Fri, 2015-03-27 22:06
As Torben indicated on the geoserver blog we got together for a one day sprint after the foss4gna conference. Torben stole my picture for that post so I will have to stick to content ...

Our topic of choice ... replacing vecmath. The use of vecmath library has been a long standing "technical debt" for GeoTools. How long standing? The issue tracker number is GEOT-22.
So what is the problem with vecmathThe vecmath.jar is used by gt-referencing for coordinate system transformations. We only uses a couple classes form the library: primarily to implement GeneralMatrix for use in MathTransforms.GeneralMatrix extending GMatrixThere is one small problem with this idea - vecmath is not open source! Technically vecmath is distributed as part of Java 3D (an extensions to the Java Virtual Machine). As an extension to Java it was distributed under the same licenses (Sun Binary License and a Research License) as Java.
With the GeoGig project going through LocationTech incubation we have a couple ways to use jars:
  • prerequisite: open source jars required to run
  • works with: optional jars that extend the functionality if present. These may be proprietary like an oracle database driver.
Although the vecmath license is fine for distribution it does not meet the strictly open source policies required for the GeoGig project. In this case we want GeoTools to include matrix math and needed to shop around for a replacement.
The use of vecmath (as a non open source dependency) also causes trouble for Rich Fecher's proposal to publish GeoTools on Maven Central. Enter EJMLWith a technical dept page capturing research, some email discussion and a great lunchtime conversation at foss4gna with Eric Engle (the overlap with EclipseCon was good for something) we settled on the recommended Efficient Java Matrix Library (EJML).
GeneralMatrix delegating to DenceMatrix64FThe strategy here is delegate to the DenseMatrix64F implementation provided by EJML, and implement the methods we expect from XMatrix in terms of this new implementation.
The EJML library has the similar arrangement with SimpleMatrix wrapping a DenseMatrix64F an API friendly to casual developers. We were able to use SimpleMatrix as a guide, saving a lot of time.How to helpWhile the code sprint was a success in proving the approach, there is a bit of work to go:
  • Tyler (from GeoGig) is working on removing the dependency on vecmath (there are a few other Exceptions and data structures in our API that need to be removed).
  • Jim (from GeoMesa) wants to write up more test cases to check for regressions between vecmath and EJML
  • Although Rich Fecher (from GeoWave) was unavailable to take part in the code sprint - his inspiration to work on this now means we will be hitting him up for a review when the work is complete. Thanks Rich!
  • And there is always the question of performance ... will it be faster!
To help take part, or review our work see this branch in github:Thanks to Boundless victoria staff, Jim and Andrea for really getting behind this work. This kind of up keep keeps the community ticking along and helps the library be used in more places.
I would also like to thank the new crop of projects using GeoTools for taking part and contributing upstream. It is important to keep our community diverse and your participation is both welcomed and appreciated.
Categories: OSGeo Planet

Slashgeo (FOSS Articles): GeoServer 2.7 Released

OSGeo Planet - Fri, 2015-03-27 19:44

The popular open source geospatial data server GeoServer version 2.7 has been released earlier this week.

The new features highlighted in the announcement:

  • Color composition and color blending
    • These are two new extensions to the rendering engine that allows for greater control over how overlapping layers in a map are merged together
  • Relative time support in WMS/WCS
  • WPS:
    • WPS clustering
    • WPS security
    • WPS limits
    • WPS dismiss
  • CSS extension refresh
  • Cascade WFS Stored Queries

The post GeoServer 2.7 Released appeared first on Slashgeo.org.

Categories: OSGeo Planet

Slashgeo (FOSS Articles): OpenLayers 3.4.0 Released

OSGeo Planet - Fri, 2015-03-27 19:05

The popular open source web mapping library OpenLayers version 3.4.0 has been released today.

Some new features according to the announcement: “Dateline wrapping has been added for tile sources, you can most clearly see this in the new wms-tiled-wrap-180 example. The draw interaction can now draw circles as well, check out the updated draw features example and select Geometry type Circle. […] Another interesting change is the ability to allow GeoJSON to be serialized according the right-hand rule, this refers to the orientation of the rings. This is very important for interoperability of GeoJSON, with systems such as Elasticsearch. […] In version 3.3.0 support for ArcGIS REST services was released […]”

Here’s the full changelog for all version from 3.1.0 to 3.4.0, versions that were not mentioned over the official OpenLayers blog.

The post OpenLayers 3.4.0 Released appeared first on Slashgeo.org.

Categories: OSGeo Planet

Tyler Mitchell: IoT Day 1: Home Energy Monitoring

OSGeo Planet - Fri, 2015-03-27 15:58

  In my next series of blog posts we explore an Internet of Things topic – Home energy monitoring –…

The post IoT Day 1: Home Energy Monitoring appeared first on spatialguru.com.

Categories: OSGeo Planet

OpenLayers Team: OpenLayers 3.4.0 released

OSGeo Planet - Fri, 2015-03-27 14:28

The OpenLayers development team is proud to announce the release of OpenLayers 3.4.0. We have been on a monthly release schedule since the beginning of this year, so you can expect a fresh OpenLayers 3 release every month.

The 3.4.0 release brings some interesting new features as well as several bug fixes. Dateline wrapping has been added for tile sources, you can most clearly see this in the new wms-tiled-wrap-180 example.

The draw interaction can now draw circles as well, check out the updated draw features example and select Geometry type Circle. You will need to click once for the center and then drag to give the circle its radius, and finally click again to finalise the circle geometry.

Draw circle geometry

Another interesting change is the ability to allow GeoJSON to be serialized according the right-hand rule, this refers to the orientation of the rings. This is very important for interoperability of GeoJSON, with systems such as Elasticsearch. For all the details please refer to the pull request.

A new example was added to show how to use existing functionality to draw arrows in line strings.

In version 3.3.0 support for ArcGIS REST services was released, which was the result of a great contribution outside of the normal developer pool, of which we have had many lately, which is very exciting. Right after the 3.3.0 release we found out through user testing (thanks neogeo) that there was an issue with this source type on Retina screens. This was fixed a few hours after the report and version 3.4.0 has the fix for this incorporated.

Also we would like to draw some more attention to the fact that we are now exclusively using StackOverflow with the openlayers-3 tag for user questions. The ol3-dev Google group is now only to be used for developer communication.

We’re excited to be meeting up next week in Schladming, Austria for a developer sprint.

 

Categories: OSGeo Planet
Syndicate content