[mapserver-dev] ms rfc 48: adding a type keyword to the styleblock

[Yewondwossen Assefa]

Thomas,

  Thanks for putting out the RFC and sorry for commenting a bit late on 
this.

   Reading the proposal and comments on it, If the initial intention was 
to support arrow heads/tails, I do not see anything wrong with directly 
supporting them.  From my point of view, we already use symbols to be 
dawn along lines and the support of symbols at different positions would 
fit naturally in this context. I see this being purely a styling 
addition vs the geometry transformation. This styling option I think is 
common and for example in svg, they use  the terms marker-start, 
marker-end and marker-mid to place symbols at different positions. 
Having something similar in Mapserver styling with SYMBOLPOSITION for 
example could possibly achieve the same result.

  I understand the need to make things more generic and the power of 
what is proposed but wanted also to stress that simply supporting this 
as a styling parameter might also make sense.

  Best Regards,


thomas bonfort wrote:
> On Mon, Nov 10, 2008 at 15:11, Daniel Morissette
> <dmorissette at mapgears.com> wrote:
>> thomas bonfort wrote:
>>> the original intent of this rfc was to have something a bit more
>>> generic than directly adding arrowhead support, so this is getting a
>>> bit unwieldy  :)
>>>
>> Ha! I know that feeling!
>>
>> Guys, let's keep in mind that the simplicity of MapServer used to be its
>> main advantage? Did we forget that "MapServer is not a full-featured GIS
>> system, nor does it aspire to be"?
>>
>> While it may sound cool to perform a
>> centroid(convexhull(buffer([geom],0.5))) in a style at rendering time, that
>> remains a purely theoretical example with no application in real life as far
>> as I can tell... BTW, do we also expect that a feature rendered after such a
>> complex operation should be clickable (queryable) as well and how do we plan
>> on managing that if all those operations are done only at rendering time in
>> the style object and not in the data source where the query happens?
>>
>> If anyone needs that kind of fancy operation, I think they can afford to
>> load their data in PostGIS and do the spatial operations in there instead of
>> bloating MapServer with stuff that's of no use for 99% of the users... that
>> will also solve the queryability issue.
> 
> thanks Daniel for putting us back on the tracks :)
> 
>> I'd say keep it simple and manageable in the time that you have available,
>> and plan the mapfile changes/keywords so that they can be extended in the
>> future if possible... that's what you've done so far I think.
>>
>> The RFC and future docs should also discuss the impact of the use of
>> geotransform on queries.
> 
> I hadn't considered the queries for this RFC, as the intent of it was
> geared at styling. I guess that queries as a whole should be left
> aside for as long as we stick to our "not a gis" motto.
> 
> as for the expression to be used, I'm wondering what syntax should be
> used, with the long-term goal of being backwards-compatible if/when
> nested expressions are added:
> 
> 1) start(geometry) : "geometry" would be a reserved keyword
> 2) start([geometry]): this expresses that the geometry is an attribute
> of the feature, but would collide with attribute binding
> 3) start() : will pose a problem for nested expressions, and for
> passing options (eg buffer(5) ).
> 
> I'm in favor of no1, are there better possibilities ?
> 
> thomas
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> 


-- 
----------------------------------------------------------------
Assefa Yewondwossen
Software Analyst

Email: assefa at dmsolutions.ca
http://www.dmsolutions.ca/

Phone: (613) 565-5056 (ext 14)
Fax:   (613) 565-0925
----------------------------------------------------------------