MapFish and GeoExt

Matt Priour recently asked about the future of the client part of MapFish, and more specifically whether it will be replaced by GeoExt. This is actually a question that every MapFish user should be asking . Anyway I thought an answer to that question could make a post on my blog. There it is.

The short story: the client part of MapFish will not be replaced by GeoExt.

Now the longer story. As of today the client part of MapFish includes OpenLayers, Ext, and the MapFish JavaScript lib. The latter is itself composed of two parts: core and widgets.

• core includes classes that are independent of Ext; most of them extend OpenLayers classes like OpenLayers.Control, OpenLayers.Protocol, OpenLayers.Strategy, etc. For example the client-side implementation of the MapFish Protocol is part of core.
• widgets includes Ext-based classes, mostly GUI components (but not only, the FeatureReader and stuff are part of widgets). widgets also has stuff that’s directly related to the server side of MapFish, the print widgets are a good example.

GeoExt will not replace core, nor will it replace the widgets components that rely on MapFish web services. But basically every new Ext-based component that isn’t tied to any server-side stuff is going into GeoExt.

In addition to OpenLayers and Ext, MapFish will include GeoExt. We had initially planned to integrate GeoExt into MapFish earlier, but finally decided to let things settle down a bit in GeoExt before doing the integration. We’re currently doing that integration, and we will gradually be deprecating classes as their equivalents are added into GeoExt. For example, the work on FeatureRecord, FeatureReader and FeatureStore we’ve been doing in GeoExt will deprecate the FeatureReader, FeatureStore and LayerStoreMediator classes in the MapFish JavaScript lib.

Also, MapFish, as a framework, aims to provide an integrated solution. For client-side development, this means that the developer doesn’t need to download Ext, OpenLayers and GeoExt, install them within his application, and think about the organization of his application. Instead, we want that applications created with the MapFish framework are well organized from their creations; with the Ext, OpenLayers, GeoExt and MapFish libs ready, with the JavaScript build tool ready, with the unit test suite ready, etc. I guess I will cover this topic in a later post…

Wooo, two posts in two days, scarry…

Additions to the MapFish Protocol

We recently added new stuff to the MapFish Protocol.

As a refresher, let’s first take a look at what the MapFish Protocol had before the new additions.

(Note that you’d need the JSONovich FireFox extension to see the output of the examples given below in your web browser.)

Geographic query params

• box={x1},{y1},{x2},{y2}: the features within the specified bounding box
• geometry={geojson_string}: the features within the specified geometry
• lon={lon}&lat={lat}&tolerance={tol}: the features within the specified tolerance of the specified lon/lat

Examples:

• http://demo.mapfish.org/mapfishsample/trunk/summits?box=6.2,45.6,6.3,45.7
• http://demo.mapfish.org/mapfishsample/trunk/summits?geometry={“type”:”Polygon”,”coordinates”:[[[6.2,45.6],[6.3,45.6],[6.3,45.7],[6.2,45.7],[6.2,45.6]]]}
• http://demo.mapfish.org/mapfishsample/trunk/summits?lon=6.2&lat=45.6&tolerance=0.1

Limiting and Sorting

• limit={num}: the maximum number of features returned
• offset={num}: the number of features to skip
• order_by={field_name}: the name of the field to use to order the features
• dir=ASC|DESC: the ordering direction

Examples:

• http://demo.mapfish.org/mapfishsample/trunk/summits?limit=10
• http://demo.mapfish.org/mapfishsample/trunk/summits?limit=10&offset=2
• http://demo.mapfish.org/mapfishsample/trunk/summits?limit=10&offset=2&order_by=elevation
• http://demo.mapfish.org/mapfishsample/trunk/summits?limit=10&offset=2&order_by=elevation&dir=ASC
• http://demo.mapfish.org/mapfishsample/trunk/summits?limit=10&offset=2&order_by=elevation&dir=DESC

The new params

• no_geom=true|false: so that the returned feature has no geometry (“geometry”: null)
• attrs={field1}[,{field2},...]: to restrict the list of properties returned in the features
• queryable={field1}[,{field2},...]: the names of the feature fields that can be queried
• {field}__{query_op}={value}: filter expression, field must be in the list of fields specified by queryable, query_op is one of “eq”, “ne”, “lt, “le”, “gt”, “ge”, “like”, “ilike”

And now an example combining all the new parameters:

• http://demo.mapfish.org/mapfishsample/trunk/summits?queryable=name,elevation&name__ilike=col&elevation__gte=3500&attrs=name,elevation&no_geom=true

The above query returns a GeoJSON representation of the summits whose names include “col” and whose elevations are greater than or equal to 3500. The returned features have no geometry and their attributes include “name” and “elevation” only.

Not including the geometry in the features makes the parsing in the browser much faster, so for cases where the geometries aren’t needed this is a big win.

Credits for the “queryable={field}&{field}__{query_op}={value}” syntax goes to FeatureServer!