Now that we have a nice clean Interface for the OGC spec, and Geo's datasets Schema API-friendly and cataloged in the Geo API, I'm ready to start rejiggering the Views support. The bad news is that most of your existing views will break on the next release. The good news is we've got much more flexible and usable handling.

More importantly, it will be possible to interrelate geo stuff based on matching geographies. Imagine a view that can show the population of the state where your address is in, or filtering businesses based on the name of the neight

I'm posting a patch here before I finish and commit it. Please check it out and let me know what you think.

CommentFileSizeAuthor
geo_views.patch47.38 KBallie micka

Comments

phayes’s picture

phayes commented

I like the general direction where things are going. I really like the new field settings of being able to arbitrarily apply a function to geo data in order to format it as wkt, area etc.

One thing that might make this better would be to separate out the Data format (the function) from display. For example, we may want to output WKT as text, or as a map. We may want to output area as text or as a circle whose size represents the relative area. By default we can always display things as text - but it might be useful to write hooks that allow other modules to take that data and handle the display. This way geo concentrates on getting and processing the data using functions (as your currently have), but then we could leave it up to other modules to handle display.

allie micka’s picture

allie micka
she/her
commented

This big patch is committed to HEAD, by the way.

Meanwhile, thank you for your input phayes! I assume you are discussing the field handler, right? In that case, yes; this needs work.

Here's what we used to have:
* Different CCK field formatters declare what types of input they might expect/desire to work with.
* Geo attempts to provide appropriate data (wkt, array, etc) "just in time" before a node with Geo content is rendered.
* On nodes, CCK selects and caches all of its node's fields. At the time of selection (nodeapi/fieldapi:load), you can _guess_ what the field's formatter might be, but you can't _assume_ anything because someone might come along. Thus the above step must be just-in-time, not using actual queries that are supported by the database.
* For that reason, CCK fields are selected as WKB and converted as needed to arrays, wkt, etc.
* By extension, Views support has been doing the wkb-selecting and converting on the fly so that formatters can use it.

HOWEVER, continuing to support this model is both expensive and limiting for Views. Since we know what we want before the query is executed, we can just go ahead and query AsText(), X(), Y(), and so on; and output its results 'raw' with no postprocessing. Additionally, PostGIS supports other cool stuff like GeoHash, SVG, etc. natively, which will also be less expensive and will possibly let me avoid reinventing them in PHP.

Right now I've kind of thrown the baby out with the bathwater. As of this moment, The latter model is supported but the CCK Field model isn't, which means we can't show results on little individual maps and stuff (unless you use a node-based view, like a teaser view).

In the cases of anything that appears in geo_fields(), we should re-add the formatter capability so that we can leverage any existing formatter and make these fields go back to behaving like other CCK fields. However, this must be handled in a way that isn't confusing. Specifically, we want to eliminate duplicates (e.g. Longitude, Latitude, WKT, etc.).

If I understand you correctly, this may do the trick by leveraging the theme - or formatter system in Drupal rather than implementing Yet Another Hook

...?

plopesc’s picture

plopesc
he/him
Primary language Spanish
commented

Hi!

I think that this refactorization of geo views behaviors is really good. In IDELab, one of our goals is something similar to this: 

* Some handlers, in particular the distance handlers, have been deprecated.
    Instead, we're using the full power of *all* available GIS functions for
    filters, sorting and fields.  Leveraging views' number handlers, you can:
  
    - Find routes (linestrings) that are longer than 1km but shorter than 10km
  
    - Find neighborhoods (polygons) that are larger than 5 square miles.
  
    - Find businesses (points) that are within 10 miles of me (another point)

We would be very grateful if you were interested in our collaboration. We think that join forces is the best option.

Best regards,
plopesc

allie micka’s picture

allie micka
she/her
commented

Sure, I'm interested in collaboration! Go ahead and file any feature requests or discussions you think are appropriate, or patches if you've got 'em

Thanks a lot!

allie micka’s picture

allie micka
she/her
commented
Status: Needs work » Fixed

These changes have been committed. Additional support requests/features/bugs should be filed separately.

Thanks everyone!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.