[OpenLayers-Dev] projection on geometry
Tim Schaub
tschaub at opengeo.org
Wed Nov 12 02:50:33 EST 2008
Hey-
Eric Lemoine wrote:
> This design makes sense to me.
>
> Regarding the strategy: are you thinking of a projection strategy that
> will listen on beforefeaturesadded and, if the layer proj isn't the
> same as the map proj, will reproject the features before they're added
> to the layer? Such a strategy would be useful when the data isn't read
> through a format.
I was thinking that any strategy that makes a call to the protocol
should be wise to projection.
For the BBOX strategy, this looks like:
http://trac.openlayers.org/browser/sandbox/topp/wfs/lib/OpenLayers/Strategy/BBOX.js#L114
and
http://trac.openlayers.org/browser/sandbox/topp/wfs/lib/OpenLayers/Strategy/BBOX.js#L211
For the Fixed strategy, it looks like:
http://trac.openlayers.org/browser/sandbox/topp/wfs/lib/OpenLayers/Strategy/Fixed.js#L58
Obviously some code to be shared.
The Save strategy is one that manages "writes". This is a bit funky
because you actually want to send clones to the protocol:
http://trac.openlayers.org/browser/sandbox/topp/wfs/lib/OpenLayers/Strategy/Save.js#L31
Once there are other strategies that implement similar stuff, we can
cull out the common parts.
Tim
>
> Eric
>
> 2008/11/11, Tim Schaub <tschaub at opengeo.org>:
>> Hey-
>>
>> Picking up on the thread that Bart just referenced:
>> http://www.mail-archive.com/dev@openlayers.org/msg02523.html
>>
>> I agree, we should keep track of projection at the geometry level.
>>
>> There are plenty of times that you have a geometry without a feature or
>> a layer, and you want to maintain the srs info for that geometry.
>>
>> I've always thought this change would come with 3.0. But it probably
>> makes sense to start working it in to see how things go.
>>
>> Seems to me like we need a setter and getter. So the following would work:
>>
>> polygon.setProjection(foo);
>> polygon.components[0].components[0].getProjection(); // foo
>>
>> And it makes sense to me to push the work on to the setter (setting the
>> same on all components), making access less work.
>>
>> I think it also makes sense to me that the layer does not set the
>> geometry projection. We assume that geometry projection is properly set
>> before a feature is added to a layer. This pushes the setting or
>> transforming closer to the parsing (where it makes sense that you'd know
>> the projection).
>>
>> In some cases, a format would do the transform (assuming
>> internal/externalProjection are set). In other cases, a strategy could
>> do the transform (since it knows the map projection and the layer
>> projection - where the layer projection should be set to match the source).
>>
>> I'm sure there's lots more to talk about. This is what a sprint is good
>> for. Without that, it probably makes sense to get some code going and
>> see where it takes us. To this end, I've created a new sandbox [1]. I
>> won't have any time for a bit to work on it, but I'll be happy to comment.
>>
>> Tim
>>
>> [1] http://svn.openlayers.org/sandbox/projection
>>
>>
>> --
>> Tim Schaub
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>> _______________________________________________
>> Dev mailing list
>> Dev at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
More information about the Dev
mailing list