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 <[EMAIL PROTECTED]>: >> 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@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
