[Geoserver-devel] Open Client - AJAX, SVG, and FLASH

GeoServer GeoServer Developer
1

(cross posting to mapbuilder and geoserver-devel)

TOPP (The Open Planning Project) is very soon starting the
"GeoCollaborator" project. The basic goals of the GeoCollaborator
project is to "bring open mapping to the masses" in the sense that we
want people to be able to easily put maps on their site, easily add and
edit layers, and easily share their layers with others.

We're just starting out, but I belive it'll be, basically, 4 things:
1. Hosted base layers (like TIGER, VMAP0, and Landsat) as WMS/WFS
2. Hosting user's layers
3. Added 'extended' WFS functionality (ie. security, Feature Versioning,
etc...)
4. Nice Client Application (we are looking to support all the
open-standards-based ones, but we want a default one for our hosted
apps)

#1 and #2 mean that it should be absolutely trivial for someone to setup
a map or dataset on their site (and we're going to make it as easy as
possible). #3 adds "wiki" like support to the geodata so its easier to
manage and track changes (see recent discussion on the geoserver-devel
list).

What I'm emailing you folks about is #4 ("Nice Client Application"). We
want to have a really easy-to-use application for editing that
leverages the open standards (ie. WFS-T). All the current
implementations, I feel, can be improved.

I've been looking into three technologies for doing this - AJAX, SVG,
and FLASH.

I put a wiki up with a bunch of notes (mostly links to articles, but
also some really tiny experiments) here:

http://docs.codehaus.org/display/GEOS/ajax_flash_svg

I'll summarize VERY briefly here:

A) AJAX (ie. Mapbuilder)
    Join onto the Mapbuilder project and build the application from it.

    Looks like AJAX is available on 90% of browsers BUT:
       a) Application and WFS must be on the same server (or use proxy)
       b) Browser security issues (high security = no XMLHTTPRequest)

    But:
       a) JavaScript isn't nice, cross-browser JS is murder.
       b) drawing using <Div> doesn't scale nor is it pretty
       c) [sortof] stuck with just using <img>
       d) always have to go back to server to get data

    Pluses:
       a) existing Mapbuilder community
       b) lots of people can hack a little JS
       c) has lots of potential

B) SVG
    Join mapbuilder; change it so that there is a pure-HTML rendering
engine (ie. <IMG> and <DIV>) and an SVG-based scene graph (that will
handle everything the HTML version does, but also SVG content, plus
SVG-applications).

    NOTE: I really like this solution, but it has quite a few issues.

Main Problems:
a) see AJAX section above
b) Browser support:
     * Only available in a few % of browsers:
    Stats say 13.5%, but FireFox no longer support
     the Adobe SVG plugin, so that's probably 10% too high.
    "Support" and "Good Support" are two different things.
     * Adobe doesn't seem to be supporting their SVG plugin. Last
       release was 2 years ago - people were expect a new version
       "any day now" in 2003. Also, Adobe bought Macromedia (ie.
       Flash) so its no longer in their best interest to promote
       SVG-in-the-browser.
     * Modzilla SVG was supposed to be in 1.1, but its been delayed
       until 1.5. I'm not sure how active the development is, but it
       does appear to be decent (this is encouraging).
     * People seem to love SVG, but there doesn't appear to actually
       be much actually happening.
     * Its POSSIBLE that a future flash will support SVG.
c) Plugins: You have to download a plugin to see it in IE. Users
doesn't
    want to do this, and many are prevented from doing this. This is a
    huge hassle and its biggest problem by far.
d) Implementations arent that stable (I've blue screened my machine
twice running SVG applications). But, i think our useage will be in
the "easy" category, so I dont think this is a problem.
e) Most of the SVG applications are very buggy, which is very
discouraging (this could just be cross-browser JS issues; its hard to
tell).
f) worried that we'll spend a lot of time getting a nice SVG application
that only a few % of users can actually use.

Advantages:
a) SVG is useful in all sorts of applications (i.e. PDFs, drawing
programs, printing, etc...) and is vector based (ie 'scalable').
b) Very powerful - you can do lots with it
c) Fairly easy to do simple stuff
d) easy for hackers to interact with and do "neat stuff"
e) data is actually small and compresses well (ie. all of manhattan
TIGER is about 50-100k, smaller than a single image) which means very
reduced bandwidth & fast downloading.
f) scalable (in terms of size; much better than <DIV> drawing)
g) easier to make "nice" UIs (??)
h) SVG is an open standard
i) nice to add good SVG support to geoserver anyways
j) XML/DOM based; lots of tools to manipulate it and its 'familiar'

