Allow for the definition of relative coordinates in untransformed inline features.

Good idea!

I would like to see another option of using values of 0 to 1 to represent a
proportional witdth and height.  Prehaps the REALTIVETO could be IMGSIZE in this
case with the upper left being 0,0 as before...

I have used this nomenclature in other plotting packages and like it...

Just a thought...

The positioning needs to be a combination of:

1) Absolute - have this today
2) Absolute positioning relative to a point like
  UL - upper left
  CL - center left
  LL - lower left
  UC - upper center
  CC - center center
  etc
3) The point above could be specified by %H %W

Then need for absolute positioning relative to the point, is so you can offset a
text label relative to the point based on some number of pixels like the font
size. This way when the image size changes the point changes relative to the
image size and the offsets stay fixed to the font size or image size that you
are poisitioning.

This map be pushing the limits, but this idea got me to thikning about drawing
things on the resulting images. Things like fancy Borders and such, not just Text.

Maybe something along the lines of a north arrow that way alway some percentage
of the width of the image, things like that.

I was just wondering what other things besides TEXT could use this positioning
method.

Another thought, would be in somehow nexting the positioning, similar to HTML
tables inside of each other.  Just another LOOP after all.  Remember I said it
might be pushing things  :c)

Bob, this not for just text. These are full blown features that can be drawn 
using any of MapServer's other features. I think you could do some pretty fancy 
stuff.

Steve

I've been doing some more thinking on this positioning stuff.

These ideas may be out there with regard to general usefulness to the 
community, but with the right Client side tools . . .

Does it make any sense to entertain some sort of templating method to approach 
this with.

Something akin to an Overlay or Heads-up Templating mechanism to handle these 
arbitrary positioning Items.  This might also be a way of embedding Pixel 
scaling inside of a config seperate from the MapFile method, where a global 
Scale could be applied in this overlay for all background (map) imagery.

Further . . .

using some sort of templating like this at the Pixel level of measurement might 
also lend itself to a method of drawing primitives in/on the client view for 
transfer back to the server (transactional spatial requests), this same type of 
template could be the model for sending the data back to the server.

Being able to build a dynamic redlining andor markup layer, possibly even on a 
(server) layer by layer basis (think Clientside imagemap generation), this 
could become something fairly powerful as far as transactional processes.

The obvious choice for me would be to use XML for this.  There may be other 
better suited methods, but XML seems like a good fit as a a start.

Adding myself to the CC.

Bob: I think an overlay template is an interesting idea. I would look at is as 
an additional feature as opposed to replacing what is being talked about in 
this feature request. You could go so far as to be able to define the overlay 
using SVG and then render that atop (or anywhere in) the layer stack. Obviously 
not a trivial addition...

Steve

I think for starters I'm just going to go with the RELATIVETO idea, with the 
percentage support coming later (if necessary). I think the bulk of 
applications only need to specify coordinates relate to a fixed point. I hope 
to have this in place in CVS HEAD before the end of the week.

Steve

Wondering where the parameter support should be added. Any comments? Personally
I think it should be at the feature level as mentioned in the first comment.
That way you could place a copyright notice in the lower lefthand corner of the
image and a date or something in the lower righthand corner with the same layer
definition. 

That will require a tweak to MapScript as well. The layer add method will have
to take another *optional* parameter that determines relativeness (is that a word?).

Steve

I have got this working in principle, here's a mapfile snippet:

MAP
  NAME 'test'
  SIZE 500 500
  EXTENT 0 0 500 500
  
  LAYER
    NAME 'testy'
    TYPE ANNOTATION
    TRANSFORM FALSE
    STATUS DEFAULT
    FEATURE
      RELATIVETO LL
      POINTS 50 -50 END
      TEXT 'Lower Left'
    END
    FEATURE
      POINTS 50 50 END
      TEXT 'Upper Left'
    END
    FEATURE
      RELATIVETO UR
      POINTS -50 50 END
      TEXT 'Upper Right'
    END
    FEATURE
      RELATIVETO LR
      POINTS -50 -50 END
      TEXT 'Lower Right'
    END
    FEATURE
      RELATIVETO CC
      POINTS 0 0 END
      TEXT 'Center of Image'
    END
    CLASS
      LABEL SIZE MEDIUM COLOR 0 0 0 END
    END
  END
END

Will post the output shortly...

Steve

Output from sample mapfile.

Hi Steve,

I agree with you about using it at the FEATURE level.

Alternatively, you could use the image center point as (0, 0) then you don't
need RELATIVETO, but could just use:

FEATURE
  POSITION RELATIVE # POSITION DEFAULTS TO ABSOLUTE
  POINTS -50 -50 END # 50 pixels left of center, 50 pixels lower than center
END

But it could be too confusing to have another coordinate space .....

Bart

The center point won't work in all cases since the distance to say the LL 
corner of the image relative to that point will change depending on image size. 
It becomes impossible then to anchor something to the lefthand corner of the 
image. I think we need to be able to define what that anchor point is feature 
by feature.

Adding a couple of other CC's...

Steve

Thanks for cc'ing me. This looks great. It is exactly what we need for this
feature. Please make sure the embedded scalebar can be placed using this. Thanks.

Steve, does this work for Bug#1592, it also needs a percentage placement and
RELATIVETO placement.

Couple of things:

  - embedded scalebars already have a position capability and are different 
animals altogether (at this point).

  - percentages may come later. At this point I don't see a need for them since 
absolute values relative to various anchor points are far more stable over a 
range of image dimensions.

  - this is not directly related to bug 1592 at all although perhaps some 
concepts could transfer.

This enhancement pertains to INLINE features only...

Steve

I agre with Steve about starting with what is described in comment #10 and other
enhancements such as %W %H can always come later if they are really needed.

Just an update. There are several ways to address this feature and some may be 
more invasive than others. Because of that I wanted to create an RFC to address 
the issue and get more feedback from other developers. The RFC is online (RFC 
14) at the MapServer website.

Steve

I committed an initial version (that needs testing) tonite just to get it off my
development version. Basically you use the TRANSFORM parameter at the layer level:

e.g. TRANSFORM TRUE|FALSE or UC|UR|CR|CC...

I also added PERCENTANGES as a layer unit type (e.g. UNITS PERCENTAGES).

I'll whip up a couple of test cases for points, lines/polygons and circles and
do any necessary clean up ASAP.

Steve

Will post a test case for annotation. Also just cleaned up the code a bit so it
actually works. If folks would confirm things work we can close this one out...

Steve

test case output

test case mapfile

I'm using Mapserver 4.8.3 from a recent MS4W, and this feature seems not to be
present.  Which branch were these changes committed to?  Will they propogated
into future releases?

Brock

This was a new feature so it is only in 4.9/5.0, so it is present in CVS HEAD...

Steve

This is complete in version 4.10. Marking as fixed.

Steve