Subject: [Geojson] RFC 7946 - composing geometry objects with "mixed" positions

From: Udo Schochtert <[email-masked]>
Date: Tue, 25 Apr 2017 14:31:06 +0200

hi,

I have a quick question regarding RFC 7946 specs.

according
  https://tools.ietf.org/html/rfc7946#section-3.1.1
a position is an array of numbers which MUST have 2 elements and SHOULD not
extend beyond 3 elements.

so a valid Point (containing 2 elements) is
{
  "type": "Point",
  "coordinates": [100.0, 0.0]
}
and one containing 3 elements
{
  "type": "Point",
  "coordinates": [101.0, 1.0, 1.0]
}
is valid as well.

my question is if the following MultiPoint (composed by"mixed" positions)
would be valid as well

{
  "type": "MultiPoint",
  "coordinates": [
    [100.0, 0.0],
    [101.0, 1.0, 1.0]
  ]
}

that would also apply to other geometries composed by"mixed" positions as
well (e.g. LineString, Polygon, etc.). correct?

thanks, udo

---

From: Erik Wilde <[email-masked]>
Date: Wed, 26 Apr 2017 17:59:35 +0200

hello udo.

On 2017-04-25 14:31, Udo Schochtert wrote:
> my question is if the following MultiPoint (composed by"mixed"
> positions) would be valid as well
>
> {
>   "type": "MultiPoint",
>   "coordinates": [
>     [100.0, 0.0],
>     [101.0, 1.0, 1.0]
>   ]
> }
>
> that would also apply to other geometries composed by"mixed" positions
> as well (e.g. LineString, Polygon, etc.). correct?

that's a good question. afaict, there is nothing in the spec language 
that keeps you from doing this. however, the semantics are unspecified. 
it is not clear if positions without elevations should have elevation 
zero or "inherit" the elevation of the last elevation-labeled position. 
my suggestion would be to not use this "mixed model", but that's just my 
personal opinion.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Tim Schaub <[email-masked]>
Date: Wed, 26 Apr 2017 16:11:55 +0000

There will be parsers that make assumptions about the consistency of
dimensions. So while not strictly invalid, you'll likely sacrifice
interoperability if you plan to share data with inconsistent dimensions.

Tim

On Wed, Apr 26, 2017 at 8:59 AM Erik Wilde <[email-masked]> wrote:

> _______________________________________________
> GeoJSON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geojson
>

---

From: Udo Schochtert <[email-masked]>
Date: Wed, 26 Apr 2017 20:53:37 +0200

erik, tim, thanks for your feedback.

I was thinking about this because I contributed to the python-geojson
project to help fix issue
  https://github.com/frewsxcv/python-geojson/issues/79
with pull request
  https://github.com/frewsxcv/python-geojson/pull/92/files
which now supports processing of positions containing 3 elements (the
altitude/elevation being the 3rd element).

I was wondering how the validation should treat the "mixed" scenario and
what the specs would recommend.

I understand that having "mixed" geojson data is not good and should be
avoided.

for me the question is answered.

thanks, udo