Changes between Version 56 and Version 57 of WikiStart

02/17/09 21:32:29 (6 years ago)



  • WikiStart

    v56 v57  
    1313This roadmap contains an overview of the anticipated directions, with links to more detailed design specifications and tickets for software development.  There are no set dates on the roadmap, but anyone is welcome to build the components or contract out a developer who will commit to a deadline.  The order is not definitive at all, and indeed will shift according to funding.  If there are other ideas for features and directions don't hesitate to raise the ideas on the [ mailing list]. 
    15 == Multiple Symbolizers on one Rule == 
     15=== Multiple Symbolizers on one Rule === 
    1616In order to support features like roads with outlines, we need the ability to define more than one symbolizer on a rule.  Right now there is an assumption that each rule only has one symbolizer.  This is not a constraint of SLD, just on what we've built thus far. 
    1818''Design proposal:'' [wiki:Symbolizers] 
    20 == Image Manager == 
     20=== Image Manager === 
    2121Currently the management of remote images is not very intuitive.  Users must select 'external' from a drop down menu, and then fill in a URL to an image on the web.  Many however may not know of a good set of images on the web, or they may only have images on their desktop.  A good Image Manager should easily present a set of default images, plus ones that others are using on the same server.  It should also have nice upload capabilities, for users with appropriate permissions to upload their images to the server, where they may be available to others.  An advanced image manager would handle lots of images well, perhaps presenting them as groups, and make it easy to add another whole group on the web (like Google's KML images). 
    2323''Design proposal:'' [wiki:ImageManager Image Manager] 
    25 == Integration with GeoExt toolkit == 
     25=== Integration with GeoExt toolkit === 
    2626Right now Styler is a standalone application.  It should instead be built to be a set of components for GeoExt, with the 'Styler application' simply being a collection of GeoExt components that allow users to pick layers, log-in, and edit the styles.  This work item includes the GeoExt components needed to support a Styler application, and the integration of Styler code in to the [ official GeoExt codebase]. 
    28 == More labeling and stroke options == 
     28=== More labeling and stroke options === 
    2929The first release of Styler does not support all the potential options for SLD strokes and labels.  These should be accessible in the UI, to give users full control over their output. Past the SLD basics GeoServer has a number of new vendor specific params (grouping, displacement, follows, line breaks, etc) that should be controllable from Styler.  Ideally Styler will be able to detect what type of server is doing the rendering of SLD, and would not make available vendor options that the server does not support. 
    3131''Design proposal:'' [wiki:Symbolizers] 
    33 == Copy/Paste == 
     33=== Copy/Paste === 
    3434There are many times when a user might do something a particular way in one style, and want to copy it for use in another.  We should support a variety of copy and paste options, within styles and hopefully even across styles.  A number of things could be copy/pasted in a sensible way: colors, single symbolizers, symbolizer stacks, single rules, rule groups. 
    36 == "View Source" / [ Edit SLD] == 
     36=== "View Source" / [ Edit SLD] === 
    3737Until we support every option in SLD, and every potential vendor option, we need to give users a way to edit the raw SLD file through Styler.  It should be presented in a window that has nicely indented XML, and should reflect the current state of the GUI.  If options that can be represented in the GUI are changed then the GUI should reflect those changes.  The window should also do minimal validation, making sure it is at least valid XML, before sending to the server and generating the error there. 
    3939''Design proposal:'' [wiki:ManagingStyles Managing Styles/SLDs] 
    41 == Improved Scale Management == 
     41=== Improved Scale Management === 
    4242This is one of the least clear items, as it is charting somewhat new territory – no GIS stylers are optimized for web mapping.  To do this right we'll need to try out a few different ideas, and do extensive user testing, to make a truly intuitive management and generation of zoom levels. This is potentially one of the biggest work items, but also one with a big pay off if done right. 
    4444''Design proposal:'' [wiki:LimitByScale Limit by scale] 
    46 == Management of Groups: Unique Values and Thematic Maps == 
     46=== Management of Groups: Unique Values and Thematic Maps === 
    4747Two standard features of any GIS styler are to do Unique values and Thematic maps. The first is extremely useful when there are features of a few different types, which should all be drawn differently.  A good example is roads – you want your interstates, your highways, your primary roads, and your secondary roads to all look different.  We should provide nice wizard type functionality to generate unique values, and work flows that make it easy to further customize. 
    5353''Design proposal:'' [wiki:StyleQuantities Style as quantities] 
    55 == Pop-up styling == 
     55=== Pop-up styling === 
    5656(For Google Earth, GeoRSS, etc) Since one of the main use cases of Styler is to make things look good to serve to Google Earth we should let users style the 'description' and 'snippet' fields of KML output.  Ideally users could also edit extrudes and time templates through Styler.  (Implementation details: For OWS-5 we extended SLD to handle description and snippet.  For GeoServer we got this working with an expression that read our Freemarket templates.  The better way to do it would be to update our implementation to make use of the ExtendedData stuff (hopefully the changes we suggested got in), and then the template thing that Google provides (need to look up the name, am offline right now), as it is a bit more standard than our Freemarket language. 
    58 == Cascadenik CSS-like language == 
     58=== Cascadenik CSS-like language === 
    5959One of the coolest things we've seen recently is [ Cascadenik], which turns Mapnik's styling language in to a CSS-like language that is more accessible to designers.  Many designers may grok this really well, and prefer it to editing SLD/XML and to navigating a GUI.  It would be great to share the same language, and SLD should be close enough to Mapnik's style rules.  We could then have a 'view source' tab that lets you edit either SLD or the cascadenik language.  Ideally Styler could also be used to style Mapnik. 
    6161(Implementation – a basic pass might not be too hard to implement – it would just translate cascadenik to and from OpenLayers style objects. These could then be represented in the GUI and persisted out as SLD. Getting Styler to style Mapnik could maybe use the same route cascadenik uses, or could be written to go straight to/from Mapnik style XML to OL style objects.) 
    63 == ArcMap export == 
     63=== ArcMap export === 
    6464Though outside the scope of Styler per se, it would be really good to have a tool that exports from ArcMap in to styler.  Many users have many styles already defined in ArcMap, and some may prefer to start styling their map there, and finish off the zoom level customization in Styler.  We hope that someone will built a tool that easily exports from ArcMap to SLD and in to Styler. 
    66 == CQL for filters == 
     66=== CQL for filters === 
    6767Many times it may be tedious to use the filter builder gui if you know exactly the complex filter you want to write.  Making an XML filter is a bitch, but CQL is a nice little intuitive language to make filters. This would involve mostly writing a CQL parser / producer for OpenLayers filter objects.  Probably not worth the effort, but worth mentioning. 
    69 == Live editing == 
     69=== Live editing === 
    7070OpenLayers has some awesome style support, that works directly in the browser using SVG or VML.  Instead of having the server render the style, which takes a network round trip no matter what, Openlayers could render the style directly in the browser.  Once the user is happy it could send to the server to make sure it looks as expected.  To truly support this we would need to have OL cover all the options in SLD, as well as the vendor params we will expose in Styler.