[OpenLayers-Dev] [Dev] Re: Vectors in OpenLayers?
Paul Spencer
pspencer at dmsolutions.ca
Fri Oct 20 09:09:27 EDT 2006
I'm not keen on using GML as the only representation. For me, I
rarely deal with GML and am more often dealing with WKT.
I am also hesitant to agree to having the digitizing tools generate
GML that is then processed into Geometry->Shape ... that seems quite
awkward to me.
I suggest that the architecture support serializing Geometries/Shapes
into something ... those of us that are interested in implementing
support for a particular format can implement it.
Then digitizing/editing tools can generically operate on Shapes and
be part of the generic graphics lib. Remember that one of our design
goals was to build a graphics lib independent of the GIS part, that
could be used as a stand-alone component.
Cheers
Paul
On 20-Oct-06, at 7:15 AM, Cameron Shorter wrote:
> Bart van den Eijnden (OSGIS) wrote:
>> Also, if somebody starts drawing new geometries from scratch, you
>> will need a way to generate GML to insert them using a WFS. So not
>> in all use cases will the client already have the data in GML format.
>
> We already cover this use case in Mapbuilder, and I suggest we use
> the same design pattern in this design.
>
> When a User draws on a map, we process the mouseActions and create
> a GML Layer. The GML Layer is rendered the normal way GML->Geometry
> Classes->Vector Renderer.
>
> Then when the user presses the SAVE button, you build a WFS
> Transaction from the GML and send it to the server.
>
> So there is no need for serialising from Geometry->GML.
>
>> Cameron, are you suggesting to go for one format (WKT or GML), and
>> then use the server-side to transform if necessary?
>
> I think it will be a rare user requirement to convert from WKT->GML
> or visa-versa in a Web Client. So I don't think it is worth
> spending too much time addressing yet.
>
>> If so, would you go for WKT or GML? In my opinion GML is the most
>> logical option, it can always be transformed server-side to WKT if
>> you need to go to something like PostGIS directly (without a WFS),
>> since mostly we will talk to OGC web services and not to something
>> like PostGIS directly. Disadvantage is that its structures are
>> more elaborate than WKT.
>
> I agree that GML would probably be better.
> We have quite a bit of experience and code dealing with GML and WFS
> in Mapbuilder, and we should be able to reuse that.
>
>> Best regards,
>> Bart
>> Cameron Shorter schreef:
>>> I'm wondering whether we will need to create a Geometry->GML
>>> serialiser.
>>> In an application which uses GML, the rendering logic will go:
>>>
>>> GML -> Geometry Classes -> Vector Rendering HTML
>>>
>>> Ie, the client will already have the data in GML format.
>>>
>>> If the user edits features, then we can have the tools update the
>>> data source (GML in this case) which in turn will propagate the
>>> update though to the Geometry and Renderer.
>>>
>>> The other reason you might want to serialise is so that you can
>>> convert from one format to another, eg WKT->Geometry->GML or
>>> similar. However I suggest we keep vector transformation on the
>>> server, probably as a web service.
>>>
>>> Paul Spencer wrote:
>>>
>>>> For you maybe ;) GML would be another good output choice I guess
>>>>
>>>> Paul
>>>>
>>>> On 19-Oct-06, at 3:44 AM, Bart van den Eijnden (OSGIS) wrote:
>>>>
>>>>
>>>>> Will there also be an option to serialize the objects as GML?
>>>>>
>>>>> Since interaction will mostly be against OGC Web Services.
>>>>>
>>>>> Best regards,
>>>>> Bart
>>>>>
>>>>> --
>>>>> Bart van den Eijnden
>>>>> OSGIS, Open Source GIS
>>>>> http://www.osgis.nl
>>>>>
>>>>>
>>>>> --------- Oorspronkelijk bericht --------
>>>>> Van: Paul Spencer <pspencer at dmsolutions.ca>
>>>>> Naar: Pierre GIRAUD <bluecarto at gmail.com>
>>>>> Cc: dev at openlayers.org
>>>>> Onderwerp: Re: [OpenLayers-Dev] [Dev] Re: Vectors in OpenLayers?
>>>>> Datum: 19/10/06 00:09
>>>>>
>>>>>
>>>>>> Hi Pierre,
>>>>>>
>>>>>> I haven't looked at the code but I think that this will be
>>>>>> needed in
>>>>>> some sort of factory object that can create Geometry (and
>>>>>> associated
>>>>>> Shape) objects from WKT. We are a bit early for implementation
>>>>>> details right now (despite the fact that I've already done a
>>>>>> bunch of
>>>>>> implementation), but when the design is finalized, we'll need
>>>>>> this
>>>>>> piece.
>>>>>>
>>>>>> This reminds me that Geometry objects need to be able to
>>>>>> serialize
>>>>>> themselves as WKT.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> On 13-Oct-06, at 12:46 PM, Pierre GIRAUD wrote:
>>>>>>
>>>>>> > I wanna propose you some peace of code for this.
>>>>>> > Hope you'll be able to have a quick look and check if I'm
>>>>>> the good
>>>>>> > way.
>>>>>> >
>>>>>> > I tried to follow the "factory" pattern, but
>>>>>> I'm not sure I
>>>>>> > implemented it right considering the rest of the
>>>>>> architecture.
>>>>>> >
>>>>>> > Regards and nice week-end
>>>>>> >
>>>>>> > Pierre
>>>>>> >
>>>>>> > ps : this code might be useable in the current vector
>>>>>> sandbox
>>>>>> >
>>>>>> > On 10/13/06, Pierre GIRAUD <bluecarto at gmail.com>
>>>>>> wrote:
>>>>>> >> I don't know if this is a needed functionnality, but
>>>>>> it can
>>>>>
>>>>>
>>>>> probably
>>>>>
>>>>>> >> help. I was trying to think about and implement a way
>>>>>> to add a
>>>>>> >> feature
>>>>>> >> by its WKT string writing.
>>>>>> >>
>>>>>> >> Something like :
>>>>>> >>
>>>>>> >> OpenLayers.Vector.WKT
>>>>>> >>
>>>>>> >> p4 = new OpenLayers.Vector.WKT('POINT(-40 30)');
>>>>>> >>
>>>>>> >> Regards
>>>>>> >>
>>>>>> >> Pierre
>>>>>> >>
>>>>>> >> On 10/13/06, Paul Spencer
>>>>>> <pspencer at dmsolutions.ca> wrote:
>>>>>> >> > Thanks Chris :)
>>>>>> >> >
>>>>>> >> > Performance really sucks if you add a lot of
>>>>>> features. I
>>>>>
>>>>>
>>>>> wrote a
>>>>>
>>>>>> >> > quick loop to add a 1 degree box every 10
>>>>>> degrees and
>>>>>
>>>>>
>>>>> brought my
>>>>>
>>>>>> >> > firefox to a halt. Profiling reveals a number of
>>>>>
>>>>>
>>>>> problematic
>>>>>
>>>>>> >> areas,
>>>>>> >> > the biggest of which is getPx (of course).
>>>>>> >> >
>>>>>> >> > I've done some optimization that improves
>>>>>> performance in
>>>>>
>>>>>
>>>>> this case:
>>>>>
>>>>>> >> >
>>>>>> >> > * remove the call to Pixel.add(x,y) and
>>>>>> directly modify the
>>>>>
>>>>>
>>>>> pixel
>>>>>
>>>>>> >> > position - this was a big savings ...
>>>>>> >> >
>>>>>> >> > * cached px location in the Point object based
>>>>>> on the bounds
>>>>>
>>>>>
>>>>> of the
>>>>>
>>>>>> >> > containing vectorLayer so getPx is only called
>>>>>> when the
>>>>>
>>>>>
>>>>> bounds have
>>>>>
>>>>>> >> > actually changed.
>>>>>> >> >
>>>>>> >> > attached is a patch against the sandbox to
>>>>>> incorporate these
>>>>>
>>>>>
>>>>>> >> changes.
>>>>>> >> >
>>>>>> >> > Next steps for me are:
>>>>>> >> >
>>>>>> >> > * fix rendering in IE and Safari (that was the
>>>>>> whole point
>>>>>
>>>>>
>>>>> of using
>>>>>
>>>>>> >> > excanvas)
>>>>>> >> >
>>>>>> >> > * further optimizations, including:
>>>>>> >> >
>>>>>> >> > o try caching the bounds of each vector and
>>>>>> test for
>>>>>> >> intersection
>>>>>> >> > with layer bounds before rendering
>>>>>> >> >
>>>>>> >> > o tighten inner loops and remove deep call
>>>>>> chains
>>>>>
>>>>>
>>>>> (possibly
>>>>>
>>>>>> >> > putting some of the pixel conversion stuff right
>>>>>> into
>>>>>
>>>>>
>>>>> convertToPx)
>>>>>
>>>>>> >> >
>>>>>> >> > o anything else you can think of
>>>>>> >> >
>>>>>> >> > * convenience functions for constructing
>>>>>> polygons and lines
>>>>>
>>>>>
>>>>> from
>>>>>
>>>>>> >> > points without having to construct intermediate
>>>>>> objects
>>>>>> >> >
>>>>>> >> > Other things that need to be done at some point,
>>>>>> but not
>>>>>> >> necessarily
>>>>>> >> > for 2.3:
>>>>>> >> >
>>>>>> >> > * refactor the code (what, already?) so that the
>>>>>> Vector
>>>>>> >> architecture
>>>>>> >> > can support multiple rendering types (Canvas,
>>>>>> SVG, VML,
>>>>>
>>>>>
>>>>> possibly
>>>>>
>>>>>> >> > others in the future) by introducing
>>>>>> Layer.Vector subclasses
>>>>>
>>>>>
>>>>> and a
>>>>>
>>>>>> >> > new Rendering class that knows how to render
>>>>>> into the
>>>>>
>>>>>
>>>>> sub-classed
>>>>>
>>>>>> >> > layer types
>>>>>> >> >
>>>>>> >> > * refactor styling support to make it less
>>>>>> specific to
>>>>>
>>>>>
>>>>> Canvas
>>>>>
>>>>>> >> > rendering stuff
>>>>>> >> >
>>>>>> >> > * add some Controls for digitizing and possibly
>>>>>> editing
>>>>>> >> >
>>>>>> >> > Cheers
>>>>>> >> >
>>>>>> >> > Paul
>>>>>> >> >
>>>>>> >> > On 12-Oct-06, at 7:55 PM, Christopher Schmidt
>>>>>> wrote:
>>>>>> >> >
>>>>>> >> > > On Thu, Oct 12, 2006 at 05:02:00PM -0400,
>>>>>> Paul Spencer
>>>>>
>>>>>
>>>>> wrote:
>>>>>
>>>>>> >> > >> Schuyler, et al
>>>>>> >> > >>
>>>>>> >> > >> attached is a first cut at the vector
>>>>>> stuff. It
>>>>>
>>>>>
>>>>> extracts
>>>>>
>>>>>> >> over an
>>>>>> >> > >> existing openlayers folder and
>>>>>> contains only the
>>>>>
>>>>>
>>>>> new files
>>>>>
>>>>>> >> I've added
>>>>>> >> > >> plus a change to OpenLayers.js to load
>>>>>> the extra
>>>>>
>>>>>
>>>>> files by
>>>>>
>>>>>> >> default
>>>>>> >> > >> (except for excanvas for some reason ;)).
>>>>>> >> > >>
>>>>>> >> > >> There is a vector.html in the examples
>>>>>> folder.
>>>>>> >> > >
>>>>>> >> > > This code, with some improvements from
>>>>>> Schuyler and I,
>>>>>
>>>>>
>>>>> is now
>>>>>
>>>>>> >> in place
>>>>>> >> > > in a sandbox in the OpenLayers SVN. You
>>>>>> can check out
>>>>>
>>>>>
>>>>> with:
>>>>>
>>>>>> >> > >
>>>>>> >> > > svn co http://svn.openlayers.org/sandbox/
>>>>>> sderle/ vector/
>>>>>> >> > >
>>>>>> >> > > You can try it out at:
>>>>>> >> > >
>>>>>> >> > >
>>>>>
>>>>>
>>>>> http://openlayers.org/~crschmidt/vector/examples/vector.html
>>>>>
>>>>>> >> > >
>>>>>> >> > > Click once to start drawing a line --
>>>>>> click again to
>>>>>
>>>>>
>>>>> end it.
>>>>>
>>>>>> >> > >
>>>>>> >> > > FF only at the moment.
>>>>>> >> > >
>>>>>> >> > > Cool stuff, Paul, thanks for getting the
>>>>>> ball rolling
>>>>>
>>>>>
>>>>> on this.
>>>>>
>>>>>> >> > > --
>>>>>> >> > > Christopher Schmidt
>>>>>> >> > > Web Developer
>>>>>> >> >
>>>>>> >> >
>>>>>
>>>>>
>>>>> +-----------------------------------------------------------------
>>>>> +
>>>>>
>>>>>> >> > |Paul Spencer
>>>>>
>>>>>
>>>>> pspencer at dmsolutions.ca |
>>>>>
>>>>>> >> >
>>>>>
>>>>>
>>>>> +-----------------------------------------------------------------
>>>>> +
>>>>>
>>>>>> >> > |Chief Technology Officer
>>>>>
>>>>>
>>>>> |
>>>>>
>>>>>> >> > |DM Solutions Group Inc
>>>>>
>>>>>
>>>>> http://www.dmsolutions.ca/ |
>>>>>
>>>>>> >> >
>>>>>
>>>>>
>>>>> +-----------------------------------------------------------------
>>>>> +
>>>>>
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > _______________________________________________
>>>>>> >> > Dev mailing list
>>>>>> >> > Dev at openlayers.org
>>>>>> >> > http://openlayers.org/mailman/listinfo/dev
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> >> <wkt.html>
>>>>>> >> <WKT.js>
>>>>>> > _______________________________________________
>>>>>> > Dev mailing list
>>>>>> > Dev at openlayers.org
>>>>>> > http://openlayers.org/mailman/listinfo/dev
>>>>>>
>>>>>> +----------------------------------------------------------------
>>>>>> -+
>>>>>> |Paul Spencer
>>>>>> pspencer at dmsolutions.ca |
>>>>>> +----------------------------------------------------------------
>>>>>> -+
>>>>>> |Chief Technology
>>>>>> Officer |
>>>>>> |DM Solutions Group Inc http://
>>>>>> www.dmsolutions.ca/ |
>>>>>> +----------------------------------------------------------------
>>>>>> -+
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> Dev at openlayers.org
>>>>>> http://openlayers.org/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> +-----------------------------------------------------------------+
>>>> |Paul Spencer pspencer at dmsolutions.ca |
>>>> +-----------------------------------------------------------------+
>>>> |Chief Technology Officer |
>>>> |DM Solutions Group Inc http://www.dmsolutions.ca/ |
>>>> +-----------------------------------------------------------------+
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> Dev at openlayers.org
>>>> http://openlayers.org/mailman/listinfo/dev
>>>>
>>>
>>>
>
>
> --
> Cameron Shorter
> http://cameron.shorter.net
+-----------------------------------------------------------------+
|Paul Spencer pspencer at dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
More information about the Dev
mailing list