[Geojson] Representation of empty

[Arlo Belshee]

The thing is, these are the same types as regular Point & LineString. They are valid instances of these types, according to (at least my read of) OGC SF. So representing them as new types isn't quite right - and adds complexity to interop.

I hear you about the value always being an array. Given that, and the OGC empty defs, is there any reason not to represent them as empty arrays?

{
  "type": "Point",
  "coordinates": []
}

{
  "type": "MultiLineString",
  "coordinates": [[], [1,2], [3,4], []]
}

Thoughts?

Arlo

-----Original Message-----
From: geojson-bounces at lists.geojson.org [mailto:geojson-bounces at lists.geojson.org] On Behalf Of Tim Schaub
Sent: Wednesday, June 29, 2011 10:58 AM
To: geojson at lists.geojson.org
Subject: Re: [Geojson] Representation of empty

Hello Arlo-

I think what you've proposed below is a legitimate way to serialize the data you're working with.

If you're expecting otherwise uneducated parsers to deal with this data, I imagine you'll run into problems - it does not strictly follow the specification for coordinates (from 2.1 "The value of the coordinates member is always an array.")

If you wanted to be able to handle these "empty" geometries in your parser and not trip up otherwise strict parsers, you could use a different value for the type member.  E.g.

{
     "type": "EmptyPoint",
     "coordinates": null
}, {
     "type": "EmptyMultiLineString",
     "coordinates": [null, [[1, 2], [3, 4]], null]
}

As long as you are not trying to include these as geometries in feature 
objects, the spec doesn't have anything to say about them.

Tim

On 6/28/11 4:33 PM, Arlo Belshee wrote:
> I have a question. Looking through the archive, I found a related
> discussion in 2007. However, it doesn't quite apply to my situation, so
> I wanted to see what the community recommends.
>
> First, some background. I'm working on adding spatial data support to
> the OData standard (http://odata.org). OData exposes strongly-modeled
> data. We're adding support for geospatial data types as primitives.
> We're using the OGC SF types, minus Feature & FeatureCollection. We've
> got our Entity data modeling stuff to do everything features were
> designed for and more.
>
> The question: given that, how do I represent on OGC EMPTY value in GeoJSON?
>
> Example (without EMPTY):
>
> { "d" : {
>
> "results": [
>
> {
>
> "__metadata": {
>
> "uri": "http://services.odata.org/Foursquare.svc/Users('Neco447')",
>
> "type": "Foursquare.User"
>
> },
>
> "ID": "Neco447",
>
> "Name": "Neco Fogworthy",
>
> "FavoriteLocation": {
>
> "type": "Point",
>
> "coordinates": [-127.892345987345, 45.598345897]
>
> },
>
> "LastKnownLocation": {
>
> "type": "Point",
>
> "coordinates": [-127.892345987345, 45.598345897],
>
> "crs": {
>
> "type": "name",
>
> "properties": {
>
> "name": "EPSG:4326"
>
> }
>
> },
>
> "bbox": [-180.0, -90.0, 180.0, 90.0]
>
> }
>
> },
>
> { /* another User Entry */ }
>
> ],
>
> "__count": "2",
>
> } }
>
> So, what do I do if the value of LastKnownLocation is the one the is
> written in OGC WKT as "Point EMPTY"? And similarly, what would I do for
> the corresponding value to "MultiPolygon EMPTY"? I do want to maintain
> the type distinction - these values do have different meaning. And, of
> course, the most fun one: "MultiLineString(EMPTY, (1 2,3 4), EMPTY)".
> Yes, I know that last one doesn't mean anything different than the
> LineString would, but such twisted values can show up in our users' data.
>
> Assume that all these examples are in some planar coordinate system, so
> there's no confusion about mapping order of lat/long.
>
> Given that, my supposition would be to represent these as:
>
> {
>
> "type": "Point",
>
> "coordinates": null
>
> }
>
> {
>
> "type": "MultiPolygon",
>
> "coordinates": null
>
> }
>
> {
>
> "type": "MultiLineString",
>
> "coordinates": [null, [[1, 2], [3, 4]], null]
>
> }
>
> Does this match the expectations among the GeoJSON community?
>
> Thanks for your help.
>
> Arlo
>
>
>
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
_______________________________________________
Geojson mailing list
Geojson at lists.geojson.org
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org