Example Technical Committee Proposal...

Steve Lime steve.lime at DNR.STATE.MN.US
Mon Jul 25 16:38:05 EDT 2005


Looks nice, thanks Howard. Could we set up a document template for proposals like this? That
is fill in the form and publish...

Steve

>>> Howard Butler <hobu at IASTATE.EDU> 07/13/05 1:37 PM >>>
All,

I have put Steve's RFC on the website in reStructured text format.  If you 
are a developer, you should be able to log into the website to 
edit/modify.  If not, let me know.
<http://ms.gis.umn.edu/development/rfc/ms-rfc-2>

Howard

At 01:32 PM 7/13/2005, Daniel Morissette wrote:
>Steve Lime wrote:
>>A real proposal, sample proposal template...
>
>More comments on the proposal below.
>
>With respect to the template, the contents seems fine to me at first 
>sight, but... <rant>I HATE using MS Word documents as an interchange 
>format: .doc files are large, require that you launch an external 
>application to view/edit them (only 15 seconds, but still 15 seconds 
>wasted), and they assume that everybody lives in MS Windows/Office which 
>is not true... if I use Open office to edit the doc then you may end up 
>losing formatting or some information.</rant>
>
>My personal opinion is that TSC proposals should be done either in plain 
>text or ReStructured text, or another more widely supported and easier to 
>deal with format.
>
>
>>Instead of writing a new WKT parser I would provide access to underlying 
>>GEOS functionality to do this and leverage the Geometry ï*³ shapeObj 
>>wrapper code that is already available.
>
>I believe OGR is also able to ingest WKT, and mapogr.cpp has code to 
>convert OGR features to shapeObj. Should we conpare the value of using 
>GEOS vs OGR for this task? Frank may be in the best position to comment on 
>that. This comment is mostly driven by the fact that I have not seen a 
>real need for using GEOS yet (but I'm sure that will change in the 
>future), and since GDAL/OGR is used by over 90% of users, OGR may be an 
>easier dependency to require than adding GEOS for those who want this feature.
>
>
>>Implementation Issues:  Biggest problem may lie with MapScript and how to 
>>integrate into the shapeObj code. Ideally one would just create an 
>>overloaded shapeObj constuctor. Itâ€*s not clear how cross-language that 
>>would be although both Perl and Python support that via SWIG. Not sure 
>>about other SWIGed languages or PHP.  Could also consider adding a method 
>>like â€*addWKTâ€* to the layer object.
>
>If SWIG can do it, then we'll find a way to make it work in PHP.
>
>Daniel
>--
>------------------------------------------------------------
>  Daniel Morissette               dmorissette at dmsolutions.ca 
>  DM Solutions Group              http://www.dmsolutions.ca/ 
>------------------------------------------------------------



More information about the mapserver-dev mailing list