c) FLASH
    Write a Macromedia Flash application, or build off a currently
existing project (like worldbuilder, if it goes Open Source).

Disadvantages:
a) Hard to have an "open" flash project since you basically need the
Flash IDE.
b) cannot join with other projects like mapbuilder
c) non-flash programmers are pretty much excluded.

Advantages:
a) Works on 97% of browsers - even ones in libraries, corporately
controlled, etc...
b) The .SWF format is "open"-ish (and there's lots of OS tools for
generating it - but they're all non-trivial to learn)
c) nice [macromedia $500] IDE to build applications
d) ActionScript (flash's scripting language) IS cross-browser and nicer
than JS.
e) lots of Flash programmers out there
f) Flash doesn't crash your machine
g) Fast
h) just write the application and it'll work well.

I'm just sending out thoughts so that I can gather more information and
ideas - we're not going to be starting for a bit.

Dave

ps. again, I'll mention the wiki notes page (with some experimental
stuff at the bottom):
http://docs.codehaus.org/display/GEOS/ajax_flash_svg

(feel free to add to it)

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

2

A) AJAX (ie. Mapbuilder)

I vote for this.

B) SVG

I did try svg myself with a tiling client a couple of years ago at:

  http://thingster.org/client.html

I found the performance of SVG to be poor - a lot of objects in the scene
graph make it sluggish. It just is not consumer ready technology - and
there are no killer apps like say google maps that are driving it towards
completion.

Another option is a rich java client - this would allow WFS (last I saw
MapBuilder did WFS on the client in a non-scaleable way).

- a

3

Comments line:

dblasby@anonymised.com wrote:

(cross posting to mapbuilder and geoserver-devel)

TOPP (The Open Planning Project) is very soon starting the
"GeoCollaborator" project. The basic goals of the GeoCollaborator
project is to "bring open mapping to the masses" in the sense that we
want people to be able to easily put maps on their site, easily add and
edit layers, and easily share their layers with others.

Dave, I'm peeing my pants with excitement to hear about this project.
It is very closely aligned with my personal goals of building a Community Mapbuilder, or Geowiki as people are now calling it. In particular, I want to create a Bicycle Route Builder - http://bikemap.openearth.com.au/docs/whitepaper/index.html

Could you please give some more details about the project. Is it being funded, if so by who?
Do you have a specific set of goals or requirements?
What timeframe are you working to?
If you are funded, do you have any positions left on your team?

We're just starting out, but I belive it'll be, basically, 4 things:
1. Hosted base layers (like TIGER, VMAP0, and Landsat) as WMS/WFS
2. Hosting user's layers
3. Added 'extended' WFS functionality (ie. security, Feature Versioning,
etc...)
4. Nice Client Application (we are looking to support all the
open-standards-based ones, but we want a default one for our hosted
apps)

5. Create a VML based application. VML is a vector drawing language available in IE but not Mozilla. Although I have not looked into it, I assume we could incorporate this into Mapbuilder quite easilly.

6. As Aslam suggested, a Java aplet. I worked on the Geotools-lite applet a long time ago (and added WMS client support to it) but our biggest problem was the size of the applet. It took too long for the initial download.

7. If you have going to have Geoserver (and hence Java) on the server, then you could move some of the applet functionality to the server to reduce the applet size.

8. Provide a downloadable application (something like a tailored JUMP). This is what I'd suggest is a logical "big brother" to a Mapbuilder AJAX application.

The use cases you are addressing are quite broad and it will be difficult for one client to be all things to all people.
As you suggest, an AJAX client can be used by everyone, but doesn't scale well.

#1 and #2 mean that it should be absolutely trivial for someone to setup
a map or dataset on their site (and we're going to make it as easy as
possible). #3 adds "wiki" like support to the geodata so its easier to
manage and track changes (see recent discussion on the geoserver-devel
list).

What I'm emailing you folks about is #4 ("Nice Client Application"). We
want to have a really easy-to-use application for editing that
leverages the open standards (ie. WFS-T). All the current
implementations, I feel, can be improved.

