[Live-demo] Postgis 2.0 - legacy.sql

[Hamish]

Hi all,

Sergio wrote:
> From Kosmo part, it would be ok to change to postgis
> 2.0 if legacy.sql is loaded into at least the natural_earth2
> database, that form part of the quickstart guide. But i
> think that if you load it into the postgis template database
> before creating the others spatial databases it could be
> better.
>
> I think that the ticket #1059 from the tracker [1]
> could be also solved loading the legacy.sql, as the
> offending sql function that it's not found is restored with
> the legacy.sql.

Brian wrote:
>   we have already passed to Beta 1, so it is too late
> to make changes like this.

No it isn't, if it makes things on-the-whole less broken than
they were before. That is the most important question to ask
and standard to live by. Broken but happy to have strictly
stuck to protocol is no place to be.

It would be useful if those in the know could explain more
about legacy.sql, and if it risks anything other than bloat
in the database. (I'm not an expert here)


> In general, all other apps have ported to PostGIS 2.0,

as noted with #1059, this has broken gpsdrive too, it's not
just Kosmo. If loading legacy.sql is a known good solution,
for my 2c I say do not hesitate one minute, go with it so we
can do a final test. (and actually do a really serious test
on it, not just 1 or 2 people as usual)

For the record, Gpsdrive makes use of PostGIS for the OSM
dataset, but not the natural earth(2) one, for Nat Earth it
uses the shapefiles instead. I am happy to make changes to
port whatever needs to be ported to the 2.0 API but I do need
help with that since I am unfamiliar with what is needed.


> which was released in April 2012.

release date or how many amazing new features it has doesn't
mean very much from a packaging and integration perspective.
when it made the transition into Debian/testing and so on to
Ubuntu's repositories and so the .deb-family stack properly and
fully rebuilt upon it is what is vitally important.
very little else matters [speaking from a packaging perspective].

as it is it PostGIS 2 hasn't even made it into Debian/unstable
or debian/experimental yet (I suspect mainly due to the current
release freeze for wheezy). So we are very much in experimental
territory here, and we must take some pain to support those not
on the bleeding edge. i.e. the proponents of PostGIS 2 must help
the dev teams fix what needs to be fixed/less debate more action.


> PostGIS 2.0 is a major, and much improved update to PostGIS,

You don't have to sell us on PostGIS 2.0, we're using it now
and it is too late to change. It doesn't matter how great it
is, what matters is the maturity of the packaging. If using
legacy.sql helps us and is low risk, I'm all for it. I'd much
rather that than have to push out a new package of gpsdrive
which has had no testing.


> and has had extensive testing.

again, it's all about the testing of the packaging toolchain,
not the base software (which needs to be there as well as a
prerequisite of course, and if it is great makes the rest easy,
but the story doesn't end there)


> I see no benefit in using legacy.sql generally, and

well, does it magically fix kosmo and gpsdrive? (and maybe
other things too?)

> definitely not in the standard data set for the disk.

why not? (that's a curiosity question not a rhetorical one)


my vote, conditional to more info on how risky legacy.sql could
be*, is to go with legacy.sql as a less risky option to cutting
new packages of kosmo and gpsdrive.

[*] my past experience is that these sql loads just add bloat to
the DB and are ignored by the newer stuff, and so are intrinsicly
safe.


> I am certain that Kosmo can improve itself, and become
> current, with some effort.

please (all) help with that effort. I'm on IRC now and will
be for the next hours if someone can give some pointers I'm
all eager ears and typing fingers.



thanks,
Hamish