W3C home > Mailing lists > Public > public-sdw-wg@w3.org > June 2015

Re: UCR issue: phrasing of CRS requirement(s) [SEC=UNCLASSIFIED]

From: Peter Baumann <p.baumann@jacobs-university.de>
Date: Mon, 1 Jun 2015 14:00:17 +0200
Message-ID: <556C4951.4080905@jacobs-university.de>
To: Bruce Bannerman <B.Bannerman@bom.gov.au>, "frans.knibbe@geodan.nl" <frans.knibbe@geodan.nl>
CC: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Hi Bruce,

this is a mindblowing idea. I'll be curious about how to model this, and how to
craft service definitions (like simple subsetting) in future.

-Peter


On 06/01/15 00:27, Bruce Bannerman wrote:
> Hi Peter and Frans,
>
> Just to add a little more complexity to this use case:
>
>   * There is an emerging concept of a dynamic datum, where the datum is
>     regularly adjusted to take into account a number of factors, including:
>     adjustment for continental drift; update of the geoid model as better data
>     becomes available; fixes for errors; etc.
>
>   * In Australia, in my domain, we expect this to become an issue to address
>     after the release of our GDA 2020 datum. Other domains may need to work
>     more quickly.
>
> We have an increasing number of people discussing the benefit of a dynamic
> datum, particularly in relation to an increasing number of precision location
> use cases such as precision agriculture.
>
> Therefore it will be important to know 'when' locations were collected in
> addition to what SRS datum was used to constrain the coordinates. The 'when'
> will also need to be constrained by a temporal datum.
>
> We are starting to think about the implications that this has for effective
> spatial data management and for the software and standards that we use with
> the data.
>
> For a little more on this see from the Australian Intergovernmental Committee
> on Surveying and Mapping:
>
>   * [1], Note discussion on Stage 2 goals. 
>   * [2], slides 31 - 32. The rest of the slide pack may also be of interest.
>
> Bruce
>
> [1] http://www.icsm.gov.au/geodesy/index.html  
> [2] http://www.icsm.gov.au/publications/PCG-SSSC_2013_Canberra.pdf
>
> --------------------------------------------------------------------------------
> *From:* Peter Baumann <p.baumann@jacobs-university.de
> <mailto:p.baumann@jacobs-university.de>>
> *Sent:* Friday, 29 May 2015 10:07:28 PM
> *To:* Frans Knibbe
> *Cc:* SDW WG Public List
> *Subject:* Re: UCR issue: phrasing of CRS requirement(s)
>  
> indeed, IMHO this is an excellent case showing how axis order is
> disambiguated. (There are reasons behind why OGC is doing it like this, but
> someone else should explain this).
>
> But the term "OGC registry" is well defined by way of URL. It is just that OGC
> maintains a single point for multiple CRS families. For example, EPSG does not
> want to deal with time, so OGC is adding this. And more families may come in
> future. And yes, OGC takes care that it is always in sync with EPSG.
>
> -Peter
>
> On 05/29/15 14:01, Frans Knibbe wrote:
>> Hello Peter,
>>
>> Your message made me realize that speaking of 'the OGC registry' could be
>> considered ambiguous. The OGC provides CRS descriptions according to EPSG
>> definitions and its own definitions. Take
>> http://www.opengis.net/def/crs/OGC/1.3/CRS84
>> <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
>> and http://www.opengis.net/def/crs/EPSG/0/4326. The first CRS definition
>> (that happens to be the default CRS in GeoSPARQL) is an OGC definition of
>> WGS84 where the axes have been switched with respect to the EPSG definition.
>> The latter is the EPSG definition (as one can tell by looking at how the URIs
>> are composed) of the WGS84 CRS. 
>>
>>
>> Regards,
>> Frans
>>
>>
>>
>> 2015-05-29 13:31 GMT+02:00 Peter Baumann <p.baumann@jacobs-university.de
>> <mailto:p.baumann@jacobs-university.de>>:
>>
>>     Hi again Frans,
>>
>>     On 05/29/15 13:10, Frans Knibbe wrote:
>>>     Hello Ed,
>>>
>>>     Yes, we could recommend using the EPSG descriptions in the BP. That is
>>>     future work.
>>
>>     could be done right now, through URIs. OGC maintains a resolver which is
>>     "URI conforming" (concretely, URLs):
>>     http://www.opengis.net/def/crs/EPSG/0/4326
>>     ...and it goes beyond EPSG. For example, (in agreement with EPSG) OGC is
>>     adding time support.
>>
>>>     But looking ahead to that, I think the EPSG registry has some issues:
>>>     CRS are not identified with a URI,
>>
>>     resolved by OGC
>>
>>>     it is hard to automatically process CRS data,
>>
>>     behind the links are XML descriptions, based on a well-known schema.
>>
>>>     and CRS do not have the same axis order.
>>
>>     this reflects reality. What's important is that the axis order is made
>>     explicit in these definitions, so a machine can understand coordinates
>>     expressed in such a CRS.
>>
>>>     I think CRS registries like those made available by the OGC and IGN
>>>     France are an improvement, at least in those respects.
>>
>>     I'd like to think so, but I am biassed :-)
>>
>>     Bottom line, using the OGC registry provides a low-hanging fruit.
>>
>>     -Peter
>>
>>
>>>
>>>     Do you agree with the proposed requirement?
>>>
>>>
>>>     Greetings,
>>>     Frans
>>>
>>>     2015-05-27 15:29 GMT+02:00 Ed Parsons <eparsons@google.com
>>>     <mailto:eparsons@google.com>>:
>>>
>>>         Describing CRS attributes is a "can of worms" for is, I would rather
>>>         we just point to the EPSG repository for simplicity. Perhaps we
>>>         could in the BP point out a few well used CRS and their EPSG
>>>         descriptions.
>>>
>>>         Ed
>>>
>>>         Ed Parsons
>>>         Geospatial Technologist, Google
>>>
>>>         Mobile: +44 (0)7825 382263 <tel:%2B44%20%280%297825%20382263>
>>>         www.edparsons.com <http://www.edparsons.com> @edparsons
>>>
>>>         On 27 May 2015 13:49, "Frans Knibbe" <frans.knibbe@geodan.nl
>>>         <mailto:frans.knibbe@geodan.nl>> wrote:
>>>
>>>             Hello all, 
>>>
>>>             It is nice to see a good discussion with lots of outside
>>>             references and proposals for meeting the requirements. But I
>>>             would like to get back to the issue of phrasing the requirements. 
>>>
>>>             Linda was right in noting that the requirement for a default or
>>>             canonical has not been listed in the UCR document yet. I will
>>>             add it. It will be very interesting to see if we can succeed in
>>>             finding such a CRS. But that is something that will become clear
>>>             when we work on the Best Practices.
>>>
>>>             As for the phrasing of the CRS requirement, I would like to
>>>             propose the following:
>>>
>>>             "There should be a standard for publishing data about coordinate
>>>             reference systems (CRS). It should be applicable to any 2D or 3D
>>>             CRS, not only geographical reference systems. CRS descriptions
>>>             should be referencable by HTTP URIs."
>>>
>>>             I think that given the context of this WG (spatial data on the
>>>             web), the requirement that things should be referencable goes
>>>             without saying, but I have made it explicit nonetheless. 
>>>
>>>             I should note that when put this way, there is no requirement
>>>             for having a registry of CRSs - anyone can publish a CRS
>>>             defintion anywhere. 
>>>
>>>             Would it be sensible to add some information about what kind of
>>>             data we would expect when a CRS is described? There could be a
>>>             need for having complete descriptions that allow automatic
>>>             coordinate transformation. Or we could try to list a few CRS
>>>             attributes that we consider essential for common usage (like
>>>             axis order, units, whether it is spherical or flat plane,
>>>             spatial coverage....)
>>>
>>>             Greetings,
>>>             Frans
>>>
>>>
>>>             2015-05-26 21:12 GMT+02:00 Krzysztof Janowicz <janowicz@ucsb.edu
>>>             <mailto:janowicz@ucsb.edu>>:
>>>
>>>                     Krzysztof, why is Java such a hot bed of linked data?!?
>>>
>>>
>>>                 Good question. If you look at the detailed map here
>>>                 http://stko.geog.ucsb.edu/pictures/lstd_map.png you will see
>>>                 massive data errors. Based on our 14+ million sample, it
>>>                 looks like about 10% of all linked geographic data has some
>>>                 issues related to it. In many cases those issues were
>>>                 systematic and we notified the data providers, e.g.,
>>>                 DBpedia. For instance, the dense block-like areas in China
>>>                 are in fact places from the US east coast. I will look into
>>>                 the data from Java and will let you know if I find something
>>>                 interesting.
>>>
>>>                 Anyway, the systematic list of errors may turn out to be
>>>                 useful for our sdw group as it illustrates what typically
>>>                 goes wrong.
>>>
>>>                 Best,
>>>                 Krzysztof
>>>
>>>
>>>
>>>
>>>                 On 05/18/2015 07:39 AM, Kerry.Taylor@csiro.au
>>>                 <mailto:Kerry.Taylor@csiro.au> wrote:
>>>
>>>                     WGS84 is certainly widely used for linked data in
>>>                     practice, probably  heavily influenced by this
>>>                     http://www.w3.org/2003/01/geo/, commonly called "geo".
>>>
>>>                     Oddly, perhaps, schema.org <http://schema.org> seems not
>>>                     to care about CRS at all: http://schema.org/GeoCoordinates
>>>
>>>                     Can we take inspiration from the former one  (geo)  and
>>>                     admit alternative CRSs that must be identified by virtue
>>>                     of the ontology (and therefore namespace, assuming a 1-1
>>>                     relationship) that is used?  We could perhaps develop a
>>>                     couple ourselves (perhaps a WGS84-like one, and another
>>>                     for a relative 3D system), and then allow any other to
>>>                     be used by virtue of reference to the intended
>>>                     vocabulary (as our best practice advice)?
>>>
>>>                     Maybe this is a cop-out but it is a way of dealing with
>>>                     the common cases blindly, yet requiring a CRS to be
>>>                     implicitly identified, and also enabling the use of more
>>>                     complex or niche CRS whenever needed. We won't stop
>>>                     people making mistakes, whatever we do.
>>>
>>>                     This could do for  *referencing* a  CRS without ever
>>>                     needing a "default". For the *description" of a CRS, I
>>>                     would vote to defer that to the OGC by its existing
>>>                     methods, and I see no reason why that description needs
>>>                     to have a linked data representation,  beyond an
>>>                     ontology that permits its use.
>>>
>>>
>>>
>>>
>>>                     Krzysztof, why is Java such a hot bed of linked data?!?
>>>
>>>                     Kerry
>>>
>>>
>>>                         -----Original Message-----
>>>                         From: Svensson, Lars [mailto:L.Svensson@dnb.de
>>>                         <mailto:L.Svensson@dnb.de>]
>>>                         Sent: Monday, 18 May 2015 9:44 PM
>>>                         To: Ed Parsons; janowicz@ucsb.edu
>>>                         <mailto:janowicz@ucsb.edu>
>>>                         Cc: SDW WG Public List
>>>                         Subject: RE: UCR issue: phrasing of CRS requirement(s)
>>>
>>>                         On Monday, May 18, 2015 12:24 PM, Ed Parsons wrote:
>>>
>>>                             In most cases I don't think they actually do
>>>                             mean WGS84 as in the
>>>                             ellipsoid and datum.
>>>
>>>                             I would guess it is usually shorthand for the
>>>                             the full spatial
>>>                             reference system defined by EPSG4326 or more
>>>                             likely on the web
>>>                             EPSG:3857
>>>
>>>                         My fear is that in some cases the data providers
>>>                         don't really know what
>>>                         their coordinates mean in terms of ellipsoid, datum
>>>                         and reference
>>>                         system. They have some coordinates taken from
>>>                         geonames, Wikipedia or
>>>                         some other source and haven’t really thought of that
>>>                         (geographic)
>>>                         coordinates are not just coordinates but that there
>>>                         is a context to
>>>                         that, too. To what extent we can assume that they
>>>                         mean CRS84, I don't
>>>                         know.
>>>
>>>                         So I think I'm on the same page as Linda on this.
>>>
>>>                         Best,
>>>
>>>                         Lars
>>>
>>>                             On 16 May 2015 at 04:02, Krzysztof Janowicz
>>>                             <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>>
>>>
>>>                         wrote:
>>>
>>>                             right, so how can they be sure they mean WGS84?
>>>
>>>                             Here is a funny example how this can go wrong
>>>                             and went wrong in the
>>>
>>>                         past:
>>>
>>>                             http://stko.geog.ucsb.edu/location_linked_data
>>>                             (See the Copernicus
>>>                             crater)
>>>
>>>                             Best,
>>>                             Krzysztof
>>>
>>>
>>>
>>>
>>>                             On 05/15/2015 04:27 AM, Peter Baumann wrote:
>>>                             right, so how can they be sure they mean WGS84?
>>>                             if I copy-past
>>>                             coordinates from web info about Germany then in
>>>                             the past this used to
>>>                             be Gauss-Krüger, and several strips =
>>>                             sub-systems. Now let's talk
>>>                             about height and SI vs imperial units etc - what
>>>                             default could we
>>>
>>>                         agree on?
>>>
>>>                             With a default, all coordinate info out there on
>>>                             the Web (flat,
>>>                             height/depth, time, pressure, ...) will often be
>>>                             interpreted wrongly.
>>>                             IMHO we should rather encourage, for m2m
>>>                             communication, that we
>>>                             achieve informational completeness.
>>>
>>>                             my 2 cents,
>>>                             Peter
>>>
>>>                             On 05/15/15 13:21, Linda van den Brink wrote:
>>>                             Hi all,
>>>
>>>                             OK, that could be the consensus within OGC, but
>>>                             the GeoJSON spec does
>>>                             describe a default CRS and I can understand this
>>>                             very well. Non-
>>>
>>>                         experts, i.e.
>>>
>>>                             people from outside the geospatial domain who
>>>                             are using or want to
>>>
>>>                         use
>>>
>>>                             geospatial data, often have no idea that there
>>>                             even *are* multiple
>>>                             coordinate reference systems.
>>>
>>>                             Linda
>>>
>>>                             Van: Peter Baumann
>>>                             [mailto:p.baumann@jacobs-university.de
>>>                             <mailto:p.baumann@jacobs-university.de>]
>>>                             Verzonden: vrijdag 15 mei 2015 13:01
>>>                             Aan: Linda van den Brink; Frans Knibbe; SDW WG
>>>                             (public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>)
>>>                             Onderwerp: Re: UCR issue: phrasing of CRS
>>>                             requirement(s)
>>>
>>>                             Hi all,
>>>
>>>                             FYI, there has been a vivid discussion in OGC on
>>>                             default CRSs on the
>>>                             occasion of JSON coming up with such an idea,
>>>                             and OGC very much and
>>>                             strongly agreed that this is not a good idea.
>>>
>>>                             In general, a coordinate tuple should have
>>>                             exactly one CRS referenced
>>>                             which may include
>>>                             - spatial horizontal (such as Lat/Long)
>>>                             - time (possibly using different calendars)
>>>                             - elevation
>>>                             - anything else (eg, atmospheric sciences like
>>>                             to use pressure as a
>>>                             proxy for
>>>                             height)
>>>                             - finally, planetary CRSs are more and more
>>>                             coming into play as well.
>>>                             I sense that this is very much in alignment with
>>>                             the ideas that we
>>>
>>>                         are
>>>
>>>                             discussing here.
>>>
>>>                             OTOH, it is indeed important to have one common
>>>                             mechanism of
>>>                             describing CRSs. As mentioned earlier, OGC has
>>>                             such mechanisms in
>>>                             place through CRS WKT plus the CRS Name Type
>>>                             Specification (maybe
>>>                             quite misleading in its title, it allows to
>>>                             describe CRSs by
>>>
>>>                         composing
>>>
>>>                             them from other ones, such as flatland
>>>                             + time, flatland + pressure, flatland + depth,
>>>                             flatland + geological
>>>
>>>                         time).
>>>
>>>                             So definitely supporting Linda's observation on
>>>                             referencing vs
>>>
>>>                         describing.
>>>
>>>                             -Peter
>>>
>>>                             On 05/15/15 09:40, Linda van den Brink wrote:
>>>                             Hi Frans,
>>>
>>>                             I noticed that a requirement related to this is
>>>                             in the spreadsheet
>>>
>>>                         but
>>>
>>>                             not (yet?) in the UCR document. It is this
>>>                             requirement:
>>>
>>>                             “There should be a default CRS that is assumed
>>>                             when nog CRS is
>>>
>>>                         specified”
>>>
>>>                             (s/nog/no)
>>>
>>>                             WGS84/lat lng is the de facto standard CRS for
>>>                             spatial data on the
>>>                             web. Both publishing and using spatial data on
>>>                             the web should be easy
>>>                             for non-experts, so this requirement of having a
>>>                             default CRS makes a
>>>                             lot of sense to me. The most common cases become
>>>                             more easy that way.
>>>
>>>                         I think this should be added to par.
>>>
>>>                             5.6 of the UCR.
>>>
>>>                             In this light (i.e. usability for non-expert
>>>                             users), the best
>>>
>>>                         practice
>>>
>>>                             should have information about how data owners
>>>                             should describe, how
>>>                             users can recognize and what tools they can use
>>>                             to transform non-
>>>
>>>                         WGS84
>>>
>>>                             coordinate systems to the coordinate system they
>>>                             need.
>>>
>>>                             A second point I’d like to make is that CRS
>>>                             should be suitable also
>>>                             for non- geographical reference systems (for
>>>                             non-Earth oriented
>>>                             applications).I think this is covered by 5.14,
>>>                             but the text of that
>>>                             paragraph is not completely clear to me.
>>>                             )“Standards for spatial data
>>>                             on the web should be independent on the
>>>                             reference systems that are
>>>                             used for data.”)
>>>
>>>                             Finally, to answer the question in the issue, as
>>>                             I read it, req A is
>>>                             not replaceable by req B. Req A is about
>>>                             *referencing* a CRS, while
>>>                             req B is about *describing* a CRS – i.e. the
>>>                             description you get
>>>
>>>                         about
>>>
>>>                             the CRS when you dereference  a CRS reference.
>>>
>>>                             Linda
>>>
>>>                             Van: Frans Knibbe [mailto:frans.knibbe@geodan.nl
>>>                             <mailto:frans.knibbe@geodan.nl>]
>>>                             Verzonden: woensdag 13 mei 2015 14:20
>>>                             Aan: SDW WG Public List
>>>                             Onderwerp: UCR issue: phrasing of CRS requirement(s)
>>>
>>>                             Hello all,
>>>
>>>                             I have raised an issue for the UCR document:
>>>                             ISSUE-10.
>>>                             All help in getting this issue resolved is very
>>>                             welcome.
>>>
>>>                             Regards,
>>>                             Frans
>>>
>>>
>>>                             --
>>>                             Frans Knibbe
>>>                             Geodan
>>>                             President Kennedylaan 1
>>>                             1079 MB Amsterdam (NL)
>>>
>>>                             T +31 (0)20 - 5711 347
>>>                             <tel:%2B31%20%280%2920%20-%205711%20347>
>>>                             E frans.knibbe@geodan.nl
>>>                             <mailto:frans.knibbe@geodan.nl>
>>>                             www.geodan.nl <http://www.geodan.nl>
>>>                             disclaimer
>>>
>>>
>>>                             --
>>>                             Dr. Peter Baumann
>>>                               - Professor of Computer Science, Jacobs
>>>                             University Bremen
>>>                                 www.faculty.jacobs-university.de/pbaumann
>>>                             <http://www.faculty.jacobs-university.de/pbaumann>
>>>                                 mail: p.baumann@jacobs-university.de
>>>                             <mailto:p.baumann@jacobs-university.de>
>>>                                 tel: +49-421-200-3178
>>>                             <tel:%2B49-421-200-3178>, fax:
>>>                             +49-421-200-493178 <tel:%2B49-421-200-493178>
>>>                               - Executive Director, rasdaman GmbH Bremen
>>>                             (HRB 26793)
>>>                                 www.rasdaman.com <http://www.rasdaman.com>,
>>>                             mail: baumann@rasdaman.com
>>>                             <mailto:baumann@rasdaman.com>
>>>                                 tel: 0800-rasdaman, fax: 0800-rasdafax,
>>>                             mobile: +49-173-5837882 <tel:%2B49-173-5837882>
>>>
>>>                         "Si
>>>
>>>                             forte in alienas manus oberraverit hec peregrina
>>>                             epistola incertis
>>>                             ventis dimissa, sed Deo commendata, precamur ut
>>>                             ei reddatur cui soli
>>>                             destinata, nec preripiat quisquam non sibi
>>>                             parata." (mail disclaimer,
>>>                             AD 1083)
>>>
>>>
>>>
>>>
>>>                             --
>>>                             Dr. Peter Baumann
>>>                               - Professor of Computer Science, Jacobs
>>>                             University Bremen
>>>                                 www.faculty.jacobs-university.de/pbaumann
>>>                             <http://www.faculty.jacobs-university.de/pbaumann>
>>>                                 mail: p.baumann@jacobs-university.de
>>>                             <mailto:p.baumann@jacobs-university.de>
>>>                                 tel: +49-421-200-3178
>>>                             <tel:%2B49-421-200-3178>, fax:
>>>                             +49-421-200-493178 <tel:%2B49-421-200-493178>
>>>                               - Executive Director, rasdaman GmbH Bremen
>>>                             (HRB 26793)
>>>                                 www.rasdaman.com <http://www.rasdaman.com>,
>>>                             mail: baumann@rasdaman.com
>>>                             <mailto:baumann@rasdaman.com>
>>>                                 tel: 0800-rasdaman, fax: 0800-rasdafax,
>>>                             mobile: +49-173-5837882 <tel:%2B49-173-5837882>
>>>
>>>                         "Si
>>>
>>>                             forte in alienas manus oberraverit hec peregrina
>>>                             epistola incertis
>>>                             ventis dimissa, sed Deo commendata, precamur ut
>>>                             ei reddatur cui soli
>>>                             destinata, nec preripiat quisquam non sibi
>>>                             parata." (mail disclaimer,
>>>                             AD 1083)
>>>
>>>
>>>
>>>                             --
>>>                             Krzysztof Janowicz
>>>
>>>                             Geography Department, University of California,
>>>                             Santa Barbara
>>>                             4830 Ellison Hall, Santa Barbara, CA 93106-4060
>>>
>>>                             Email: jano@geog.ucsb.edu
>>>                             <mailto:jano@geog.ucsb.edu>
>>>                             Webpage: http://geog.ucsb.edu/~jano/
>>>                             <http://geog.ucsb.edu/%7Ejano/>
>>>                             Semantic Web Journal:
>>>                             http://www.semantic-web-journal.net
>>>
>>>
>>>
>>>                 -- 
>>>                 Krzysztof Janowicz
>>>
>>>                 Geography Department, University of California, Santa Barbara
>>>                 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>>>
>>>                 Email: jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
>>>                 Webpage: http://geog.ucsb.edu/~jano/
>>>                 <http://geog.ucsb.edu/%7Ejano/>
>>>                 Semantic Web Journal: http://www.semantic-web-journal.net
>>>
>>>
>>>
>>>
>>>
>>>             -- 
>>>             Frans Knibbe
>>>             Geodan
>>>             President Kennedylaan 1
>>>             1079 MB Amsterdam (NL)
>>>
>>>             T +31 (0)20 - 5711 347 <tel:%2B31%20%280%2920%20-%205711%20347>
>>>             E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
>>>             www.geodan.nl <http://www.geodan.nl>
>>>             disclaimer <http://www.geodan.nl/disclaimer>
>>>
>>>
>>>
>>>
>>>     -- 
>>>     Frans Knibbe
>>>     Geodan
>>>     President Kennedylaan 1
>>>     1079 MB Amsterdam (NL)
>>>
>>>     T +31 (0)20 - 5711 347 <tel:%2B31%20%280%2920%20-%205711%20347>
>>>     E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
>>>     www.geodan.nl <http://www.geodan.nl>
>>>     disclaimer <http://www.geodan.nl/disclaimer>
>>>
>>
>>     -- 
>>     Dr. Peter Baumann
>>      - Professor of Computer Science, Jacobs University Bremen
>>        www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>        mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>        tel: +49-421-200-3178 <tel:%2B49-421-200-3178>, fax: +49-421-200-493178 <tel:%2B49-421-200-493178>
>>      - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>        www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>        tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 <tel:%2B49-173-5837882>
>>     "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>
>>
>>
>>
>>
>> -- 
>> Frans Knibbe
>> Geodan
>> President Kennedylaan 1
>> 1079 MB Amsterdam (NL)
>>
>> T +31 (0)20 - 5711 347
>> E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
>> www.geodan.nl <http://www.geodan.nl>
>> disclaimer <http://www.geodan.nl/disclaimer>
>>
>
> -- 
> Dr. Peter Baumann
>  - Professor of Computer Science, Jacobs University Bremen
>    www.faculty.jacobs-university.de/pbaumann
>    mail: p.baumann@jacobs-university.de
>    tel: +49-421-200-3178, fax: +49-421-200-493178
>  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>    www.rasdaman.com, mail: baumann@rasdaman.com
>    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>
>

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann@jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann@rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
Received on Monday, 1 June 2015 12:01:17 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:16 UTC