<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I've implemented a shapefile reader in Python as a
vtkProgrammableSource which I'm planning to redo in C++ as a
vtkPolyDataSource sometime over the Easter break. Problem is I only have
files of type 1,3 and 5 (point, polyline and polygon) so currently I
only have methods to reliably read these types. If anyone has
multipatch shapefiles or shapefiles containing Z and/or optional M
(measurement) data that I can use for development and testing PLEASE, PLEASE
send me some (ie. anything other than vanilla point, polyline and
polygon).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I'm going to make the reader freely available -
I'll put in the vtk copyright etc. so if it's up to scratch (or can be made so)
and the folk at VTK want to include it, I'll be more than
happy.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>For any potential-users
/ interested-parties here's my thinking so far ... </FONT></DIV>
<DIV><FONT face=Arial size=2>uses separate method to read each main
type (point, polyline, polygon, multipart - chosen after parsing the
header) -hopefully if the format is extended (or as I get new types for the
first time) it lessens impact on existing code. If present,
Z data will be included in the points (otherwise Z = 0.0), M data as
scalars in point-data. The id (record number) will be included as scalars in
cell-data (facilitating look-ups into attribute-data on picking etc.).
Polygons will require tessellation - I'm currently favouring the GLU built-in
tessellator as it can handle the multipart polygons as is. For flexibility I
think importing of attribute-data should be a separate issue - merging with
attribute-data can take part down-stream if required. I was
thinking a dBase reader could be provided later as a vtkDataObjectSource
for those who don't want to connect to a database. Same goes for the shx
indexing files - can provide reader later if need arises (provides position in
shapefile of shape record based on id).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Any suggestions or disagreements most
welcome.</FONT></DIV>
<DIV><FONT face=Arial size=2>Also, if there already is a reader and I've missed
it, I'd rather feel stupid now than later.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Regards</FONT></DIV>
<DIV><FONT face=Arial size=2>Malcolm Drummond<BR>GeoVision
cc</FONT></DIV></BODY></HTML>