-
Notifications
You must be signed in to change notification settings - Fork 282
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
Removing newly introduced GDAL dependency (again) #336
Comments
I can't think of any other reasons. I'd also welcome a PR adding back the fallbacks if it works on all versions supported (2.2 through 3.2). |
@karimbahgat I'm looking at doing this because my own project could use it, and the surgery is still easier for me than writing my own django maps admin widget. GDAL just doesn't install easily, especially in dockerized environments. Do you want me to share my work with you? |
Loading django-leaflet without installing the GDAL stuff would be really nice. Any updates on this? |
I know this is an old issue now, but would like to show my support. It would be great to not have the GDAL dependency unless you actually use something from GDAL. |
django.contrib.gis requires GDAL and uses it for coordinate transformations. It is very common to use a different SRID on a map than the SRID used to store geometries in the database. |
This is true but simple apps (e.g. just storing a list of locations in lat/lon, which might only ever be submitted through the app itself and therefore will never need any transformation) wouldn't require any gdal functionality at all. It's just two decimal numbers. The issue here is that when someone has an idea for a very simple web app that might display some very simple data on a map, they immediately think of leaflet as a quick and easy way to do this. It is quick and easy, in javascript. But then they find there is a django library, great. But they need GDAL, for no particular reason at all. This was my exact thought process over the last two hours. Off topic but there is a library pyproj that does co-ordinate transformations without gdal at all. |
100% agree @apwebber , and well put! Been a while since I looked at this, but I don't believe leaflet ever uses the projection abilities of the django.contrib.gis geometry wrappers. Dropping the gdal dependency would be a huge benefit for minimal effort, especially since the solution already exists and can probably be copied from the older versions where a fake non-gdal geometry wrapper was implemented. @kayagoban if you were able to fix the issue for your project, I'd suggest just submitting a PR to the main repo, even if it isn't perfect / doesn't solve all issues. It will make it easier for others to contribute the remaining parts. |
What a frustrating experience :) |
Any updates on this? |
I'm no longer involved in the django world, and this issue is so old that I can't remember enough to start again. Sorry I cannot help :/ |
Continuing the conversation from #332.
A recently introduced change added GDAL as a dependency to django-leaflet (see #299), resulting in a number of raised issues. In my opinion, there should be no reason to hang on to this dependency, it only hampers the ability of many users and light-weight applications which struggle or for other reasons cannot use GDAL,. Especially since django-leaflet as well as django-geojson has been touted and become known as lightweight packages that "just works" for non-gis users and simple websites (e.g. https://fle.github.io/easy-webmapping-with-django-leaflet-and-django-geojson.html, https://heds.nz/posts/leaflet-maps-django-geojson/). Opening this issue now to start the conversation on how this might be possible, before I can get around to a PR.
The only reason django-leaflet now requires GDAL is that it relies on
GeometryField
andBaseGeometryWidget
fromdjango.from django.contrib.gis
. However, nothing about these classes uses anything of the actual GDAL library, it's only that importing fromdjango.contrib.gis
triggers a GDAL check. Previously, there was a fallback to a.nogeos.py
or.backport.py
module within django-leaflet which implemented the same classes but without requiring GDAL, but this was removed in #282 seemingly in the name of dropping support for Django < 1.8?Unless I'm missing something here, when I get the time I will submit a PR that reintroduces the old fallbacks. Were there any other deeper reasons why the fallbacks were dropped?
The text was updated successfully, but these errors were encountered: