I'm in the process of open sourcing mapjunction.com. Java applet.
http://www.mapjunction.com/places/Boston_BRA
I'm trying to justify ripping out my server vector code and replacing
it with geoserver.
"current" is what I have now and I'm benchmarking against. It works
good for a city but won't scale to state level without indexing.
Hmmm... So your current solution is definitely faster then? I would
encourage GeoServer since the huge win is interoperability, your server
would then also be able to be accessed by a number of other clients.
Also, if your client support wfs and wms well then you would probably
get quite a bit of outside interest, as there really isn't too much
that's very good out there (as I think you recently discovered). With
a nice, fast performing implementation you could make a pretty big
splash in the open source GIS community. One other thing to note is
that wfs is allowed to serve up data formats other than just gml. GML
is the reference format, and all must do it, but you can add different
ResultFormats. Gabriel recently reworked our responses to use
delegates, and you could write a MapJunctionFeatureResponseDelegate
that produced your format, as it looks to be smaller than svg and is
obviously geared towards your applet. The WMS portion has a similar
delegate structure going on. I'd even consider rolling it in to the
main geoserver distribution, though I think an even better answer would
be to make our response delegates pluggable, like the gt2 datastores,
so that people could just make their jars available for others to add
to their lib section, and they'd be up and running. This would allow
your client to make requests from GeoServer in the native format, which
would speed things up, and then could just use wfs/wms for other
servers that don't support the native map junction vector format.
Using GeoServer would also mean that your server could access postgis,
oracle, arcsde and whatever geotools spits out next. And yeah, the
other win to working with GeoServer is you can piggyback on an already
active developer community, instead of trying to generate your own,
which I find to be the real benefit of open source, not just the free
software but the knowledge base that builds around successful projects.
There is also a flash client that is going to be open sourced that my
son
wrote that has a larger viewing window.
http://www.mapjunction.com/places/Test_BRA/flash/flash.pl.
I couldn't get this to work, but yeah, if you had a nice open source
wms/wfs flash client then you would make some people very happy. My
biggest complaint right now with the opengis consortium is the lack of
good clients to show off what they've done.
Best regards,
Chris
I also tried to test the wms raster support but I don't have X
windows
running on the server and java offscreen
imaging fails without X.
-greg.
----- Original Message -----=20
From: <cholmes@anonymised.com>
To: "Gabriel Rold=E1n" <gabriel.roldan@anonymised.com>
Cc: "Greg Cockroft" <greg@anonymised.com>;
<geoserver-devel@anonymised.com=
et>
Sent: Wednesday, April 07, 2004 11:40 PM
Subject: Re: [Geoserver-devel] Some speed tests
>
> Thanks for this, the images look good. Do we have ideas as to why
> GML2.gz is slower? Is it the extra time to zip it up shows up, but
the
> saved bandwidth doesn't, as it's on the same machine? And what is
the
> 'current' row?
>
> I'd also be super interested in comparisons between servlet
containers.
> I've done time tests with resin and tomcat, and found resin much
> faster. But Jetty seems pretty darn quick too, should get you an
> improvement over tomcat, and it's nice because it's completely open
> source.
>
> > Test data is the streets of boston in a postgis database.
32,000
> > polylines
> > Input Shapefile was 18 Meg.
> >
> > geoserver 1.2-beta
> > Redhad 7.3 on dual 2 Ghz. processor.
> > tomcat-5.0.19.
> >
> > The current format is a non-indexed 2D display list that gets
> > searched sequentially and gzip'ed to the client from a perl
cgi.
> >
> > Times were the best of 3 trials.
> > Command line http fetch from the same machine.
> >
> > 400x400 pixel area zoom level 8
> >
> > Format Time Size
> > -----------------------------------------
> > GML2 0.265s 88,357
> > GML2.gz 0.758s 14,934
> > svg 0.165s 19,419
> > current 0.094s 4,435
> >
> > Here is what the data looks like if you have the svg plugin
> >
> >
>
http://agog.com:8080/geoserver/wms?SERVICE=3DWMS&VERSION=3D1.0.0&REQUEST=3D=
GetMap&LAYERS=3Dtopp:streets&BBOX=3D773394.1225,2955758.52416667,774706.4=
55833333,2957070.8575&FORMAT=3Dimage/svg+xml&styles=3Dnormal&WIDTH=3D400&=
HEIGHT=3D400
> >
> >
> >
> > 800x800 pixel area zoom level 16
> >
> > Format Time Size
> > ----------------------------------------
> > GML2 2.664s 1,013,882
> > GML2.gz 8.311s 153,311
> > svg 1.298s 138,831
> > current 0.095s 43,941
> >
> >
> >
>
http://agog.com:8080/geoserver/wms?SERVICE=3DWMS&VERSION=3D1.0.0&REQUEST=3D=
GetMap&LAYERS=3Dtopp:streets&BBOX=3D770720.243333333,2946837.93833333,775=
969.576666667,2952087.27166667&FORMAT=3Dimage/svg+xml&styles=3Dnormal&WID=
TH=3D800&HEIGHT=3D800
> >
> >
> >
> >
> >
>
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/