juliageo / geoformattypes.jl

Wrapper types for spatial data formats like well known text, KML, Proj4 strings.

GeoFormatTypes

GeoFormatTypes defines wrapper types to make it easy to pass and dispatch on geographic formats like Well Known Text or GeoJSON between packages. This way information about what format is contained is kept for later use, - instead of passing a String or Int that could mean anything.

Wrapper types also allow methods such as convert to work with data in multiple formats, instead of defining lists of format-specific handling methods. Currently ArchGDAL.jl is privileged to define convert methods for GeoFormatTypes.jl objects, using GDAL. When it is loaded, objects can be converted from one format to another:

julia> using GeoFormatTypes, ArchGDAL

julia> convert(WellKnownText, EPSG(4326))
WellKnownText{GeoFormatTypes.CRS, String}(GeoFormatTypes.CRS(), "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AXIS[\"Latitude\",NORTH],AXIS[\"Longitude\",EAST],AUTHORITY[\"EPSG\",\"4326\"]]")

ArchGDAL.jl is not a direct dependency of GeoFormatTypes.jl, so small packages that handle geospatial formats in some way can depend on GeoFormatTypes.jl without worry about large dependencies.

One complexity of GeoFormat objects is that some formats can hold either CRS (Coordinate Reference System) or geometric data, or even both at the same time.

This is handled using the CRS, Geom and Mixed traits. When the contents are explicitly known to be e.g. crs data, then CRS can be used, for example with all types of well known text:

crs = WellKnownText2(CRS(), crs_string)

If the contents are not known, the default Mixed() will mostly do the right thing anyway - it can be converted to either CRS or geometry formats using convert, given that it is actually possible to do with the contained data.

We thank Julia Computing for supporting contributions to this package.

geoformattypes.jl's Issues

Broken link to docs

Currently the links from the Readme.md to the documentation do not work.

Specifically tell users to run `using ArchGDAL` in errors when conversion isn't possible

Rename `MixedFormat`?

Mixed has always been a bit unclear to me. Maybe we could go for Extended (like Extended WKB/WKT, which hold a CRS on top of the normal WKT), or Combined? Or just GeomCRS to remove any ambiguity altogether?

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

GeoJSON type conflicts with the GeoJSON package

What do you think @evetion? GeoJSONstring ? It would be breaking but probably a good time to break things.

Make empty CRS possible

#sdsl23

And set it to the engineering crs?

PR #22 is breaking... should a major release be issued?

#22 is breaking.

using GeoFormatTypes v0.4.1

julia> epsg = GeoFormatTypes.EPSG(4326)
EPSG(4326)

julia> GeoFormatTypes.EPSG(epsg)
EPSG(4326)

julia> typeof(epsg) == GeoFormatTypes.EPSG
true

using GeoFormatTypes v0.4.2

julia> epsg = GeoFormatTypes.EPSG(4326)
EPSG{1}((4326,))

julia> GeoFormatTypes.EPSG(epsg)
ERROR: MethodError: no method matching EPSG(::EPSG{1})

Closest candidates are:
  EPSG(::AbstractString)
   @ GeoFormatTypes ~/.julia/packages/GeoFormatTypes/UFNTK/src/GeoFormatTypes.jl:319
  EPSG(::Tuple{Vararg{Int64, N}}) where N
   @ GeoFormatTypes ~/.julia/packages/GeoFormatTypes/UFNTK/src/GeoFormatTypes.jl:316
  EPSG(::Int64...)
   @ GeoFormatTypes ~/.julia/packages/GeoFormatTypes/UFNTK/src/GeoFormatTypes.jl:318
  ...

Stacktrace:
 [1] top-level scope
   @ REPL[6]:1

julia> typeof(epsg) == GeoFormatTypes.EPSG
false

Add type parameters for compile-time dispatch on CRS

It would be useful to add at least coordinate order XY/YX and Spherical/Cartesian singletons to the CRS type.

This may let us wrap point with e.g. y/x order in the CRS, and dispatch to the correct distance/area methods. Having these in the type means we can use them for low level operations with no overheads.

These parameters could be nothing by default. At whatever point they to be used we could parse the CRS with Proj/ArchGDAL and fill in the parameters, or as the worse case / status quo - assume they are x/y, and just error for area/distance.

It may be that some other object could hold these parameters instead, but it seems like it should be attached to the CRS object to keep things simple.

It may also be useful for users to be able to specify the X/Y order manually because many other tools also do not follow the crs point order.

Should we merge this with the new GeoInterface?

Would be nice to define these kind of abstract types there so everyone can use them, but I'm not sure how necessary that would be.

Add WKB and extended variants

Well Known Binary (WKB) is a binary format, akin to WKT. Both these formats also exist in the Extended format (EWKB, EWKT), that prefix the CRS information, as used in PostGIS. See https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry#Format_variations.

Decide on blessed conversion implementation or API

Related to #2.

With JuliaGeo/Proj.jl#74 Proj could also convert between GFT.CRS instances. Proj itself is a lighter dependency than ArchGDAL, and is actually what GDAL itself uses (indirectly).

Add Ellipsoid type?

Should we add an Ellipsoid type to GeoFormatTypes?

This is what I'm using in my work:

"""
An ellipsoidal representation of the Earth surface 
"""
struct Ellipsoid
    a::Float64        # radius of the ellipsoid
    e::Float64        # eccentricity of the ellipsoid
    name::Symbol      
    epsg::EPSG
    # of the const instance in the package!
end