[GeoJSON] Aligning implementations

[Chris Holmes]

Tim Schaub wrote:
> Hey-
> 
> Chris Holmes wrote:
>> Ok, I'd like to take a shot at lining up the proto-implementations and 
>> perhaps putting some words down on the wiki.
>>
>> The big open question for me right now is if geometry is a top level 
>> property, as in OpenLayers/PCL at the moment
> 
> ...
> 
>> Or do we want geometry as just one of the properties:
> 
> My thinking:
> 
> What does every feature have?  Some way to be identified (id), some 
> geometry (geometry), and a bunch of other attributes (properties).
> 
> Can you have a feature without geometry?  No, that's silly.
I definitely have a set of users who want to be able to serve up data 
even if it doesn't have a geometry.  I know it's a bit silly for 
displaying on openlayers, but there could be other applications that 
make use of it.

Though I'm still fine with it being top level, just as long as it can be 
null.

My concern, though, isn't so much about geometry not being useful as top 
level, it's more wondering about what I do when I have two geometries. 
How do I decide which one to put in the default position?  How do I 
represent the one that's not in the default position?

If I'm creating geojson from a database that has two geometry columns, 
what do I do?  Right now I definitely have users who have databases like 
this.  I'm ok if the answer is 'we're doing simple features for now, 
just pick one as the default and make the other a string that says 
'geometry''.  I just want to raise the issue, since I'm going to have to 
code something to deal with it.

I think Sean's suggestion of overloading the envelope is interesting. 
I'm still not sure how I feel about it though.  I'll respond to that one 
separately.

We probably should have an optional envelope param though, as I 
definitely have a set of users who appreciate that value for 
multi-geometries - they can zoom in to a certain area without have to do 
a ton of computation.


> Ok, I know that's a bit narrow, but continuing in that same vein - if 
> I'm writing an application that reads GeoJSON, I'm going to make it 
> break if a feature comes in without a geometry.  
You're going to have it break?  I would just not display it - if 
GeoServer broke whenever it encountered a null geometry users would not 
be happy.  Sometimes people have good reasons for null geometries (have 
the attributes, but haven't got the exact location) and sometimes they 
have bad ones.  But breaking may not be the best thing.

I guess my take on both of these is dealing with actual databases and 
dumping them out to GeoJSON.  We already have a core feature model that 
deals with nulls and multiple geometries, and I need to figure out how 
I'm going to dump them out to GeoJSON.

Chris

If a feature comes in
> without a title or a link, I'll continue on without flinching.  That 
> suggests to me that geometry and title don't belong in the same place 
> (both under properties).
> 
> Of course, all of this only becomes a rule if enough people think in the 
> same way.
> 
> Are things like envelopes and links fundamental components of a 
> geographic feature for others?  Obviously, I see utility in more than 
> what I've proposed - but I think it makes sense to sort out requirements 
> before getting into options.
> 
> Tim
> 
> _______________________________________________
> geojson mailing list
> geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20070409/271d37c4/attachment.vcf>