[Featureserver] GeoJSON, setting CRS in FeatureServer/OpenLayers

[Christopher Schmidt]

On Mon, Dec 17, 2007 at 05:35:34PM +0100, David E. Reksten wrote:
> On 17/12/2007, Josh Livni <mailing_lists at umbrellaconsulting.com> wrote:
> > The changelog for 1.09 notes 'Insert bogus CRS into GeoJSON' - line 35
> > of GeoJSON.py does that.
> 
> Thanks for the hint, knowing this it was easy to patch GeoJSON.py to
> hardcode the (only) CRS we're using here. It seems that the beta
> builds of FME 2008 is a bit picky about CRS values, it will only
> accept "EPSG", not "OGN" values.
> 
> FYI: I had to change the keyword "features" to "members" in line 35 as
> well, for FME to accept the GeoJSON string. Very cool to insert
> features in your browser using OpenLayers, then read them back with
> FME directly from the web service!

Note that both of these mean that FME is a rev behind in GeoJSON spec
following.  members  -> features was a change we made in r5, I believe. 


> > I'd expect a patch to read an additional crs or (srid or whatever)
> > parameter in the cfg file would be easy, but I'm not sure if that's the
> > appropriate place to put that sort of info (What happens your datasource
> > has multiple srids, but your query result only displays one?  No idea...)
> 
> Why not store (and return) an individual CRS for each feature?

Store where? Keep in mind that with the exception of the DBM and sqlite
datasources, we don't have any way to add columns to store additional
attributes: we simply represent the data as it is.  

Regards,
-- 
Christopher Schmidt
MetaCarta