SVG, JavaScript, DOM, AJAX and web mapping

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

SVG, JavaScript, DOM, AJAX and web mapping

Nick Whitelegg-2

Was reading last week about a technology variously known as "Remote
Scripting" or "AJAX" (Asynchronous JavaScript And XML) which allows
JavaScript running on a browser to send an HTTP request to a web server *at
any point* (not just when the user submits a form) and then the server
responds with some XML which the JavaScript can then use to manipulate the
Document Object Model of the web page, and change the page content *without
having to load a new page*.

This is an interesting concept and got me wondering about how it could be
used for web mapping. An approach where...

1) User navigates the map by pressing an arrow key, e.g. moves left
2) Client (JavaScript ) sends server an HTTP request for data in the new
grid square
3) Server sends back the data in the new grid square as XML embedded within
an HTTP response
4) JavaScript processes the data. Map is stored client-side as an SVG
document. JavaScript redraws the map by manipulating the Document Object
Model of the SVG.

This would reduce load on the server significantly and lead to much cleaner
client-server separation in the code (hence more maintainable code) as well
as creating a "rich web app" which was as smooth and seamless as a regular
desktop app (no page reloads necessary) and opens up the possibility of all
sorts of advanced user interaction.

To make this work (i.e. allow the client to dynamically create an image
from XML data) would require browser SVG support. Apparently Firefox 1.1
will support SVG natively. I can see how all this would work apart from one
thing which I'm not sure can be done or not. Can JavaScript embedded within
an HTML document access and manipulate the Document Object Model of an SVG
document?

Thanks,
Nick


_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: SVG, JavaScript, DOM, AJAX and web mapping

Richard Fairhurst
On 5 Jul 2005, at 15:20, Nick Whitelegg wrote:

> This is an interesting concept and got me wondering about how it could
> be
> used for web mapping. An approach where...
>
> 1) User navigates the map by pressing an arrow key, e.g. moves left
> 2) Client (JavaScript ) sends server an HTTP request for data in the
> new
> grid square
> 3) Server sends back the data in the new grid square as XML embedded
> within
> an HTTP response
> 4) JavaScript processes the data. Map is stored client-side as an SVG
> document. JavaScript redraws the map by manipulating the Document
> Object
> Model of the SVG.

This is very similar to what we're doing at waterscape.com, except with
Flash rather than SVG/JavaScript.

