-
Notifications
You must be signed in to change notification settings - Fork 19
convert to module types #85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
This looks like a nice solution to me. So the only thing that What about packages that offer multiple point types, e.g. This also still needs docs. Also: fixes #80 |
|
Yeah mostly just the for that Another option is to make it an agreed apon package method instead of a shared interface: (In GeoJSON.jl) traittype(::GI.PointTrait) = Point
traittype(::GI.LineStringTrait) = LineString
traittype(::GI.PolygonTrait) = Polygon
traittype(::GI.MultiLineStringTrait) = MultiLineString
traittype(::GI.MultiPolygonTrait) = MultiPolygon
traittype(::GI.GeometryCollectionTrait) = GeometryCollectionand here just do: function convert(package::Module, geom)
convert(package.traittype(package, t), t, geom)
endWhich seems kind of cleaner actually, and doesn't have the module name sharing problem. And yes the abstract type thing can just be worked out by the package |
|
That does look better indeed. So how do we proceed? I think #66 can already be merged and is not breaking right? And we can at any point already start moving implementations over from Base to GeoInterface convert, or we wait for this to be tagged and also add in the convert to Module methods from this PR directly. For packages moving from Base to GeoInterface convert is breaking however. GeometryBasics already uses GeoInterface.convert, but ArchGDAL and LibGEOS still use Base.convert. I haven't checked others yet. |
|
Yes I think this is better. I've written the GeoJSON.jl implementation. ArchGDAL will likely have to return a single abstract type from Yes let's merge #66 Edit: this is updated to be my second proposal, with I'm wondering if the function should be called |
3372b72 to
c748850
Compare
|
Added a test - this should be good to merge. |
|
LGTM if you fix the tests ;) nitpick: geointerface_traittype(trait) should be the inverse of |
|
I'm a bit confused by your |
Ah, that was because we both have geomtrait(geom) as trait(geom). The latter being more generic, also working for feature. So the inverse of But this is all semantics, I'm up for merging as is. |
|
Renamed to |
This PR adds the method:
GeoInterface.convert(Package, geom)I still need to add some tests with a dummy module.
@evetion and @visr what do you think of this
traittypeas the interface method that returns a geometry/feature type for a corresponding trait?As we have discussed packages will only have to define that method, e.g. in GeoJSON is all that is needed for
convert(GeoJSON, geom)to work (along with the actual basicconvertmethods I'm also adding now):