Serving-up GeoJSON while having a REST on the GeoCouch

Wow, it's been a while.  Between having my tonsils removed (which is not pleasant as an adult), to finishing up with my employer of 11 years and starting a new job, things have been rather hectic over the last few months, but I have found time to put together my third post on my GeoJSON adventure that I have been dabbling with for the last 6 months or so.


I set out on this GeoJSON journey to investigate the definition as a spatial format specification, and to see what I could get for free in terms of interoperability, and I have been pleasantly surprised by the number of applications that support the format.


In my first post on Tile5 rendering GeoJSON I was interested mainly on the map rendering side of things and what I needed to do to massage my data into GeoJSON to take advantage of that rendering.


In my second post on Leaflet rendering GeoJSON passed from ExpressJS/NodeJS I delved more into the interoperability of GeoJSON between Leaflet on the client, and the javascript application server serving data from PostGIS, which was able to return query results in GeoJSON format.


In this third post I have taken the next step, storing my GeoJSON data in a NoSql database - CouchDB, and exposing it directly from the database to the client.

Nought to PostGIS in 6.3 seconds…almost

In a recent post I decided to investigate some technologies that were new to me, such as leaflet, node.js and express, but in addition to these I had never interacted with PostgreSQL/PostGIS before either, so setting up PostGIS was part of my learning exercise.  Being a noob when it came to PostgreSQL and PostGIS, and fairly inexperienced in linux generally, I was able to find the information I needed to get going, but I thought I would pool it together in one location so others can see what I had to do to get my spatial database and queries working in PostGIS, for any other new comers to PostGIS to learn from as well.

Node.js + Express + Leaflet + PostGIS = Awesome Maps

Recently I blogged about using GeoJSON to create a very lean application for serving dynamic maps.  To date, all of my posts have related in some way to Microsoft technologies because that is my environment, day-in, day-out, but I thought it would be interesting to create a similar solution to the last blog post using technologies I haven't used before - why? - because it's good to learn something new, and these libraries are really cool!

Simple Maps Using GeoJSON and Tile5

I've been wanting to post about GeoJSON for a while now because I like what the standard provides in terms of simplifiying interoperability.  The thing is, GeoJSON is just a standard structure for geometry and features represented in JSON, so there isn't much for me to talk about in regard to GeoJSON itself.  So what I decided to do is see how I could utilise GeoJSON to create a very simple mapping application by simplifying communication between tiers, and highlight how JavaScript mapping libraries such as Tile5 can help you achieve your vision of simplicity.

Persisted Spatial Calculation Columns

This blog post discusses how I computed the area values of the features in my spatial tables to improve query/reporting performance during my investigation of SQL Server spatial indexes.

SQL Server Invalid Geometry

While recently investigating SQL Server spatial indexes I encountered an issue regarding invalid geometry in some of the features in my source shape files, so I thought I would do a quick blog post on what this means, and how to detect and resolve these issues in SQL Server.

Datum Transformations

In my last post on SQL Server Spatial Datums I discussed the SRID setting, and what it relates to in terms of standard mapping datums, but I mentioned that SQL Server is not a GIS and does not have a facility to perform coordinate transformations between datums, so it is important to execute spatial operations on data sets that relate to the same datum.

In this post I will discuss transforming data sets from one datum to another, and focus more specifically on the change of the Australian datum from the Australian Geodetic Datum (AGD) to the Geocentric Datum of Australia (GDA).

SQL Server Spatial Datums

As part of my investigation of spatial indexes in SQL Server, I performed some analysis on some spatial data sets, so during the import of my spatial data I had to consider the datum for my data, so I thought I would devote this blog post to a dicussion about datums and spatial reference systems in SQL Server.

Spatial Index Tuning Scripts

I have posted some of the scripts I used when performing the analysis for my previous post on Spatial Index Tuning in SQL Server

The Black Art Of Spatial Index Tuning In SQL Server

For my inaugural blog post I have decided to discuss some investigations I have been making recently into tuning spatial indexes in SQL Server.

I have found that while there is a lot of information on teh interwebs about the theory of SQL Server spatial indexes, and the utilities that can be used to tune them, there is very little guidance on what spatial index settings are best suited for different data scenarios, and there is only limited information about the characteristics to consider when tuning these indexes.

As an attempt to provide some guidance I have investigated configuring and tuning spatial indexes on three different spatial data sets which I have discussed as case studies, but before jumping straight into these I think it would be wise to discuss some background aspects to spatial indexing in SQL Server.