>>>>> Michael Ströder <michael...> writes:
[...]
>> * designate some ``standard coordinate system'' (like: WGS 84) for
>> the attributes (like: `latitudeWGS84', `longitudeWGS84'); convert
>> the values on the client side whenever a non-standard coordinate
>> system is to be used;
[...]
>> To my mind, the first approach leads to potential information loss,
>> as there may be rounding errors in the conversion process, or there
>> could simply be no conversion function at the moment when the data
>> is to be stored.
> Hmm, from the schema design approach I'd prefer the first
> possibility.
Actually, I haven't investigated on these conversions much, so
I'm not sure that it would always be ``appropriate'' (from a
geographer's standpoint) to perform such a conversion.
>> The last approach seems to be the most flexible. However, I don't
>> know if it's possible to ``tie'' attributes into such a ``triples''
>> with LDAP? Should these triplets be granted its own syntax and,
>> consequently, an attribute? (like: geoSurfacePoint.)
> Defining your own LDAP syntax would be the solution (similar to
> RFC2307 NIS Netgroup Triple, OID 1.3.6.1.1.1.0.0).
ACK. Thanks.
> But encouraging all the LDAP server vendors to implement an
> additional syntax can take some time. ;-)
The system I'm working on is going to have somewhat narrow field
of use, so, in practice, it would probably be sufficient to
provide a single implementation (did I say OpenLDAP?) supporting
the syntax.
The question is, how would an LDAP DSA (DUA) treat attributes
having the syntax unknown to it? Would it, e. g., simply treat
their values as binary strings?
> Also it would require to define name/ID registry
Do you mean anything specific by ``ID'' here?
> for all the coordinate systems and encourage people to register their
> coordinate systems.
This could be the easiest part, as there're already developed
``vocabularies'' of coordinate systems. In particular, I
believe WKT [1] uses one.
[1] http://en.wikipedia.org/wiki/Well-known_text
--
FSF associate member #7257
