Topics: SharpMap v2.0
May 3, 2008 at 4:46 PM
Hi, guys. I've been away for a few weeks, wrapping up a project. I'm now ready to make a commitment to SM V2.x if it's operational. Can you provide a brief snapshot of the status of the 2.x refactoring?

1) Can we use the versions of GeoAPI and NTS that were refactored with Generics, yet? There is a coordinate system factory that is ready to go?

2) Is the Winforms render running now?

3) Did we get a Feature Layer interface defined that let's us plug in our own datasets as feature layers, rather than requiring us to write data providers that copy into the Sharmap feature layer object?

I'm prepared to download stuff and get current, based upon the doc on the home page, but would just as soon pass if it isn't ready to go yet.

May 5, 2008 at 3:36 PM
Hi again Magnum4610, Codekaizen has been doing a lot of good work on the v2 effort, most recently on NTS v2, last I heard he was working through the NTS tests. There is a coordinate system factory which resides in the NTS v2 assembly, but overall it is not an end to end solution quite yet. Codekaizen was asking for volunteers to help knocking a few of the failing NTS tests on the head, if you can help I'm sure it would be appreciated.
HTH jd
May 5, 2008 at 11:02 PM
Thank you. I'm the most focused on the NTS stuff and getting it working correctly, right now, so I will be glad to do what I can. I'll pull down the NTS and GeoAPI sources and see what I can make of them.
May 5, 2008 at 11:35 PM
Hi again, Magnum -

The source is in a bit of a mess right now as I have focused almost completely on getting NTS up, running and passing the validation tests.

Since last week I got the main test cases passing (It was quite a happy moment to see the Overlay operation in NTS, which is used to generate intersections, function correctly), I'm working with another developer to get all the pieces put back together for a run at a build which renders and displays this week. Source code should stabilize between today and Wednesday, and this should provide a "yes" to questions one and two.

On question 3, serendipitously enough, the initial pieces are now being covered by my work mate. He noticed that the IFeatureLayerProvider could be refactored to a provider / table adapter collaboration and is removing all of the FeatureDataTable methods from it. A customizable adapter can be used to work with IFeatureLayerProvider instances to query a data source and fill a feature table. However, the upper layers of SharpMap still depend on a FeatureDataTable instance to do their work. Do you descend from FeatureDataTable, or do you have something completely different?
May 6, 2008 at 1:49 AM
Edited May 6, 2008 at 1:53 AM
That sounds very good. My goal would be to upgrade my existing code to use the new NTS/GeoAPI stuff. I have test cases very ready to go for data that is a problem in the current implementation. I could probably put off work with the rendering stuff for a month. NTS is the most important part of the whole project for me. The issues we are having with the current implementation are really starting to cause a problem for us. We deal with some geometries that take over a minute to test the "IsValid" property. Can I get you to shoot me an e-mail when you think I should grab GeoAPI\ProjNet\NTS and start running my test cases against them?

We have a "GISDataSet" object that is built upon the Microsoft DataSet, with a table for extended column properties like Unit-Of-Measure, intended data use, etc. It is intended to run as a stand-alone in-memory recordset. We have special versions of it that are optimized to represent vector surfaces, etc. And we have the version that holds the 50,000 yield site implementation we have discussed. We can implement the IDataProvider interface on this, and have done so earlier as an academic exercise. But we wanted to just be able to respond with a TableView to the extent query request, rather than copying all of the data in view to another display layer.

Maybe we could have built this by extending a FeatureDataTable... I could still look into that. But I was kind of thinking that we would be able to just implement an interface that would let our TableViews plug straight into a renderer, instead of needing to copy from a "data provider" into a FeatureLayer. I'll review our options here when we get the WinForms render running again. I'll can accept reponsibility for reviewing the dependency on the FeatureDataTable and whether it can be replaced with an IFeaturDataTable interface, but it sounds like you might be heading down a different road with the adapter metaphor. We can look when the time is right.