Next steps

[Chris Holmes]

Ok, so I think we're pretty close to done with an initial pass of formatting. Thanks Jason, Tim and Scott for all jumping in and showing some collaboration on it, getting in pull requests. I think it's a nice demonstration of the tools.

So I think we're pretty close to all the initial formatting. I've made a milestone for this, see https://github.com/cholmes/gpkg-tiles/issues?milestone=1

For general strategy I think once we get that milestone we'll mark it as 'done', and then start refactoring.

I want to get to a core spec that is super tight, no extraneous sql statements, notes or requirements. And just tiles, not raster.

So I think we can dump all the sql blocks in to an annex, that we'll perhaps evolve in to a 'safe geopackage'.

Notes maybe we can put at the end of the document, and do internal links to them?

And the requirements / conformance class stuff makes sense to me in another annex.

Thinking we can just do each annex as a separate document in the same repo.

I'm going to go through and make issues and milestones for everything. I'll leave issues unassigned, and if you are going to work on it right then assign it to yourself. Try to just do it if you are actively working, so there are open tasks for anyone who has a bit of time.

But yeah, let's still not do any real content changes, just get it to a core spec that can be discussed.

[Jason Poffenberger]

Chris,

Just a heads up... I was going to do the sql later today. Currently I'm in the middle of coding some Android stuff and will lay that aside this afternoon.

Jason

---

From: Chris Holmes <cho...@opengeo.org>
To: gpkg-til...@googlegroups.com; Jason Poffenberger <jpo...@yahoo.com>; Benjamin T Tuttle NGA-IIG USA CIV <Benjamin...@nga.mil>
Sent: Thursday, April 11, 2013 10:50 AM
Subject: Next steps

[Scott Clark]

>
> Notes maybe we can put at the end of the document, and do internal
> links to them?
>
> And the requirements / conformance class stuff makes sense to me in
> another annex.
>
> Thinking we can just do each annex as a separate document in the same
> repo.
>

Writing this up, I was wondering how to link to elements within the doc
(using the markup). There are a lot of cross-references (to some table
or some clause) and it would be ideal that those are all hyperlinked.
Being new to markup, I couldn't find a way to tag those elements for
cross-reference.

Scott

[Chris Holmes]

I haven't played with it yet or got it working, but see https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#wiki-links

[Chris Holmes]

Awesome. Just claim that task when you start. Do it on a branch. I'll try to get section 10.7 in right now so then can take the sql out of that too.

[Chris Holmes]

Just made an issue for this: https://github.com/cholmes/gpkg-tiles/issues/10

Would be good to get for the first milestone. Scott, assign to yourself if you're going to tackle it soon, though I may have a go at it pretty soon. Will assign to myself if I do.

On Thu, Apr 11, 2013 at 10:56 AM, Scott Clark <sct...@gmail.com> wrote:

[Chris Holmes]

Hrm, yeah, that doesn't actually get us what I was hoping for. It's just to put the link references at the bottom of the page...

[Chris Holmes]

Ok, so I think the best we can do is to use headings. If you use like heading 5 or 6 it can be pretty small. So we could like turn all the table header text in to headings, and then we'd be able to link to them internally. Linking internally is easy, you just do (#internal-id) for the link.

[Chris Holmes]

Ok, just put out 0.1.0. 

https://github.com/cholmes/gpkg-tiles/tree/v0.1.0

Now we can start rearranging much more. 

I'm going to make branches for 'sql reorg' and 'requirements reorg'. I think that if I create the branches on the command line then everyone should be able to edit directly online on the branch. Just have to switch to the branch in the dropdown. Let me know if that doesn't work. 

Plan should be to put both all the sql statements and then all the requirement statements in side documents.

[Jason Poffenberger]

I can go ahead and put in the sql statements on the branch right now. I'll try directly on your branch. If anyone else is doing it, please stop me.

---

From: Chris Holmes <cho...@opengeo.org>

To: Scott Clark <sct...@gmail.com>
Cc: "gpkg-til...@googlegroups.com" <gpkg-til...@googlegroups.com>; Jason Poffenberger <jpo...@yahoo.com>; Benjamin T Tuttle NGA-IIG USA CIV <Benjamin...@nga.mil>
Sent: Thursday, April 11, 2013 5:56 PM
Subject: Re: Next steps

[Chris Holmes]

Cool, yeah, I just assigned a ticket to you. And on that branch there should be a safe-gpkg.md file, where you can dump all the sql.

Thanks!

[Jason Poffenberger]

OK. Got the first revision done. I would suggest that the triggers sections get removed and some general rules defined instead. For example a statement such as

CREATE TRIGGER 'raster_columns_r_raster_column_insert' 

BEFORE INSERT ON 'raster_columns'

FOR EACH ROW BEGIN

SELECT RAISE(ROLLBACK,'insert on raster_columns violates constraint: r_raster_column value must not contain a single quote')

WHERE NEW.r_raster_column LIKE ('%''%');

SELECT RAISE(ROLLBACK,'insert on raster_columns violates constraint: r_raster_column value must not contain a double quote')

WHERE NEW.r_raster_column LIKE ('%"%');

SELECT RAISE(ROLLBACK,'insert on raster_columns violates constraint: r_raster_column value must be lower case')

WHERE NEW.r_raster_column <> lower(NEW.r_raster_column);

END

Could become a note such as

r_raster column should be in all lower case without single or double quotes

