<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>[GeoJSON] Aligning implementations</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText14592 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Hello everyone,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr>[my name must be very new to members of this list, but I've been
reading this thread for quite some time, and since I have some experience with
the topic, I thought I'd share it with you]</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> geojson-bounces@lists.geojson.org on
behalf of Chris Holmes<BR><B>Sent:</B> Sat 4/7/2007 7:07 PM<BR><B>To:</B>
geojson@lists.geojson.org<BR><B>Subject:</B> [GeoJSON] Aligning
implementations<BR></FONT><BR></DIV></DIV>
<DIV>
<P><FONT size=2>Ok, I'd like to take a shot at lining up the
proto-implementations and<BR>perhaps putting some words down on the
wiki.<BR><BR>The big open question for me right now is if geometry is a top
level<BR>property, as in OpenLayers/PCL at the moment<BR><BR>{<BR>
'id': '1',<BR> 'properties': {<BR> 'title':
u'Feature 1',<BR> 'summary': u'The first
feature',<BR> 'link': <A
href="http://example.org/features/1">http://example.org/features/1</A>,<BR>
}<BR> 'geometry': {<BR> # WGS84 crs is
implied<BR> 'type': 'Point',<BR>
'coordinates': [-105.8, 40.05],<BR> }<BR>}<BR><BR>Or do we want
geometry as just one of the properties:<BR><BR>{<BR> 'id':
'1',<BR> 'title': u'Feature 1',<BR> 'summary': u'The
first feature',<BR> 'link': <A
href="http://example.org/features/1">http://example.org/features/1</A>,<BR>
'geometry': {<BR> # WGS84 crs is
implied<BR> 'type': 'Point',<BR>
'coordinates': [-105.8, 40.05],<BR> }<BR>}<BR><BR><BR>Is there some
javascripty advantage to putting geometry as a special<BR>property? I
suppose it makes it easier to get at the geometry, not<BR>having to dig in to
the property array?</FONT></P><FONT size=2></FONT></DIV>
<DIV><FONT size=2>
<P> </P>
<P>IMHO, there's no advantage at all. </P>
<P>Making use of the geometry will be _much_ more costly than digging in the
property array anyway. </P>
<P>Typically, you'll want to do things like:</P>
<P> * Showing the envelope/footprint of the geometry on the map (therefore
toying with the DOM tree of the browser)</P>
<P> * Edit that geometry (toying with the DOM + computations +
all-the-logic-inside-to-allow-that)</P>
<P>Both those are more costly than a simple lookup in an array of objects.</P>
<P>Moreover, in the WFS's XML output representation, a geometry is a property
like any other. I don't think there's a good reason to not follow that
convention.</P>
<P>Now, about "designing the default geometry property": I think that
kind of information should be present in the feature type information. If you
mean to do anything solid with features in the browser, you'll need that
information anyway, so I think it'd be a good idea to put that extra bit in that
place.</P>
<P>Best regards,</P>
<P> Arnaud</P>
<P> </P>
<P> </P>
<P><BR><BR>I think one potential issue with geometry as a top level property
is<BR>what if you have a feature with more than one geometry? This
is<BR>certainly not that uncommon (though I concede it does break us out
of<BR>'simple features'), like including the bounds with the geometry
(which<BR>we could do with a special envelope property), or say a feature that
has<BR>both the lot geometry and the building geometry.<BR><BR>Thoughts?
I'm fine with either, I just never heard explicit<BR>justification for the
change to geometry on the top level.<BR><BR>Chris<BR><BR>--<BR>Chris
Holmes<BR>The Open Planning Project<BR><A
href="http://topp.openplans.org">http://topp.openplans.org</A><BR></P></FONT></DIV>
</BODY>
</HTML>