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 Andreas Neumann <ne...@karto.baug.ethz.ch> on 2006/03/13 09:29:51 UTC
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
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