Blog

Archive for the ‘Technology’ Category

It goes up to 2.0

Maybe someday PostGIS will go to 11, but for now, we’re still shooting for 2, point oh. And happily we are getting closer and closer. We have moved to a weekly schedule of alpha releases (this week was alpha3) and have started cleaning down the list of tickets against the 2.0 milestone.

Last month, much of the time spent by me and Sandro Santilli on PostGIS 2.0 preparation was funded by the Humanitarian Information Unit of the US Department of State. So, from the PostGIS development team, and the PostGIS community in general: thanks, HIU! Why is HIU funding PostGIS? Because the kinds of tools that HIU and its partners use for humanitarian response are backed by PostGIS, and they want to see those tools get better. Funding PostGIS development is an economical way to simultaneously raise the capabilities of a whole ecosystem of tools in HIU’s space.

Getting Curvey

PostGIS has supported curved geometry types — CIRCULARSTRING, COMPOUNDCURVE< CURVEPOLYGON — since version 1.4, but the number of functions that directly calculate against the curved features has remained pretty small. You can generate a bounding box, or calculate a length, but that’s about it.

A COMPOUNDCURVE made up of a line string, a circular arc, and another line string.

In order to do more complex calculations like area calculation or intersections, you have to first convert the curved object into a linearized approximation, using the ST_CurveToLine function. This is fine for functions that return numbers (like ST_Area) or booleans (like ST_Intersects), but what about functions that return derived geometries?

Linearized version of the compound curve. The arc has been replaced by a regular collection of lines.

For derived geometries, the result will be linearized like the inputs. But portions of the geometry will be linearized versions of the original curves: wouldn’t it be nice to have those curves back for storage?

Yes, it would which is why ST_LineToCurve exists. The line to curve logic works on the premise that a linearized version of a curve will have a certain amount of regularity in it.

The version of the code from PostGIS 1.4 and 1.5 works by looking at the angles between successive segments. Segments that share an angle of deflection with neighbours are probably components of a circular arc. This worked OK, but the code involved a fair amount of trigonometry.

By looking at angles between edges, you can find edges that are former components of an arc.

A simpler approach used for 2.0 turned out to be looking at the circle the arc is inscribed on. Any circular arc in PostGIS is defined by a start point, mid point and end point. Between them, they imply a circle, and the center of the circle can be calculated. Any successive point which is the same distance from that center point as the arc points can be considered part of the arc.

By using the circle as a basis for comparison, each successive point needs a simple distance check, instead of a trig check.

The new code is a lot simpler, and can deal with derived segments of more variable length that the old code.

The simplest way to prove that it works is to wrap a curved geometry in multiple nests of ST_LineToCurve and ST_CurveToLine, pushing the geometry back and forth between representations. While the functions are not perfect inverses (the segmentization routine doesn’t necessarily include the middle control points of the input arcs) you can see that the space bounded by the geometries does not change.

Happy curving!

GeoExt Code Sprint - Spring

OpenGeo is always eager to help advance open source geospatial software projects. When Andreas Hocevar told us that the GeoExt community was planning a code sprint for GeoExt 2.0 we were happy to get involved. The sprint is still in the planning stages and, unfortunately, not fully funded. Though many have contributed, we’re hoping others will join us in sponsoring this event.

GeoEXT and ExtJS 4
GeoExt enables building desktop-like GIS applications through the web. It is a Javascript framework that combines the GIS functionality of OpenLayers with the user interface of the ExtJS library provided by Sencha. GeoExt currently works with ExtJS 3 but that does not utilize the new features in ExtJS 4 (charting, harmonized API with Sencha Touch for mobile applications, and others). The upcoming code sprint will target developing GeoExt 2.0 to work with ExtJS 4 in order to leverage the newest features.

Participants
Representatives from the following companies have confirmed attendance and sponsorship:

  • OpenGeo
  • Camptocamp
  • terrestris
  • Mapgears

These organizations have provided core developers for GeoExt 1.x and have experience as service providers building applications with ExtJS 4. We’re excited to work with them again as we help develop GeoExt 2.0

Sponsor search
A week-long gathering of eight developers calls for a budget of $52,000. This covers travel, accommodations and partly the developers themselves. While much of this cost is being borne by the participating organizations we have not been able to close the gap.

We are looking for sponsors to help. Sponsors will be named explicitly and are encouraged to input their priorities for desired functionality in GeoExt 2.0.

Call for sponsorship
The participating organizations would like to invite all organizations and users utilizing GeoExt to sponsor the code sprint. Becoming a sponsor ensures the benefits from the new functions that will be implemented.

OpenGeo Suite now on GitHub

The OpenGeo Suite team has migrated all of our source code over to Git from Subversion, and we are now hosting the code on GitHub. This follows the trend of lots of open source software projects toward a distributed version control system.

Switching from Subversion to Git has all sorts of benefits for the development team, as well for anyone interested in playing with the code. There are numerous sites that detail the advantages of Git (we particularly like this one), but it will allow us to more easily incorporate features for our clients, manage multiple release streams, and work simultaneously without breaking development for everyone else. As the client base of the OpenGeo Suite grows (and as more and more people download the free Community Edition) this change has been a long time in coming.

