Project

General

Profile

MapRestServiceIdeas » History » Version 7

Andreas Kohlbecker, 12/02/2008 05:11 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 5 Andreas Kohlbecker
14 7 Andreas Kohlbecker
##### Andreas Kohlbecker - 27.10.2008, 03.11.2008
15 2 Andreas Kohlbecker
16
17 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.
18
19
20
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
21
22
23
 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. 
24
25
26
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 
27
28
29
 
30
31
* polygon border style
32
33
* background fill colour 
34
35
* foreground color and pattern
36
37
38
39
The API proposal already is designed that way: 
40
41
~~~
42
  (area style) as=<area style id>:<color>[,<style_label>]|..              -  defines a background (fill) color for a shape
43
 
44
               as=<area style id>:<pattern id><color>[,<style_label>]|.. -  defines a pattern and foreground color to fill a shape with
45
~~~
46
You can define separate area styles for background and foreground and you can apply arbitrary combinations of these to an area:
47
48
49
~~~
50
(area data) ad=<layer name>:<area style ids>:<area id>,..|<area style ids>:<area id>,..||<layer name>:<area style ids>:<area id>,..|
51
<area style ids> is a string of one letter [a-z,A-Z] area style ids
52
~~~
53
54
The polygon border style however is missing in the API, but we have the 
55
56
~~~
57
(layer style) ls=<layer_style_id>:[<line_color>][,<line_width>][,<stroke_style_id>]|..
58
~~~
59
60
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 ?
61
62
63
And split area style into area background style and area foreground style then we would have the following attributes:
64
65
~~~
66
(area background  style) abs=<area style id>:<color>[,<style_label>]|..              -  defines a background (fill) color for a shape
67
 
68
(area foreground style)  afs=<area style id>:<pattern id><color>[,<style_label>]|.. -  defines a pattern and foreground color to fill a shape with
69
 
70
(area polygone style)    aps=<area style id>:[<line_color>][,<line_width>][,<stroke_style_id>][,<style_label>]|.
71
~~~
72
73
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
74
75
76
 
77
78
abs=a:aaaaaa|b:ffff00
79
80
aps=c:0000ff,dotted,4|d:0000ff,no-dotted,10| e:00ff00,no-dotted,10
81
82
83
84
area border styles would be also applicable to layers: 
85
86
~~~
87
(layer) l=<layer name>[:[<area style id>][,<shp file url>][,<raster data url>]]|...
88
~~~
89
90
The layer attribute only would accept <area style id>s which actually are area border styles .
91
92
93
94
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
95
96
~~~
97
abs=a:aaaaaa|b:ffff00
98
aps=c:0000ff,dotted,4|d:0000ff,no-dotted,10| e:00ff00,no-dotted,10
99
~~~
100
Now lets take the styles from your example and express them by combinations of a, b, c, d, e 
101
102
~~~
103
grey,blue,4,dotted = ac
104
grey,blue,10,no-dotted = ad
105
yellow,green,10-no-dotted = be
106
~~~
107
So you would use these combinations of area styles in
108
109
~~~
110
(area data) ad=<layer name>:<area style ids>:<area id>,..|
111
~~~
112
The advantage I see in this approach are the better legends you can create eg:
113
114
115
~~~
116
abs=a:aaaaaa,arid|b:ffff00,semiarid
117
aps=c:0000ff,dotted,4,native|d:0000ff,no-dotted,10,cultivated| e:00ff00,no-dotted,10, abandoned
118
~~~
119
would result in a legend like which explains all possible combinations without the need to explicitly mentioning every one:
120
121
122
~~~
123
[  ] : arid
124
[  ] : semiarid
125
[  ] : native
126
[  ] : cultivated
127
[  ] : abandoned
128
~~~
129 5 Andreas Kohlbecker
130
131 7 Andreas Kohlbecker
##### pere roca ristol - 06.11.2008
132 5 Andreas Kohlbecker
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]]
145 6 Andreas Kohlbecker
146
147
Resulting in Area Data...
148
149
ad=layer/aac:Mexico,Brazil ... and so on, being aac=color 1,(dotted,5),(y/symbol3)
150
151
152
It's a little crazy and maybe will take some time... but I think it has sense, specially when dealing with many data classification.
153
154 1 Andreas Kohlbecker
155 6 Andreas Kohlbecker
156
## Map Image & Bounding Box
157
158
159
160
161 7 Andreas Kohlbecker
##### Andreas Kohlbecker - 23.10.2008
162 6 Andreas Kohlbecker
163
164
For example I could say:  BBOX=tdwg1:2  (region 2 of tdwg layer1) this would result in a map showing all of Africa. 
165
166
BBOX=earth would result in a map showing the whole world. 
167
168
169
The recalculate parameter be inferred from what is specified by the ms parameter:
170
171
If only the width is defied ms=700  the service infers that recalculation is desired and will adjust the image height to avoid distortions. 
172
173
If the image height is specified:  ms=,300  the service again  infers that recalculation is desired but  will adjust the width in this case.
174
175
If both width and height are defined the service knows that recalculation is not wanted and creates a distorted map.