Project

General

Profile

MapRestServiceIdeas » History » Version 15

Katja Luther, 03/30/2022 12:23 PM

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