id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
948,Consider WKT as a definition format for inline features...,sdlime,sdlime,"{{{
Here's the thread the spawned the bug...

Steve

I spared the GEOS guys the reply. I don't envision working in just GEOS, it's a
support library for MapServer so there will likely always need to be translation
to/from shapeObj's. Pure GEOS is better served with Sean's SWIG interface. That
said your idea has merit. WKT could be considered as an alternative definition
format for inline features and layers. I've created a bug so as not to loose the
idea. This won't make into 4.4 but perhaps the next release.

Steve

>>> Ferdinando Villa <ferdinando.villa@uvm.edu> 10/07/04 3:42 PM >>>
If I can chime in with an almost unrelated one...

what about adding a WKT layer type to mapserver  - should be simple if
GEOS is being worked in. Unless things have changed recently, the only
way to specify a shape was by means of explicit points or polygons. The
WKT layer would make specifying a generic shape a lot easier -
particularly if a program writes the mapfile, as mine do all the time
(and you should see the 150+ LAYER sections for the USA polygon... :)

cheers,
ferdinando

On Thu, 2004-10-07 at 14:27, Steve Lime wrote:
> I've got a skeletal setup in MapServer now. Nothing functional just a
> setup of how this will work. Basically I propose extending the standard
> shapeObj to contain a GEOS geometry. Then I have to write the code to go
> between GEOS geometries and shapeObj's. The wrappers for the GEOS
> functionality then become really easy. You'll see things like
> msGEOSBufferShape and so on. You'll never see the GEOS geometry and will
> deal with shapeObj's. That way you can draw or use those features easily
> with existing MapServer code. I also plan to make use of the PROCESSING
> block as a mechanism to trigger processing. For example you might do
> something like:
> 
> PROCESSING
>   BUFFER 500
> END
> 
> Which would trigger all features to be buffered before being released
> to MapServer or MapScript. MapScript would then gain a whole bunch of
> geospatial analysis methods attached to shapeObjs. That's what I'm
> planning anyways. Now just to find the time to write the converters. WKT
> will likely be too slow for this purpose.
> 
> Steve
> 
> Stephen Lime
> Data & Applications Manager
> 
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
> 
> >>> Godwinl@AGR.GC.CA 10/7/2004 12:29:04 PM >>>
> I've cross-posted this to various lists, so I'm sorry to those who are
> getting duplicates.
>  
> I'd like to beef up my Mapserver applications with some geoprocessing
> functionality - buffers at present, other functions will follow.  For
> now I am playing with PostGIS and having great sucess, IF my features
> are all stored in the database.
>  
> What I'd like to be able to do though, is take a feature from WMS
> getFeatureInfo or WFS and be able to buffer that.  As a test of this,
> I
> took the GML from a getFeatureInfo request and parsed it manually to
> be
> a WKT string.  Then used PostGIS to run the buffer.  Apart from slight
> precision differences, it appeared to be close to what PostGIS would
> have done with it's own feature (the WMS request was done against the
> same feature through MapServer).  
>  
> Now that I confirmed this is all possible, what I am missing is that
> I'd
> like to be able to 
> a.. do the conversion from GML to WKT with some script/library
> b.. do this with a GML stream
> c.. ultimately do this without PostGIS database dependancy.
>  
> I figure that GEOS can do the geometry format conversions, is this
> right?
> Has anyone written a library for linux/windows that will let me talk
> to
> it with PHP?
>  
> I'm prodding these lists in hopes of finding out what else is going on
> out there in this area. It would be fabulous if this was all built
> into
> Mapserver, but from what I can tell, it's just a thought right now. 
>  
> Thanks!!
>  
> Liz Godwin
> _______________________________________________
> geos-devel mailing list
> geos-devel@geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
-- 
Ferdinando Villa, Ph.D., Associate Research Professor, Ecoinformatics
Gund Institute for Ecological Economics and Dept of Botany, Univ. of Vermont
http://ecoinformatics.uvm.edu

_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
}}}",enhancement,closed,high,,MapServer C Library,4.3,minor,duplicate,,mapserver@…