[GeoJSON] Aligning implementations
cholmes at openplans.org
Mon Apr 9 13:35:53 PDT 2007
Tim Schaub wrote:
> 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
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
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.
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.
> geojson mailing list
> geojson at lists.geojson.org
The Open Planning Project
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 282 bytes
Desc: not available
More information about the GeoJSON