Thursday, September 20, 2007

GeoJSON redux

Sean Gilles has a post responding to my call for a simplified coordinate representation in GeoJSON. His argument is that clarity of representation is more important that implementation overhead which I agree with to some extent.

However, it seems to me that the reason that JSON is so much better than XML for many purposes is exactly that it *does* take into account implementation overhead, thereby making it easier to exchange internal data structures without the overhead of XML.

For any sane implementation of JSON, the following must be extracted as a list of lists:

[ [x1, y1, z1], ..., [xn, yn, zn] ]

So a list of 10,000 coordinates will give you 10,000 lists of 3 floating points each. Or 10,000 list structures and 30,000 floats. Each list takes time and memory to create and address and extract the elements out of. Whereas:

[ x1, y1, z1, ..., xn, yn, zn ]

gives you the same 30,000 floats but only one list. A big win for any standardized JSON reading algorithm. Creating a custom, context sensitive JSON parser to ignore the structure is more than a little implementation detail.

Strangely, after Sean argues against removing context information to improve clarity, he then requests just that. He suggests that the "type" element that describes what kind of GeoJSON element you are looking at be removed since it should be obvious from the type of request that you made to receive the GeoJSON content. What if one were to receive a set of files with various different sets of data, some single features, some feature sets and perhaps some just geometry elements? If you remove the type field from the geometry elements, how would you know what kind of geometry you have? You couldn't tell a Point from a Polygon without the type field.

All that said, I do have another simplification for GeoJSON that is unrelated to the previous issues. How about we do away with the 'Point', 'LineString' and 'Polygon' geometry types. No really. They are just special cases of 'MultiPoint', 'MultiLineString' and 'MultiPolygon' with one element. I find myself writing code to take the special case single element entities and put them into the more general multi-element entities. That is code I would much rather not write since it introduces complexity and potential bugs. The only real difference in the two is the lack of a "Multi" and an extra set of an enclosing brackets.

7 comments:

Sean said...

Why not extract the JSON coordinates (list of lists) into your own favored data structures (vectors of x, y, and z or whatever)? You don't have to buy the JSON structure entirely. It's a wire format.

"Type" is necessary for geometries because one can't otherwise distinguish between otherwise identical multipoint and linestring representations. Geometry "type" also lets GeoJSON geometries implement a tiny bit of the OGC SFSQL (standard geometry types). "Type" on features and collections is just a crutch.

Your situation of receiving a set of files that might contain any random mix of GeoJSON objects is something that you need to prevent. That's an engineering problem.

matt_giger said...

The same could be said the other way around, you could extract every three coords into a list if you like. However to use a standard JSON library like Python's simplejson, you are out of luck.

Yes "type" is required for geometry, but without it, you also couldn't have the "GeometryCollection" type of feature, which would be fine with me. Feature and GeometryCollection should be merged and the "geometry" element of the Feature class should be a list of geometries rather. "Box" can go away to be replaced with a "bounds" Feature element. I think that the spec need some serious simplification.

I guess we are coming at it from very different perspectives. I am coming from standpoint of having GeoJSON as a standard data format for static and dynamic content. It seems like your position using it as a short-lived transactional format. It should be able to do both.

Sean said...

That's right: I'm only using JSON in HTTP requests.

matt_giger said...

Perhaps I should take some time out and propose a GeoJSON spec...

Sean said...

Simplejson is easy to extend. See http://trac.gispython.org/projects/PCL/browser/GeoJSON/trunk.

IMO, GeoJSON isn't useful as a general purpose GIS data format. For starters, there's no specification of metadata.

Abedo Ahmed said...

لا داعى للقلق وانت تتعامل مع شركة اركان المملكه للتنظيف والمكافحه والتسليك
وغير ذالك من كافه انواع التنظيف فى المملكه السعوديه باكملها اذا
كل ما عليكم هو زياره صفحتنا للتطلع على اقل الاسعار المتاحه
والتى تفى احتياجاتكم الخاصه
شركة مكافحة حشرات بالدمام



شركة مكافحة حشرات بابها



شركة رش مبيدات بجازان



شركة مكافحه حشرات بالاحساء



شركة رش مبيدات بالرياض



شركة اركان المملكه

شركة تنظيف بابها

شركة تنظيف فلل بابها

شركة تنظيف بالدمام

شركة تنظيف منازل بالرياض

شركة تنظيف منازل بابها

شركة تنظيف منازل بخميس مشيط

شركة تنظيف شقق بالدمام

شركة تنظيف بجازان

شركة تنظيف بالاحساء
اتصلوا بنا دائما تجدونا فى كل وقت وكل مكان
لاننا نتعامل بمنتهى الدقه والفعاله والاهميه الكبيره مع شركة
اركان المملكه لاداعى للقلق نحن معك دائما

Abedo Ahmed said...

اتصلوا بنا تجدونا اينما كنتم وفى كل وقت وكل مكان
نتعامل معكم بافضل جوده واحسن اداء واقل الاسعار
مع شركة اركان المملكه انتو تتعاملون مع افضل شركة بالمملكه ككل
لاننا شركة زات باع كبير فى عالم التنظيف على مر السنين ونعمل باقصى جهد من اجل راحتكم اولااا
:::::::::::::::::::::::::::::::::::::
شركة كشف تسربات المياه بجازان




شركة كشف تسربات المياه بخميس مشيط



شركة كشف تسربات المياه بابها



شركة كشف تسربات المياه بالدمام



شركة كشف تسربات المياه بالرياض

شركة نقل اثاث بجازان



تسليك مجارى بالدمام


شركة تسليك مجارى بخميس مشيط



شركة تسليك مجارى بجازان


شركة تسليك مجارى بنجران

شركة مكافحه حشرات بخميس مشيط

شركة تسليك مجارى بابها

شركة نقل عفش بالرياض


شركة نقل عفش بخميس مشيط

مع شركة اركان المملكه نحن معك دائما وحولك نقدم لك كل ماهو جديد وفعال
بمنتهى القوه والسرعه ندعوكم دائما لزياره مؤسسه اركان المملكه للتمتع بكل ما هو جديد وفعال