postgis

[elcolie]

Do you have plan to support postgis? For example search that read the point and distance at the same time

[carltongibson]

Not really... what would it need? Custom Filter subclasses?

[elcolie]

Yes and it receive 2 inputs at the same time. I had read the doc. It does receive only 1 input at a time

[Andrew-Chen-Wang]

@carltongibson @elcolie Also looking into some GeoDjango functionality, specifically a PointField (or MultiPointField) with a circular radius around (each) point. It really helps when using with location based apps. I'd be willing to help, but Carlton knows much more about Django than me, so I'd like some assistance in knowing what to write before starting a draft PR.

Some pointers that we could do for the (Multi)PolygonField would be distance from, within, or on the edge. Not sure about the LineStringField.

I guess some issues with supporting GeoDjango is the extent of it all. I had a lot of confusion when programming my first geolocation-based app with Django, so clear communication would be necessary for Django-filters.

I guess another issue would be which database to allow in tests/settings.py for geolocation development. For most people, that'd be using PostGIS (we can add the geolocation database in runtests.py by adding an arg for database name). Setting up Travis won't be a problem (although, should we test on multiple Postgres and/or Postgis versions? Not entirely supportive of SQLite geolocation extension...).

Idk, thoughts? Like how would I/we go about this? I'd much rather have the geolocation functionality in the main repo rather than in a plug-in repo so that everything is simultaneously updated.

[carltongibson]

OK... SO...

A django-filter Filter is (at most):

• A widget, which maps query parameters to a basic python value. Most times one of Django's widgets is enough, but what does the query string look like here? ... ?center_point=LAT:LONG — You tell me. GeoDjango ships widgets.
• A form field. Again often a Django form field, or here a GeoDjango field, is what we need. Validate the the value from the widget, covert it to a more complex type, maybe.
• A Filter, that takes the value from the form field, and a queryset and does queryset.filter(field_name=value) — so what does that look like if you're just doing it by hand in your view?

So some examples. And then what of those are needed?

[Andrew-Chen-Wang]

Thanks for the reply! I think I was more focused on url encoded filtering and basically neglecting forms -- the ui -- altogether. Addressing points:

• That's what I was initially thinking regarding the query string (since the current app I've got is heavy DRF). I was thinking ?point__within=LON:LAT:RADIUS with an additional query string for units (if using django.contrib.gis.measure.Distance) like units=m. Another option to not need the units query string would be to have a default, overridable setting (not sure if that's already part of GeoDjango).
• A weird case would be trying to see if a (multi)point was inside a (multi)polygon. In that case, I wouldn't know a good query string to use. Or a polygon intersect another (multi)polygon. In that case, the user input would be something like a LineString in which you input the vertices of the polygon. We could raise an exception if the polygon doesn't actually form (I think creating a Polygon itself would raise an exception if input was incorrect).
  • Obviously, we could try to url encode some brackets and tuples to represent a polygon; the construction of polygons should just be Polygon([(0,0), (1,2), (3,4), (0,0)]). Weird case is multipolygon.
  • Django filters really just maps out the field lookups, no?
• Converting to a django.contrib.gis.geos type doesn't seem too difficult... at least based on what I've been seeing. For a polygon, input an array of values. The Point is just xy(z).
• I'm a little confused what you mean "doing it by hand in your view." Are you talking about someone who wasn't using Django filters and instead using request.GET to fill out a filter query?

I'm not too well versed about the Django widgets, so I'm not too well aware about their methods of mapping out the multitude of field lookups for GeoDjango (within, covers, intersects, etc.).