map_coords() should work recursively on Feature and FeatureCollection

[dharasty]

map_coords() has an obvious use case in transforming the geometry of features.

It should operate on Features and FeatureCollections, as well.

[hramezani]

What should be done for this issue?

[dharasty]

I just checked the current state of the code, and I think map_tuples() does what I propose.
So... OK w/ me to close the issue!

Note: these docs don't reference map_tuples(). Why is that?

[rayrrr]

We are making some improvements around the map_ utility functions and will improve the docs along the way.

[dharasty]

I regularly use projected coordinate systems for calculations (using pyproj4, for example). I recommend that python-geojson should support this workflow:

Given:

• a pyproj4 projection
• geojson data in lng/lat format

Process:

• a call to map_geometries() or map_tuples() with the projection
• resulting in data in, say, meters in x, y
• do calculations on the projected data (angles, area, etc)
• allow side effects (such as shift in meters) with other calls to the map_*() functions
• a call to map_geometries() or map_tuples() with the inverse projection

Output:

• geojson data in lng/lat format, with the appropriate operations applied.

That, IMO, is a great use case for map_geometries() or map_tuples(). I hope you support it. From what I can see, it looks like you do... but some examples or test cases to confirm would be great.

[rayrrr]

Hi @dharasty, while the 2008 version of the GeoJSON spec supported multiple Coordinate Reference Systems, the officially adopted RFC standard removed that support and fixes the CRS to WGS84 for all GeoJSON objects. Section 4 of RFC 7946 states:

In general, GeoJSON processing software is not expected to have access to coordinate reference system databases or to have network access to coordinate reference system transformation parameters.

So I don't think we should support handling data in other CRS formats directly in this package. However, your original request, support for Feature and FeatureCollection objects in map_coords(), was just merged to master. Can you checkout the master branch and let us know if it meets your needs in that regard?

[mathuin]

This issue does not appear to be fixed in v2.5.0.

If I understand correctly, running bar = map_coords(lambda x: x, foo) where foo is a FeatureCollection object should result in bar being an identical FeatureCollection object. Instead, bar is a dict. I am unaffected by the other changes with quoting and property order but some others may not be.

Perhaps this fix needs revisiting?

>>> from geojson import FeatureCollection, Feature, Point
>>> from geojson.utils import map_coords
>>> foo = FeatureCollection([Feature(geometry=Point((1.234, 5.678)))])
>>> type(foo)
<class 'geojson.feature.FeatureCollection'>
>>> print(foo)
{"features": [{"geometry": {"coordinates": [1.234, 5.678], "type": "Point"}, "properties": {}, "type": "Feature"}], "type": "FeatureCollection"}
>>> bar = map_coords(lambda x: x, foo)
>>> type(bar)
<class 'dict'>
>>> print(bar)
{'type': 'FeatureCollection', 'features': [{"geometry": {"coordinates": [1.234, 5.678], "type": "Point"}, "properties": {}, "type": "Feature"}]}

EDIT: it is worth noting that geojson.dumps() output for both objects is identical in quoting and order.