[Gvsig_english] [SoC] Weekly Report for Week 8. gvSIG.

[Benjamin Ducke]

(forwarding this to the general mailing list, as it may be
of interests to others, as well)

Hi Luca,

3D topology is a lot more complex than 2D (and 4D is for math
geniuses only). No GIS has so far implemented full 3D topology.
Most completely ignore it and pretend that 3D is the same as
2D.

It is up to the user to understand the 3D limits of current
GIS data models and I don't think we will be able to change
that situation in the course of this GSoC project.

So I suggest you don't worry too much about it. Just do as all 
the others do and simply treat the features as 2D as far as the
JTS is concerned. Just make sure that when reading coordinates 
and writing them back to the SQLite DB you don't lose the
extra dimension(s). Because unlike some other GIS, gvSIG is capable
of preserving > 2D geometries. You just can't run any analysis
on them. But a 3D extension is in development. And it is possible 
to e.g. export them to a 3D shapefile and then import them into a 
3D viewer or perform analysis on them in GRASS GIS.

Best,

Ben


----- Original Message -----
> Hi Ben,
> 
> I've done some tests about JTS (the java topologic API, as you very
> probably know) support of 3d/4d geometries and it looks like it's not
> supporting it directly.
> 
> It's not a problem implmenting the support we need, it just takes some
> time of course (not too much to be honest), both for WKB and
> SpatiaLite, anyway before loosing too much time it's much better I ask
> you some suggestion to fit the implementation firstly on our needs and
> organize better my time.
> 
> In your opinion what kind of support we need into gvSIG ? The question
> is probably very trivial for you but I'm not very aware about some
> basic gis aspects and this is one of those I know less: I've read
> around forums and so on that there are not a lot of gis using 3d/4d
> data. I've also read that even OGC specifications of 3d/4d geometries
> are not such precise as far as each "gis group" has more or less
> implementd them in their own way. What features do we need ?
> 
> Thanks for the help,
> Ciao, Lu
> 
> 
> 
> 2010/7/12 luca bianconi < lc.bianconi at googlemail.com >
> 
> 
> Hi dear Ben,
> 
> yes, I hope everyhing goes on as it's gone till now without any very
> big problem!
> I'm quite happy frankly, even if there are some important things to
> fix yet, like adding transactions and add the 3D/4D geometries
> support, you've spoken to me the past week.
> 
> 
> 
> Remember: we absolutely have to fill in the mid-term reports this
> week, so that you will get your payment. I will start writing mine
> today, but as far as I understand, you also have to hand in a report,
> so don't forget to do that, or they won't pay you!
> 
> Yes, thanks. I fill it today as well. I don't want to send it lately,
> as far as there's something not very clear to me, I'd ask you
> suggestion about it.
> 
> Thanks for the help,
> Say hello to Paulina,
> Lu
> 
> 
> 
> 2010/7/12 Benjamin Ducke < benjamin.ducke at oxfordarch.co.uk >
> 
> 
> 
> 
> 
> Hi Luca,
> 
> this sounds really great.
> I have just finished the final release of gvSIG OADE 2010 and will
> announce it on July 15th. So now there will be more time for me
> to assist you with this.
> 
> Remember: we absolutely have to fill in the mid-term reports this
> week, so that you will get your payment. I will start writing mine
> today, but as far as I understand, you also have to hand in a report,
> so don't forget to do that, or they won't pay you!
> 
> Cheers,
> 
> Ben
> 
> 
> 
> 
> ----- Original Message -----
> > Hi all,
> >
> >
> > I describe shortly the activities of this week aimed mostly to a
> > generic code review, both on the logical and on the coding sides,
> > and source code reformatting according to gvSIG standards as
> > described into the specifications [1].
> >
> > I've finished the general reformatting of the code, commenting the
> > existing ones and adding test cases, improving a little bit the
> > testing part of the library.
> >
> >
> > What have I done:
> >
> > * reformatted the code completely
> > * reformatted comments completely
> > * adding logging system (with SLF4J) according to gvSIG
> > specifications * adding testcases for other classes
> > * not implement yet reading/writing capabilities of 3D geometries
> > from/to SpatiaLite Blob:
> > discussed longely about it with A. Furieri (developer of SpatiaLite)
> > from whom I've received important explications and suggestions on
> > how to implment evetually the 3D/4D geometry support
> > * fixed some bugs
> >
> >
> > What I plan to do next week:
> >
> > * implement the proper extension for gvSIG using the small library
> > created during the past weeks
> >
> > If there's time already this week :
> > * implment of reading/writing capabilities of 3D geometries from/to
> > SpatiaLite Blob and WKB
> > * adding transactions for securing the SQL operations
> >
> > I postpone the implementation of reading/writing capabilities of
> > 3D/4D geometries from/to SpatiaLite Blob and WKB because the bug fix
> > to the
> > gvSIG plugin Wizard has been done during the past week so I could
> > integrate now the library for enabling SQLite/SpatiaLite support
> > within gvSig already this week, if nothing goes wrong. That would
> > mean that the whole job would be completed and integrated with the
> > software and I would have a marvellous month more to improve, add
> > capabilities and features, do lots of debugging, create tests and to
> > any other
> > stuffs my mentors think useful.
> >
> > Problems:
> >
> > * No real problem, just need to loose some time for fixing the
> > "3D/4D problems" with JTS(java library used here for WKB/WKT) and
> > SpatiaLite Blob. Probably I will be obliged to implement all these
> > functions outside JTS.
> >
> >
> > Cheers,
> > Luca
> >
> >
> > [1]
> > https://gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/coding-development-guidelines/coding-conventions
> >
> > _______________________________________________ SoC mailing list
> > SoC at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/soc
> 
> 
> ------ Files attached to this email may be in ISO 26300 format (OASIS
> Open Document Format). If you have difficulty opening them, please
> visit http://iso26300.info for more information.


------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.