Modifying layers / in-memory layers
Bernhard Reiter
bernhard at intevation.de
Wed Jul 2 12:59:34 CEST 2008
Hi Anthony,
On Monday 30 June 2008 18:21, Anthony Lenton wrote:
> I have been thinking that a very neat feature for thuban would be to
> allow you to modify a layer's shapes and info some how. For that a
> previous step would be to have some sort of in-memory layers, to not
> have to rewrite and reload a whole shapefile each time you modify
> anything.
I agree that this would be nice to have.
It goes beyond the "interactive viewer" idea, but I consider this fine.
While the original idea of Thuban was to first be a tool to very nicely do
interactive data exploration and leave the "hard" GIS tasks to real GIS
like GRASS, somehow this vision has become outdated. For once, developing
GRASS frontends (for Thuban and similiar) did not really happen and there
have been many other small goe-viewers that libraries that go into the
direction of being a GIS (while mostly not fully there, but that would not be
necessary in many cases anyway).
> I looked in to this while coding the importMP extension and
> I couldn't find in-memory shapestores. The SHPTree class needs to be
> initted from a shapefile. I guess posgis shapestores could be used,
> those are quite a bit faster than rewriting the whole shapefile, but
> depend on you having postgis up and running. There is an
> implementation of an in-memory table, MemoryTable, but it doesn't seem
> to be used anywhere, is this so?
I think the tests might use it.
> And then there are also TransientDatabase tables that use SQLite.
Yes, good for important query options.
> So,
> - What do you think of the whole
> allow-the-user-to-modify-shapes-and-info idea? Is it bound to fail?
It is a good idea that will work if done right.
Having the possiblity of a diff to a current data-layer that is read-only
would be cool.
> Is somebody working on this already?
There was a rough experimental extension to enable very simple line drawing,
which probably is not a blueprint nor a good example to build upon.
Somebody posted some changes for this a while ago: Barry. He stopped
responding (maybe because we were slow to react as well) so that code was
never taken up (nor copyright transfered).
> - What do you think of the in-memory stores idea? Is there an
> implementation I haven't seen? Is there a reason not to do this all
> together? Is a postgis store a better idea?
I believe in-memory is fine for a start. Most changes will be small.
There should be a "commit" function to make the change permanent
and possibly a "save-as" function to save to as many targets as we can which
would include postfix/gis as well, if possible.
> - How much work does shptree do, is it a in-memory store that only
> needs a shapefile to initialize from, or is it more of just a proxy to
> the shapefile?
Don't know without inspection.
> - Has anybody tried SpatiaLite? http://www.gaia-gis.it/spatialite/ I
> haven't, but it might come in handy as a middle point between keeping
> layers in memory and needing to set up a postgis database.
I have not tried it, my strong guess is that it was not available when Thuban
was designed. We were quite early in adoption sqlite.
Could be a good idea for transient data, as it is used for tables already.
> Comments? Ideas? Suggestions? Knights with rubber chickens?
:)
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20080702/01d6f1d6/attachment.bin
More information about the Thuban-devel
mailing list
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)