don't mix x/y and lat/lon about geo HOT 17 CLOSED

You are right, for geographic coordinates lat/lon are very useful. But there are also non-geographic (e.g. projected) spatial coordinates where lat/lon makes no sense.
I think that each algorithm should only use one of them and generic algorithms should only use x/y.

from geo.

@Indy2222 This feature exists in the form of the optional Project and Convert traits, see #192 (note that the MapCoordsFallible trait has become TryMapCoords. As of now, the vast majority of Geo's functionality is predicated on planar coordinates (or coordinates in planar projections), which is signalled by the use euclidean for clarity where necessary, and haversine for e.g. spherical coordinates.

from geo.

How do people feel about dropping the lng and lat methods? Would that be a satisfying resolution here?

from geo.

Great, let's deprecate them then with the plan to remove them in a future breaking change release.

from geo.

What do you propose? removing getter/setter lat/lon?

I think that these getter/setter are very useful. Else, when we work with geographical coordinates, using x and y is very error prone.

from geo.

Does anyone know what similar libraries use? (e.g. go.geo, OGR, etc.)

from geo.

@jdroenner I agree with that

from geo.

JTS uses x,y (z)
The OGC Simple Feature Access also defines points as x,y (z).
The OGC spec is implemented in most database systems (Oracle, SQL Server, PostGIS, Mysql).

from geo.

boost geometry use

double x = bg::get<0>(point);
double y = bg::get<1>(point);

As you should implement that for your own struct, you can use whatever you want.

from geo.

We could change Coordinate to be a tuple to get .0 and .1 ;)

from geo.

@jdroenner please no ;)

from geo.

I'm fine with x, y, lng, lon, lat. I'm against .0 and .1 because it's not obvious if the user is dealing with longitude, latitude or latitude, longitude.

from geo.

Relevant: http://www.macwright.org/lonlat/

from geo.

Well i guess the important part is to not mix x/y and lat/lon. Can we enforce this somehow?

@frewsxcv web based GIS is an area where very strange things happen ;) The axis ordering in WMS was switched between two versions and this is still confusing.

from geo.

It would be nice if geometries could be projected between different spacial reference systems (#32) in which case lat() and lon() would have to be projected to WGS84 SRS. For example a hypothetical GIS GUI may need to project geometries to Web Mercator [and its pixel coordinates] to draw them as overlay of a map. For example see GeoJSON.io.

I personally prefer attitude where geometric libraries are coordinate system agnostic (i.e. it behave like the coordinates are Cartesian) and doesn't force users to use any specific projection. For example if one needs accurate but local SRS she can use UTM zone, etc. Different projections are good for different purposes and from my experience its best to separate geometrical library and projection library from each other. I this context lon(), lat() getters stay in the way.

from geo.

I think so. The only potential users of lat / lng I can think of might be the CanalTP people, just because it's an older codebase. In any case, we could deprecate with a "we'll be dropping this in 1.0" message?

from geo.

#710

from geo.