Agreed.

I've been looking into three technologies for doing this - AJAX, SVG,
and FLASH.

I put a wiki up with a bunch of notes (mostly links to articles, but
also some really tiny experiments) here:

http://docs.codehaus.org/display/GEOS/ajax_flash_svg

I'll summarize VERY briefly here:

A) AJAX (ie. Mapbuilder)
    Join onto the Mapbuilder project and build the application from it.

    Looks like AJAX is available on 90% of browsers BUT:
       a) Application and WFS must be on the same server (or use proxy)

I have a theory on how to get around this issue. I think we can create a web frame from the WFS server which is included into the client which is hidden in the client.
It would require all WFS's to include a small form.html file in their distribution.

       b) Browser security issues (high security = no XMLHTTPRequest)

    But:
       a) JavaScript isn't nice, cross-browser JS is murder.

Yes, although there are a number of libraries which help by covering the cross browser issues and ease the pain.

       b) drawing using <Div> doesn't scale nor is it pretty

Yes.

       c) [sortof] stuck with just using <img>
       d) always have to go back to server to get data

You have this issue with all clients. Either you download the entire dataset, or you need to keep updating the data as you pan/zoom.
Both approaches could be included in the Mapbuilder solution, however I think that usually you only want to download the data you want to display. Bandwidth is usually your biggest limitation.

    Pluses:
       a) existing Mapbuilder community
       b) lots of people can hack a little JS
       c) has lots of potential

B) SVG
    Join mapbuilder; change it so that there is a pure-HTML rendering
engine (ie. <IMG> and <DIV>) and an SVG-based scene graph (that will
handle everything the HTML version does, but also SVG content, plus
SVG-applications).

    NOTE: I really like this solution, but it has quite a few issues.

Main Problems:
a) see AJAX section above
b) Browser support:
     * Only available in a few % of browsers:
    Stats say 13.5%, but FireFox no longer support
     the Adobe SVG plugin, so that's probably 10% too high.
    "Support" and "Good Support" are two different things.
     * Adobe doesn't seem to be supporting their SVG plugin. Last
       release was 2 years ago - people were expect a new version
       "any day now" in 2003. Also, Adobe bought Macromedia (ie.
       Flash) so its no longer in their best interest to promote
       SVG-in-the-browser.
     * Modzilla SVG was supposed to be in 1.1, but its been delayed
       until 1.5. I'm not sure how active the development is, but it
       does appear to be decent (this is encouraging).
     * People seem to love SVG, but there doesn't appear to actually
       be much actually happening.
     * Its POSSIBLE that a future flash will support SVG.
c) Plugins: You have to download a plugin to see it in IE. Users
doesn't
    want to do this, and many are prevented from doing this. This is a
    huge hassle and its biggest problem by far.
d) Implementations arent that stable (I've blue screened my machine
twice running SVG applications). But, i think our useage will be in
the "easy" category, so I dont think this is a problem.
e) Most of the SVG applications are very buggy, which is very
discouraging (this could just be cross-browser JS issues; its hard to
tell).
f) worried that we'll spend a lot of time getting a nice SVG application
that only a few % of users can actually use.

Advantages:
a) SVG is useful in all sorts of applications (i.e. PDFs, drawing
programs, printing, etc...) and is vector based (ie 'scalable').
b) Very powerful - you can do lots with it
c) Fairly easy to do simple stuff
d) easy for hackers to interact with and do "neat stuff"
e) data is actually small and compresses well (ie. all of manhattan
TIGER is about 50-100k, smaller than a single image) which means very
reduced bandwidth & fast downloading.
f) scalable (in terms of size; much better than <DIV> drawing)
g) easier to make "nice" UIs (??)
h) SVG is an open standard
i) nice to add good SVG support to geoserver anyways
j) XML/DOM based; lots of tools to manipulate it and its 'familiar'

c) FLASH

Flash seems promising, but I don't have any experience in it so have no comments here.

--
Cameron Shorter
http://cameron.shorter.net
http://mapbuilder.sourceforge.net

4

Adding SVG support to Mapbuilder won't be all that difficult. We just need some good XSL for GML -> SVG.

