Spatial Reference System of geometries about geo HOT 16 OPEN

My 2c is that this should be low on the list of priorities. While projected data is an intense focal point of traditional GIS, its modern relevance is iffy. Here's the author of PostGIS saying that projected data is mainly a case of legacy technology and expectations. Libraries like Shapely and Turf successfully avoid the question of projections, doing calculations in WGS84 only and expecting users to project on the way in & out if they must. And for that, we have the very robust proj4 library, which one fellow has already started porting into rust.

Relative to other priorities at this early stage, my personal instinct is that dealing with projected data shouldn't be one of them. We should make a distinction between x/y points and lat/lon points, but after that distinction is made, a distance algorithm should only deal with lat/lon points.

from geo.

I agree with @tmcw. At least for now, I think it makes sense to leave projections out of rust-geo for now. If anyone is particularly interested in projections though, feel free to create a new repo+crate under the GeoRust organization and experiment.

from geo.

And for that, we have the very robust proj4 library, which one fellow has already started porting into rust.

BTW https://github.com/georust/rust-proj

from geo.

Even if the most data created today (locations / GPS) is in WGS84 there are a lot of datasets with different coordinate systems. So a geometry should have a type or field representing its CRS. My experience is that no matter what you do there is always one dataset with an esoteric coordinate system ;)

I agree that transformations between CRSs should be handled by an other crate (e.g. proj) and algorithms like distance should only be implemented for WGS84. A type/ filed could be used to bound algorithms to coordinate systems (e.g. WGS84).
If you want to use proj4 for transformations you still need some information about the CRS. Or are you suggesting that rust-geo will only allow WGS84 geometries?

from geo.

Or are you suggesting that rust-geo will only allow WGS84 geometries?

Yep, this is what I'm suggesting: geographic data in georust would normally be represented as lng/lat and would not have a CRS field. Reproject in and reproject out if you need compatibility. We'd document this, and support rust-proj: this approach doesn't ignore the fact that there is lots of projected data in the world, but it tries to limit the complexity creep that data would cause and contain the problem.

from geo.

Reproject in and reproject out if you need compatibility.

So i would need a second crate to load/represent my geometries with different coordinate system?

from geo.

Actually what I wonder is that generally meter projection are more accurate for distance and surface. And it is a pity to limit our self to WGS84.

In GRASS GIS all the data in a Location are with the same CRS (you can not even import in a location a dataset with a different one). This solve the problem to check every time if two data have the same CRS or not.

But then we still have to store somewhere the CRS, to be able to properly convert (through rust-proj) into lat/lon when using lat/lon method of a point.

from geo.

Actually what I wonder is that generally meter projection are more accurate for distance and surface. And it is a pity to limit our self to WGS84.

Can you go into more detail here? There's quite a bit of datum FUD in the geo industry, and not much of it is backed up by research or evidence.

I'm suggesting reprojecting in & out; this would not limit rust-geo's usefulness to WGS84: it'd simply require people to reproject on the way in and the way out, instead of rust-geo reprojecting internally.

from geo.

rust-geo doesn't need to handle transformations internally :)
Maybe we could create a trait for SRS/CRS with a method to get the corresponding proj4 string or the projection ID (e.g. Epsg code ). This should be enough to use an external crate (e.g. rust-proj) to handle transformations.
A generic type could be added to the geometrys to prevent mixed SRSs.
We could also add type aliases for WGS84 geometrys to make them easy to use...

I will try to create a prototype to see if this is to complicated :)

from geo.

While projected data is an intense focal point of traditional GIS, its modern relevance is iffy.

FWIW, I work in Ag, where we deal with a large number of different projections--often times in UTM projections--so I'd argue against this. I wouldn't necessarily argue that this functionality should belong in this library, but it could be nice to have a pointer to how to deal with this topic in the Readme, for those of us in this same bucket. This library looks really cool, but without the ability to transform geoms, I probably couldn't use it.

from geo.

