[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
GeoJSON.
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.
Right.
>
> 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,
--
Eric
More information about the Community
mailing list