[Geojson] Representation of empty

[Sean Gillies]

Hi Arlo,

It's my understanding (possibly wrong) that empty geometries exist in
SF so that we can represent very exactly the results of certain
geometric operations in the point set model. The point set
intersection of two disjoint non-empty figures, for example, is an
empty point set. The favorite location or last known location of any
physical thing (like the person in your example) can't really be an
empty set. It may be unknown, but that's different, and perhaps best
conveyed by omitting the attributes entirely.

Still, I think the empty arrays you propose come the closest (within
the restriction Tim points out) to capturing the OGC sense of empty
point sets. A mix of empty and non-empty arrays will inflict a lot of
pain on consumers, and is best avoided IMO. In other words,

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

instead of

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

Regards,

On Wed, Jun 29, 2011 at 12:21 PM, Arlo Belshee
<Arlo.Belshee at microsoft.com> wrote:
> 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

-- 
Sean Gillies
Programmer
Institute for the Study of the Ancient World
New York University