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.

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!

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.

If you have questions or interest in sponsoring the code sprint please contact us at inquiry@opengeo.org

The OpenGeo team is excited to announce the release of OpenGeo Suite 2.4.4. This is the first new version in a few months so there have been lots of stability improvements and updates.

GeoServer incorporates the new features from the recently released GeoServer 2.1.3. It now has Basic HTTP authentication for cascaded WMS servers, a feature that has been asked for by a number of our clients. GeoServer also has support for non-advertised layers, with layers configured and active, yet not publicized in the capabilities documents. For our European friends, we’ve made enhancements to the View Service for the GeoServer INSPIRE extension.

The GeoServer-embedded GeoWebCache now has a significantly improved UI, exposing many options previously only configurable via a text editor. It’s now possible to add a new layer, configure tile size, view disk quotas, enable GWC services and cache formats.

GeoExplorer has improved stability when deployed under Glassfish and WebSphere containers. Logout functionality has now been exposed, based on many user requests. In general, GeoExplorer now has a faster loading of JavaScript resources.

The OpenGeo Suite is and continues to be 100% open source and we’ve migrated the source code onto GitHub to improve our development process and make it easier for anyone to check out our source code.

We invite everyone to check out our new release—register for a trial of the Enterprise Edition or download the free (but unsupported) Community Edition. If you’re looking for support, unlimited bug fixes, access to core developers, updates, telephone support, and even custom development hours, we invite you to consider becoming an OpenGeo Suite Enterprise Edition client.

Thanks to everyone who submitted bug reports and feature requests. Thanks as well to all developers involved in our component projects. Finally, thanks to our current Enterprise Edition clients, who enable to us to continue to develop the best geospatial software.

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!

Welcome back to the newest edition of OpenGeo Connections. Today we’re excited to announce that Matt Priour has joined the OpenGeo team. Matt has a breadth of experience in both the open source and proprietary web mapping worlds with special expertise in the front-end components of the OpenGeo Suite. He has already made a big impact working on GeoNode projects, and his responsibilities have quickly expanded to work directly with more OpenGeo Suite components.

OpenGeo’s David Dubovsky (OG): Hello Matt, welcome to OpenGeo!
Matt Priour (MP):  Hi, I’m thrilled to be here.

(OG): Tell us a little bit about yourself.
(MP): I’m a happily married father of two young children, a trained wildlife biologist, and a web-centric geospatial software developer with a primary focus on client-side development. I’m also a native Texan and love living here. My wife is a veterinarian, and I used to volunteer as an emergency veterinary technician.

(OG): Great, and how did you decide to get involved in the geospatial field?
(MP): Well I’ve always loved maps, aerial photos, and working with computers. I seemed to drift toward geospatial-related interests while in college at Texas A&M University. Later on, I made heavy use of GIS/GPS in my field research for my master’s degree.

(OG): So you didn’t go to school specifically for web development or GIS?
(MP): No, not really. After utilizing GIS/GPS so much in school I had a really solid background. Inevitably I became the “GIS guy” at my first job after school. Eventually that lead to forming my own business for custom desktop GIS projects, extensions, and scripts, and finally to specializing in producing custom geospatial web apps for my clients.

(OG): And how long have you been at it now?
(MP): I’ve been working with geospatial in some form or another since 1999. I’ve been primarily focused on open-source geospatial technologies and web development since 2007.

(OG): During that time what projects do you look back on most fondly?
(MP): I’ve really enjoyed any project which has allowed me the opportunity to solve an interesting problem for a client. Two such projects come to mind:
First, ParkScore, which was a demonstration project for the California chapter of Trust for Public Land. ParkScore allowed users to enter their addresses and be presented with an interactive map and results tables showing them the distance to public parks, schools, fitness centers, and other “healthily living” opportunities. Data had to be retrieved and compiled from a variety of sources using documented and undocumented API’s and displayed on a map in a rapid, per formant manner. I also developed a YUI based mapping app interface through this project that I was able to re-use on several other projects.

(OG): That sounds pretty interesting, and the second?
(MP): The second was a train tracking and incident management app which consolidated 3 separate inoperable desktop programs into a single unified map-based interface using GeoServer, GeoExt, and OpenLayers. It presented the problem of how to display large amounts of rapidly changing data with dynamic client-side filtering and specialization using OGC methods. Several GeoServer-specific vendor parameters, filter functions, and some SLD magic made this into a much more manageable task.

(OG): Wow, so you got to work with OpenGeo Suite components. Is that how you became involved with OpenGeo?
(MP): I’ve been tracking OpenGeo’s growth since it was a part of “The Open Planning Project”. This organization has done so much to promote open-source geospatial technologies and helped position it as a real alternative to proprietary systems. I was very excited when an opportunity to provide some development services related to temporal mapping for the MapStory project presented itself this summer.

(OG): So what will you be doing here at OpenGeo?
(MP): Along with the MapStory project I’ll be providing support for clients implementing, customizing or extending portions of the OpenGeo Suite.

(OG): Before we wrap up is there any interesting facts you’d like to reveal to the world?
(MP): Hmm, I can think of a few. I can do a rather good Beaker (from the Muppets) impersonation, in fact I was able to convince my wife to continue going out with me after our first date with that impression. Also I know over 100 North American songbirds by sound alone.

(OG): Wow – I honestly couldn’t say which one is more impressive! Thanks for the time and welcome aboard, Matt!
(MP): Glad to join the team!

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.

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]}'));

OpenGeo is evaluating offering training sessions for GIS instructors at colleges and universities. If you are affiliated with an academic institution, please answer the following questions so we can gauge interest. This form is intended to be filled out by GIS users and instructors in academica. If you would like to find out more or discuss your specific needs please contact us.