Also, keep in mind that, to handle the issue of SVG support, you could use SVG (native or plug-in) where available, and default to a vector proxy (e.g., mapbuilder's use of the wz_jsgraphics library) where not. I sketched out this sort of approach, including some sample code, in a paper for SVGOpen a couple of years ago, see:

http://www.svgopen.org/2003/papers/SVGAsAnEditingEnvironment/

dblasby@anonymised.com wrote:

(cross posting to mapbuilder and geoserver-devel)

TOPP (The Open Planning Project) is very soon starting the
"GeoCollaborator" project. The basic goals of the GeoCollaborator
project is to "bring open mapping to the masses" in the sense that we
want people to be able to easily put maps on their site, easily add and
edit layers, and easily share their layers with others.

5

Cameron Shorter wrote:

Comments line:

dblasby@anonymised.com wrote:

(cross posting to mapbuilder and geoserver-devel)

TOPP (The Open Planning Project) is very soon starting the
"GeoCollaborator" project. The basic goals of the GeoCollaborator
project is to "bring open mapping to the masses" in the sense that we
want people to be able to easily put maps on their site, easily add and
edit layers, and easily share their layers with others.

Hi, (sorry for the lenthy mail)
We will be presenting some stuff around these topics at the Wikimania this weekend. Maybe you want to have a look at the workshop we are organizing on sunday. Could be good for some publicity and i still don't really know enough about TOPP to present it.
http://en.wikibooks.org/wiki/Wikimania05/Workshop-AC1

Dave, I'm peeing my pants with excitement to hear about this project.
It is very closely aligned with my personal goals of building a Community Mapbuilder, or Geowiki as people are now calling it. In particular, I want to create a Bicycle Route Builder - http://bikemap.openearth.com.au/docs/whitepaper/index.html

I will be referencing this project as i already know it some.
:slight_smile:
There is a fairly mature project going on in Germany (BBBike, that guy did coll things well before its time).

Could you please give some more details about the project. Is it being funded, if so by who?
Do you have a specific set of goals or requirements?
What timeframe are you working to?
If you are funded, do you have any positions left on your team?

We're just starting out, but I belive it'll be, basically, 4 things:
1. Hosted base layers (like TIGER, VMAP0, and Landsat) as WMS/WFS
2. Hosting user's layers
3. Added 'extended' WFS functionality (ie. security, Feature Versioning,
etc...)
4. Nice Client Application (we are looking to support all the
open-standards-based ones, but we want a default one for our hosted
apps)

We can offer to support the technical side mainly regarding WMS and a catalog of world wide services. We are keen on supporting MapBuilder as WFS-T instead of reinventing the wheel yet again. A lot seems to going on regarding JavaScript based editing of geometries on remote services so that ease of use for WFS-T services is hgh on the agenda. This might be a cozy niche to fit MapBuilder in so that it doesn't have to worry about where to find them and how to overcome security issues, this is what the Mapbender project could also provide for.

5. Create a VML based application. VML is a vector drawing language available in IE but not Mozilla. Although I have not looked into it, I assume we could incorporate this into Mapbuilder quite easilly.

6. As Aslam suggested, a Java aplet. I worked on the Geotools-lite applet a long time ago (and added WMS client support to it) but our biggest problem was the size of the applet. It took too long for the initial download.

Might want to have a look at OpenStreetMap, JUMP, deeJUMP, udig, qgis - at least that is the ones that we know of work fine.

7. If you have going to have Geoserver (and hence Java) on the server, then you could move some of the applet functionality to the server to reduce the applet size.

8. Provide a downloadable application (something like a tailored JUMP). This is what I'd suggest is a logical "big brother" to a Mapbuilder AJAX application.

OK, first read then comment. So JUMP is known already...

The use cases you are addressing are quite broad and it will be difficult for one client to be all things to all people.
As you suggest, an AJAX client can be used by everyone, but doesn't scale well.

Why would you say that it does not scale well? We are trying to figure this out - so if you have more infoprmation this would be valuable for us.

#1 and #2 mean that it should be absolutely trivial for someone to setup
a map or dataset on their site (and we're going to make it as easy as
possible). #3 adds "wiki" like support to the geodata so its easier to
manage and track changes (see recent discussion on the geoserver-devel
list).

Cameron and Chris Holmes probably are the ones to talk to about this one... :slight_smile:

What I'm emailing you folks about is #4 ("Nice Client Application"). We
want to have a really easy-to-use application for editing that
leverages the open standards (ie. WFS-T). All the current
implementations, I feel, can be improved.

Agreed.

Well, we agree on this one for quite some time now. But there actually are applications out there that can be used and that do look fine. Just one humble example:
http://www.flo.rlp.de
This application allows for editing geometries and it seems to have been done in a fairly usable way. The demo obviously does not allow for editing existing geometries and wont let you store. The productive system (authentication required) is being used by some 8000 farmers in Germany to manage their EU subsidy grants. We underestimated the GIS competence of the farmers thoroughl suspecting them to not get it done at all. Instead they just used it with practically not one complaint. This is our current showcase to demonstrate that OGC WFS-T and usabilty with a simple HTML web interface are not extremes but complement each other perfectly.

I've been looking into three technologies for doing this - AJAX, SVG,
and FLASH.

I put a wiki up with a bunch of notes (mostly links to articles, but
also some really tiny experiments) here:

http://docs.codehaus.org/display/GEOS/ajax_flash_svg

I'll summarize VERY briefly here:

A) AJAX (ie. Mapbuilder)
    Join onto the Mapbuilder project and build the application from it.

    Looks like AJAX is available on 90% of browsers BUT:
       a) Application and WFS must be on the same server (or use proxy)

