Remove (standalone) GeoAPI #70
Comments
airbreather
added
the
breaking change
Most of this belongs to
Not that this could not be handled differently, though. I also did think about some use-cases for geometry definition without actual topological functionality:
The question however is, would the possibility to create ones own geometry definition ever be adopted by anyone or would everyone stick with NTS geometry. |
|
After having thought about it a bit more, a candidate for a limited Thats why I invite @danames and @jany-tenaj to comment. |
I did touch on SharpMap in the other comment:
Wouldn't you still need to ensure valid topology after the transformation in order to do it correctly?
This is what sent me off on this thread. I doubt it.
As it pertains to this specific issue, it looks like they are very much using the NTS algorithms (this is one of the first files that came up when I searched their repo for uses), so I don't think they'd be profoundly impacted if As it pertains to #30, DotSpatial does look like the best candidate for |
|
Hey guys, thanks for thinking about our project as you make these changes
to NTD. I’m going to defer to @jany-tenaj As my teaching and research low
lately has kept me from making many contributions or edits to the core of
DotSpatial. Though I continue to use it in my projects and benefit from
the updates that the rest of the team are making :-) Dan
On Thu, Mar 28, 2019 at 5:36 AM Joe Amenta ***@***.***> wrote:
- plain map rendering
I did touch on SharpMap in the other comment:
- SharpMap seems like it may be a candidate (I haven't looked at it in
much detail). But...
- Doesn't even that have to clip / ensure valid topology / do basic
intersection testing?
- reprojection service
Wouldn't you still need to ensure valid topology after the transformation
in order to do it correctly?
The question however is, would the possibility to create ones own geometry
definition ever be adopted by anyone or would everyone stick with NTS
geometry.
This is what sent me off on this thread. I doubt it.
the folks at DotSpatial.
As it pertains to this specific issue, it looks like they are very much
using the NTS algorithms (this
<https://github.com/DotSpatial/DotSpatial/blob/2c2302778278e61a01143b1ea6c8126a3ae8198e/Source/DotSpatial.Plugins.Contourer/Contour.cs#L201-L211>
is one of the first files that came up when I searched their repo for
uses), so I don't think they'd be profoundly impacted if
IGeometryDefinition moved to NetTopologySuite.Core.
As it pertains to #30
<#30>, DotSpatial does
look like the best candidate for IGeometryDefinition that I've seen so
far: their changes all seem to be to add more consistent Z/M support, and
although a lot of that is already in develop (with more coming once
NetTopologySuite/NetTopologySuite#303
<NetTopologySuite/NetTopologySuite#303> gets
merged), their version of Envelope does have Z/M stuff that JTS's still
does not (plus, of course, other changes to support setting the Z / M
bounds on Envelope instances).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#70 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADT89M4rYaTSDekDGywX8dvq-wc996Ouks5vbKkqgaJpZM4cNw94>
.
--
**********************************************************************
Daniel P. Ames, Ph.D., P.E.
Professor, Civil & Environmental Engineering,Brigham Young University,
Provo, Utah, USA
President, International Environmental Modelling & Software Society
Editor-in-Chief, Environmental Modelling & Software
http://ceen.et.byu.edu/content/dan-ames
http://www.researchgate.net/profile/Daniel_Ames
http://scholar.google.com/citations?user=S0GUCeUAAAAJ
**********************************************************************
|
|
I have to say when I switched the code to NTS I was wondering what GeoAPI was good for. It felt senseless to have to go there to have to look there for some of the files while most where in NTS. Not sure whether this IGeometryDefinition would be good for us. Basically I cloned your code to get M/Z into it, because when I tried to use our own ICoordinateArraySequence (if I remember correctly) for the geometries as @FObermaier had suggested, the problem was that whenever I gave those geometries to NTS it returned Nts geometries that no longer contained M/Z. So this was basically useless. Because we did just a few changes I don't see a big problem with just updating the source code from time to time to stay up to date. |
|
Now, as there does not seem to be much support for standalone GeoAPI, let's do as @airbreather suggested:
|
|
@FObermaier If you remove IGeometry what will we get instead? Just asking because we use IGeometry quite a lot. |
|
GeoAPI started as an attempt to make this in .net code, but faster I realized that the effort was too big for my time and knowledge, and I thinked that eventually can be useful to have an "interface layer" that hides actual NTS implementation, even if actually GeoAPI interfaces matches closely NTS implementations, just because of program to an interface, not to an implementation. Your points are all valid, so if all of youy think GeoAPI it's only a complication, I of course don't have any objection. |
You have the abstract |
|
@DGuidi thank you for providing the context and for challenging me to respond with more justification on this big change. OGC GeoAPI 3.0.1 doesn't specify much that's relevant to NTS Core, but some relevant stuff it does specify is significantly different from what's currently in JTS. Our This is a big deal on its own, but it goes even further when you look at some of the pending stuff. So with regards to the parts of our GeoAPI.NET interfaces that came from JTS, in short, I get the feeling that we'd be better served waiting for those parts of the specification to be finalized and then (if there's demand for it) implementing the GeoAPI standard as a dedicated effort with a direct line of communication open with the OGC as we do so to ensure that we conform to the specification (and, perhaps, to offer our own feedback). In the meantime, it's a burden for a bunch of reasons I've mentioned. re: the parts of OGC GeoAPI that our GeoAPI.NET implements more faithfully (coordinate reference / transformation stuff), I don't think that what we have is all that bad. That said, I have a guess that it's also hardly used independent of ProjNet4GeoAPI. Given that it's still not a complete port of the relevant parts of OGC GeoAPI 3.0.1, and given that the rest of OGC GeoAPI 3.0.1 is not likely to be implemented in .NET anytime "soon", I feel that the benefits of bringing GeoAPI.NET along as a standalone part of NTS v2 are not worth the ongoing costs.
I'll get started on this once NetTopologySuite/NetTopologySuite#303 is finished.
I'm not going to immediately jump on this, certainly not at the same time as absorbing GeoAPI.NET into its implementations. I didn't want this issue to get too bogged down by the concerns of #67 / #68, as those concerns are different (albeit related) and have their own costs / benefits.
@jany-tenaj yeah I expect as much... #68 implies a non-trivial effort for most downstream folks to migrate from v1.x. I hope it doesn't get received as being too bad, but it's not something we should do lightly. |
|
|
Oops I was kinda hoping I couldn't entirely resolve this issue from a commit in a different repository, since there's still the coordinate system stuff. |
Looks like this is done. |
After #68 (comment) I've been thinking hard about this, and the more I do, the more confident I feel in saying that standalone GeoAPI feels like a solution in search of a problem.
As I mentioned in that linked comment, maintaining GeoAPI as a standalone thing means maintaining a separate Git repository, complete with its own separate GitHub issue tracker and its own separate milestones, containing a separate Visual Studio solution that builds two separate NuGet packages exposing types in their own separate namespaces.
This is a lot of separate stuff we have to maintain, and users probably see it as an arbitrary division (frankly, I do too, every time I have to add more
usingstatements). We also often have to update both together anyway when porting new JTS updates, which adds a bit of a burden from time to time. There does not seem to be enough value here to justify all this cost, and I have not yet seen a proposal which would add the value that I claim is missing.Even if we do something like the
IGeometryDefinitionidea from #68 (comment), that bundle of interfaces seems equally fit in theNetTopologySuite.Corepackage, especially since moving the mathematically interesting capabilities off of the GeoAPI interfaces only seems to decrease the already low number of use cases that could be satisfied with a reference to theGeoAPI.Corepackage without also referencing theNetTopologySuite.Corepackage.So I propose that we put this GitHub project in maintenance mode (keeping it on 1.x), move the useful types it exposes into other projects in the NetTopologySuite organization starting with version 2.x, and continue ongoing efforts to redesign the API over there.
It's very tempting to try to do some of that redesign as part of this, but I think this issue needs to be focused on just moving what we already have (warts and all), only adjusting namespaces at most.
I volunteer to write up the specific details of where everything should go, once there's a consensus on whether or not to do this at all, but for the most part (I'm sure there would be exceptions):
GeoAPI.Corepackage would go somewhere under this folder, which becomes theNetTopologySuite.Corepackage.GeoAPI.CoordinateSystemspackage would go under this folder, which becomes theNetTopologySuite.CoordinateSystemspackage.If we do this, it's important that we keep the ability to trace the history of the moved files... probably, the commit on the "moved-to" side should include "
as of NetTopologySuite/GeoAPI@d2b5ecb" (or whatever commit) when it adds the files so that we can click that link to go back to the history of the file on this side.The text was updated successfully, but these errors were encountered: