Hi, On 25.11.2008, at 03:16, Chris Holmes wrote:
OpenGeo is doing some RnD on iphone stuff for OpenLayers, trying to build a community of everyone trying to get OL on the iPhone. See the posts on http://docs.opengeo.org/geospiel/ And email list at http://www.openplans.org/projects/iol/lists/iol-discussion
I saw this when I started researching for my project and [EMAIL PROTECTED] also pointed me on that project. I would really go into it more deeply, but I don't have timee, since my project will focus on SDAZ zooming capabilities on the iPhone. For an example video on a dektop see here:
http://www-ui.is.s.u-tokyo.ac.jp/~takeo/video/autozoom.movI am afraid, that the doing all the logics with OL and JavaScript will make things too slow. So I will concentrate on small and easy to render SVG files.
One more point on not using PostGIS asSVG() is that it won't pick up the styling that you've defined for your layer in GeoServer. Of course only the batik svg one does that now.
AsSVG does not produce the final SVG output. It just produces the coordinates (relative or abs) with given precision, so one could easily still do style afterwards. But I see that the SVG renderer already uses relative coords, so I don't see a need for AsSVG anymore.
The ideal svg output format would likely end up being similar to the KML one. Both are XML outputs that should use styling. Ideally we'd have a nice refactoring that lets them share good code, and also share code with the non-XML formats, as there is now some code replication.
of course, that would be the best solution, but as I said, unfortunately I don't have so much time for spending on this subject.
For 'tiling', the ideal solution would be to do something like we've done in KML, with GWC, for 'super overlays'. See http://geoserver.org/display/GEOS/Vector+Super+Overlays GeoServer figures out which data to return first, and GWC caches it all at the right level. I could see it being adapted to SVG in a nice way, to stream in data as users zoom in. Of course it's a non- trivial amount of work, but it would be quite cool. I think there's a lot of potential directions it could go, like incorporating generalization and the like.
that was a very good hint, thank you.Especially the different approaches for deciding if a feature should be rendered or not will be usefull.
But yeah, an improved SVG output format for GeoServer would be a great improvement, even without all the super advanced stuff.
yes, absolutely. We will see what I can do. At the moment I will concentrate on the small SVG output. And if time allows afterwards on the SVG cache, if not, I will just precache the tiles in my client, even though they might be ugly on the tile-edges...
cheers ivo
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
