1
|
<?xml version="1.0" encoding="UTF-8"?>
|
2
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN"
|
3
|
"http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
|
4
|
<article>
|
5
|
<title>Community Mapbuilder State Of Play - June 2005</title>
|
6
|
|
7
|
<abstract>
|
8
|
<para>I think that we have reached a stage in the Mapbuilder project where
|
9
|
we should look at what we have achieved, look at the state of the software
|
10
|
world around us, and plan our future.</para>
|
11
|
|
12
|
<para>We have recently seen a number of new names join the Mapbuilder
|
13
|
email list and I invite all our you to contribute to this
|
14
|
discussion.</para>
|
15
|
</abstract>
|
16
|
|
17
|
<section>
|
18
|
<title>Where have we come from?</title>
|
19
|
|
20
|
<para>The Community Mapbuilder website started in 2001 as my idea to build
|
21
|
a Geo-Wiki and was originally planned to bring together WMS/WFS-T
|
22
|
components into one easy to configure application. The only thing missing
|
23
|
was a WFS-T client and I started working on the developing Geotools
|
24
|
library to create a Java client.</para>
|
25
|
|
26
|
<para>In 2003 Raj Singh demonstrated the potential of a web based client
|
27
|
by producing the first prototype web based feature entry client which
|
28
|
talked directly to a database. From then we started mapbuilder-lib,
|
29
|
initially a WMS client, then a WFS-T client which conformed to OGC
|
30
|
standards.</para>
|
31
|
|
32
|
<para>As we developed further, we joined efforts with Nedjo Rodgers, Mike
|
33
|
Adair, Tom Kralidis and Tom Schuller who were all working on similar
|
34
|
projects. Mapbuider-lib broadened it's scope from being a geo-wiki to
|
35
|
being a robust client to OGC services.</para>
|
36
|
|
37
|
<para>In mid 2005, Geoserver, an open source WFS-T included mapbuilder-lib
|
38
|
in it's distribution and Mapbuilder started gaining more interest and
|
39
|
attracted more developers.</para>
|
40
|
</section>
|
41
|
|
42
|
<section>
|
43
|
<title>What are Mapbuilder's Strengths?</title>
|
44
|
|
45
|
<variablelist>
|
46
|
<varlistentry>
|
47
|
<term>WMS/WFS-T in a browser</term>
|
48
|
|
49
|
<listitem>
|
50
|
<para>Mapbuilder runs in a standard web browser without requiring
|
51
|
any plug ins. This makes Mapbuilder easy to use for non-technical
|
52
|
users.</para>
|
53
|
|
54
|
<para>Clients are fast and feature rich because most code is stored
|
55
|
in the client, accessing Web Services using Asynchronous Javascript
|
56
|
And XML (AJAX).</para>
|
57
|
</listitem>
|
58
|
</varlistentry>
|
59
|
|
60
|
<varlistentry>
|
61
|
<term>Modular design</term>
|
62
|
|
63
|
<listitem>
|
64
|
<para>Mapbuilder's modular design makes it easy to add extra
|
65
|
functionality.</para>
|
66
|
|
67
|
<para>Tailored clients are kept small by only including the required
|
68
|
modules.</para>
|
69
|
|
70
|
<para>We have the opportunity to factor out core modules (like our
|
71
|
projection libraries) to be used and improved by other
|
72
|
projects.</para>
|
73
|
</listitem>
|
74
|
</varlistentry>
|
75
|
|
76
|
<varlistentry>
|
77
|
<term>Standards compliant</term>
|
78
|
|
79
|
<listitem>
|
80
|
<para>Standards compliance means that Mapbuilder can build upon the
|
81
|
great work done in the Open GIS services projects.</para>
|
82
|
</listitem>
|
83
|
</varlistentry>
|
84
|
|
85
|
<varlistentry>
|
86
|
<term>Strong user community</term>
|
87
|
|
88
|
<listitem>
|
89
|
<para></para>
|
90
|
</listitem>
|
91
|
</varlistentry>
|
92
|
</variablelist>
|
93
|
</section>
|
94
|
|
95
|
<section>
|
96
|
<title>What software industry developments effect us?</title>
|
97
|
|
98
|
<para>The advantage of working with Open Source software is that we don't
|
99
|
need to look at competing projects as threats, they are potential
|
100
|
partners. Together we can help each other become better.</para>
|
101
|
|
102
|
<section>
|
103
|
<title>Asynchronous Javascript And XML (AJAX)</title>
|
104
|
|
105
|
<para>AJAX describes a way for web browsers to refresh themselves
|
106
|
quickly using asynchronous javascript functions. This functionality has
|
107
|
been available for a couple of years but has only recently become
|
108
|
popular since it's use by high profile Google web sites.</para>
|
109
|
|
110
|
<para>Recently, a hand full of AJAX library projects have started and
|
111
|
have a strong user base behind them. These project are young and
|
112
|
Mapbuilder still contains a significant amount of AJAX functionality
|
113
|
beyond that provided by the libraries. In particular, Mapbuilder's
|
114
|
Model/View/Controller design pattern and dynamic loading of widgets
|
115
|
would be a useful addition to the AJAX libraries.</para>
|
116
|
|
117
|
<para>The Mapbuilder project should consider factoring out it's AJAX
|
118
|
libraries and merging them into one of the existing AJAX library
|
119
|
projects.</para>
|
120
|
</section>
|
121
|
|
122
|
<section>
|
123
|
<title>Other Web Based Geographic Clients</title>
|
124
|
|
125
|
<para>Mapbuilder currently has a number of features not yet provided by
|
126
|
other Web Mapping Clients, however, there are some features from other
|
127
|
projects that would be nice to include. Where possible, we should try to
|
128
|
collaborate with these projects and merge our efforts. We can do this by
|
129
|
factoring out and sharing common libraries or merging our efforts into
|
130
|
one project.</para>
|
131
|
</section>
|
132
|
|
133
|
<section>
|
134
|
<title>Geoserver</title>
|
135
|
|
136
|
<para>Geoserver, the Open Source WMS/WFS has incorporated Mapbuilder
|
137
|
into it's release. This is a good relationship for us because:</para>
|
138
|
|
139
|
<itemizedlist>
|
140
|
<listitem>
|
141
|
<para>We are getting exposure with our core potential user
|
142
|
base.</para>
|
143
|
</listitem>
|
144
|
|
145
|
<listitem>
|
146
|
<para>We are seeing developers join Mapbuilder from the Geoserver
|
147
|
project.</para>
|
148
|
</listitem>
|
149
|
</itemizedlist>
|
150
|
|
151
|
<para>Gabriel Roland pointed out that we can make cross development
|
152
|
easier by using similar tools. In particular, we should consider moving
|
153
|
some functionality from Sourceforge to <ulink
|
154
|
url="http://www.codehaus.org/">http://www.codehaus.org/</ulink>.</para>
|
155
|
</section>
|
156
|
|
157
|
<section>
|
158
|
<title>Geographic Wiki</title>
|
159
|
|
160
|
<para>Significant interest is developing for a Geographic Wiki, where
|
161
|
many people can collaboratively build geographic maps. Mapbuilder would
|
162
|
be an ideal client for a Geographic Wiki and we should aim be involved
|
163
|
in any such project.</para>
|
164
|
|
165
|
<para>This will introduce a many new challenges, like handling user
|
166
|
authentication.</para>
|
167
|
</section>
|
168
|
|
169
|
<section>
|
170
|
<title>Content Management Systems (CMS)</title>
|
171
|
|
172
|
<para>Content Management Systems are one of the big potential users of
|
173
|
Map Viewers and Feature Entry Clients. Unfortunately there are hundreds
|
174
|
of CMS products and there doesn't seem to be a standard
|
175
|
interface.</para>
|
176
|
|
177
|
<para>Java CMS seem to be a better position with standard portlet
|
178
|
specifications and we may be able to target these first.</para>
|
179
|
|
180
|
<para>Nedjo Rodgers notes that Mapbuilder contains many components
|
181
|
needed by CMSs and that different CMSs will all face similar problems.
|
182
|
We should encourage the development of a CMS integration toolkit.</para>
|
183
|
</section>
|
184
|
|
185
|
<section>
|
186
|
<title>Browser support for SVG</title>
|
187
|
|
188
|
<para>It seems that version 7 browsers will provide SVG support by
|
189
|
default. This means that we can make use of SVG's more powerful
|
190
|
rendering and we can expect average users will still be able to use our
|
191
|
web pages.</para>
|
192
|
</section>
|
193
|
|
194
|
<section>
|
195
|
<title>Use stable release numbers</title>
|
196
|
|
197
|
<para>Mike Adair notes that potential users are scared by our "alpha"
|
198
|
version numbers. We should create a 1.0 release and advertise the
|
199
|
existence of applications using Mapbuilder.</para>
|
200
|
</section>
|
201
|
</section>
|
202
|
|
203
|
<section>
|
204
|
<title>Opportunities for improvement</title>
|
205
|
|
206
|
<section>
|
207
|
<title>Testing</title>
|
208
|
|
209
|
<para>With only two core developers, and while software was still in
|
210
|
alpha state we were able to get away without automated testing. However
|
211
|
we are now at a stage where we should consider automated testing
|
212
|
frameworks like jsunit.</para>
|
213
|
|
214
|
<para>Advantages of automated testing includes:</para>
|
215
|
|
216
|
<itemizedlist>
|
217
|
<listitem>
|
218
|
<para>We can easily test Mapbuilder against new browsers and
|
219
|
platforms as they become available.</para>
|
220
|
</listitem>
|
221
|
|
222
|
<listitem>
|
223
|
<para>We can test our updates don't break another part of the code.
|
224
|
This is more important as the software becomes more complex and
|
225
|
there are more developers working on sections we are not familiar
|
226
|
with.</para>
|
227
|
</listitem>
|
228
|
|
229
|
<listitem>
|
230
|
<para>Software can be released more frequently because the head
|
231
|
version of the software should always be working.</para>
|
232
|
</listitem>
|
233
|
|
234
|
<listitem>
|
235
|
<para>Our releases should become more robust.</para>
|
236
|
</listitem>
|
237
|
</itemizedlist>
|
238
|
</section>
|
239
|
|
240
|
<section>
|
241
|
<title>Design Patterns</title>
|
242
|
|
243
|
<para>There are a number of areas in Mapbuilder which could be improved
|
244
|
by the introduction of design patterns. Good use of design patterns will
|
245
|
simplify the code and make it easier to maintain. We should review then
|
246
|
refactor our code for this.</para>
|
247
|
</section>
|
248
|
|
249
|
<section>
|
250
|
<title>Memory Leaks</title>
|
251
|
|
252
|
<para>Memory leaks in a browser can cause a browser to crash or
|
253
|
significantly slow a computer down. We were not considering Memory Leaks
|
254
|
when writing the code, so they probably exist. We should be able to
|
255
|
minimise Memory Leaks if we use an AJAX library which addresses
|
256
|
leaks.</para>
|
257
|
</section>
|
258
|
|
259
|
<section>
|
260
|
<title>Documentation</title>
|
261
|
|
262
|
<para>While we have made a start our documentation needs to be updated.
|
263
|
Good documentation is essential for attracting and keeping potential
|
264
|
developers.</para>
|
265
|
|
266
|
<para>Nedjo Rodgers and others noted that we need concrete guides for
|
267
|
developers. For example, A guide for creating widgets. This should be
|
268
|
combined with mentoring from core developers.</para>
|
269
|
|
270
|
<para>Chris Holmes noted that it is easier to build documentation in a
|
271
|
wiki as it is continuously updated by users. In particular we should
|
272
|
consider using Codehaus.</para>
|
273
|
</section>
|
274
|
|
275
|
<section>
|
276
|
<title>Professional Look and Feel</title>
|
277
|
|
278
|
<para>Feedback I've been getting often includes "The technology is
|
279
|
great, but we need a sexy interface to sell Mapbuilder to decision
|
280
|
makers". We need to provide a sexy interface to Mapbuilder and we need
|
281
|
to ensure we have a stable demonstration release.</para>
|
282
|
</section>
|
283
|
</section>
|
284
|
|
285
|
<section>
|
286
|
<title>Recommendations</title>
|
287
|
|
288
|
<variablelist>
|
289
|
<varlistentry>
|
290
|
<term>AJAX</term>
|
291
|
|
292
|
<listitem>
|
293
|
<para>Contact AJAX library projects, suggest working toward a common
|
294
|
AJAX library then coordinate exporting Mapbuilder functionality into
|
295
|
one of these projects.</para>
|
296
|
</listitem>
|
297
|
</varlistentry>
|
298
|
|
299
|
<varlistentry>
|
300
|
<term>Projection Libraries</term>
|
301
|
|
302
|
<listitem>
|
303
|
<para>Export the projection libraries into a separate project so it
|
304
|
can be used by other projects.</para>
|
305
|
</listitem>
|
306
|
</varlistentry>
|
307
|
|
308
|
<varlistentry>
|
309
|
<term>Review design</term>
|
310
|
|
311
|
<listitem>
|
312
|
<para>Review the design, introduce design patterns, refactor
|
313
|
code.</para>
|
314
|
</listitem>
|
315
|
</varlistentry>
|
316
|
|
317
|
<varlistentry>
|
318
|
<term>Update documentation</term>
|
319
|
|
320
|
<listitem>
|
321
|
<para>In particular, concrete examples of how developers should do
|
322
|
specific tasks (like creating a widget).</para>
|
323
|
</listitem>
|
324
|
</varlistentry>
|
325
|
|
326
|
<varlistentry>
|
327
|
<term>Produce a Professional Look and Feel</term>
|
328
|
|
329
|
<listitem>
|
330
|
<para></para>
|
331
|
</listitem>
|
332
|
</varlistentry>
|
333
|
|
334
|
<varlistentry>
|
335
|
<term>Codehaus</term>
|
336
|
|
337
|
<listitem>
|
338
|
<para>We should ask if we can get Mapbuilder hosted on
|
339
|
http://www.codehaus.org. It provides subversion, better bug
|
340
|
tracking, a wiki for documentation, and is used by Geoserver and
|
341
|
Geotools, projects which we aim to align ourselves with.</para>
|
342
|
</listitem>
|
343
|
</varlistentry>
|
344
|
|
345
|
<varlistentry>
|
346
|
<term>SVG</term>
|
347
|
|
348
|
<listitem>
|
349
|
<para>We should encourage developers who may be interested in adding
|
350
|
SVG support.</para>
|
351
|
</listitem>
|
352
|
</varlistentry>
|
353
|
|
354
|
<varlistentry>
|
355
|
<term>CMS</term>
|
356
|
|
357
|
<listitem>
|
358
|
<para>We should encourage the development of a CMS integration HOWTO
|
359
|
and collaboration from people integrating Mapbuilder into different
|
360
|
CMSs.</para>
|
361
|
</listitem>
|
362
|
</varlistentry>
|
363
|
|
364
|
<varlistentry>
|
365
|
<term>Create a 1.0 release</term>
|
366
|
|
367
|
<listitem>
|
368
|
<para>We should create a 1.0 release and advertise the existence of
|
369
|
applications using Mapbuilder.</para>
|
370
|
</listitem>
|
371
|
</varlistentry>
|
372
|
</variablelist>
|
373
|
</section>
|
374
|
</article>
|