The user opens a page containing an SWF client (non-dynamic) which
sends the HTTP request for data in the new grid square, as per above. A
'responder' script on the server sends back the data (in query string
format, not XML... my feelings on XML are roughly equivalent to
http://ex-parrot.com/~chris/sucks/trainwreck.html ).

This data comprises two things: a list of icons, each with grid
reference, and a list of waterways. The SWF client has all the icons
embedded in its 'symbol library', so can place these on the map
instantly. For the waterways, which are vector data, a further call to
the server results in a dynamically-generated SWF (courtesy of Ming,
ming.sourceforge.net) which can be overlaid on the map.

There's a third element of the map: the raster tiles, which form the
backdrop to all of this. These follow a consistent naming convention
and therefore can simply be loaded in as JPEGs directly from the
server, without any need to consult the responder.

The client<->server communication is pretty simple call-and-response
stuff. Flash actually has a much nicer facility for opening up sockets
and 'talking' on those, but unfortunately, most corporate firewalls
seem to block the port range chosen by Macromedia. Since our map has to
be accessible to the general consumer, this rules it out for us.
(That's also why we've used Flash rather than SVG.)

cheers
Richard


_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: SVG, JavaScript, DOM, AJAX and web mapping

stevec-4
* @ 05/07/05 07:57:53 PM [hidden email] wrote:

> On 5 Jul 2005, at 15:20, Nick Whitelegg wrote:
>
> >This is an interesting concept and got me wondering about how it could
> >be
> >used for web mapping. An approach where...
> >
> >1) User navigates the map by pressing an arrow key, e.g. moves left
> >2) Client (JavaScript ) sends server an HTTP request for data in the
> >new
> >grid square
> >3) Server sends back the data in the new grid square as XML embedded
> >within
> >an HTTP response
> >4) JavaScript processes the data. Map is stored client-side as an SVG
> >document. JavaScript redraws the map by manipulating the Document
> >Object
> >Model of the SVG.
>
> This is very similar to what we're doing at waterscape.com, except with
> Flash rather than SVG/JavaScript.
>
> The user opens a page containing an SWF client (non-dynamic) which
> sends the HTTP request for data in the new grid square, as per above. A
> 'responder' script on the server sends back the data (in query string
> format, not XML... my feelings on XML are roughly equivalent to
> http://ex-parrot.com/~chris/sucks/trainwreck.html ).


I'm no fan of XML, but RSS and whatever perls problems are, arn't XMLs
problems.


>
> This data comprises two things: a list of icons, each with grid
> reference, and a list of waterways. The SWF client has all the icons
> embedded in its 'symbol library', so can place these on the map
> instantly. For the waterways, which are vector data, a further call to
> the server results in a dynamically-generated SWF (courtesy of Ming,
> ming.sourceforge.net) which can be overlaid on the map.
>
> There's a third element of the map: the raster tiles, which form the
> backdrop to all of this. These follow a consistent naming convention
> and therefore can simply be loaded in as JPEGs directly from the
> server, without any need to consult the responder.
>
> The client<->server communication is pretty simple call-and-response
> stuff. Flash actually has a much nicer facility for opening up sockets
> and 'talking' on those, but unfortunately, most corporate firewalls
> seem to block the port range chosen by Macromedia. Since our map has to
> be accessible to the general consumer, this rules it out for us.
> (That's also why we've used Flash rather than SVG.)
>
> cheers
> Richard
>
>
> _______________________________________________
> Openstreetmap mailing list
> [hidden email]
> http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
>

have fun,

SteveC [hidden email] http://www.fractalus.com/steve/

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: SVG, JavaScript, DOM, AJAX and web mapping

David Cantrell (at home)
On Tue, Jul 05, 2005 at 09:24:09PM +0100, SteveC wrote:
> * @ 05/07/05 07:57:53 PM [hidden email] wrote:
> > The user opens a page containing an SWF client (non-dynamic) which
> > sends the HTTP request for data in the new grid square, as per above. A
> > 'responder' script on the server sends back the data (in query string
> > format, not XML... my feelings on XML are roughly equivalent to
> > http://ex-parrot.com/~chris/sucks/trainwreck.html ).
> I'm no fan of XML, but RSS and whatever perls problems are, arn't XMLs
> problems.

No, XML's problems lie elsewhere.  I have ranted about them previously
in another place:

http://drhyde.hates-software.com/2004/01/09/62309985.html
http://drhyde.hates-software.com/2004/09/29/4998d8cf.html

Summary: XML is broken as designed

--
David Cantrell | top google result for "internet beard fetish club"

If you're doing business with a religious son of a bitch, get it in
writing.  His word isn't worth shit, not with the Good Lord telling him
how to fuck you on the deal   -- W.S.Burroughs

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: SVG, JavaScript, DOM, AJAX and web mapping

Raphael Jacquot-2
David Cantrell wrote:

> On Tue, Jul 05, 2005 at 09:24:09PM +0100, SteveC wrote:
>
>>* @ 05/07/05 07:57:53 PM [hidden email] wrote:
>>
>>>The user opens a page containing an SWF client (non-dynamic) which
>>>sends the HTTP request for data in the new grid square, as per above. A
>>>'responder' script on the server sends back the data (in query string
>>>format, not XML... my feelings on XML are roughly equivalent to
>>>http://ex-parrot.com/~chris/sucks/trainwreck.html ).
>>
>>I'm no fan of XML, but RSS and whatever perls problems are, arn't XMLs
>>problems.
>
>
> No, XML's problems lie elsewhere.  I have ranted about them previously
> in another place:
>
> http://drhyde.hates-software.com/2004/01/09/62309985.html
> http://drhyde.hates-software.com/2004/09/29/4998d8cf.html
>
> Summary: XML is broken as designed
>

no. XML in itself is very simple. It's all the crap that people have
added around it (note that XSLT, XML schema, SOAP, WSDL and friends are
different specs, not the original XML spec).

_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap
Reply | Threaded
Open this post in threaded view
|

Re: SVG, JavaScript, DOM, AJAX and web mapping

Nick Whitelegg-2
In reply to this post by Nick Whitelegg-2

I think the biggest benefit of XML is that it is a human-readable and
editable, logical, structured format for data. It's the ideal format for
saving and loading application data, and (providing the bandwidth is there)
sending data across the web.

I'm less convinced that it's a catch-all solution for everything, for
example XSLT seems rather messy compared with using a combination of a
traditional programming language and an XML API such as DOM or SAX. But
that's probably just my own personal programming preferences....

I do wish Microsoft Office products would move to XML, or at least some
structured text-based format, rather than the amorphous, non-human-editable
formats they use at the moment. The user would then have much more control
over documents.....

Nick


_______________________________________________
Openstreetmap mailing list
[hidden email]
http://bat.vr.ucl.ac.uk/cgi-bin/mailman/listinfo/openstreetmap