Seeking help about projnet4geoapi HOT 8 OPEN

The timing on this might be finally right. I've been using NetTopologySuite for a few years now, and I haven't contributed to any open-source stuff before, but I use it so frequently that I'd love to help out with both that project and ProjNet4GeoAPI when I have time. I'm very impressed with what you guys have built, and have added some extensions of my own locally. The main goal for me, initially, would be to get Orthographic projections into this library, but being new to all this, any advice or recommendations would be much appreciated

from projnet4geoapi.

Yeah, the goal would be to try to support the bug fixes necessary to keep it alive. I just figured I'd get my feet wet and learn the code by working on something I feel more confident with, rather than just jumping into the deep end on issues I'm not familiar with.

That said I definitely don't have time to singlehandedly support this, so I guess we'll see how far it goes, but I think it's worth the effort initially

from projnet4geoapi.

I' m too interested in contributing. My expertise isn't in Projections but more to make small Bugfixes. When I'm familiar with the Code base I might contribute more but I can't promise yet anything.

from projnet4geoapi.

my2cents: any improvement is weel accepted, of course. but as far as I understand, you are planning to extend a library, but the library itself can not be supported by the original maintainers, so to me it's basically up to you to decide if you want to invest in a library that is marked as "obsolete". also: maybe worth do a little check and see if the suggested solutions (see main page) already supports your use cases.
of course this improvement could make sense if you plan also to support the library, just because it's up to you to fix the bugs you find using the library itself.

from projnet4geoapi.

It is great, @tommygebhardt and @inforithmics that you are willing to help. PR's and code review is a good start to get involved.
Thanks!

from projnet4geoapi.

I found the need to have EPSG codes associated with the projection, which is why I found this library much more useful than the DotNetSpatial.Projections library. However, I found out that only WGS84 and WebMercator are the only two systems implicitly referenced.

As a result, I took GDAL's projection database which uses PROJ6 (https://gdal.org/tutorials/osr_api_tut.html) to get all the authorities and codes. Then looped through it and gathered the WKTs for roughly 7k of the 10k database entries. I did this by stripping the WKTs from https://spatialreference.org/ref/ and also from https://epsg.io/. Many of the codes were either not found or there was parsing issues in the WKT from these two websites.

Question is, would the database I gathered be useful in this project or would it cause bloat that you don't want in the project? Right now, I have the database stored as a csv; the columns are: name, alias, authority, code, type (projected/geographic/etc), isDeprecated, and WKT. it is around 5Mb. It could be embedded as a csv or an sqlLite db (as it is in GDAL), it could be made smaller to remove all the deprecated codes, it could be split up based on the the type of coordinate system (GCS/PCS), etc. Thoughts?

from projnet4geoapi.

@gktval, I see two possible use cases:

• Use it within the unit-tests for WKT parsing
• Enhance CoordinateSystemServices to possibly use a configuration file like the one you created.

from projnet4geoapi.

I tested loading the file into the two dictionaries, but it was super slow. So instead I have already put it into an sqlite database so that the indexing was faster. I had also fixed up several of the parsing error, such as you explain in #106. There were a few other parsing issues than just the EXTENSION tag that I found. I may submit a PR when I get it cleaned up, but I am unsure what to do with the dictionaries... I also added Net7 to the build.

from projnet4geoapi.