I have produced a function to convert an integer grid to a shapefile
that is now used in two different plugins (MWSWAT and another that is
being developed).

Unlike the existing GridToShape it generates shapes with only
horizontal and vertical polygon edges. This makes it much faster.
Note there also seems to be a bug with the existing function - see
message of 7 September on plugins forum, also experienced by me.

It generates one shape for each grid value, typically with many parts.

I would like to include this function in the official MapWindow code. Some
questions if this is OK.

1. Where? GeoProc? Utils?

2. Name? GridToShapeManhattan? ("ShapesFromGrid" is used below.)

3. Parameters? Currently it takes path of gridfile and a string "id". It
generates "gridfile_from_grid.shp" and adds an attribute "id" to the
.dbf file containing the values from the grid.

4. The algorithm also keeps track of the areas of the polygons that it
builds. So it would be easy to add an "AREA" attribute to the .dbf.
Needed?

5. For one application I create a shapefile from a combination of
several grids, and I don't want to create the gridfile of the
combination. So I have made it possible to create the shapefile in
several steps, by adding one row at a time, with C# code that looks like:

ShapesFromGrid shapes = new ShapesFromGrid(origin, dX, dY, noData);
// where origin is a MapWinGIS.Point for the top left corner of the grid.
// noData is a value to be ignored, which will
// produce holes in the shapefile if it occurs in any rows.
// Can also use overload ShapesFromGrid(header)

// To add grid values, make an integer array of length the width of
// the grid.

// For each row in grid,
// populate the array with the row values, then
shapes.addArrayRow(array, rowNumber);
// If you are adding from a grid you can use
// shapes.addGridRow(grid, rowNumber)

// Merge the polygons from different rows:
shapes.FinishShapes();

// Create a shapefile:
string shapeName = ...; // path of intended .shp file
MapWinGIS.Shapefile shapeFile = new MapWinGIS.Shapefile();
// Remove any existing shapefile, .dbf etc
MapWinGeoProc.DataManagement.DeleteShapefile(ref shapeName);

bool success = shapeFile.CreateNew(shapeName, ShpfileType.SHP_POLYGON);
if (!success) ... // error
success = shapeFile.StartEditingShapes(true, null);
if (!success) ... // error

// Add any fields you want

int shapeIndex = 0;
foreach (int k in shapes.Values)
{
success = shapes.InsertShape(shapeFile, k, ref shapeIndex);
if (!success) ... // error
// Edit the cell value for any fields you created.
// Useful functions are shapes.Area(k), which is type double,
// and shapes.CellCount(k), which is type int.
}

success = shapeFile.StopEditingShapes(true, true, null);
if (!success) ... // error
shapeFile.Close();

Please comment - and answer questions above!

Chris

Dan says that you have commit powers to MapWinGeoProc, and I think that is the most appropriate place for the code. If it has to go under an existing heading I would figure maybe SpatialOperations, but to be honest, the ArcGIS category is called Conversion Tools, so it could go under an entirely new folder called Conversion or something. I see a lot of folders that read like clsSpatialOperations with the cls before it. It could go in clsConversion or something. I think that this is a really exciting new tool and we definitely look forward to having this update added to the geoproc library.

I think you are more aware of what parameters you need to have, and there aren't any hard and fast rules for MapWinGeoProc, especially if you are the main person using these new functions. I think lots of functions work on a filename basis, so that would not be problematic. Also, if you already are calculating the area, I don't think it would hurt to add it as an extra field, but what you could do is add a boolean input parameter that specifies whether or not to add the area field.

Let me know if you are having trouble adding the code itself via the svn repository through the standard commit process or have any other questions.

Shade1974

I have added ManhattanShapes.cs to the folder MapWinGeoProc:clsUtils, since the (unimplemented) GridToShape is in Utils. There are also .Designer.cs and .resx files. The svn server seems to be very erratic - perhaps it started its Thanksgiving celebration early. Commit to the repository reports errors, but the files seem to be there (using a web browser). Someone will need to include the 3 new files in the project and rebuild: I didn't commit my project file as doubtless my folder structure is different (and I use SharpDevelop).

I added everything in a separate file so that I didn't have to touch anything else in GeoProc.

Two things:

1. Any idea when this will be incorporated into MapWindow? Until then I will have to supply a special version of MapWinGeoProc.dll to my users.

2. Can anyone help with generating the Wiki pages? All my functions are properly commented, but I presume someone has something for generating the Wiki sections for the function headers from the comments.

Thanks,

Chris

I am trying to convert ManhattanShapes to work with dotspatial. I would love an explanation on how the polygons are created. Any idea also on how to convert the two functions conserning the creation of the polygons (addChainToShape, makeShape) would be helpfull.

Join the MapWindow IRC channel on irc://irc.freenode.net/mapwindow

I wrote ManhattanShapes so should be able to help you. I suggest you write to me directly in future as the details probably won't interest most people: cwg at iist dot unu dot edu.

First, it is called ManhattanShapes because the edges are all either vertical (N-S) or horizontal (E-W). I wrote it to be fast because I have an application generating hundreds of shapes with, in total, thousands of parts. I also wrote it because the existing MapWindow code for converting a grid to a shapefile failed on my examples.

I don't know what you mean by "convert to dotspatial". ManhattanShapes works mostly with a grid of unit cells, representing polygons as lists of unit vectors (called "links" in the code), and does almost all its processing on these vectors, which means all arithmetic and comparisons are integer. Only as a final step does it convert the sequences of vectors forming each part into sequences of points to reflect the actual coordinates and cell dimensions.

Think of each square cell in a grid having a sequence of 4 unit vectors to form its (clockwise) perimeter. Then if two cells have the same value and complementary vectors in their perimeters you can merge the two sequences into a single sequence which gives a perimeter around the two cells. Repeat until there is no pair of perimeters for the same cell value which have complementary vectors. Make a shape for each cell value by collecting all its perimeters as parts. Convert the perimeters into (closed) sequences of points by knowing the geographic location of the origin and the cell dimensions and you are finished.

There is more detail in the algorithm, especially to deal with the way holes appear, and some techniques to make it go faster.

If dotspatial has a special way to represent shapes then, as I say, I suspect all you have to change is the final step which converts sequences of vectors into sequences of points.

The two functions you mention, makeShape and addChainToShape, are part of this final step. makeShape is called for each cell value in the grid, to make a single shape consisting of parts, each part being one of the perimeters, or "chains", of unit vectors, or "links".

addChainToShape makes a minimal list of points for each perimeter. First, it "rotates" the perimeter: if the first and last vectors have the same direction it moves the first to the end, and repeats. This avoids the first (and last) point of the part being in a straight side. Then it forms the sequence of points to make the part by using only those points where the perimeter changes direction.

I hope this is clear: feel free to contact me. Please also note that I have just updated the SVN site to the latest source.

Chris

Thank you very much for your time and explanation.
I think i managed to do a conversion in the creation of the polygons correctly and so i created a demo of the Manhattan grid to shapefile algorithm using vb.net this time and dotspatial (also known as mapwindow 6) so you can send more feedback if you have time. Any suggestions would be appreciated. Currently according to my needs the algorithm converts all raster with values equal to -1000 to polygons.I included the my initial raster file for convenience.
You can download the demo from here
( [147.102.85.132] )

Join the MapWindow IRC channel on irc://irc.freenode.net/mapwindow