RFC 14 out for comment...

Steve Lime Steve.Lime at DNR.STATE.MN.US
Tue Apr 11 13:49:48 EDT 2006

I think typically users would only use a couple of them, but yes, we'd
support all 9 positions.

As for percentages, I've been thinking about that. My opinion at this
point is that we could support that automatically by checking to see
if all coordinates in the shape (they tend to be very small shapes so 
this would be fast) are between 0.0 and 1.0. If so treat them as 
percentages. The danger is (1.0, 1.0) I guess. If automatic there would
be no additional parameters.

Worst case at the layer level we would add an option to the UNITS
parameter- e.g. UNITS PERCENT.


>>> Stephen Woodbridge <woodbri at swoodbridge.com> 4/11/2006 12:29:02 PM >>>

Well, actually, I think there should be at least nine ORIGINs possibilities:


for the placement options. While the corners will probably be the most, 
I think it would be silly to not provide access to all these points.

In the original request there was some discussion of adding positioning 
based on 0.0 ... 1.0 ratio. Granted this was not to be implemented 
initially, but which of the implementation methods would prevent or 
facilitate doing this in the future. I think that should be taken into 
account when planning this out so that we don't implement something 
today, that is not extensible and then have to implement something else 
that is similar but different and confuses users.

-Steve W

Sean Gillies wrote:
> Steve,
> At most there will be 4 extra layers, right? That's not so bad. The  
> constraint that all features of a layer be in the same CRS has been  
> fine for MapServer. As a born-again MapServer conservative, I'm  
> concerned about creating special cases for wiggling out of this  
> constraint. Special cases increase documentation pressure, require  more 
> tests, etc.
> Sean
> On Apr 11, 2006, at 9:50 AM, Steve Lime wrote:
>> Sean: Good point. I thought about that too and  would agree except
>> that for the types of things folks want to do it might be more  
>> convenient
>> to define this at the feature level. I think it will be quite  common 
>> to place
>> text in multiple corners of an output image. Granted, that could be  
>> handled
>> with multiple layer definitions. I do like the ORIGIN parameter  
>> regardless,
>> sounds better than RELATIVETO...
>> What do folks think about having to define multiple layers to define
>> multiple origins?
>> Steve
>>>>> Sean Gillies <sgillies at FRII.COM> 4/10/2006 10:29:59 PM >>>
>> On Apr 10, 2006, at 3:31 PM, Steve Lime wrote:
>>> Hi all: I posted a new RFC for supporting relative coordinates
>>> (primarily =
>>> for inline features)
>>> to the mapserver website. Comments would be appreciated. The actual =
>>> computations
>>> are trivial to make this work. The issues are more implementation
>>> related- =
>>> hanging a
>>> new parameter off a shapeObj vs something else and so on...
>>> I have coded up one solution and the end result is very useful.
>>> Steve
>> Steve,
>> To me, "relative to XX" is just a shorthand description of a
>> coordinate reference systems. When I think of it as a CRS, it clearly
>> should be defined at the layer level like the geographic and
>> projected coordinate systems already in play.
>>      layer.setImageOrigin(LR)   # or maybe even override  setProjection()
>>      layer.transform = MS_FALSE
>>      layer.addFeature(shape)
>>      layer.draw()
>> My $0.02
>> Sean
>> ---
>> Sean Gillies
>> http://zcologia.com 

More information about the mapserver-dev mailing list