I have a theory on how to get around this issue. I think we can create a web frame from the WFS server which is included into the client which is hidden in the client.
It would require all WFS's to include a small form.html file in their distribution.

I do not really understand the problem? In our understanding a WFS-T always is reomte and connecteds via http only. See the example above or right at the bottom of this message (alternative to Flash).

       b) Browser security issues (high security = no XMLHTTPRequest)

    But:
       a) JavaScript isn't nice, cross-browser JS is murder.

Yes, although there are a number of libraries which help by covering the cross browser issues and ease the pain.

We were appalled at what *can* be done by Gogglemaps. Besides all the wrath Googlemaps brought upon the OS scene and concerning standards it reconciled us a lot with ECMAScript :slight_smile:

       b) drawing using <Div> doesn't scale nor is it pretty

Yes.

       c) [sortof] stuck with just using <img>
       d) always have to go back to server to get data

You have this issue with all clients. Either you download the entire dataset, or you need to keep updating the data as you pan/zoom.
Both approaches could be included in the Mapbuilder solution, however I think that usually you only want to download the data you want to display. Bandwidth is usually your biggest limitation.

That would be the standard approch regarding WFS-T as we understand it. You would just download whatever section you need - like you do with WMS.

    Pluses:
       a) existing Mapbuilder community
       b) lots of people can hack a little JS
       c) has lots of potential

Further pluses:
    d) high integration with GeoServer dev
    e) full support of standard specs
    f) organized code base (sort of "unspent" as far as we can see)

B) SVG
    Join mapbuilder; change it so that there is a pure-HTML rendering
engine (ie. <IMG> and <DIV>) and an SVG-based scene graph (that will
handle everything the HTML version does, but also SVG content, plus
SVG-applications).

    NOTE: I really like this solution, but it has quite a few issues.

Main Problems:
a) see AJAX section above
b) Browser support:
     * Only available in a few % of browsers:
      Stats say 13.5%, but FireFox no longer support
       the Adobe SVG plugin, so that's probably 10% too high.
      "Support" and "Good Support" are two different things.
     * Adobe doesn't seem to be supporting their SVG plugin. Last
       release was 2 years ago - people were expect a new version
       "any day now" in 2003. Also, Adobe bought Macromedia (ie.
       Flash) so its no longer in their best interest to promote
       SVG-in-the-browser.
     * Modzilla SVG was supposed to be in 1.1, but its been delayed
       until 1.5. I'm not sure how active the development is, but it
       does appear to be decent (this is encouraging).
     * People seem to love SVG, but there doesn't appear to actually
       be much actually happening.
     * Its POSSIBLE that a future flash will support SVG.

All these reasons are enough to make SVG not viable for our purposes (obviopusly speaking for our limited community onyl).

c) Plugins: You have to download a plugin to see it in IE. Users
doesn't
    want to do this, and many are prevented from doing this. This is a
    huge hassle and its biggest problem by far.

