[Fwd: Re: [mapserver-dev] Canvas support for MapServer]

Steve Lime Steve.Lime at dnr.state.mn.us
Tue Jan 27 15:27:35 EST 2009


MapServer can output GeoJSON via query calls to the CGI... Here's an example template:

var csgSites = { "type": "FeatureCollection",
[resultset layer="sites"]"features": [
    [feature limit=-1 trimlast=","]{"type": "Feature",
      "geometry": {"type": "Point", "coordinates": [[shpxy]]},
      "properties": {
        "station": "[station]",
        "long_name": "[long_name]",
        "short_name": "[short_name]",
        [item escape="none" name="storet_id" pattern="." format="'storet_id':'$value',"]
        [item escape="none" name="usgs_id" pattern="." format="'usgs_id':'$value',"]
        "has_telemetry": [has_telemetry],
        "has_archive": [has_archive],
        "has_water_chemistry": [has_water_chemistry],
        "has_gagings": [has_gagings],
        "has_photos": [has_photos]
      }
    },[/feature]
  ][/resultset]
};

You'd pair this with a new-style OUTPUTFORMAT like so:

 OUTPUTFORMAT
    NAME json''
    DRIVER 'TEMPLATE'
    MIMETYPE 'aplication/json'
    FORMATOPTION 'FILE=sites.js'
 END

Steve

