[GRASS-dev] better mysql support

[Emanuele Conti]

So, can anyone explain the meaning of the first two points in this feaure
list <http://grass.itc.it/grass60/index.php#features> of grass6, where there
is a direct and explicit mention to postgis?

2007/4/16, Paul Kelly <paul-grass at stjohnspoint.co.uk>:
>
> On Sun, 15 Apr 2007, Emanuele Conti wrote:
>
> > Hi everybody,
> > I'm a university student and I'm doing a thesis on the integration of
> grass
> > with mysql. I found that grass has a good support for postgis and I'd
> like
> > to duplicate all the main features available for this db for mysql,
> which
> > has geometry extensions (opengis compliant) and performs significantly
> > better than postgres. I downloaded grass 6.3 cvs source code yet and I
>
> As I understand it the OpenGIS vector format is a lot less featureful than
> the GRASS format (i.e. it doesn't store the topological relationships
> between vector features, which is important for a lot of vector analyses)
> and thus it is debateable whether it is useful to store GRASS data in that
> format. It would mean topology would have to be re-built from the external
> data any time an analysis is to be done in GRASS. My understanding is the
> OpenGIS format is more of a quick-access format useful for displaying
> data, but if it is to be edited, topological format is better for ensuring
> the integrity of the data (no overlapping boundaries and that kind of
> thing).
>
> As far as I can remember GRASS used to directly support storage of vector
> geometry in PostGIS in 5.7/6.0 pre-releases, but that was removed before
> the release of 6.0.0 final because there were problems with it. The
> PostGIS support was integrated by a group of final year project students I
> think - there may also have been a paper written about it. It would
> probably be a good idea to investigate this (e.g. download an old version
> of GRASS and try it out etc.) and investigate what the problems were and
> why it was dropped, and see if you can do better with your MySQL spatial
> support.
>
> Off the top of my head though, I think the shortcomings of the OpenGIS
> vector format for spatial analysis were a major factor. But you would need
> to read old mailing list posts from Radim Blazek for more insight.
>
> Paul
>
> > started to have a look to the code, but I've some questions:
> > - from the grass 6 features page I understood that with postGis it's no
> more
> > necessary to pass through gdal ogr translation: is this true? Is there a
> > direct db manipulation?
> > - what part of the code implements the direct "Export/Import to
> > *PostGIS"*(functions as
> > v.to.db and so on) and which directories and files should I look at?
> > - what documentation could help me and where could I find it (I googled
> for
> > technical docs oriented to grass/db integration, but I did't found much
> > material);
> > - is this a project that could become part of grass in any way? How
> could I
> > receive support and/or feedback when necessary?
> >
> > I hope to read of you soon. Thanks...
> >
> > --
> > Emanuele Conti
> > Senior Student at University ROMA TRE
> > Department of Informatics and Automation
> > ROME, Italy (matr. 251318)
> > Mob:       +39 328 2681070
> > Home:     +39 06 39741124
> > e-mail:     emanuele.conti at yahoo.com
> > y!:            emanuele_c
> > msn:        emanuele_c at yahoo.com
> >
>



-- 
Emanuele Conti
Senior Student at University ROMA TRE
Department of Informatics and Automation
ROME, Italy (matr. 251318)
Mob:       +39 328 2681070
Home:     +39 06 39741124
e-mail:     emanuele.conti at yahoo.com
y!:            emanuele_c
msn:        emanuele_c at yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20070416/f841c1f8/attachment.html