juliageo / geoformattypes.jl Goto Github PK

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.

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.

#sdsl23

And set it to the engineering crs?

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).

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

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!

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?

#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

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.

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

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