[OSM-dev] Plan: Stop having amf_controller reproject

Christopher Schmidt crschmidt at metacarta.com
Mon May 12 13:55:00 BST 2008

On Mon, May 12, 2008 at 01:01:19PM +0100, Tom Hughes wrote:
> In message <20080512113010.GE29009 at metacarta.com>
>         Christopher Schmidt <crschmidt at metacarta.com> wrote:
> > So, I started hacking on amf_controller last night, and one of the
> > things that makes amf_controller more 'special' than it needs to be is
> > server side reprojection with the basex/basey/masterscale stuff.
> >
> > Having just chatted with Richard, the plan for solving this going
> > forward is:
> >  * I create a branch of the rails_port from trunk
> >  * I change the server side code to work exclusively in lat/lon
> >  * Richard updates potlatch to match
> >  * We work with someone (Tom?) to merge the work into trunk
> >  * Then merge the resulting changes into the api06 branch
> >
> > This should let the code be a bit less confusing to anyone trying to
> > work on it; at the very least, it makes the amf API calls not
> > as potlatch-specific. 
> Fine by me - if you fancy working with Richard to do any more
> cleanup beyond that on the AMF API then that would be very
> helpful as far as I'm concerned...

Small things first, but yeah, that's my hope eventually: That I work on
learning a bit more about amf_controller, and then through that, I
understand enough abuot amf_controller and the rails code that I can
migrate some of the Very Scary code away. A bunch of the code will need
to be changed for api06: I think the right fix is to migrate the code to
rails objects where possible, rather than simply updating the SQL :) So
hopefully some of that can be done in trunk, and then there's less work
to be done in the api06 branch.

Christopher Schmidt

More information about the dev mailing list