This project has moved and is read-only. For the latest updates, please go here.

Unit Tests

Aug 24, 2006 at 7:51 PM
Hey Morten -

I'd like to start doing some development (turns out my employer wants some features added, so I'd like to add write capability to the Shapefile provider), but fret that changes will break stuff.

Are there any unit tests or should I go ahead an write some?
Aug 24, 2006 at 9:38 PM
There are around 50 units tests, but the providers aren't the best covered by these tests.
Aug 24, 2006 at 9:49 PM
I am using the TFS client to get the latest code, but I can't see any unit tests... what am I missing?
Aug 24, 2006 at 9:52 PM
Hrm - nm. Did another update and they showed up.

Not especially the best first experience with TFS.
Aug 26, 2006 at 9:23 AM
Hi codekaizen,

How about starting a central GIS vector library for the
".Net" tribe? Something like "Gdal.Net" .

I think, it would be cool, to get more and more formats
to be read native, instead of using the OgrProvider.
Your starting point is Morten's fast Shapefile provider.
I do even looking to get my MapInfo code working for
read access in the next future.
For simpleness we could take the same Classes/Methods
out of OGR and change them, where .Net 2.0 allows us
modern constructs of programming(e.g. generics)

Lets start a discussion!!!

Aug 30, 2006 at 8:36 PM
Volleyknaller -

I've considered this, since I've used OGR a number of times and am even somewhat familiar with the code.

I'm currently adding to the Shapefile provider in SharpMap to introduce write operations on the provider, since we need to use it for import/export.

Naturally, of course, I wondered what a more generic framework for plugging providers in would look like. A good skeleton is already in SharpMap, and with a bit of work, an OGR-level of abstraction would be achievable. It would be nice to implement it in terms of ADO.Net, too.

However, practically, after I complete the add/update functionality on the Shapefile provider, I have to move on to rendering. For our purposes, we would like to have much faster rendering than GDI+ can give us, and I've already put a good deal of time into a DirectX rendering engine as well as rearchitecting the rendering subsystem to accomodate it.