>>> On 1/27/2009 at 10:25 AM, in message <497F358E.8000908 at uva.nl>, Jan Hartmann
<j.l.h.hartmann at uva.nl> wrote:
> Another option would be to use GeoJSON. Is MapServer able to output
> 
> GeoJSON, or is it going to be? I guess it would be much easier to write 
> a conversion program from GeoJSON to Canvas than from SVG, and I am sure 
> it would be much more efficient.
> 
> Jan
> 
> Stephen Woodbridge wrote:
>> Dan Little wrote:
>>> I think there is some problems with the Canvas implementations across
>>> the different browsers.  I've actually done quite a bit of work using
>>> the Canvas and the exCanvas extension from Google.  While exCanvas
>>> SAYS it is a 100% implementation for IE there tends to be a number of
>>> quirks when it comes to actually placing objects in a drawing stack,
>>> animating them, or simply clearing the canvas at a predictable point.
>>>
>>>
>>> Also, I think it would be much more to the benefit to simply have a
>>> VML output.  A little bit of browser sniffing is easy to do with any
>>> JS application (or even some server side scripting) and you'd be
>>> outputting either SVG or VML in that browser's native preferred
>>> format.  No goofy javascript library required.
>>
>> I think converting some SVG into the proposed Canvas format would be a 
>> good starting point so we can evaluate the performance. If consuming a 
>> large Canvas file causes the browser to be slow or crash, then it 
>> might not make sense to even consider moving forward with something 
>> like this. It would seem to be a pretty straight forward task if we 
>> can find someone that knows perl, Canvas and svg or is willing to do a 
>> little research.
>>
>> -Steve W
>>
>>> ----- Original Message ----
>>>> From: Brent Fraser <bfraser at geoanalytic.com> To: Jan Hartmann
>>>> <j.l.h.hartmann at uva.nl> Cc: mapserver-dev at lists.osgeo.org Sent:
>>>> Tuesday, January 27, 2009 9:07:32 AM Subject: Re: [mapserver-dev]
>>>> Canvas support for MapServer
>>>>
>>>> Jan,
>>>>
>>>> So your thought is to have MapServer generate something like
>>>> (hacked from the example on
>>>> https://developer.mozilla.org/en/Canvas_tutorial/Basic_usage): 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sure, it could be done.  One way is to write another output driver
>>>> for Mapserver.  Another is to use some server-side scripting to
>>>> ingest Mapserver's SVG and change into JavaScript-canvas code like
>>>> that above. A performance hit, but at least it would be on the
>>>> server side, and it might be a good way to prototype the Mapserver
>>>> driver.
>>>>
>>>> Brent
>>>>
>>>> Jan Hartmann wrote:
>>>>> Hi Brent,
>>>>>
>>>>> First let me say that Canvas support is just an idea; I think it
>>>>> can be done
>>>> but whether it is advisable to do so is up to you to decide. I
>>>> liked the idea because the Canvas element is supported nowadays by
>>>> most browsers, unlike SVG which needs a plugin. It is also much
>>>> simpler, so it's easier to use for simple maps, and especially for
>>>> simple interactive operations like digitizing, or combining
>>>> server-side with client-side graphics. That's why I would prefer 
>>>> Canvas above SVG, let alone the fact that I much prefer to program
>>>> in native Javascript above parsing XML. Most of my maps are simple
>>>> (I would guess that goes for many people here), so SVG is decidedly
>>>> overkill. The Canvas HTML element also fits nicely in the page
>>>> layout and can be processed easily by web-editors.
>>>>> Your suggestion that Canvas could be implemented at the client
>>>>> side by
>>>> catching SVG output and transforming it into Canvas directives is
>>>> certainly viable. That is also Paul Spencer's view in his reply to
>>>> my email.  Yet I would prefer a server-side approach: it's more
>>>> efficient (no second parsing of SVG code that had to be generated
>>>> in the first place), and I think the server-side code can be easily
>>>> adapted from the SVG driver. Canvas is a very simple format, just a
>>>> few graphic primitives, more like GD than SVG actually.
>>>>> Again, I don't know how difficult it would be to add a Canvas
>>>>> outputformat,
>>>> and whether it fits at all into the MapServer design philosophy.
>>>> However, when it could be done, it would give me an a far more
>>>> easier tool than SVG  to combine server-side and client-side
>>>> mapping.
>>>>> Jan
>>>>>
>>>>> Brent Fraser wrote:
>>>>>> Jan,
>>>>>>
>>>>>> My interest is in building a (or re-purposing an existing) tool
>>>>>> for
>>>> Cartographic Layout, for printing or rendering a graphics format
>>>> for easy viewing (e.g. PDF).  Steve's comments were about using
>>>> existing Web formats and syntax to describe the layout, and
>>>> existing(?) web editors to do the placement/moving of the layout
>>>> components.
>>>>>> My (very limited) understanding of the HTML tag is that it's a
>>>>>>
>>>> "container" recognized by the browser, and vector (and raster)
>>>> graphics are rendered into it using client-side JavaScript.  Sort
>>>> of the JavaScript equivalent of the SVG format.
>>>>>> It would be possible to add another output format to Mapserver
>>>>>> to generate
>>>> JavaScript code of canvas rendering methods, but a more elegant
>>>> approach might be to write a small(?) JavaScript module to ingest
>>>> Mapserver's SVG and render the objects to the canvas.
>>>>>> Are there some specific features of the direct-canvas-output
>>>>>> approach not
>>>> available in SVG that you need?
>>>>>> Brent Fraser
>>>>>>
>>>>>>
>>>>>> Jan Hartmann wrote:
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> A few weeks ago I suggested in a thread about PDF support
>>>>>>> that Mapserver
>>>> could perhaps be made to support the new "Canvas" tag. There were
>>>> no reactions to this, so I don't know if this suggestion is
>>>> viable/advisable/practicable, or just downright stupid. Can anyone
>>>> comment? (from 
>>>> http://lists.osgeo.org/pipermail/mapserver-dev/2009-January/008055.html) 
>>>>
>>>>
>>>>>>>> I am wondering if MapServer support for the "Canvas" tag
>>>>>>>> could do what
>>>> Steve suggests in a more simple way. Originally, only Safari, Opera
>>>> and Firefox supported this tag to allow (simple) 2D drawing, but
>>>> recently a surprisingly simple Javascript interface for IE has
>>>> become available, translating Canvas command to native IE VRML
>>>> commands. It requires just one single script tag in the web page.
>>>>>>>> See the tutorial at the Mozilla site at:
>>>> https://developer.mozilla.org/en/Canvas_tutorial 
>>>>>>>> and the IE interface (from the Google stables) at:
>>>> http://excanvas.sourceforge.net/ 
>>>>>>>> This is something I have long been looking for. The
>>>>>>>> graphics are very
>>>> simple, so the functionality is nothing like PDF or SVG, but I
>>>> could imagine that a driver for MapServer could fulfill many needs.
>>>> I can use it already by letting Mapserver generate raw coordinates
>>>> and catching them with some sort of Ajax, but a separate driver
>>>> would be very neat of course.
>>>>>>>> How about it?
>>>>>>>>
>>>>>>>> Jan
>>>>>>>>
>>>>>>>>
>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ mapserver-dev
>>>>>>> mailing list mapserver-dev at lists.osgeo.org 
>>>>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev 
>>>> _______________________________________________ mapserver-dev
>>>> mailing list mapserver-dev at lists.osgeo.org 
>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev 
>>>
>>>
>>>
>>>
>>> _______________________________________________ mapserver-dev mailing
>>> list mapserver-dev at lists.osgeo.org 
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev 
>>
>>
> 
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev


More information about the mapserver-dev mailing list