give projection options, or default to 4326

[mikelmaron]

No description provided.

[dodobas]

at the moment results are "hardprojected" to the http://spatialreference.org/ref/epsg/3785/ projection at ... https://github.com/hotosm/hot-exports/blob/master/custom_data_export/cde.cpp#L75
I don't know what were the reasons to do the reprojection the in the first place, or why is epsg:4326 a better choice at the moment...

This change requires modifications to the CDE C++ utility, backend export processors and RubyOnRails frontend applcation

[pnorman]

at the moment results are "hardprojected" to the http://spatialreference.org/ref/epsg/3785/

The more common name for that string is EPSG:3857.

It's also worth noting that it only attempts the string if the SRS https://github.com/hotosm/hot-exports/blob/master/custom_data_export/cde.cpp#L72 fails.

As a projection for transferring data in, 3857 is reasonable provided you aren't working outside +/- 85 degrees latitude, particularly for OSM data when most work in creating that data will have been done in that projection.

The C++ utility does calculate way_area, which is particularly meaningless in WGS84, being a non-conformal projection.

[AndrewBuck]

If we change the hardcoded projection to 4326 not only does that somewhat address this issue, but it will likely fix the bugs assosciated with issue #75 as well.