Project

General

Profile

MapRestServiceIdeas » History » Version 5

Andreas Kohlbecker, 12/02/2008 05:00 PM

1 1 Andreas Kohlbecker
2
## Wild and tame ideas for the EDIT Map REST Service API
3
4
5
6
## Area Styles
7
8
9 5 Andreas Kohlbecker
----
10
11 4 Andreas Kohlbecker
 **Andreas Kohlbecker - 27.10.2008, 03.11.2008** 
12 2 Andreas Kohlbecker
13
14 1 Andreas Kohlbecker
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.
15
16
17
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
18
19
20
 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. 
21
22
23
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 <style_label> for each style combination thus introducing redundancy. Therefore I recommend splitting the definitions for 
24
25
26
 
27
28
* polygon border style
29
30
* background fill colour 
31
32
* foreground color and pattern
33
34
35
36
The API proposal already is designed that way: 
37
38
~~~
39
  (area style) as=<area style id>:<color>[,<style_label>]|..              -  defines a background (fill) color for a shape
40
 
41
               as=<area style id>:<pattern id><color>[,<style_label>]|.. -  defines a pattern and foreground color to fill a shape with
42
~~~
43
You can define separate area styles for background and foreground and you can apply arbitrary combinations of these to an area:
44
45
46
~~~
47
(area data) ad=<layer name>:<area style ids>:<area id>,..|<area style ids>:<area id>,..||<layer name>:<area style ids>:<area id>,..|
48
<area style ids> is a string of one letter [a-z,A-Z] area style ids
49
~~~
50
51
The polygon border style however is missing in the API, but we have the 
52
53
~~~
54
(layer style) ls=<layer_style_id>:[<line_color>][,<line_width>][,<stroke_style_id>]|..
55
~~~
56
57
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 ?
58
59
60
And split area style into area background style and area foreground style then we would have the following attributes:
61
62
~~~
63
(area background  style) abs=<area style id>:<color>[,<style_label>]|..              -  defines a background (fill) color for a shape
64
 
65
(area foreground style)  afs=<area style id>:<pattern id><color>[,<style_label>]|.. -  defines a pattern and foreground color to fill a shape with
66
 
67
(area polygone style)    aps=<area style id>:[<line_color>][,<line_width>][,<stroke_style_id>][,<style_label>]|.
68
~~~
69
70
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
71
72
73
 
74
75
abs=a:aaaaaa|b:ffff00
76
77
aps=c:0000ff,dotted,4|d:0000ff,no-dotted,10| e:00ff00,no-dotted,10
78
79
80
81
area border styles would be also applicable to layers: 
82
83
~~~
84
(layer) l=<layer name>[:[<area style id>][,<shp file url>][,<raster data url>]]|...
85
~~~
86
87
The layer attribute only would accept <area style id>s which actually are area border styles .
88
89
90
91
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
92
93
~~~
94
abs=a:aaaaaa|b:ffff00
95
aps=c:0000ff,dotted,4|d:0000ff,no-dotted,10| e:00ff00,no-dotted,10
96
~~~
97
Now lets take the styles from your example and express them by combinations of a, b, c, d, e 
98
99
~~~
100
grey,blue,4,dotted = ac
101
grey,blue,10,no-dotted = ad
102
yellow,green,10-no-dotted = be
103
~~~
104
So you would use these combinations of area styles in
105
106
~~~
107
(area data) ad=<layer name>:<area style ids>:<area id>,..|
108
~~~
109
The advantage I see in this approach are the better legends you can create eg:
110
111
112
~~~
113
abs=a:aaaaaa,arid|b:ffff00,semiarid
114
aps=c:0000ff,dotted,4,native|d:0000ff,no-dotted,10,cultivated| e:00ff00,no-dotted,10, abandoned
115
~~~
116
would result in a legend like which explains all possible combinations without the need to explicitly mentioning every one:
117
118
119
~~~
120
[  ] : arid
121
[  ] : semiarid
122
[  ] : native
123
[  ] : cultivated
124
[  ] : abandoned
125
~~~
126 5 Andreas Kohlbecker
127
128
----
129
130
131
 **pere roca ristol - 06.11.2008** 
132
133
134
I think we could also add...
135
136
137
-Area Hatching Style
138
139
140
path_to_symbol=x:path1/y:path2
141
142
ahs=a:x/symbol1|b:x/symbol2|c:y/symbol3
143
144
[[with|an optional parameter to define to the legend]]