Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Both MySQL Spatial and PostGIS support a general 'geometry' column type that can store and work with any other geometry type (well, everything except collection - which is not supported in either). It would be great to implement this as a supported data type in geo. Specifically, i'm looking to get geo_field to be able to accept points, lines, AND polygons all at the same time. We have successfully done this in openlayers module, where we are storing each geometry as a separate entity in a multi-value field (read: no 'collection').
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | full_geometry_type.patch | 1.79 KB | phayes |
| #4 | full_geometry_type.patch | 2.56 KB | phayes |
| #3 | geo_types.patch | 894 bytes | phayes |
Comments
Comment #1
allie mickaI think that geo_field is now creating fields of type 'geometry' on the database itself, but constrains the input on the Drupal level to one of the specific geometry types.
The primary reason for this is organization: Some input elements and formatters are more- or less-capable of dealing with different geometry types, and some queries are only appropriate for certain geometry types. As a Drupal developer, I'm tasked with finding generic ways of grouping and listing my datasets in a CCK/Views/Drupal UI.
By locking these down and cataloging them in one place, I'm able to decide, for example, which of Geo's datasets are an appropriate target for a Within query in Views. Or, if a formatter that can only cope with points should be available to a linestring field.
I'm open to suggestions though!
Comment #2
phayes commentedThanks for the comments,
I'll do a bit more digging and thinking on this and and give some more specific suggestions. If it's easy enough I'll just submit a patch.
Comment #3
phayes commentedAttached in a patch that extends the supported geometry types somewhat. I've added 'GEOMETRY' and assigned it to '0', bumping POINT to '1'. This patch is incomplete in the sense that it will break other code that assumes a 0 refers to a point, but I thought it made more sense if geometry was 0, since it is considered to be the 'root' in the opengis specs.
I've also added aliases to COLLECTION and LINESTRING: GeometryCollection, Line, and LinearRing. I believe my reading of the OpenGIS spec is correct that these are aliases, I would love someone to confirm for me.
Also, the OpenGIS spec has some other obscure types such as 'Triangle' etc. that might be a good idea to implement at this point, but I dont think it really matters.
If you all think these changes are good, i'll need some hints on how to find all the references where POINT references '0' to change these to '1'.
Patrick
Comment #4
phayes commentedAttached is the full patch (includes the one above) that adds support 'Geometry' in geo field.
Comment #5
phayes commentedWhoops. Previous patch included some other crud. New patch attached.
Comment #6
allie mickaHi phayes,
I'm basing these types from the GEOMETRY_TYPE value defined on page 15 of the "Simple Features - SQL - Types and Functions" document listed at http://www.opengeospatial.org/standards/sfs . I would much prefer not to move these around as to create inconsistencies with these values. I think it would be better to use NULL or GEO_UNKNOWN on the dataset level.
More importantly, as I mentioned in my first comment, is how these values are going to be used throughout the system. The primary goal of the Geo project is to make it easy to derive and draw relationships between geography data of all stripes, so they can be available for Views, maps, etc.
To facilitate this, I'm storing the geometry type on the dataset itself, so that I can determine which datasets are appropriate for, say, the target of a Within query and provide an appropriate selection in the Views interface. Additionally, some formatters may/may not be able to deal with different geometry types, so I need to know on the dataset level before trying to match up these incompatibilities.
Until we've had a discussion about how to make this work from a Drupal UI / organization perspective, I'd like to defer making a change like this. Can you elaborate on specific use cases?
Comment #7
phayes commentedAha, I was trying to find where you got those integer values from. Agreed, we should not mess with the values if they are part of the spec.
My use case is this:
I need to allow users to post either lines or points, but not polygons. This will be for a 'bicycle city repair' project where users will be able to post either places or routes that are problematic for cyclists.
From your comments I see now why my patch won't do. 'Geometry' is too general and gives no hints on how it should be handled throughout the system. I suppose what I really want to do is to be able to assign an array of geometry types as the type. This adds considerable overhead to other functions of course, which must be able to parse the array and decide whether it can work with the set of types given. Thoughts?
Comment #8
allie mickaHi Patrick,
It seems that you could go one of two routes with your use case:
* You could store info on separate fields, of separate types; and then try to put them back together via CCK formatters and/or Views.
* You could stuff them all into the same field (AKA the general 'geometry' data type you're looking for here) and then find a way to use them in the ways I've described here.
Both approaches have benefits and drawbacks, and I'm happy to discuss them here so we can come up with a workable model for your use case. Right now, I'm storing the Geo type for all of the fields, or I'm storing GEO_UNKNOWN. It's possible that we can continue doing it this way, but limit some of the places where unknown fields appear?