You can also visit OpenGeo’s main GitHub repository as well as the main repositories for GeoExplorer, GXP, and more. Please fork the code and play around. If you have patches, feel free to send us a pull request. While we can’t guarantee that all patches will be accepted, we value every suggestion we receive.

If you have thoughts about our svn to git conversion, we’d love to hear about in the comments section. Though please, no x-is-better-than-y wars. Each one of us is correct!

Why choose? A hybrid approach to GIS

Earlier this year Esri released a white paper highlighting the benefits of open source and open specifications. No, that wasn’t a joke; the article is real, and well worth a read. It is a solid summation of open source in the marketplace and discusses the differences between open source software and open standards (what Esri calls “open specifications”). But more fundamentally, in this paper, Esri makes a bold and sensible claim that may surprise some people:

Deciding between open source and ArcGIS is not an either/or question. Esri encourages users to choose a hybrid model, a combination of open source and closed source technology, based on their needs.

The paper goes on to talk about Esri’s integration with various open source projects, from their ArcGIS Editor for OpenStreetMap, to their integration of Python into ArcGIS 10 (ArcPy), to their Geoportal Server, which is hosted on SourceForge. On the use of hybrid technology, we are in firm agreement. From the beginning, we have designed our software with integration in mind. For example, the OpenGeo Suite can connect to a number of proprietary databases, including ArcSDE, Oracle Spatial, IBM DB2, and Microsoft SQL Server, and the list continues to grow. In addition, with GeoCat Bridge you can publish data from ArcGIS Desktop to the web with the OpenGeo Suite.

Why would we advocate for proprietary systems? Simply put, we always suggest using the right tool for the job. Esri has great desktop tools, but on the server side there are faster, more reliable, more flexible options that support more standards. It can make sense to use ArcGIS Desktop and then use GeoCat Bridge to publish directly to the OpenGeo Suite. Or to use ArcSDE for data collaboration, then connect to the OpenGeo Suite to serve to the web. We know you have options when choosing any piece of software: Apache Tomcat versus IBM WebSphere, PostgreSQL versus Oracle Spatial, QGIS or uDIG versus ArcGIS Desktop, and, of course, the OpenGeo Suite versus ArcGIS Server. While we feel that open source holds the best route forward for software development, we are happy to give advice on the pros and cons of various architectures. The OpenGeo Suite Enterprise Edition clients use a variety of solutions that meet their needs. We’ll be publishing some white papers in the near future to help you compare the different software options in the marketplace; and we applaud Esri for their moves toward open source, and appreciate their candor in promoting a hybrid model.

ST_GeomFromGeoJSON

One of the things that makes PostGIS powerful and useful for web developers is that it can handle multiple input formats and multiple output formats. That means that a simple script binding a web service to the database can be a powerful processing and query tool. But, in order for those queries to work, the database has to speak the same language as the web service.

So, for output we have in addition to the OGC standard formats, ST_AsGML, ST_AsKML, ST_AsGeoJSON, and ST_AsSVG. And for input we have in addition to the OGC formats (WKB, WKT), ST_GeomFromGML and ST_GeomFromKML. But web developers don’t work in GML or KML, they work in JSON, and our favourite web developers, Vizzuality wanted to have a ST_GeomFromGeoJSON function, and backed up their desire with funding.

It turns out that most of the work had already been done, I just needed to clean up an existing patch and integrate with the build system a little more. Like the from-GML and from-KML functions, this iteration of the from-JSON function probably needs to be moved into a more central part of the code tree, but that’s a programmer-level clean-up that can wait. For now, thanks Vizzuality for supporting PostGIS and thanks Kashif Rasul for the patch!

To prove to yourself that it works:

select st_astext(st_geomfromgeojson(st_asgeojson('POLYGON((0 0,1 1,1 0,0 0))')));

To actually see the JSON:

select st_astext(st_geomfromgeojson('{"type":"Point","coordinates":[1,1]}'));

Celebrate PostGIS Day with Reduced Rates on the OpenGeo Suite

This year GIS Day fell on Wednesday, November 16. That means that today is PostGIS Day!

(Get it? Post-GIS Day!)

In honor of PostGIS Day and American Thanksgiving, we’d like to extend a special offer to those of you who are considering signing up for an OpenGeo Suite support contract. For a limited time, anyone who purchases our Basic, Professional, or Platform packages of the OpenGeo Suite Enterprise Edition will receive a 10% discount. But wait, it gets even better! For even more savings buy a two year contract and we’ll increase the discount to 20% off! This is one sale where you won’t have to fight any lines at the mall! (If you want to get up before dawn, that’s okay; we’re pretty excited too.)

If you have considered purchasing the OpenGeo Suite, now is the time. As always, you’ll receive full technical support, priority bug-fixes, and help further the mission of building the best open source geospatial software.

At OpenGeo we have a lot to be thankful for: we’re working with the best open source communities around, our clients and friends are doing amazing things with our support, and our team is comprised of some ridiculously talented people. In this season of appreciation and reflection, we want to pass our good fortune on to you.

