MapRestServiceIdeas » History » Revision 10
- Table of contents
- Wild and tame ideas for the EDIT Map REST Service API
- Area Styles
- Map Image & Bounding Box
- Labels on/off
Wild and tame ideas for the EDIT Map REST Service API¶
Andreas Kohlbecker - 15.10.2008¶
Hhow can border styles for the shapes can be defined?
The current urls demonstrate this feature, the REST api however does not provide any means to specify the line color, width and stroke style.
This styling is currently defined by a styled layer descriptor, as I assume, but should be exposed by the REST API.
This style information could be put into the layer attribute or into the area data attribute â€˜adâ€™.
Currently I would prefer the following solution, which introduces an optional layer style id into the layer attribute.
(layer style) as=:,,|..
The grid layers then could also use the layer style id:
(grid resolution) gr=[]:[,] - specifies a grid layer
Andreas Kohlbecker - 27.10.2008, 03.11.2008¶
I would prefer a more generic syntax for specifying area styles. First of all I'd like to explain why I think that the Geo REST Service would benefit from a more generic syntax.
Let's assume a situation in which a map should express different kind of information, e.g. distribution, soil characteristics, etc.. In this case one would likely want to express the different kind of information by
a) the polygon border style by b) the fill colour of the polygon, c) by a pattern drawn a foreground of the polygon. So we would have to handle arbitrary combinations of the different styles.
Now if we define the polygon border style, fill colour and the color and pattern drawn in the foreground together in on area style attribute, we would have to define every combination of these individually. This would not only bloat up the style definition but would also bloat up the legend by requiring a for each style combination thus introducing redundancy. Therefore I recommend splitting the definitions for
polygon border style
background fill colour
foreground color and pattern
The API proposal already is designed that way:
(area style) as=<area style id>:<color>[,<style_label>]|.. - defines a background (fill) color for a shape as=<area style id>:<pattern id><color>[,<style_label>]|.. - defines a pattern and foreground color to fill a shape with
You can define separate area styles for background and foreground and you can apply arbitrary combinations of these to an area:
(area data) ad=<layer name>:<area style ids>:<area id>,..|<area style ids>:<area id>,..||<layer name>:<area style ids>:<area id>,..| <area style ids> is a string of one letter [a-z,A-Z] area style ids
The polygon border style however is missing in the API, but we have the
(layer style) ls=<layer_style_id>:[<line_color>][,<line_width>][,<stroke_style_id>]|..
Which is nothing else but a polygon border style applied to all polygons defined in one layer. Maybe we should rename layer style into area border style ?
And split area style into area background style and area foreground style then we would have the following attributes:
(area background style) abs=<area style id>:<color>[,<style_label>]|.. - defines a background (fill) color for a shape (area foreground style) afs=<area style id>:<pattern id><color>[,<style_label>]|.. - defines a pattern and foreground color to fill a shape with (area polygone style) aps=<area style id>:[<line_color>][,<line_width>][,<stroke_style_id>][,<style_label>]|.
The in the currently proposed syntax does not allow using named colors, otherwise the attribute values can not be parsed, so I am using the rgb hex values here
area border styles would be also applicable to layers:
(layer) l=<layer name>[:[<area style id>][,<shp file url>][,<raster data url>]]|...
The layer attribute only would accept s which actually are area border styles .
The the currently proposed syntax does not allow using named colors, otherwise the attribute values can not be parsed, so I am using the rgb hex values here
abs=a:aaaaaa|b:ffff00 aps=c:0000ff,dotted,4|d:0000ff,no-dotted,10| e:00ff00,no-dotted,10
Now lets take the styles from your example and express them by combinations of a, b, c, d, e
grey,blue,4,dotted = ac grey,blue,10,no-dotted = ad yellow,green,10-no-dotted = be
So you would use these combinations of area styles in
(area data) ad=<layer name>:<area style ids>:<area id>,..|
The advantage I see in this approach are the better legends you can create eg:
abs=a:aaaaaa,arid|b:ffff00,semiarid aps=c:0000ff,dotted,4,native|d:0000ff,no-dotted,10,cultivated| e:00ff00,no-dotted,10, abandoned
would result in a legend like which explains all possible combinations without the need to explicitly mentioning every one:
[ ] : arid [ ] : semiarid [ ] : native [ ] : cultivated [ ] : abandoned
pere roca ristol - 06.11.2008¶
I think we could also add...
-Area Hatching Style
Resulting in Area Data...
ad=layer/aac:Mexico,Brazil ... and so on, being aac=color 1,(dotted,5),(y/symbol3)
It's a little crazy and maybe will take some time... but I think it has sense, specially when dealing with many data classification.
Map Image & Bounding Box¶
Andreas Kohlbecker - 23.10.2008¶
For example I could say: BBOX=tdwg1:2 (region 2 of tdwg layer1) this would result in a map showing all of Africa.
BBOX=earth would result in a map showing the whole world.
The recalculate parameter be inferred from what is specified by the ms parameter:
If only the width is defied ms=700 the service infers that recalculation is desired and will adjust the image height to avoid distortions.
If the image height is specified: ms=,300 the service again infers that recalculation is desired but will adjust the width in this case.
If both width and height are defined the service knows that recalculation is not wanted and creates a distorted map.