Also, I would make the create statements more generic such as

CREATE TABLE raster_columns (

r_table_name TEXT NOT NULL,

r_raster_column TEXT NOT NULL,

compr_qual_factor INTEGER NOT NULL DEFAULT -1,

georectification INTEGER NOT NULL DEFAULT -1,

srid INTEGER NOT NULL DEFAULT 0,

CONSTRAINT pk_rc PRIMARY KEY (r_table_name, r_raster_column)

ON CONFLICT ROLLBACK,

CONSTRAINT fk_rc_r_srid FOREIGN KEY (srid)

REFERENCES spatial_ref_sys(srid),

CONSTRAINT fk_rc_r_gc FOREIGN KEY (r_table_name) REFERENCES geopackage_contents(table_name))

Could become

CREATE TABLE raster_columns (

table_name TEXT NOT NULL,

raster_column TEXT NOT NULL,

compression_quality INTEGER NOT NULL DEFAULT -1,

georectification INTEGER NOT NULL DEFAULT -1,

spatial_reference_identifier INTEGER NOT NULL DEFAULT 0,

)

and make a note that spatial_reference_identifier is a foreign key. As a matter of fact, the whole raster_column table should go out the door. It should look more like the MBTiles table with maybe georectification, spatial_reference_identifier, and possibly compression_quality but I don't know why compression_quality would matter. Anyway, I would rework almost the whole sql spec to be more MBTiles like.

Jason

---

From: Chris Holmes <cho...@opengeo.org>

To: Jason Poffenberger <jpo...@yahoo.com>
Cc: Scott Clark <sct...@gmail.com>; "gpkg-til...@googlegroups.com" <gpkg-til...@googlegroups.com>; Benjamin T Tuttle NGA-IIG USA CIV <Benjamin...@nga.mil>
Sent: Thursday, April 11, 2013 6:37 PM
Subject: Re: Next steps

[Chris Holmes]

On Thu, Apr 11, 2013 at 7:20 PM, Jason Poffenberger <jpo...@yahoo.com> wrote:

OK. Got the first revision done.

Awesome. Did you push to github? I couldn't find it, let me know when you do and I can check it out directly. More responses inline.

 

I would suggest that the triggers sections get removed and some general rules defined instead. For example a statement such as

CREATE TRIGGER 'raster_columns_r_raster_column_insert' 

BEFORE INSERT ON 'raster_columns'

FOR EACH ROW BEGIN

SELECT RAISE(ROLLBACK,'insert on raster_columns violates constraint: r_raster_column value must not contain a single quote')

WHERE NEW.r_raster_column LIKE ('%''%');

SELECT RAISE(ROLLBACK,'insert on raster_columns violates constraint: r_raster_column value must not contain a double quote')

WHERE NEW.r_raster_column LIKE ('%"%');

SELECT RAISE(ROLLBACK,'insert on raster_columns violates constraint: r_raster_column value must be lower case')

WHERE NEW.r_raster_column <> lower(NEW.r_raster_column);

END

Could become a note such as

r_raster column should be in all lower case without single or double quotes

I'm not sure that we even need that note? But yeah, I guess if we want to put something in there that could make sense. But I feel like we could just assume people know how to create a proper column, and follow the cases we write in the spec.

 

Also, I would make the create statements more generic such as

CREATE TABLE raster_columns (

r_table_name TEXT NOT NULL,

r_raster_column TEXT NOT NULL,

compr_qual_factor INTEGER NOT NULL DEFAULT -1,

georectification INTEGER NOT NULL DEFAULT -1,

srid INTEGER NOT NULL DEFAULT 0,

CONSTRAINT pk_rc PRIMARY KEY (r_table_name, r_raster_column)

ON CONFLICT ROLLBACK,

CONSTRAINT fk_rc_r_srid FOREIGN KEY (srid)

REFERENCES spatial_ref_sys(srid),

CONSTRAINT fk_rc_r_gc FOREIGN KEY (r_table_name) REFERENCES geopackage_contents(table_name))

Could become

CREATE TABLE raster_columns (

table_name TEXT NOT NULL,

raster_column TEXT NOT NULL,

compression_quality INTEGER NOT NULL DEFAULT -1,

georectification INTEGER NOT NULL DEFAULT -1,

spatial_reference_identifier INTEGER NOT NULL DEFAULT 0,

)

and make a note that spatial_reference_identifier is a foreign key.

Makes sense. But yeah, I feel like if we're not defining the constraints in the main spec then there's no reason to define the create statement at all. People should be able to make it. But we can put the whole thing in the gpkg-safe side spec, for people who want to define tables with proper constraints.

 

As a matter of fact, the whole raster_column table should go out the door. It should look more like the MBTiles table with maybe georectification, spatial_reference_identifier, and possibly compression_quality but I don't know why compression_quality would matter. Anyway, I would rework almost the whole sql spec to be more MBTiles like.

Definitely. But let's hold off on that until we get the first few milestones I laid out. First just factor out all the extraneous pieces (sql statements, requirements, weird notes on implementation) to side specs. So we have at least an mbtiles style spec. And then we can start doing pull requests on real changes, that we can track. 

Though I guess if you want to try it early, before the formatting changes, you could make a branch just for the full changes and PR that. May get out of date though.

But yeah, I agree on getting it down to super similar to MBTiles. But first want to show how even their sort of weird existing spec could become a whole lot more readable.