[Live-demo] Postgis 2.0 - legacy.sql

[Alex Mandel]

On 01/25/2013 11:03 PM, Hamish wrote:
> 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,
> Hamis


Simple clarification: Can legacy.sql be installed into an existing
postgis 2.0 database without any negative effect?

If yes, then we should probably do it to avoid breaking Kosmo and
GPSdrive. Of course it should be noted this is a short time fix, long
term yes people will need to upgrade as we don't know how long
legacy.sql will exist. I'll note in my research there is also a
legacy_minimal which may or may not have what's needed.

Thanks,
Alex