You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Javid Alimohideen <ja...@gmail.com> on 2006/03/13 01:29:59 UTC
Distributed rendering
Hi,
I know that this question is not within the scope of batik's abilities but I
would like to do distributed rendering using batik. Can someone tell me what
core classes of batik should I look into and make myself familiar? I am
little clueless as where to start. I would be using clusters to do the
real-time rendering in very high resolutions (say 10000 x 10000).
Thanks for any help,
Javid
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: L
Posted by Javid Alimohideen <ja...@gmail.com>.
Hi Andreas,
Firstly, I would like to thank you for your suggestion. The traffic map was
an example I am using for my prototype application. Kindly, excuse me as
this is not in the scope of Batik.
Small Description of my project:
Real-time sensor data from the Chicago Highway Traffic Server is visualized
using a SVG map with layers added like events, accidents etc. The aerial
imagery is obtained from our own dataserver (around 20GB of data with 1 foot
resolution). The key idea of the project is how to visualize these data for
different display devices (low-resolution cell phones to High resolution
Wall sized displays). Since, the resolution varies so widely I need a
distributed rendering module in my application so that I could use several
wall sized displays as my clients. The main reason for choosing Batik/SVG is
I will be able to increase the scale of rendering ( I mean pixels) and also
the multi-resolution spec of SVG 1.2 support in Batik which I feel would
help me provide alternate content to my clients based on their display
resolution.
Related paper: http://www.evl.uic.edu/core.php?mod=4&type=3&indi=286
Again, please forgive me for posting stuff that was unrelated to batik. But
Batik has been very helpful to me in the past few months towards my
research.
Thanks,
Javid
-----Original Message-----
From: Andreas Neumann [mailto:neumann@karto.baug.ethz.ch]
Sent: Monday, March 13, 2006 2:30 AM
To: batik-users@xmlgraphics.apache.org
Subject: L
Hi Javid,
what you describe here sounds like a typical application for a map
server. You could f.e. experiment with the Open Source UMN Mapserver
(University of Minnesota), which is widely distributed and in use. see
http://mapserver.gis.umn.edu/
It can easily handle the typical image sizes requested by browsers and
can tie into dynamic backends, such as PostgreSQL/Postgis. E.g. to
include up-to-date traffic-specific information. But I am pretty sure
there are limitations when it comes to (very) big image sizes.
I don't know if that would be an option for you. Not that I would like
to shy you away from Batik, but there might be better technology out there.
If you are on Java, you could also look at the Open Source Degree GIS
and the Java Topology Suite project.
Andreas
Javid Alimohideen wrote:
>Thanks for your suggestions Thomas,
>As of now my prototype application has only few vector data (e.g. Traffic
>Congestion map) and few layers like events, weather, accidents etc. and
>also, the document would be dynamic. The main reason for me to go for the
>distributed rendering approach is to create high resolution images. For
now,
>I am just using a single node to render a 2000 x 2000 image but I would
>like to scale it up more for the following reasons:
>1. Number of clients will increase
>2. Client display size vary widely (few hundred pixels to million pixels)
>3. Need a remote JSVGCanvas (as close as possible) for clients to interact
>with the server side rendered images.
>
>Just FYI, the application would be a server/client based where all the
>rendering happens at server-side and clients just display those streaming
>pixels.
>
>Thanks again for your suggestions.
>
>Javid
>
>
>
--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
L
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Hi Javid,
what you describe here sounds like a typical application for a map
server. You could f.e. experiment with the Open Source UMN Mapserver
(University of Minnesota), which is widely distributed and in use. see
http://mapserver.gis.umn.edu/
It can easily handle the typical image sizes requested by browsers and
can tie into dynamic backends, such as PostgreSQL/Postgis. E.g. to
include up-to-date traffic-specific information. But I am pretty sure
there are limitations when it comes to (very) big image sizes.
I don't know if that would be an option for you. Not that I would like
to shy you away from Batik, but there might be better technology out there.
If you are on Java, you could also look at the Open Source Degree GIS
and the Java Topology Suite project.
Andreas
Javid Alimohideen wrote:
>Thanks for your suggestions Thomas,
>As of now my prototype application has only few vector data (e.g. Traffic
>Congestion map) and few layers like events, weather, accidents etc. and
>also, the document would be dynamic. The main reason for me to go for the
>distributed rendering approach is to create high resolution images. For now,
>I am just using a single node to render a 2000 x 2000 image but I would
>like to scale it up more for the following reasons:
>1. Number of clients will increase
>2. Client display size vary widely (few hundred pixels to million pixels)
>3. Need a remote JSVGCanvas (as close as possible) for clients to interact
>with the server side rendered images.
>
>Just FYI, the application would be a server/client based where all the
>rendering happens at server-side and clients just display those streaming
>pixels.
>
>Thanks again for your suggestions.
>
>Javid
>
>
>
--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: Distributed rendering
Posted by Javid Alimohideen <ja...@gmail.com>.
Thanks for your suggestions Thomas,
As of now my prototype application has only few vector data (e.g. Traffic
Congestion map) and few layers like events, weather, accidents etc. and
also, the document would be dynamic. The main reason for me to go for the
distributed rendering approach is to create high resolution images. For now,
I am just using a single node to render a 2000 x 2000 image but I would
like to scale it up more for the following reasons:
1. Number of clients will increase
2. Client display size vary widely (few hundred pixels to million pixels)
3. Need a remote JSVGCanvas (as close as possible) for clients to interact
with the server side rendered images.
Just FYI, the application would be a server/client based where all the
rendering happens at server-side and clients just display those streaming
pixels.
Thanks again for your suggestions.
Javid
-----Original Message-----
From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
Sent: Sunday, March 12, 2006 7:09 PM
To: batik-users@xmlgraphics.apache.org
Cc: batik
Subject: Re: Distributed rendering
Hi Javid,
"Javid Alimohideen" <ja...@gmail.com> wrote on 03/12/2006 07:29:59 PM:
> I know that this question is not within the scope of batik's abilities
but I
> would like to do distributed rendering using batik. Can someone tell me
what
> core classes of batik should I look into and make myself familiar?
The core classes in batik for rendering is the GVT package. If you can
afford it the simplest thing would be to distribute the GVT tree to all
the
nodes and have each work on rendering a subpart of the document (just set
a clip).
If as I suspect you will need to subset the geometry you will need to
implement a sort of 'gridding' system where one node is responsible for
maintaining the complete geometry and then dispatching/updating that
geometry to each of the nodes in the cluster (based on if the nodes
grid intersects a new/modified/deleted piece of geometry).
You might find the 'UpdateTracker' class useful for this. If
it turns out that the geometry is too large for one node to manage
the changes (remember it doesn't render anything it is mostly doing
bounding box like computations and sending updates). Then you will
likely have to manually split the data set and load just pieces on
managers.
Is this 'just' going to be lots of vector data or will you be
doing lots of filtering as well?
> I am little clueless as where to start. I would be using clusters to do
the
> real-time rendering in very high resolutions (say 10000 x 10000).
>
> Thanks for any help,
>
> Javid
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Distributed rendering
Posted by th...@kodak.com.
Hi Javid,
"Javid Alimohideen" <ja...@gmail.com> wrote on 03/12/2006 07:29:59 PM:
> I know that this question is not within the scope of batik's abilities
but I
> would like to do distributed rendering using batik. Can someone tell me
what
> core classes of batik should I look into and make myself familiar?
The core classes in batik for rendering is the GVT package. If you can
afford it the simplest thing would be to distribute the GVT tree to all
the
nodes and have each work on rendering a subpart of the document (just set
a clip).
If as I suspect you will need to subset the geometry you will need to
implement a sort of 'gridding' system where one node is responsible for
maintaining the complete geometry and then dispatching/updating that
geometry to each of the nodes in the cluster (based on if the nodes
grid intersects a new/modified/deleted piece of geometry).
You might find the 'UpdateTracker' class useful for this. If
it turns out that the geometry is too large for one node to manage
the changes (remember it doesn't render anything it is mostly doing
bounding box like computations and sending updates). Then you will
likely have to manually split the data set and load just pieces on
managers.
Is this 'just' going to be lots of vector data or will you be
doing lots of filtering as well?
> I am little clueless as where to start. I would be using clusters to do
the
> real-time rendering in very high resolutions (say 10000 x 10000).
>
> Thanks for any help,
>
> Javid
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org