So while you’re celebrating PostGIS Day, contact us to take advantage of this great deal on the OpenGeo Suite. This special offer is only available from PostGIS Day through Monday, November 28.

How will you be celebrating PostGIS Day? Let us know!

Open Source Panel at GEOINT

Last month, a few of us at OpenGeo attended the GEOINT Symposium in San Antonio where, for the first time, open source received some serious attention. There were two panels on open source technologies and multiple keynote addresses highlighting the benefits of open source and the need to reduce software licensing costs.

Our COO, Eddie Pickle, sat on a panel moderated by John Scott, Co-Chairman of RadiantBlue and Dr. Christopher Tucker, USGIF Board Member. He used the opportunity to offer his thoughts on open source geospatial technologies and discuss open source adoption. Eddie highlighted the TsuDAT project as an example of a collaborative, open source GeoNode application. Zoom ahead to 38:00 minutes in the video below to see Eddie discuss OpenGeo’s experiences developing, deploying, and supporting open source solutions.

The video also offers some interesting perspectives from other panelists who discussed their experiences implementing and using open source technologies. Questions start at 58:00 minutes, enjoy.

OpenLayers 2.11 Released

Congratulations to the OpenLayers development team on the release of OpenLayers 2.11!

This release is a big one, closing over 380 outstanding tickets and providing significant performance improvements. The biggest win is the mobile support enhancements. OpenLayers now allows features to be dragged and zoomed with touch gestures on mobile devices. Handlers for pinching and zooming have also been added to the library.

Other key highlights are the plethora of performance enhancements and the additional support for accessing Bing Maps tiles. The release notes go into detail about all of the new features and you can see them in action on the OpenLayers demo site—to really get a feel for the improvements open the demo in a mobile browser.

OpenGeo is committed to the OpenLayers project and we’re eager to support it however we can. A good deal of the development was done by OpenGeo team members Tim Schuab, Andreas Hocevar and Bart van den Eijnden in February as a part of the code sprint hosted by Camptocamp and Swisstopo. That week in Switzerland proved to be a critical step forward in pushing mobile enhancements and the 2.11 release to completion. A full recap of the sprint is accesible from Tim’s post on the OpenLayers blog.

Thanks again to the OpenLayers team, the supporters of the code sprint and everyone who has contributed to this new release!

Indexed Nearest Neighbour Search in PostGIS

An always popular question on the PostGIS users mailing list has been “how do I find the N nearest things to this point?”.

To date, the answer has generally been quite convoluted, since PostGIS supports bounding box index searches, and in order to get the N nearest things you need a box large enough to capture at least N things. Which means you need to know how big to make your search box, which is not possible in general.

PostgreSQL has the ability to return ordered information where an index exists, but the ability has been restricted to B-Tree indexes until recently. Thanks to one of our clients, we were able to directly fund PostgreSQL developers Oleg Bartunov and Teodor Sigaev in adding the ability to return sorted results from a GiST index. And since PostGIS indexes use GiST, that means that now we can also return sorted results from our indexes.

Which is a very long way of saying that PostGIS (the development code in the source repository) now has the ability to do index-assisted nearest neighbour searching.

This feature (the PostGIS side of it) was funded by Vizzuality, and hopefully it comes in useful in their CartoDB work.

You will need PostgreSQL 9.1 and the PostGIS source code from the repository, but this is what a nearest neighbour search looks like:

SELECT name, gid
FROM geonames
ORDER BY geom <-> st_setsrid(st_makepoint(-90,40),4326)
LIMIT 10;

Note the magic <-> operator in the ORDER BY clause. This is where the magic occurs. The <-> is a “distance” operator, but it only makes use of the index when it appears in the ORDER BY clause. Between putting the operator in the ORDER BY and using a LIMIT to truncate the result set, we can very very quickly (less than 10ms on a 2M record table, in this case) get the 10 nearest points to our test point.

“It can’t possibly be this easy!!” You’re right. It can’t. Because it is traversing the index, which is made of bounding boxes, the distance operator only works with bounding boxes. For point data, the bounding boxes are equivalent to the points, so the answers are exact. But for any other geometry types (lines, polygons, etc) the results are approximate.

There are actually two different approximations available for you to chose from.

  • Using the <-> operator, you get the nearest neighbour using the centers of the bounding boxes to calculate the inter-object distances.
  • Using the <#> operator, you get the nearest neighbour using the bounding boxes themselves to calculate the inter-object distances.

In general, because the box calculations are approximations of calculations on the objects themselves, getting a more exact “nearest N objects” is going to require a two-phase query, where the first phase grabs a larger candidate set, and the second phase does an exact test (just like all the other index-assisted predicates). So, for example:

with index_query as (
  select
    st_distance(geom, 'SRID=3005;POINT(1011102 450541)') as distance,
    parcel_id, address
  from parcels
  order by geom <#> 'SRID=3005;POINT(1011102 450541)' limit 100
)
select * from index_query order by distance limit 10;

The indexed query pulls the 100 nearest objects by box distance, and the second query pulls the 10 actual closest from that set.