>>>>> Hallvard B Furuseth <h.b.furuseth...> writes:
[...]
>>> * Create an attribute option range "coordinate-<system name>" so
>>> that you can create one attribute description set for each
>>> coordinate system:
>>> attribute "latitude;coordinate-a", value "1"
>>> attribute "latitude;coordinate-b", value "2"
>>> attribute "latitude;coordinate-c", value "3"
>>> attribute "longitude;coordinate-a", value "9"
>>> attribute "longitude;coordinate-b", value "8"
>>> attribute "longitude;coordinate-c", value "7"
[...]
>> OTOH, there'd be no way to make multiple (latitude, longitude) pairs
>> given a single coordinate system.
> True. Well, one could add a distinguising number in the "coordinate"
> attribute (see example below), but it does get quite cumbersome.
Actually, this restriction is most probably the desired one.
>> Given the schema above, would it be possible to make an LDAP filter
>> for the points lying within a rectangular region (like: latitude is
>> between 50 and 55, longitude is between 79 and 89)?
> With the values in different attibutes, you can search for
> (&(latitude>=50)(latitude<=55)(longitude>=79)(longitude<=89))
> if you define ORDERING matching rules for the attributes.
> Note however that this doesn't work right with multi-valued attrs,
> even if you disambiguate them somehow: It will match e.g. this:
> latitude;coordinate-a-value1: 10
> longitude;coordinate-a-value1: 20
> latitude;coordinate-a-value1: 60
> longitude;coordinate-a-value1: 89.5
> To get around that you'd need to stuff each position into a separate
> entry.
ACK. Thanks.
> With a single "all in one" position attribute, no it's not possible -
> unless you write a server plugin which defines a new syntax and
> matching rule. Even with simpler searches you need substring search
> which is more expensive in the server than equality search, and also
> the filter must somehow distinguish latitude from longitude.
... And also the scarcity of ``filter types'' defined for LDAP
has to play its part.
[...]
> Also, unless you have a small database you'll want a syntax which the
> server can index for efficient ORDERING searches. With OpenLDAP I
> think that would have to be INTEGER.
So, there's no support for any indexes on floating-point values
in OpenLDAP?
> Which maybe leads you to create supplementary attributes that can be
> indexed for ordering, in addition to more detailed attributes with
> the real values...
... Perhaps, some ``hybrid'' approach could be used. E. g.:
geoPosition (multi-value): to hold all the possible pairs;
geoLatitudeWGS84,
geoLongitudeWGS84: to hold the WGS 84 coordinates;
geoBBoxNorthWGS84,
geoBBoxSouthWGS84,
geoBBoxWestWGS84,
geoBBoxEastWGS84: to hold the WGS 84 bounding box.
The first attribute is to be the ``payload'' one, and the rest
will facilitate filtering. It'd be up to the client to maintain
them in sync.
> An entirely different approach would be to store this in an SQL
> database on the server and define some magic filter strings that
> translate into proper SQL searches, where you can do complex
> filtering like that. That way you'll in effect just be using LDAP as
> a cumbersome access control to SQL. Don't know if any LDAP servers
> support that though.
I hope it won't be necessary.
--
FSF associate member #7257
