[Community] inheriting from geojson.codec.PyGFPEncoder

Eric Lemoine eric.c2c at gmail.com
Sun Jul 13 11:41:55 EEST 2008

On Sun, Jul 13, 2008 at 9:08 AM, Matthew Russell
<matt.horizon5 at gmail.com> wrote:
> Hello Eric,
> I think it's should be ok to subclass PyGFPEncoder, although I'm at best
> dubious about the name, i'm not even sure what GFP stands for!

Not sure... GIS Feature Protocol?

> I think that decimal.Decimal usage is likely so common that perhaps
> PyGFPEncoder could handle decimals by default.

It's so common that simplejson default encoder (JSONEncoder) should
handle it, don't you think?

> Since Decimal(float_obj) is not allowed:
>>>> Decimal(1.1)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File
> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/decimal.py",
> line 648, in __new__
>     "First convert the float to a string")
> TypeError: Cannot convert float to Decimal.  First convert the float to a
> string
> perhaps "Encoder.default" should convert to str/unicode instead of float.
> (Is conversion of decimal > float lossless?)

If the encoder converts to str/unicode, then we'll end up with strings
in the GeoJSON. I don't think that's what we want - one wouldn't
expect numeric column values to be represented as strings in the

But I don't know whether the decimal to float conversion is lossless?
Definitely something I need to consider...

> There's no need to do the "import as _dumps" and wrap dumps, since
> geojson.dump(s) pass through their arguemnts to simplejson:
>>>> geojson.dumps(obj, cls=MapFishJSONEncoder)

Right. I just did that to test MapFishJSONEncoder without having to
modify the rest of the code.

> Assuming it can be arranged such that decimals in input GeoJOSN get
> encoded correctly with geojson.dump(s), and are retuned as decimals in
> the result of geojson.load(s), I think it'd be a nice-to-have in geojson.
> Regadless, provdiing a custom encoder should always be ok,
> with the proviso that the super class contract is obeyed. (this should be
> documented in geojson).
> i.e ommiting the "super" call to PyGFPEncoder.default would obviously
> break geojson encoding.


> Sorry to be verbose, in summary I'm +1 for PyGFPEncoder being part of
> the public API (but under a more sensible name),
> and +0 on adding decimal support to geojson

+1 on having PyGFPEncoder being part of the public API.

-0 on adding decimal support to geojson, because I think decimal
support should go into simplejson instead.

Thanks a lot Matt,


More information about the Community mailing list