Project

General

Profile

MapRestServiceIdeas » History » Version 11

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

1 7 Andreas Kohlbecker
{{>toc}}
2 1 Andreas Kohlbecker
3 7 Andreas Kohlbecker
4
5
6 1 Andreas Kohlbecker
## Wild and tame ideas for the EDIT Map REST Service API
7
8
9
10
## Area Styles
11 5 Andreas Kohlbecker
12 1 Andreas Kohlbecker
13 9 Andreas Kohlbecker
14
##### Andreas Kohlbecker - 15.10.2008
15 5 Andreas Kohlbecker
16 8 Andreas Kohlbecker
17
Hhow can border styles for the shapes can be defined?
18
19
20
The current urls demonstrate this feature, the REST api however does not provide any means to specify the line color, width and stroke style. 
21
22
23
This styling is currently defined by a styled layer descriptor, as I assume, but should be exposed by the REST API. 
24
25
26
This style information could be put into the layer attribute or into the area data attribute ‘ad’. 
27
28
29
Currently I would prefer the following solution, which introduces an optional layer style id into the layer attribute. 
30
31
 
32
(layer) l=<layer name>[[<layer|style id>]][[<shp|file url>]][[<raster|data url>]]|...
33
34
35
(layer style) as=<area style id>:<line color>,<line width>,<stroke style>|..
36
37
 
38
The grid layers then could also use the layer style id:
39
40
41
(grid resolution) gr=<layer name>[[<layer|style id>]]:<long>[,<lat>] - specifies a grid layer
42
43
44
45
46 7 Andreas Kohlbecker
##### Andreas Kohlbecker - 27.10.2008, 03.11.2008
47 2 Andreas Kohlbecker
48
49 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.
50
51
52
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
53
54
55
 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. 
56
57
58
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 
59
60
61
 
62
63
* polygon border style
64
65
* background fill colour 
66
67
* foreground color and pattern
68
69
70
71
The API proposal already is designed that way: 
72
73
~~~
74
  (area style) as=<area style id>:<color>[,<style_label>]|..              -  defines a background (fill) color for a shape
75
 
76
               as=<area style id>:<pattern id><color>[,<style_label>]|.. -  defines a pattern and foreground color to fill a shape with
77
~~~
78
You can define separate area styles for background and foreground and you can apply arbitrary combinations of these to an area:
79
80
81
~~~
82
(area data) ad=<layer name>:<area style ids>:<area id>,..|<area style ids>:<area id>,..||<layer name>:<area style ids>:<area id>,..|
83
<area style ids> is a string of one letter [a-z,A-Z] area style ids
84
~~~
85
86
The polygon border style however is missing in the API, but we have the 
87
88
~~~
89
(layer style) ls=<layer_style_id>:[<line_color>][,<line_width>][,<stroke_style_id>]|..
90
~~~
91
92
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 ?
93
94
95
And split area style into area background style and area foreground style then we would have the following attributes:
96
97
~~~
98
(area background  style) abs=<area style id>:<color>[,<style_label>]|..              -  defines a background (fill) color for a shape
99
 
100
(area foreground style)  afs=<area style id>:<pattern id><color>[,<style_label>]|.. -  defines a pattern and foreground color to fill a shape with
101
 
102
(area polygone style)    aps=<area style id>:[<line_color>][,<line_width>][,<stroke_style_id>][,<style_label>]|.
103
~~~
104
105
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
106
107
108
 
109
110
abs=a:aaaaaa|b:ffff00
111
112
aps=c:0000ff,dotted,4|d:0000ff,no-dotted,10| e:00ff00,no-dotted,10
113
114
115
116
area border styles would be also applicable to layers: 
117
118
~~~
119
(layer) l=<layer name>[:[<area style id>][,<shp file url>][,<raster data url>]]|...
120
~~~
121
122
The layer attribute only would accept <area style id>s which actually are area border styles .
123
124
125
126
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
127
128
~~~
129
abs=a:aaaaaa|b:ffff00
130
aps=c:0000ff,dotted,4|d:0000ff,no-dotted,10| e:00ff00,no-dotted,10
131
~~~
132
Now lets take the styles from your example and express them by combinations of a, b, c, d, e 
133
134
~~~
135
grey,blue,4,dotted = ac
136
grey,blue,10,no-dotted = ad
137
yellow,green,10-no-dotted = be
138
~~~
139
So you would use these combinations of area styles in
140
141
~~~
142
(area data) ad=<layer name>:<area style ids>:<area id>,..|
143
~~~
144
The advantage I see in this approach are the better legends you can create eg:
145
146
147
~~~
148
abs=a:aaaaaa,arid|b:ffff00,semiarid
149
aps=c:0000ff,dotted,4,native|d:0000ff,no-dotted,10,cultivated| e:00ff00,no-dotted,10, abandoned
150
~~~
151
would result in a legend like which explains all possible combinations without the need to explicitly mentioning every one:
152
153
154
~~~
155
[  ] : arid
156
[  ] : semiarid
157
[  ] : native
158
[  ] : cultivated
159
[  ] : abandoned
160
~~~
161 5 Andreas Kohlbecker
162
163 7 Andreas Kohlbecker
##### pere roca ristol - 06.11.2008
164 5 Andreas Kohlbecker
165
166
I think we could also add...
167
168
169
-Area Hatching Style
170
171
172
path_to_symbol=x:path1/y:path2
173
174
ahs=a:x/symbol1|b:x/symbol2|c:y/symbol3
175
176
[[with|an optional parameter to define to the legend]]
177 6 Andreas Kohlbecker
178
179
Resulting in Area Data...
180
181
ad=layer/aac:Mexico,Brazil ... and so on, being aac=color 1,(dotted,5),(y/symbol3)
182
183
184
It's a little crazy and maybe will take some time... but I think it has sense, specially when dealing with many data classification.
185
186 1 Andreas Kohlbecker
187 6 Andreas Kohlbecker
188 11 Andreas Kohlbecker
## Labels on/off
189 8 Andreas Kohlbecker
190
191
192 11 Andreas Kohlbecker
##### pere roca ristol - 13.11.2008
193 1 Andreas Kohlbecker
194
195 11 Andreas Kohlbecker
Can the area labelling be switched of? If many areas are selected this may be a bit too much.
196
197
Yes, I can include a parameter (label=on/off) ?
198
199
200
201
## Map Image & Bounding Box
202 6 Andreas Kohlbecker
203
204
205 7 Andreas Kohlbecker
##### Andreas Kohlbecker - 23.10.2008
206 6 Andreas Kohlbecker
207
208
For example I could say:  BBOX=tdwg1:2  (region 2 of tdwg layer1) this would result in a map showing all of Africa. 
209
210
BBOX=earth would result in a map showing the whole world. 
211
212
213
The recalculate parameter be inferred from what is specified by the ms parameter:
214
215
If only the width is defied ms=700  the service infers that recalculation is desired and will adjust the image height to avoid distortions. 
216
217
If the image height is specified:  ms=,300  the service again  infers that recalculation is desired but  will adjust the width in this case.
218
219
If both width and height are defined the service knows that recalculation is not wanted and creates a distorted map.