Dear people,
In our process of testing mapping suites I tried to bind a .NET datatable in straightforward manner to a geodataset/layer in MapSuite 3.0 (trial). I probably overlooked something, can anyone help me with this?
I'm using both PostGIS (where's the schema support?) and Shapefile layers.
Thanks for helping,
Wouter
Wouter,
I am not exactly sure what you tried to do. The Layers and FeatureSource objects do not support binding on them. The results from a FeatureSource or layer is not a data table and is instead a collection of Feature instances. A feature is a structure containing the well known binary of the geometry and also holds a dictionary of the attribute keys and values associated to them. If you have some code to share maybe it would enlighten me as to what you are trying to do. The more detail the better as well on your scenario.
David
David,
I’ll explain what we need, as in my opinion, this should be basic functionality of a GIS.
We do calculations on data from varying data sources, and perform them in-memory. Not only the datasources are varying, but also the calculations. They have one thing in common: they all end up grouped by zip-code. So we end up with a in-memory .NET datatable with zip-codes, and associated calculated values.
What we now want to do is visualize these new values on a map. This should be done by retrieving a zip-code feature layer, which includes a zip-code attribute, and (based on zip-code) add our newly calculated values to the features, in order to thematically map them, e.g. with varying point size, or in different colors.
The most common way to achieve the desired result is to simply join the new datatable with the featurelayer, based on zip-codes. Then the features simple get the new attributes and values added to them. This is a common GIS operation, so I assumed that it must be possible in one or another way.
You could compare it to having an Excel sheet with zip-codes and population data, and a featurelayer with zip-codes. Load them both in a desktop GIS, and join the Excel data based on zip-codes in order to draw a map of population densities. This is a basic operation for almost every desktop GIS.
I hope that this shed some light on my question!
Wouter
Wouter,
I understand much better now. We can facilitate this but in another way. I think the key thing you said that that 'it is a basic operation for almost every Desktop GIS". I agree with you but what we offer are components for building desktop GIS systems and I agree that many off the shelf desktop GIS viewers like ArcView do this we see it as something above our outside of the component. We do offer ways to link the data just not at the high level you might expect. We see it as a high level operation and what we offer out of the box is rather low level.
In our system if you want to join column data from one dataset to the main features you can use the CustomColumnFetchEvent. I am providing a link below with some sample code to show you how it works. In a nutshell on the FeatureSource there is an event called CustomColumnFetch. Whenever you want to use data from another source to join it with your other data you can reference the field as normally in our styles etc and when it goes to find it it will see that that field is not really part of the feature source. After that it will raise the above event. The event will pass you the feature ID and the feature and you can go into your data table, find the row that is is associated with and return the vale for the requested field in the event. In this way you are joining the data. We did it this way so it would be flexible for not just data tables but from anything you wanted to use.
In the sample at the link below the style references a column called ‘custom’ that does not exist in the feature source. It will cause the event to be raised and inside of the event you can do whatever you need to fill in the missing data. I think it would be very possible to build a feature source that took a data table to make the process more streamline. We would know the key from the feature and the key in the table to search one. We found that data tables were not all that fast when doing lots of look-ups. We suggest people use dictionaries that contain a dictionary of the columns as the key and values as the column values. This look-up us very fast in real-time. This all depends on how much data you will be using etc.
gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/21/aft/5966/afv/topic/Default.aspx
David