I wouldn't phrase it quite like Tom did, but the 2D algorithms in this library (and GEOS, and CGAL) assume coordinates in ℝ2.
Could you say a bit more about what might be lacking, @turboladen? I was under the impression (but I only work with one or two local projections, hence the questions) that in general, you project coordinates into a local (conformal?) projection (using PROJ.4, or PROJ.5, soon), "on the way in", treating the projected coordinates as lying in ℝ2 for the purposes of operations on them, and re-project back into whatever system you need "on the way out".
As such, there's nothing to stop you doing that today, using https://github.com/georust/rust-proj (I've actually never used it, and it could use some examples, but it looks pretty straightforward) for the re-projection steps.
I think everyone wants to see support for practical workflows, and I'm definitely interested in knowing more about how other people use (or want to use) the Rust-Geo libraries, so if there are functionality gaps or documentation gaps, let us know.

from geo.

Sure, I'm happy to share--I'm not yet using Rust for GIS things, but would like to, and would in general just like to see Rust grow more (and succeed) in that space.

I work in Agriculture, so we have quite a few ways we use GIS data. We've been using GDAL for much of what we do since we deal with both raster and vector data, and sometimes need to go back and forth between the two. (I'm not suggesting that this project support raster data, just conveying what we deal with.)

Lots of our customers use shapefiles for passing data around; many GIS-enabled tractors, for example, can accept a shapefile that essentially translate into instructions for the tractor to apply some product (herbicide, pesticide, fungicide, etc). Working with this data requires it to be projected into EPSG:4326. Once the app that ingests the shapefile receives it, it's dissected apart into vector data and any other relevant field data (thus the shapefile is no longer relevant).

We also deal with satellite imagery raster data, but often times need to extract vectors from those. That data can be defined in any number of projections, depending on the source of the data. One of our sources uses UTM projects (which can actually be a pain if we need to work with adjacent rasters, but they're in different UTM zones). Another raster data source uses EPSG:3857.

We also consume and use SSURGO data (soil sampling data) which has everything projected into ESPG:4326. Our frontend apps generally want everything projected into EPSG:3857.

...and that's just a handful of uses for us.

If we get projected data from some source, sometimes we like to store it in the same projection, sometimes we don't. It depends on the feature set. Sometimes we need to massage data from a source before storing it--I never really considered transforming it to ℝ2 for working with it, then transforming it back; that seems a bit wasteful.

My initial comment stems from... I initially jumped in to rust-geo's docs looking for how to reproject geometries (since that's a common thing for us when using GDAL), but landed on this ticket after some poking around. I expected this behavior to be here, but understand rationale for leaving it out. ...thus I expected to see some mention of the topic of "projections", but didn't find one. It'd be great to mention in docs somewhere that the library doesn't do this. It'd be even greater to have even just one example of using something like rust-proj and rust-geo together since to me, that's common functionality I'd need. My initial, cynical response to not seeing anything about the topic in your docs was to say to myself: "eh, this library is really young. I should use something else," and click away back to google ...when in reality you guys have specifically kept that "feature" out for a reason.

Like you said, it is common to use varying GIS libraries in conjunction. As such, I think it's a benefit to all of these projects to say "here's what we do well; here's what some other things do well. Here's how you can use things together for solving bigger picture problems." I think I could use something like rust-geo for some specific use cases, so it's nice to see it active and doing good things. 👍

from geo.

Thanks, @turboladen that's really helpful (also interesting! I had no idea tractors were using shapefiles, although it makes perfect sense).
With regard to the practical stuff:

I never really considered transforming it to ℝ2 for working with it

I was being unclear there – I should have said "in cases where you want to keep your data in a geographic coordinate system, but use a projected system to work with it".

In terms of actually talking about and using projections, I think there are a few things we could do for now:

1. Make it clearer that this library (currently) makes no assumptions about the SRS of your coordinates
2. Add some documentation to Rust-Proj
3. Make it easy to use Rust-Proj with map-coords, similar to the way in which Shapely can take a pyproj instance as input to its transform method. This would give us an ergonomic way to apply arbitrary EPSG projections to geometries. – we can specify rust-proj as an optional dependency.

I have no idea how 3 is going to work yet, but it should be pretty straightforward to implement. @frewsxcv @rory what do you think?

from geo.

I would really like to see some progress on this issue 😄
In my experience data sets with non WGS84 CRS are still very common.

My original idea was to use the type system to separate WGS84 geometries from others. Any ideas about that?

from geo.

@urschrei Awesome. I think any/all of those 3 options would be helpful.

from geo.

See #192 for (hopefully) some progress~

from geo.