Sorry for sounding in late, but a few more thoughts. 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
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. 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. 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. But yeah, an improved SVG output format for GeoServer would be a great improvement, even without all the super advanced stuff. best regards, Chris Ivo Brodien wrote: > Hello everybody, > > I am sorry for answering so late. Thanks for the motivating answers. > >>> 1) Shoud it be WMS or WFS service? >> Andrea Aime wrote: >> It depends, with vector output there's always a grey area. As a rule >> of thum, if the output has any styling (it has to contain color, line >> width, filled polygons and the like, and be driven by an SLD) then >> it should be a WMS output format, since there is no concept of >> styling in WFS. > > Ok, I will do it as a WMS service then, since I the plan ist to > deliver styled maps. > > >> GeoServer already has two SVG based output formats, one that >> is based on Batik and that supports SLD almost fully but it's kind >> of slow, and another one that supports very limited styling but >> is faster. >> I don't know anything about these SVG profiles for mobile hardware, >> but I guess you'll need total control over the output, so I suggest >> you look into the one that does not do full styling, and adapt >> it to your needs. The classes can be found in the WMS module, >> org.vfny.geoserver.wms.responses.map.svg package, and in particular >> the low styling high performance classes are SVGMapProducer and >> EncodeSVG, whilst the full styling lower performance is >> SVGBatikMapProducer. > > I started wit the cloning and adapting the SVGMapProdcer.java, > EncodeSVG.java and added my Render so it can be choosen via the > WebInterface as the SVG-Renderer. > > >>> 3) my biggest concern using geoserver is that I am afraid I can't >>> make use of the PostGIS function AsSVG() <http://svg.cc/pg/assvg/> >>> where I could optimize output by setting relative coords and limit >>> precision. >> True, a WMS output format receives a MapContext definitions, that >> do in turn have FeatureSource object. A good output format must not >> make assumptions on the backend, and the PostGIS data store won't >> allow >> you to make use of that function either. >> Then again, you can use the GeoTools Decimator class to perform >> a simple on the fly generalization (that class assumes you're using >> a special coordinate sequence class for your geometries, we can >> talk details about this in a separate mail). > > Okay so I guess I will just have to use external tools to make some > nicer SVG Data instead of letting PostGIS make all the work, which I > thought would be faster than doing it in Java. PostGIS also has the > Simplify function which does the generalization. It would be nice, if > we could talk about the Decimators generalization in separate mail as > you suggested Andrea. It sounds as if I also could use this class to > convert the geo data to my local screen device coordinate system, so > the client does not neet to do calculations? > >>> 4) For my purpose I guess I would use SVG Basic instead of Tiny >>> because Tiny profile does not support textpath element which is >>> nice for street names. >>> 5) A gzip output would also be nice to reduce the file size >> This is handled automatically by GeoServer already. There is a >> filter installed in GeoServer that compresses text based outputs >> on the fly. You just have to add the svg mime type (image/svg+xml) >> to the list of compressed types, look into web.xml. > > Great, works fine. > >>> 6) Since I need a lot of map data to test navigation I would like >>> to import OSM data (OpenStreetMap) into the PostGIS database. I >>> know the tables of OSM are a mess > > I have to correct myself. The data povided by GeoFabrik is pretty > nice. When I used a tool osm2psql it imported the whole table > structure. THe GeoFabrik data is very simple. > > 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 -- Chris Holmes OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------- 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
