Point with 3 coordinates or more does not pass validation while valid as per the GeoJSON specs

[lafrech]

Please excuse me if I'm mistaken, but as I was reading the GeoJSON specs, I came accross a paragraph mentioning positions with more than two elements:

A position is represented by an array of numbers. There must be at least two elements, and may be more. The order of elements must follow x, y, z order (easting, northing, altitude for coordinates in a projected coordinate reference system, or longitude, latitude, altitude for coordinates in a geographic coordinate reference system). Any number of additional elements are allowed -- interpretation and meaning of additional elements is beyond the scope of this specification.

In python-geojson's validator, this is explicitly forbidden:

code:

    if isinstance(obj, geojson.Point):
        if len(obj['coordinates']) != 2:
            return output('the "coordinates" member must be a single position')

tests:

    def test_invalid_point(self):
        point = geojson.Point((10, 20, 30))
        self.assertEqual(is_valid(point)['valid'], NO)

If my understanding is correct, the validator should allow any number of elements greater than of equal to two.

The same change was made in MongoDB:

• https://jira.mongodb.org/browse/SERVER-9220
• mongodb/mongo@bd489b1

[frewsxcv]

If my understanding is correct, the validator should allow any number of elements greater than of equal to two.

You are correct. The validation logic should allow for >= 2 elements for each position.

[lafrech]

Maybe a _dimension attribute could be added to GeoJSON. It would be set in __init__(), defaulting to None.

The validation logic would check that a position is made of >=2 elements if _dimension is None, or that it is made of exactly _dimension otherwise.

This way, the user could validate that the object has the required dimension.

Adding this feature would allow compliance with the spec while allowing people actually relying on the validation to adapt with a few changes (basically, just passing _dimension=2 at object instantiation).

[frewsxcv]

I'd like to keep this library as close to the spec as possible, and since the spec doesn't mention 'dimension' anywhere relevant, I'm hesitant to include such a feature.

[lafrech]

I understand.

This is something a user can add by subclassing GeoJSON, anyway. People relying on current validation will probably have to do something like this.

[gfhuertac]

Just to comment
It should not be >= 2 but 2 or 3 according to the latest RFC (7946).
https://tools.ietf.org/html/rfc7946#section-3.1.1

Implementations SHOULD NOT extend positions beyond three elements
because the semantics of extra elements are unspecified and
ambiguous.

[udos]

@frewsxcv , was really glad to find this library some time ago but now I miss the 3rd element badly.
I'm using it to generate LineStrings for gps trails in which the 3rd element would be the elevation... without the 3rd element it is impossible to use the lib in this context.

please reconsider extending it because it would then be covering also this part of the GeoJSON specs.
p.s.: thumbs up for a really helpful lib!

[frewsxcv]

I don't have much time to look into this right now, but if someone wants to open a PR for this, I'll gladly review it.

On a similar note, if anyone wants commit access to this repository if they want to maintain, please let me know and I'll happily add you. Alternatively, I could also create a python-geojson GitHub organization, transfer the repository, and add people there if people prefer that.

[frewsxcv]

Fixed in #92