[Geojson] Draft version 6 in restructured text and HTML

Tim Schaub tschaub at openplans.org
Thu Mar 27 13:14:12 PDT 2008


Hey-

Christopher Schmidt wrote:
> On Wed, Mar 26, 2008 at 05:37:16PM -0600, Tim Schaub wrote:
>> Hey-
>>
>> Sean Gillies wrote:
>>> The only changes I made were 1) a little restructuring to keep the CRS
>>> section from going 6 levels deep, 2) change "location" to "geometry" in
>>> the blog example.
>>>
>>> http://zcologia.com/sgillies/hg/geojson-draft/raw-file/tip/geojson-draft-6.txt
>>> http://zcologia.com/sgillies/hg/geojson-draft/raw-file/tip/geojson-draft-6.html
>> This looks great Sean.  Thanks for reworking it.
>>
>> In an effort to test all ideas before we go final, I'd like to get 
>> feedback on one more:
>>
>> Instead of:
>>
>> "crs": {
>>      "type": "name",
>>      "properties": object
>> }
>>
>> and
>>
>> "crs": {
>>      "type": "link",
>>      "properties": object
>> }
>>
>> What about:
>>
>> "crs": {
>>      "link": object
>> }
>>
>> and
>>
>> "crs": {
>>      "name": string
>> }
>>
>> ?
> 
> Doesn't this go back to the same reason we require type on everything
> else? Having switch(obj.type) seems useful to me. Am I wrong here?
> 

A point can not be represented as a linestring (in a well understood 
way).  A feature collection cannot be represented as a point (in a well 
understood way).

A single crs can be represented by a link, by a name, and by many other 
conventions.

> Should we go back to discussing whether feature objects need a type?
> After all, we can work out what they are by looking at the other
> properties.

No, that is silly.

> 
>> If people like that, then there is a second thing to consider:
>>
>> whether
>> 1) you can specify either a "link" member or a "name" member, or
>> 2) you can specify one or more of "link" and "name" (and perhaps others 
>> in the future).
> 
> Note that there is no reason you can't do thsi under the current spec.
> The behavior just isn't defined by the spec -- you can always add other
> properties.
> 

Draft 6 suggests that data providers choose one way to represent a crs 
("type": "name" or "type": "link").

However, there is no well defined way for a client to specify what they 
understand.  A client cannot say "give me all your features and describe 
the crs with links."

The link idea for crs is cool.  It is also new.  Should all GeoJSON 
creators go with link type crs representations and wait until all 
clients catch up?

Tim

> Regards,




More information about the GeoJSON mailing list