My comments on the OGC Geopackage Spec

PART A

1. Evaluator:

   Darrell Fuhriman

2. Submission: 

   OGC 12-128r1

   OpenGIS® GeoPackage Implementation Specification

PART B

1. Requirement: Core, #13

2. Implementation Specification Section number: 8.2

3. Criticality: Minor

4. Comments/justifications for changes:

The geopackage_contents table includes four columns used for the bounding box,

but does not specify the units to be used, only the defaults. The spec should

be updated to specifically list the units.

Points for clarification:

1) are the values to always be in lat/long?

 1a) If so, what datum? (Yes, I realized these values are not meant to be

     exact, but it doesn't hurt be clear)

2) are the values to be in the SRID specified in the same row?

If the values are to be specified always in lat/long, then recommend renaming

columns to reflect this:

min_x -> min_long

max_x -> max_long

min_y -> min_lat

max_y -> max_lat

=======================================================================

1. Requirement: N/A

2. Implementation Specification Section number: N/A

3. Criticality: Major

4. Comments/justifications for changes:

I believe there should be an optional extension that allows for the inclusion

of user-defined styling information.

While, I do not believe that the Geopackage format should mandate a specific

styling language, such as SLD or CartoCSS, I do think there should be a standard

location where an application can look for such data. 

The implementation should be highly generic, the intention is to allow

standards to evolve and gain experience before codifying anything, but still

having a single "go to table" for finding styling suggestions.

As an intro suggestion, I imagine there being a table, say "geopackage_styles"

consisting of four columns:

table_name  text NOT NULL

style_name  text NOT NULL

style_version text

style_data text NOT NULL

The primary key would be a composite key consisting of "table_name,

style_name", thus allowing for one table to have multiple styles associated

with in different styling languages.

For example, a table might contain:

| my_table | cartoCSS | NULL  | "some carto css"      |

| my_table | SLD      | 1.1.0 | "<BIG string of XML/>"|

Any styling information included must apply to the named table/view, and only

that table/view. Including styling suggestions for a table/view is purely

optional, and the "geopackage_styles" table need not exist at all.

=======================================================================

1. Requirement: N/A

2. Implementation Specification Section number:9.6

3. Criticality: Major

4. Comments/justifications for changes:

I am concerned that the reference implementation SpatialLite, essentially

mandates the inclusion of the GEOS library. While I have nothing against the

GEOS library, quite the opposite, this presents real problems for people who 

must statically link the libraries, something that is expressly forbidden by

the GEOS Library License (LGPL).

For reference, see: http://blog.burhum.com/post/38236943467/your-lgpl-license-is-completely-destroying-ios-adoption

I strongly encourage the OGC to create a minimal reference implementation,

contains *only* the core requirements, and makes use only of libraries which

can be statically linked.

A few things I've been working on

As an update, because you need one once in a while, here are few things I've been up to and/or working on. These are all available on github.

1. Two gems that work together to add support for PostgreSQL/PostGIS tables as task targets. I also spoke about them at the State of the Map US. There is supposedly video of said presentation online, but I'll be damned if I can find it.
2. A quick-and-dirty importer script for Census ACS data. 
3. A series of vector renderings of the bridges of Portland, OR. 

Let me know if you find any of these useful.

Faster Voronoi Diagrams in PostGIS

A couple years back, I posted a quick and dirty function for generating voronoi diagrams in PostGIS. As one of the commenters pointed out, this is not the world's most efficient algorithm. So I started looking into implementing a better one myself, but once again, being a virtuous programmer, I borrowed someone else's code, and modified it to work with PostGIS.

This one's in Python, not PL/pgSQL, so plan appropriately.  It is called similarly to my previous version:

select * from voronoi('table_name', 'geom_column') as (id integer, the_geom geometry);

You no longer need to specify an id column, but the downside is that there's no longer a relationship between the id of the input point, and the id of the output polygon. On the other hand, it's much, much, much more efficient. At least a couple orders of magnitude. In testing, my 40,000 points of input only took 20 seconds to calculate, whereas previously it took... well, I don't know, because I didn't want to wait that long.

Code is here: http://db.tt/xen7XHwC  No guarantees it actually does anything correctly, but my limited testing seems to work. Enjoy.

UPDATE: the code linked above only works with Python 2.x. If you look through the comments, you'll see there's a link to a version of my code for 3.x, but it still has a couple of bugs which I have not had time to investigate.

UPDATE 2: See the comments below about the QGIS code also producing incorrect output with this function. I'll try to investigate in my copious free time.

UPDATE 3: Matthias has published a version that corrects the problems in my initial code. His dropbox link is here: http://db.tt/gwEGpu0Y.  I've also published it as GIST, here: https://gist.github.com/darrell/6056046

This is such great news, it deserves a post of its own. The Sextante Blog has released a video showing Sextante integration with ArcGIS. While I haven't seen the full list of tools, I've every reason to think it will include all the Sextante tools, which would for many people obviate the need for an ArcInfo ArcGIS for Desktop Advanced license, as well as Spatial Analyst, Geostatistical Analyst, and maybe others...

Tremendous news, indeed.

Ten years is both a long time, and a short time...

My friend Brandon, the Mercatorial Librarian[1]  has a post up reminding me that it's been ten years since we went to Nigeria to install computer labs and do training for professors in the Library Science department at Bayero University Kano in Kano, Nigeria.

It was that event which led me to Child Aid and doing similar work at Probigua in Antigua, Guatemala in 2005. All of which ultimately led to my Master's Thesis research on the political ecology of donated computers and e-waste in Accra, Ghana[2]. One of these days I'll really get that research published (I keep telling myself).

Anyway, it just reminds me that when I'm geeking out on this blog, or teaching about spatial databases (this fall at Portland State, GEOG 4/575, come on over), where my true passion lies.


[1] I assume this is a reference to Mercator, so how can I not like it?
[2] How many Geographers actually get scooped by National Geographic? Well, this one does. Turns out I was there at the same time as the NG guys, though they published first, obviously.