Same to GNU/Linux, Unix, others which are 'konquering' our desktops in Germany at a great stride.

d) Implementations arent that stable (I've blue screened my machine
twice running SVG applications). But, i think our useage will be in
the "easy" category, so I dont think this is a problem.

Naw - we want to have something that we can explore real deep. Thats why we'd sdiscuss SVG i the firt place. So this will in the long run cause many problems.

e) Most of the SVG applications are very buggy, which is very
discouraging (this could just be cross-browser JS issues; its hard to
tell).
f) worried that we'll spend a lot of time getting a nice SVG application
that only a few % of users can actually use.

Advantages:
a) SVG is useful in all sorts of applications (i.e. PDFs, drawing
programs, printing, etc...) and is vector based (ie 'scalable').

... but not really in a sense that GIS works out. Scalability of SVG is rather limited as the amount of data varies enourmously between say 1:2,000,000 and 1:1,000 which is a fully acceptable range when doing GIS stuff.

b) Very powerful - you can do lots with it

See above - if you want to keep it simple this is not true any more.

c) Fairly easy to do simple stuff
d) easy for hackers to interact with and do "neat stuff"
e) data is actually small and compresses well (ie. all of manhattan
TIGER is about 50-100k, smaller than a single image) which means very
reduced bandwidth & fast downloading.

Cool thing. This is one of the few pros that really make a lot of sense!

f) scalable (in terms of size; much better than <DIV> drawing)
g) easier to make "nice" UIs (??)
h) SVG is an open standard
i) nice to add good SVG support to geoserver anyways
j) XML/DOM based; lots of tools to manipulate it and its 'familiar'

Another cool thing. Maybe in future it will be a viale otion but not right now. The question is whether we (geo-people) want to be the guinea pigs getting it to run. We got enough other problems.

c) FLASH

Flash seems promising, but I don't have any experience in it so have no comments here.

Bascially the same from us but nonetheless we have developed a distinct point of view. Its just a gut feeling that we do not really need Flash. We've been discussing this for years already and come up with interactive stuff that shows you do not really *need* Flash to do funny stuff. Just a tiny little example of what can be done with very standard HTML can bee seen here:
http://www.mapbender.org
A GML is requested form a WFS every time the map is moved or panned - besides the standard WMS. This GML is converted into a HTML imagemap which gives you full control to link functionality to on-mouse-over and on-mouse-click events. Its old stuff all right but that also guarantees for interoperability, usability and high performance - it was invented to work with low bandwidth - closing the loop to the bandwidth problem discussed above.

Best,
Arnulf

6

Arnulf Christl wrote:

There is a fairly mature project going on in Germany (BBBike, that guy did coll things well before its time).

Yes, I looked at it a few years back. It is a great concept.

As you suggest, an AJAX client can be used by everyone, but doesn't scale well.

Why would you say that it does not scale well? We are trying to figure this out - so if you have more infoprmation this would be valuable for us.

1. Drawing graphics (like lines) in javascript is a hack. A line is created by creating a html <div> tag for each horizonal line. Hence, a diagonal line often contains hundreds of html <div> tags.
As you can guess, this slows the client down.

I'd suggest that you should limit the number of lines/polygons rendered on a display to be less than 10, and less than 3 if the features are complex.

2. Although we have not tested the limits of browser memory, I would not like to load large GML files into a browser and then try to manipulate with javascript or XSL. I'm pretty sure you would overload the browser memory with a medium sized GML file.

Our approach with Mapbuilder is to only edit one feature at a time. After the feature has been modified it is sent to the server and then displayed on the client again as an image (using a WMS map request).

    Looks like AJAX is available on 90% of browsers BUT:
       a) Application and WFS must be on the same server (or use proxy)

I have a theory on how to get around this issue. I think we can create a web frame from the WFS server which is included into the client which is hidden in the client.
It would require all WFS's to include a small form.html file in their distribution.

I do not really understand the problem? In our understanding a WFS-T always is reomte and connecteds via http only.

Javascript security ensures that POST requests only are sent back to the server where the html form came from.
So if my mapbuilder application is at http://localhost/mapbuilder my application cannot POST a WFS request to http://somewfs/wfs

However, as mentioned above, I have an idea for a work around for this.

--
Cameron Shorter
http://cameron.shorter.net
http://mapbuilder.sourceforge.net